先说一个我踩过的坑。上个月我让 Codex “把这个电商活动页前端全部实现”它一口气生成了 40 多个文件组件、状态、请求、样式全都有看目录结构感觉已经完工了。结果一跑起来问题全来了样式类名冲突、接口字段对不上、构建阶段直接报错更麻烦的是 40 多个文件我根本没法一条条审最终只能花两天时间返工比自己写还慢。那次之后我彻底改思路——不让 Codex 一口气写完整个前端而是把任务拆成多组 Skills一次只让它干一类事。这篇文章我就详细说说我整理的 5 组 Skills 怎么拆、怎么用以及背后能解决哪些实际问题。这套方法适合正在用 Codex 或者同类 AI Agent 做前端开发的工程师尤其是被“AI 生成的代码不敢改、不敢上线”折磨过的同学。它的核心价值不是提升生成速度而是让 AI 的产出变得可审查、可测试、可构建、可回滚一句话——把你从“代码大海捞针”的状态里捞出来。1. 为什么不能一口气写完整个前端AI 生成代码的失控曲线很多人刚上手 Codex 的时候心态都是“它能写那让它全写”。但实践几轮之后你会意识到Codex 是一个聪明的执行者不是一个可靠的架构师。让它接管整个前端工程本质上是在赌它的上下文窗口永远够用赌它对需求的理解永远不出偏差但现实往往会教做人。1.1 上下文窗口和工程规模的矛盾Codex 这类 Agent 的上下文容量有限这一点是物理约束不是 prompt 技巧能完全绕开的。一个中型前端项目至少有三五十个文件组件、hooks、store、API 层、路由、配置文件。当 Codex 一次处理这么多内容时它只能记住前面的一部分后边的生成就会慢慢“失忆”然后开始自由发挥。我实际遇到过的典型情况是同一个组件被重复生成两遍第二遍还改了名字props 的定义前后不一致工具函数在不同文件里被各自实现了一份。这些问题的根源就是上下文被塞爆AI 已经无法维持全局一致性。对比来看当任务被压缩到 2 到 5 个文件时Codex 的表现会稳定很多。它能在有限上下文里保持住关键约定生成的代码也更接近一个熟悉项目的协作开发者的水平。1.2 错误传播会像滚雪球一样放大更隐蔽的问题是错误传播。第一次生成时如果对数据结构的定义就有问题后面的逻辑层、测试层甚至构建配置都会基于这个错误假设继续展开。比如我遇到过一次页面层把用户 ID 字段命名成了 userId逻辑层在后面把它当成 id 用测试又照着逻辑层的写法写。最后修第一个错误的时候牵一发动全身三个层都要跟着改。这就像盖楼的时候地基歪了越往上盖越危险。AI 单次生成的内容越多它基于错误假设继续发挥的空间就越大返工成本也就越高。工程上一直强调小步提交、持续集成本质就是把风险控制在单一变量内。AI 编码也一样每轮只做一件事返工范围就是可控的。1.3 拆分给的真正好处可验收的完成定义拆分的意义不只是降低错误率更重要的是给每个子任务一个“可验收的完成定义”。当 Codex 一口气写完整个前端你很难判断它“写完了”到底是什么标准。但如果你让它只负责页面骨架那完成标准就是组件树完整、样式符合设计 token、没有未实现的待办区块让它只负责交互逻辑完成标准就是所有用户操作都有对应的状态变更接口调用能跑通错误分支有处理。这种完成定义让 AI 的输出可以被自动检查。lint、tsc、单测、构建命令每一项都能验证它是否真的做完了。人只需要在小范围内做 review判断它做得对不对而不是从一团乱麻里挑毛病。2. 五组 Skills 全景页面、逻辑、测试、构建、审查各司其职接下来就是重头戏我实际在用的这 5 组 Skills。它们的命名基本按照前端交付物的天然层面来划分不是拍脑袋定的而是从 CI/CD 流程反推出来的视觉层、行为层、正确性验证、可发布性、质量门禁缺一不可。2.1 为什么是这五组而不是更多或更少页面、逻辑、测试、构建是前端的四大基本交付物这个比较好理解。我额外加了一组 review-police是因为没有质量门禁的 AI 协作流程到最后还是得靠人肉一遍遍扫代码。AI 生成的代码特别容易出现“能用但没完全用对”的情况比如引入了一个没用的依赖、忽略了一个类型报错、测试只写了 happy path。你想要把这些风险挡在合入之前就需要有一个明确的检查 Skill 来收口。五组这个数量也经过验证。少于五组职责边界太粗AI 还是会混着做多于五组协作成本反而变高每轮切换和上下文注入都会变得很繁琐。对大多数前端项目来说五组是一个比较舒服的粒度。2.2 各组职责边界速查表这 5 组 Skills 的职责边界我整理成了一张表写 Skills 的时候直接照着分Skill 名称核心职责典型输出明确不做page-builder页面结构、组件拆分、JSX、样式、响应式TSX 组件文件、CSS/样式文件不实现数据请求不写业务状态logic-implementor数据流、hooks、API 接口调用、业务规则hooks、stores、service 层代码不修改组件结构不动视觉样式test-runner单测、组件测试、核心路径覆盖、mock测试文件、测试报告不实现功能和业务代码逻辑build-keeper构建配置、路径别名、依赖优化、包体积vite/webpack 配置、CI 脚本不写业务模块和页面组件review-policelint、tsc、测试全量检查、review 报告质量问题清单、修复建议不直接提交新功能不改业务代码这张表的意义在于每一组 Skill 的指令都必须写清楚“你不做什么”。AI Agent 和人类一样如果不约束边界它就会按照自己的理解顺手多做一步。比如 page-builder 伸手去调 APIlogic-implementor 顺手改了个按钮样式这类越界行为是协作混乱的主要来源。2.3 协作方式和数据流更像装配线而不是外包这 5 组 Skills 不是孤立存在的它们的执行顺序有一定讲究。简单说page-builder 的输出是 logic-implementor 的输入logic-implementor 的输出又是 test-runner 的断言对象build-keeper 在最后做工程化整合review-police 则是全流程的收口关卡。每两组 Skill 之间我会设置一个人工检查点。比如页面生成后先看一下渲染效果逻辑实现后手动操作一遍核心流程测试跑完确认覆盖率不是摆设。这就像工厂里的装配线每个工位完成自己的工序质检员在旁边逐站检查。人与 AI 的关系从“你干完了我再来看”变成了“每站验收、层层递进”。3. 拆解 Skills 的内部结构如何让 Codex 每个动作都可控很多人对 Skills 的理解是“一个更长的 prompt”这个方向没错但不够。真正能在实际项目中稳定发挥作用的 Skill必须是一个结构完整的“工作说明书”。它至少包含五个部分触发条件、输入要求、执行步骤、输出标准、禁止红线。缺了任何一块Codex 的发挥空间都会变大稳定性就会下降。3.1 Skill 的基本骨架长什么样以我本地项目中的 page-builder 为例它的核心结构是这样的--- name: page-builder description: 只负责页面视觉层组件拆分、JSX 结构、样式、响应式。不实现任何数据请求和业务状态。 when_to_use: 已经确认组件树和设计 token需要批量生成页面骨架时。 --- # 输入要求 - 设计稿截图或描述 - 组件树清单 - 设计 token 文件路径 # 执行步骤 1. 读取组件树清单按原子到页面的顺序生成组件 2. 每个组件使用设计 token 中的颜色、间距、字号 3. 所有文案放入常量文件不硬编码在 JSX 中 4. 组件只声明 props不调用任何 API 或 store # 输出标准 - 组件文件全部创建无占位 TODO - 样式通过 lint 检查 - 页面在本地开发服务器可预览 # 禁止事项 - 不添加任何数据请求逻辑 - 不修改全局状态管理代码 - 不改变组件树结构除非发现明显遗漏你可以看到这个 Skill 把“怎么做”和“做到什么程度算完”都写清楚了。Codex 拿到它能干的任务范围是非常明确的。它不会再顺手写一套 fetch 逻辑因为禁止事项里已经划了红线。3.2 页面 Skill先定组件树再谈生成页面page-builder 的成败关键在输入要求里的组件树清单。我在实践中的教训是如果只丢给 Codex 一张设计稿截图它会按照自己的方式拆分组件出来的结构往往和业务逻辑层匹配不上。所以我每次都会先花十分钟把组件树列出来比如页面容器、任务卡片列表、筛选栏、添加任务表单每个组件负责什么 props大致写清楚。这十分钟的投入很值。因为后续 logic-implementor 接收的 props 契约就是从这里来的如果页面组件拆得合理逻辑层就可以直接按图索骥不需要返工。用生活化的类比这就像是先把房子的户型图定好瓦工、水电工、油漆工才不会在同一个位置重复干活。3.3 逻辑 Skill用接口契约把代码焊死在一个轨道上logic-implementor 的内部结构我的核心思路是“先契约后实现”。它必须先定义数据模型和 API 返回类型再动手写 hooks 或 store。下面是我常用的一段逻辑 Skill 片段# 执行步骤 1. 阅读页面组件的 props 定义确认每个字段的含义 2. 定义数据模型interface/type所有字段标注可选/必选 3. 确认接口路径和返回结构编写 service 层函数 4. 编写 hooks 或 store只通过 props 或事件与页面交互 5. 所有异步请求要有 loading 和 error 状态 # 输出标准 - 类型定义完整tsc 无报错 - 不修改任何 .tsx 组件文件 - 每个对外暴露的函数有简要 JSDoc这就是逻辑 Skill 的接口契约思路。有了它AI 在实现业务逻辑时不会突然冒出个新字段也不会把一个组件内部的状态管理方案改得面目全非。它只需要按照已经确定的数据流往前推进然后等待测试和构建去验证。3.4 测试和构建 Skill把检查项设计成硬性约束test-runner 这个 Skill我踩过最大的坑是它生成的测试“看起来在测其实什么都没测”。比如断言一个组件被渲染了但不检查渲染的文本是否正确或者调用了 mock 函数但不验证参数。所以我在 test-runner 的输出标准里写了硬性约束每个核心用户路径至少有一个行为断言必须验证用户操作之后的结果而不是只验证操作被调用。build-keeper 这个 Skill 更偏工程化配置。它的典型输出包括 Vite 配置、tsconfig 的路径别名、环境变量示例文件、构建脚本。它的核心检查项是本地构建命令一次通过产物能正常加载路径别名在测试和构建环境中保持一致。4. 从需求到上线五组 Skills 在真实任务中的落地过程理论说了一堆我再用一个真实任务完整过一遍流程。假设你已经决定用五组 Skills 来开发一个“待办事项面板”支持增删改、筛选、本地持久化。这是很典型的 CRUD 前端需求规模不大不小正好适合演示整套拆解逻辑。4.1 先把需求拆成五份交付物拿到需求后我做的第一件事不是让 AI 动手也不是写一堆用户故事而是确定五个交付物page-builder 交付任务列表、添加表单、筛选栏、空状态、删除弹窗logic-implementor 交付task store增删改查、筛选状态、本地 localStorage 持久化test-runner 交付添加任务、标记完成、删除任务、筛选未完成项、持久化恢复build-keeper 交付Vite React 项目脚手架配置、路径别名、构建优化review-police 交付lint 检查、tsc 类型检查、全量测试报告、代码 diff 审查这一步相当于给整个工程画了一张地图后面每轮 AI 工作都是在完成地图上的一个区块。4.2 按顺序调用五组 Skills严格走流程完整流程我会写成这样每一步都有明确的人机分工第一轮调用 page-builder。我先把组件树清单和设计 token 文件准备好然后让 Codex 生成全部页面组件。生成结束后我会打开本地预览检查视觉结构和响应式效果满意了再进入下一轮。第二轮调用 logic-implementor。它需要读取第一轮生成的 props 定义然后实现 store、hooks 和持久化逻辑。这一轮不需要动任何页面代码。完成后我会手动操作一遍添加、删除、筛选确认交互能通。第三轮调用 test-runner。它阅读需求和当前实现补充核心路径的测试。我会特别留意它是不是只测了 happy path对错误分支有没有覆盖。第四轮调用 build-keeper。它来统一处理构建配置确保别名、环境变量、分包策略没有问题本地构建能一次通过。第五轮调用 review-police。它会把 lint、类型检查、全量测试都跑一遍输出一份“待确认问题清单”我根据清单决定是修复还是合入。下面是我在实际操作中会使用的触发示例你可以当作一个模板来改写# 第一轮触发 page-builder codex 读取 components-tree.md使用 design-tokens.css按页面技能生成全部页面组件先不要管接口和状态逻辑 # 第二轮触发 logic-implementor codex 读取项目组件 props 定义按逻辑技能实现 task store、筛选逻辑和 localStorage 持久化不要修改任何页面文件 # 第三轮触发 test-runner codex 按测试技能为任务列表的添加、删除、筛选、持久化补充测试确保每个用户路径都有断言 # 第四轮触发 build-keeper codex 按构建技能统一 vite.config.ts、tsconfig 别名和构建优化配置确保 build 命令一次通过 # 第五轮触发 review-police codex 按审查技能运行 lint、tsc 和全量测试输出待确认问题清单和修复建议这套命令看着简单但每一条都绑定了对应 Skill 的执行规则Codex 不会跑到一半突然“自由发挥”。它知道这一轮的边界是什么也知道完成的定义是什么。4.3 为什么这个顺序最能减少返工我特意把页面放最前、逻辑其次、测试第三、构建第四这个顺序是经过几次返工总结出来的。页面放最前是因为视觉层相对独立Codex 生成组件时不需要理解业务只要照着设计 token 和组件树做就行。逻辑放第二因为这时候 props 契约已经确定了它只需要填数据不会出现“字段对不上”的情况。测试放第三因为测试必须针对真实实现来写逻辑没确定之前写测试就是空中楼阁。构建放第四是为了避免配置和代码频繁打架——页面和逻辑还没稳定的时候去调构建配置改一版代码配置就要跟着动一轮纯属浪费精力。4.4 人工检查点的设置方式每一轮之间的检查点我不是靠肉眼硬看而是尽量让检查自动化。页面层我用浏览器预览逻辑层我手动操作核心流程测试层我直接看通过率和覆盖率报告构建层我看构建产物大小和启动速度审查层我看 lint、tsc、测试结果汇总。这种“每层都设闸”的方式让我能够在 AI 出错的第一时间发现它而不是等到最后一刻集中爆发。返工成本能控制在非常小的范围内。5. 踩坑记录与排查技巧AI 前端协作最容易翻车的 6 个细节用五组 Skills 跑了一段时间之后我积累了不少“血泪教训”。这些坑普遍存在于 AI 协作开发中提前知道可以帮你省下大量时间。5.1 最容易翻车的三个协作问题第一个问题是页面和逻辑职责不清。我原先在 page-builder 里没有写“禁止请求数据”结果它生成的组件里带了一堆 fetch 调用后续 logic-implementor 想接数据都没法接最后只能手工把请求全部拆出来。后来我在所有页面相关 Skill 里统一加了红线这个问题就再没出现过。第二个问题是测试断言太弱。test-runner 生成的测试经常出现“只验证这个操作被调用不验证调用的参数和数据是否正确”。这种测试跑十遍都是绿的但一上线功能就是坏的。后来我把测试 Skill 的输出标准改成“必须断言行为结果”测试质量立刻上了一个台阶很多 bug 在开发阶段就被拦住了。第三个问题是构建配置被 AI 重复定义。Codex 在调整 Vite 配置时有时会同时改 tsconfig、package.json 和 vite.config.ts结果路径别名三处不一致构建失败后排查半天。现在我在 build-keeper 里规定了“配置文件改动必须给出 diff 摘要”AI 每次改了什么、为什么改我都一目了然。5.2 常见问题速查表整理一个速查表遇到问题可以直接对照问题现象大概率原因解决思路页面组件出现重复定义或改名上下文过长AI 记忆丢失把组件树清单写进本轮上下文缩小任务范围逻辑层和页面层字段对不上缺 props 契约逻辑实现前先读取页面 props 定义测试全绿但功能坏了断言太弱只测调用不测结果强化测试 Skill 的断言标准强制行为验证本地构建正常CI 构建失败环境变量或路径别名不一致用 build-keeper 统一配置并在 CI 中跑同一套脚本AI 开始顺手改样式上下文污染边界模糊在 Skill 中新增“禁止事项”每轮重新注入 contextreview-police 只挑刺不给方案Skill 输出标准不明确要求输出问题清单时必须带修复建议和优先级5.3 进阶技巧把 review 报告喂给下一轮迭代最后分享一个我觉得特别好用的进阶技巧。每一轮 review-police 跑完之后我会把它的输出报告保存下来作为下一轮任务的“前情提要”传给 Codex。比如上一轮它报告了“新增的删除按钮缺少加载态”下一轮让 logic-implementor 动工的时候我就在上下文里附带这条报告。这个做法等于让 AI 拥有了“记忆”它不会在同一个问题上反复翻车。而且因为报告本身就是上一轮真实检查的结果不是人写的抽象总结Codex 理解起来非常直接修正效率极高。我现在几乎每个迭代周期都会这么做已经形成了习惯。我个人的体会是把 Codex 当前端开发的“员工”而不是“终结者”工作流会顺很多。人定架构、定边界、定验收标准AI 负责批量执行和粗暴生成再由测试和构建兜底。这一套跑下来开发速度不一定是最快的但推进过程最省心。如果你也被“AI 写前端写得越多越乱”折磨过建议你先别急着调 prompt而是照着这个思路把任务边界和验收标准拆清楚建立你自己的五组 Skills。