前端人机协作五道防火墙：结构、逻辑、测试、构建与责任边界

1. 为什么“一口气写完整个前端”是危险的幻觉Codex 这类代码生成模型最近两年在前端圈子里确实火得有点过头。我见过太多人把一个 Vue 页面需求丢进去期待它吐出带路由、状态管理、组件拆分、单元测试、Vite 构建配置、甚至 CI/CD 脚本的完整项目——结果要么是满屏TODO和// FIXME要么是逻辑错乱的v-if嵌套三层还漏了v-else更常见的是测试用例里expect(wrapper.vm.count).toBe(1)写成了expect(wrapper.vm.count).toBe(0)而你根本没意识到它在测什么。这不是模型不行而是任务边界被彻底模糊了。前端开发从来就不是“写代码”这一个动作它是一组高度耦合又必须解耦的技能组合页面结构是视觉层的契约逻辑是数据流的编排测试是质量边界的刻度构建是交付链路的闸门。Codex 擅长的是“单点高密度补全”比如根据setup()函数签名补全ref和computed的声明或者根据describe(user login)自动生成it(should show error when password is empty)的骨架——但它无法替代你对“这个按钮点击后数据从哪里来、经过哪些校验、触发哪些副作用、最终如何反馈给用户”的全链路判断。我去年带过一个实习生他直接让 Codex 生成了一个电商商品页包括购物车加减、库存校验、价格计算、防抖提交。跑起来第一眼看着没问题但一测就崩库存校验逻辑写在mounted里没做异步等待价格计算用了parseInt却没处理小数点防抖函数传参漏了this绑定。问题不在 Codex而在他把“生成代码”当成了“完成开发”。真正的前端 Skills不是让 AI 写得更多而是让你能精准定义此刻我需要 Codex 解决哪个子问题它的输出是否符合我设定的契约我该用什么手段验证它没越界所以标题里说的“5 组 Skills”本质是五道防火墙页面结构墙挡住 UI 层的随意性逻辑编排墙守住数据流的确定性测试验证墙划清质量责任的边界构建部署墙确保交付物的可重复性最后是人机协作墙——明确哪些事必须由人拍板哪些事可以放心交给 AI 补全。这五组 Skills 不是并列关系而是层层嵌套的依赖链没有清晰的页面结构约定逻辑就无处安放没有可靠的测试验证构建产物就是定时炸弹。你不需要记住所有 Vue API但必须清楚v-model的底层是:valueinput的语法糖否则 Codex 生成的自定义组件双向绑定会悄悄失效你不必手写 Webpack 配置但得明白resolve.alias是如何影响模块查找路径的否则 Codex 添加的/components别名可能在 SSR 环境下完全不生效。这些不是八股文而是你在和 Codex 协作时手里握着的那把尺子——用来量它的输出而不是让它来量你的认知边界。2. 页面结构 Skills用契约思维代替“画图式”开发很多人把页面结构等同于“切图”或“写 HTML”这是前端最根深蒂固的认知误区。真正的页面结构 Skills核心是建立三重契约组件契约、数据契约、交互契约。Codex 可以帮你快速产出template但只有你能定义这三重契约的边界。2.1 组件契约不是“能用就行”而是“接口即文档”我见过 Codex 生成的组件props类型写成anyemits列表空着slots定义全靠注释。这种组件在团队协作中就是一颗雷。正确的组件契约必须像 API 文档一样精确!-- GoodComponent.vue -- script setup // ✅ 明确 props 类型与默认值 const props defineProps({ // 用户头像 URL必填 avatar: { type: String, required: true }, // 显示状态可选默认为 online status: { type: String, default: online, validator: (v) [online, offline, away].includes(v) } }) // ✅ 明确 emits 事件及 payload 结构 const emit defineEmits([click, status-change]) // ✅ 明确 slots 使用场景 defineSlots{ default: (props: {}) any badge: (props: { count: number }) any }() /scriptCodex 在生成组件时往往只补全props声明却忽略validator和default的业务含义。比如status默认值设为online是因为产品需求规定新用户首次进入必须显示在线状态而不是技术上随便选个字符串。这个决策必须由人做出Codex 只负责把validator函数写出来。提示当你让 Codex 生成组件时指令必须包含具体约束。不要说“写一个用户卡片组件”而要说“写一个 Vue3 组合式 API 组件接收 avatar必填字符串、status可选取值为 online/offline/away默认 online触发 click 和 status-change 事件支持 default 和 badge 插槽badge 插槽需接收 count 参数。”2.2 数据契约结构即逻辑格式即协议页面结构的骨架本质是数据结构的可视化映射。Codex 很容易生成一个userList: []的响应式数组但不会告诉你这个数组里的每个对象是否必须包含id字段用于v-for的keyavatar字段是绝对 URL 还是相对路径status字段的值域是否和组件props.status的validator严格一致我在重构一个老项目时发现Codex 生成的列表组件里v-foritem in userList直接用了item.id作为key但后端返回的数据里id字段是null——因为新接口还没上线旧数据还在用userId字段。结果页面渲染报错而错误堆栈指向的是v-for指令根本看不出是数据契约断裂。解决方法是在数据层就建立强契约// types/user.ts export interface UserItem { id: string // ✅ 必须存在且类型为 string name: string avatar: string // ✅ 必须为非空字符串协议要求为 CDN URL status: online | offline | away // ✅ 与组件 props.validator 严格一致 } // api/user.ts export const fetchUserList (): PromiseUserItem[] { return axios.get(/api/users).then(res { // ✅ 强制类型转换暴露数据契约断裂点 return res.data.map((item: any) ({ id: item.id || item.userId, // ✅ 兼容旧字段 name: item.name || 未知用户, avatar: item.avatar || /default-avatar.png, status: [online, offline, away].includes(item.status) ? item.status : offline })) }) }Codex 可以帮你写fetchUserList函数但UserItem接口定义、字段兼容逻辑、默认值兜底策略这些都必须由你基于业务规则拍板。把契约写死在类型定义里比写一百行注释都管用。2.3 交互契约状态机思维取代“if-else 堆砌”页面上的按钮、弹窗、加载态不是孤立的 UI 元素而是状态机的节点。Codex 生成的交互逻辑常常是线性的if-else堆砌比如// Bad: Codex 生成的典型交互逻辑 if (loading) { showLoading() } else if (error) { showError() } else { showContent() }这种写法的问题在于它隐含了“loading、error、content 互斥”的假设但现实中的状态远比这复杂。比如“加载中有缓存数据”该显示什么“提交失败网络恢复”该如何自动重试Codex 不会主动考虑这些分支。正确的做法是用状态机思维定义交互契约// state-machine.ts type UserState | { status: idle } // 初始态 | { status: loading; cache?: UserItem[] } // 加载中可携带缓存 | { status: success; data: UserItem[] } // 成功数据必存在 | { status: error; message: string; retry: () void } // 错误含重试方法 | { status: submitting } // 提交中独立于列表状态 // 组件内使用 const state refUserState({ status: idle }) const loadUsers async () { state.value { status: loading, cache: cachedUsers } try { const data await fetchUserList() state.value { status: success, data } } catch (e) { state.value { status: error, message: e.message, retry: loadUsers } } }Codex 可以帮你补全loadUsers函数体但UserState的联合类型定义、各状态的字段约束、retry方法的注入方式这些都必须由你设计。状态机不是增加复杂度而是把隐含的业务规则显性化——当 Codex 生成的代码偏离这个状态机时你一眼就能看出它越界了。3. 逻辑编排 Skills让数据流在可控轨道上运行前端逻辑的核心从来不是“怎么写代码”而是“数据从哪来、到哪去、怎么变”。Codex 擅长补全单个函数但极易破坏数据流的完整性。真正的逻辑编排 Skills在于建立四层防护来源层隔离、变换层契约、消费层约束、副作用层管控。3.1 来源层隔离API、本地存储、URL 参数必须物理分离Codex 生成的代码经常把不同来源的数据混在一起操作。比如一个搜索页searchTerm可能来自 URL 查询参数、搜索框输入、历史记录缓存但 Codex 生成的逻辑里它们全被塞进同一个ref里// Bad: 混淆来源无法追溯变更源头 const searchTerm ref() // 从 URL 获取 onMounted(() { searchTerm.value route.query.q || }) // 从输入框获取 const onInput (val: string) { searchTerm.value val } // 从缓存获取 const loadFromCache () { searchTerm.value localStorage.getItem(lastSearch) || }问题在于当searchTerm变化时你根本不知道是哪个来源触发的也无法针对性地做防抖、节流或持久化。正确的做法是物理隔离// sources/search-term.ts export const searchTermSources { // ✅ URL 来源只读初始化时同步 fromUrl: computed(() route.query.q || ), // ✅ 输入框来源可写带防抖 fromInput: ref(), // ✅ 缓存来源可写带持久化 fromCache: ref(localStorage.getItem(lastSearch) || ) } // logic/search.ts export const useSearchLogic () { const currentTerm ref() // ✅ 明确指定各来源的同步策略 watch(searchTermSources.fromUrl, val { currentTerm.value val }, { immediate: true }) watch(searchTermSources.fromInput, val { currentTerm.value val // ✅ 输入框变更立即触发防抖搜索 debouncedSearch(val) }) watch(searchTermSources.fromCache, val { // ✅ 缓存变更仅用于初始化不触发搜索 if (!currentTerm.value) { currentTerm.value val } }) return { currentTerm } }Codex 可以帮你写debouncedSearch函数但searchTermSources的分离设计、各watch的触发条件、immediate的使用时机这些都必须由你决策。来源隔离不是为了炫技而是为了让 Codex 的补全行为始终在一个可控的、可预测的上下文中发生。3.2 变换层契约纯函数 类型守卫拒绝“魔法转换”Codex 经常生成这样的数据变换逻辑// Bad: 魔法转换类型丢失副作用隐藏 const formatUser (raw: any) { return { id: raw.id, name: raw.name.toUpperCase(), avatar: raw.avatar || /default.png, lastLogin: new Date(raw.last_login_at).toLocaleString() } }问题在于raw类型是anylast_login_at字段名是硬编码toLocaleString()的格式依赖浏览器 localetoUpperCase()对中文无效。这种函数就像黑盒输入输出都无法验证。正确的方式是用纯函数 类型守卫// types/api.ts export interface RawUser { id: string name: string avatar?: string last_login_at?: string // ✅ 明确可选 } // utils/user-transform.ts export const transformRawUser (raw: RawUser): UserItem { // ✅ 类型守卫确保输入符合预期 if (!raw.id || typeof raw.id ! string) { throw new Error(Invalid user id: ${raw.id}) } return { id: raw.id, name: raw.name.trim() || 未知用户, // ✅ 安全处理 avatar: raw.avatar || /default-avatar.png, // ✅ 标准化时间处理避免浏览器差异 lastLogin: raw.last_login_at ? new Date(raw.last_login_at).toISOString().split(T)[0] : 未知 } } // ✅ 纯函数无副作用输入相同则输出相同Codex 可以帮你补全transformRawUser的函数体但RawUser接口定义、throw的错误类型、toISOString()的标准化选择这些都必须由你基于数据协议决定。变换层契约的本质是把“数据怎么变”变成一份可测试、可审查、可追溯的合同。3.3 消费层约束模板层只做展示禁止逻辑侵入Codex 生成的模板经常把业务逻辑塞进v-if或:class里!-- Bad: 模板层侵入逻辑 -- div :class[user-card, user.status online ? online : offline] span v-ifuser.lastLogin new Date(user.lastLogin) new Date(Date.now() - 86400000) 今日活跃 /span /div这种写法的问题是逻辑分散、难以复用、无法测试。new Date()创建实例、时间比较、字符串拼接全在模板里Codex 生成时根本不会考虑性能每次渲染都创建新 Date 实例和可维护性。正确的方式是把逻辑提取到计算属性或组合式函数script setup import { computed } from vue import { isTodayActive } from /utils/date const props defineProps{ user: UserItem }() // ✅ 计算属性封装逻辑模板只做展示 const isUserActiveToday computed(() isTodayActive(props.user.lastLogin) ) const userStatusClass computed(() props.user.status online ? online : offline ) /script template div :class[user-card, userStatusClass] span v-ifisUserActiveToday今日活跃/span /div /template// utils/date.ts export const isTodayActive (lastLogin: string): boolean { if (!lastLogin) return false const loginDate new Date(lastLogin) const todayStart new Date() todayStart.setHours(0, 0, 0, 0) return loginDate todayStart }Codex 可以帮你写isTodayActive函数但computed的使用、lastLogin字段的空值判断、todayStart的精确计算方式这些都必须由你设计。消费层约束的核心思想是模板是数据的投影仪不是逻辑的处理器。把逻辑赶出模板Codex 生成的template才真正安全。3.4 副作用层管控副作用必须可追踪、可撤销、可测试前端副作用API 调用、localStorage 操作、路由跳转是 Codex 最容易失控的领域。它可能生成一个onClick处理函数里面同时调用 API、更新本地状态、跳转路由、发送埋点而你根本不知道它做了什么。正确的副作用管控遵循三个原则可追踪所有副作用必须有明确的入口点不能散落在watch、computed或模板事件中。可撤销异步操作必须支持取消如 AbortController避免竞态请求。可测试副作用函数必须能被单独 mock 和验证。// composable/use-user-action.ts import { ref, Ref } from vue import { updateUserProfile } from /api/user export const useUpdateUserProfile () { const loading ref(false) const error refstring | null(null) // ✅ 副作用集中入口返回值明确 const execute async (userId: string, data: PartialUserItem) { loading.value true error.value null try { // ✅ 支持 AbortController可撤销 const controller new AbortController() const timeoutId setTimeout(() controller.abort(), 10000) const result await updateUserProfile(userId, data, { signal: controller.signal }) clearTimeout(timeoutId) return result } catch (e) { clearTimeout(timeoutId) error.value e instanceof Error ? e.message : 更新失败 throw e } finally { loading.value false } } return { loading, error, execute } } // 组件中使用 const { loading, error, execute } useUpdateUserProfile() const handleSubmit async () { try { await execute(props.userId, formData.value) // ✅ 副作用执行后再做 UI 反馈 showSuccessToast() } catch (e) { // ✅ 错误已由 execute 统一处理这里只做 UI 层反馈 } }Codex 可以帮你补全updateUserProfile的 API 调用但AbortController的集成、timeoutId的清理、loading/error状态的管理这些都必须由你设计。副作用层管控不是为了限制 Codex而是为了给它划定一个安全的“作业区”。4. 测试验证 Skills用测试定义 Codex 的能力边界测试不是 Codex 的终点而是它的起点。很多团队让 Codex 生成代码后才补测试结果测试用例全是it(should work, () {})这种废话。真正的测试验证 Skills在于用测试先行的方式把 Codex 的输出约束在可验证的范围内。4.1 单元测试测试即契约用例即文档Codex 生成的组件往往缺乏可测试性。比如一个SearchInput组件Codex 可能这样写!-- SearchInput.vue -- template input v-modellocalValue keyup.enteronSearch / /template script setup const localValue ref() const emit defineEmits([search]) const onSearch () emit(search, localValue.value) /script这个组件的问题是localValue是内部状态外部无法控制onSearch逻辑和v-model绑定耦合无法单独测试。测试时只能模拟 DOM 事件脆弱且慢。正确的做法是先写测试再让 Codex 实现// tests/unit/components/SearchInput.spec.ts import { mount } from vue/test-utils import SearchInput from /components/SearchInput.vue describe(SearchInput, () { it(emits search with input value when enter key is pressed, async () { const wrapper mount(SearchInput) // ✅ 测试契约输入值 - 按回车 - 触发 search 事件 await wrapper.find(input).setValue(vue) await wrapper.find(input).trigger(keydown.enter) expect(wrapper.emitted(search)).toHaveLength(1) expect(wrapper.emitted(search)![0]).toEqual([vue]) }) it(accepts initial value via prop, async () { const wrapper mount(SearchInput, { props: { modelValue: react } }) // ✅ 测试契约prop 控制初始值 expect(wrapper.find(input).element.value).toBe(react) }) })有了这个测试你就可以明确指令 Codex“实现一个 Vue3 组件接收modelValueprop支持v-model在keydown.enter时触发search事件事件 payload 为当前输入值。” Codex 生成的代码必须通过这个测试才算合格。测试即契约用例即文档——它定义了 Codex 的能力边界也定义了你的验收标准。4.2 集成测试验证跨组件协作而非单点功能Codex 擅长单个组件但前端真正的难点在于组件协作。比如一个UserList组件它依赖UserItem组件、SearchInput组件、Pagination组件。Codex 可以分别生成它们但无法保证它们能协同工作。集成测试的目标就是验证这种协作// tests/integration/UserList.spec.ts import { mount } from vue/test-utils import UserList from /components/UserList.vue import { createTestingPinia } from pinia/testing describe(UserList Integration, () { it(displays users from store and updates on search, async () { const wrapper mount(UserList, { global: { plugins: [createTestingPinia({ createSpy: vi.fn })] } }) // ✅ 模拟 store 数据 const store useUserStore() store.users [ { id: 1, name: Alice, status: online }, { id: 2, name: Bob, status: offline } ] // ✅ 验证初始渲染 expect(wrapper.findAll(.user-item)).toHaveLength(2) // ✅ 模拟搜索交互 await wrapper.findComponent(SearchInput).vm.$emit(search, Alice) // ✅ 验证搜索后只显示匹配项 expect(wrapper.findAll(.user-item)).toHaveLength(1) expect(wrapper.find(.user-item).text()).toContain(Alice) }) })这个测试的关键在于它不关心UserList内部怎么实现只关心“当 store 有数据、用户触发搜索时UI 是否按预期变化”。Codex 生成的UserList只要满足这个契约就可通过测试。集成测试把 Codex 从“写代码”解放出来聚焦于“满足契约”。4.3 E2E 测试用真实用户旅程检验交付价值单元测试和集成测试都是开发者视角而 E2E 测试是用户视角。Codex 无法理解“用户旅程”但你可以用 E2E 测试把它框住。我们团队有个经典案例Codex 生成了一个登录页表单验证逻辑完美单元测试全部通过。但 E2E 测试发现用户输入错误密码后错误提示出现位置偏移且动画卡顿——因为 Codex 生成的 CSS 里.error-message使用了position: absolute但父容器没有position: relative。E2E 测试脚本// tests/e2e/login.spec.ts import { test, expect } from playwright/test test(login with invalid credentials shows error message, async ({ page }) { await page.goto(/login) await page.fill(#username, testuser) await page.fill(#password, wrongpass) await page.click(#login-btn) // ✅ 验证错误消息可见且位置正确 const errorMessage page.locator(.error-message) await expect(errorMessage).toBeVisible() await expect(errorMessage).toHaveText(用户名或密码错误) // ✅ 验证错误消息在表单下方而非页面顶部 const formRect await page.locator(form).boundingBox() const errorRect await errorMessage.boundingBox() expect(errorRect!.y).toBeGreaterThan(formRect!.y formRect!.height) })这个测试不验证“密码校验逻辑是否正确”而是验证“用户看到的错误提示是否符合预期”。Codex 可以生成完美的校验函数但无法保证 UI 布局符合用户心智模型。E2E 测试是最后一道防线它确保 Codex 的输出最终交付的是用户价值而不是技术正确性。5. 构建部署 Skills让每一次交付都可追溯、可重现构建不是“打包上线”这么简单。Codex 可能生成一个vite.config.ts里面写着build: { minify: terser }但它不会告诉你terser压缩可能导致某些 IE 兼容性问题minify: true会关闭 source map让线上错误无法定位rollupOptions.external如果漏配会导致第三方库被打包两次。构建部署 Skills 的核心是建立三重保障环境隔离保障、依赖锁定保障、产物验证保障。5.1 环境隔离保障用.env文件族杜绝“在我机器上能跑”Codex 生成的代码经常把 API 地址、密钥、功能开关硬编码在源码里// Bad: 硬编码无法切换环境 const API_BASE_URL https://dev.api.example.com const FEATURE_FLAG true这导致开发、测试、生产环境共用同一份代码风险极高。正确的环境隔离必须物理分离.env # 所有环境共享默认值 .env.local # 本地开发gitignore .env.development # 开发环境 .env.production # 生产环境 .env.staging # 预发环境每个文件内容# .env.development VUE_APP_API_BASE_URLhttps://dev.api.example.com VUE_APP_FEATURE_FLAGtrue VUE_APP_SENTRY_DSNhttps://xxxo123.ingest.sentry.io/123# .env.production VUE_APP_API_BASE_URLhttps://api.example.com VUE_APP_FEATURE_FLAGfalse VUE_APP_SENTRY_DSNhttps://yyyo123.ingest.sentry.io/456Vite 会自动加载对应环境的.env文件并将VUE_APP_前缀的变量注入import.meta.env。Codex 可以帮你写fetchUser()函数但.env文件的结构、变量命名规范、VUE_APP_前缀的强制使用这些都必须由你设计。环境隔离保障的不是技术而是责任——谁改了生产配置谁就得为线上事故负责。5.2 依赖锁定保障package-lock.json不是垃圾是交付契约很多团队把package-lock.json当成冗余文件甚至 gitignore 它。这是构建灾难的根源。Codex 生成的package.json里vue: ^3.4.0这样的版本范围意味着下次npm install可能装3.4.25而3.4.25可能引入一个破坏性变更。package-lock.json的作用就是把“本次构建所用的确切依赖树”固化下来。它不是锁死所有依赖而是锁死本次成功构建所用的版本组合。关键实践永远提交package-lock.json它是构建可重现的唯一凭证。CI/CD 中强制使用npm ci它只安装package-lock.json中的精确版本不生成新 lock 文件。定期npm outdated 手动升级升级不是npm update而是npm install vuelatest后运行所有测试确认无回归再提交新的package-lock.json。Codex 可以帮你写package.json的依赖列表但package-lock.json的生成、提交、验证流程这些都必须由你建立。依赖锁定保障的不是代码而是信任——你承诺交付的产物和你本地测试的产物必须 100% 一致。5.3 产物验证保障用自动化检查守住交付质量底线构建产物不是“打包完就完事”。Codex 生成的代码可能无意中引入大体积依赖、未使用的 polyfill、或不安全的eval调用。产物验证保障就是用自动化工具在交付前做最后一道扫描。我们团队的标准检查清单检查项工具阈值说明包体积分析rollup-plugin-visualizerdist/assets/*.js 100KB防止意外引入大库未使用代码unplugin-unused-components0 个未使用组件清理废弃代码安全漏洞npm audit0 个 high/critical 漏洞阻断已知风险Lighthouse 性能lighthouse-ciPerformance ≥ 90保障基础体验CI/CD 流程中构建后必须运行这些检查# .github/workflows/build.yml - name: Build and analyze run: | npm run build npx rollup-plugin-visualizer --open npx unplugin-unused-components --check npm audit --audit-levelhigh - name: Lighthouse CI uses: treosh/lighthouse-ci-actionv9 with: urls: https://staging.example.com uploadArtifacts: true temporaryPublicStorage: true thresholds: {performance: 90}Codex 可以帮你写vite.config.ts但rollup-plugin-visualizer的集成、npm audit的阈值设定、Lighthouse 的评分标准这些都必须由你定义。产物验证保障的不是技术指标而是用户承诺——你交付的是一个性能达标、安全可靠、体积合理的应用。6. 人机协作 Skills明确“人”与“AI”的责任边界前面五组 Skills最终都指向一个核心人机协作 Skills。这不是技术问题而是认知问题。Codex 不是替代开发者而是放大开发者的决策能力。真正的 Skill在于清晰划分“人该做什么”和“AI 该做什么”。6.1 人的责任定义、决策、验证、兜底定义定义需求边界、数据契约、状态机、测试用例。Codex 是执行者不是定义者。决策选择技术栈、架构模式、错误处理策略、降级方案。Codex 可以列出选项但拍板必须由人。验证运行测试、审查代码、检查构建产物、监控线上表现。Codex 无法感知业务价值。兜底当 Codex 输出偏离预期时快速识别、定位、修复。这需要深厚的一线经验。我见过最典型的失败案例一个团队让 Codex 生成整个权限系统包括 RBAC 模型、路由守卫、按钮级权限控制。Codex 输出了漂亮的代码但没人检查canAccessRoute函数里user.roles数组是否为空时的默认行为——结果所有用户都能访问管理员路由。人的责任就是在 Codex 生成后问一句“如果user.roles是空数组这段代码会返回什么”6.2 AI 的责任补全、生成、翻译、加速补全根据已有上下文补全函数体、类型定义、配置项。这是 Codex 最擅长的。生成基于明确指令生成样板代码、测试骨架、文档片段。指令越精确输出越可靠。翻译将设计稿转为 HTML/CSS、将需求文档转为接口定义、将英文文档转为中文注释。加速自动 import 缺失依赖、格式化代码、生成 commit message、修复 ESLint 错误。Codex 的价值不在于它写了多少行代码而在于它把开发者从机械劳动中解放出来去专注那些只有人能做的理解业务、权衡利弊、承担后果。6.3 协作协议建立团队级的 Codex 使用守则最后把 Skills 落地为团队规范。我们团队的 Codex 协作协议禁止直接 commit Codex 输出所有 Codex 生成的代码必须经过git diff审查标注#ai-generated注释。强制配套测试任何 Codex 生成的业务逻辑必须同步生成对应测试用例否则 PR 不通过。文档同步更新Codex 修改了 API 响应结构必须同步更新 OpenAPI spec 和接口文档。每周复盘团队每周回顾 Codex 使用记录统计“哪些指令效果好”、“哪些场景容易出错”持续优化协作模式。这套协议不是限制创新而是建立信任。当每个人都知道 Codex 的输出会被怎样审查、怎样验证、怎样兜底时大家才敢真正用起来而不是把它当成一个不敢碰的“黑箱”。我在实际项目中踩过的最大坑不是 Codex 写错了代码而是团队默认“AI 生成的代码天然可信”。直到一次线上事故才发现 Cod