1. 先搞清楚一件事为什么一口气是 AI 写前端最大的坑如果你正打算把整个前端需求丢给 Codex让它一口气把页面、交互、接口、测试、构建全部生成出来我劝你先停一下。我在实际项目里踩过这个坑结果相当惨烈页面确实出来了看起来也有模有样但逻辑里埋着好几个隐蔽的状态同步错误测试文件写了一大堆却几乎全是断言永远成立的空测试构建配置更是直接让本地依赖解析花掉半个下午。问题出在哪不是 Codex 能力不行而是一口气写完这个用法本身就违背了 AI 编程工具的工作机制。Codex 这类工具本质上是一个超强的上下文推理引擎但它的注意力是有限的。当一个任务被拆成页面、逻辑、测试、构建四个维度且每个维度里还有七八个文件需要联动时Codex 在生成后半段时很容易忘记前半段的细节。我在一个中等规模的后台项目里试过让 Codex 直接生成一个包含 12 个组件的用户管理模块结果它后面写的接口调用层还在用第一个版本的状态字段名而那个字段名在第二版设计里已经改掉了。整个模块跑起来之后报错信息指向的代码位置和实际问题的位置差了三个文件。更隐蔽的问题出在测试上。Codex 在长任务里有个很典型的倾向为了让最终结果看起来完整它会自动生成那种永远不会失败的测试——要么断言写得太宽泛要么干脆把测试函数留成空壳。这种测试放进 CI 里真的会跑也真的全绿但全绿得毫无意义。所以后来我换了一套思路别让 Codex 一口气干完而是把它当成一个会写代码的协作者用 Skills 把任务拆成五组每干完一组就停下来检查一组。这听起来像多花了几轮对话的时间但实际上最终总耗时反而缩短了因为返工量从推倒重来降级成了局部修改。这篇就专门讲讲我这套拆分方法以及 5 组 Skills 的具体写法、放法、用法。2. Skills 是什么先把它和普通的提示词模板区分开在讲 5 组 Skills 之前得先把概念对齐。很多人以为 Skills 就是一组精心设计的提示词存成 Markdown 文件丢给 AI 用。这个理解方向是对的但不够完整。Skills 的核心价值不在提示词本身而是把做某类任务的完整流程、约束条件、自查清单固化成一份机器可读、可复用的操作手册。它不是一个请帮我写一个登录页面的指令而是一套完整的操作规范包括任务的输入输出约定、必须遵守的编码风格、需要生成的代码清单、完成后的验证方式、常见坑点提示等。Codex 读取一个 Skill 时相当于把这份规范加载进工作记忆然后按照规范里定义的流程来干活。这样做的效果是你给 Codex 的任务指令可以非常简短因为它知道遇到这类任务时应该按照我预设的流程走而不是每次都靠临场发挥。具体到文件组织上我习惯在一个项目根目录下建.codex/skills/目录每个 Skill 占一个子目录子目录里是一个SKILL.md主文件外加一个可选的references/文件夹。SKILL.md的开头用 YAML frontmatter 声明元信息主要包括nameSkill 的唯一名字Codex 通过这个名字感知它的存在description一句话描述这个 Skill 能干吗以及在什么场景下该被激活when_to_use显式声明适合触发这个 Skill 的任务类型关键词下面的正文部分才是重头戏。我一般会写清楚这几块内容输入约定这个 Skill 服务于什么类型的任务需要哪些前置条件执行步骤拆解成 5-10 步的具体操作每一步有明确的产出代码规范变量命名、目录结构、文件拆分方式必须落实成硬约束自查清单干完活之后逐项检查防止 AI自以为完成却漏了关键项常见反例把踩过的坑直接写进 Skill让 AI 在动手前就避开把经验沉淀成这种格式之后Skills 就成了一组可积累、可更新、跨项目复用的资产。你在第一个项目里踩过的坑写进 Skill 之后第二个项目就不会再踩第二遍。3. 5 组 Skills 的具体拆法页面、逻辑、测试、构建、审查各管一摊回到标题里说的5 组 Skills——这五组不是随便划分的而是根据前端开发的天然边界画的页面结构层、逻辑行为层、测试验证层、构建工程层、审查收口层。每一层有各自的关注点也有各自最容易出问题的环节。下面逐个拆开讲。3.1 第一组page-builder —— 只管页面结构和 UI这组 Skill 的职责范围被压缩得非常窄只负责生成 JSX/TSX 组件结构、CSS 样式、组件拆分但不负责实现任何业务逻辑、不负责写接口调用、更不负责处理状态管理。为什么要把页面单独拆出来因为页面结构是后续所有工作的基础如果连基础都没定好就急着写逻辑后面逻辑代码会和 DOM 结构强耦合改动成本极高。我在page-builder这个 Skill 里定义的核心约束有三条组件文件按一个文件一个组件的原则拆分容器组件和展示组件分目录放所有交互点按钮、表单、列表项必须留下明确的>