1. 引言：为什么不该让 Codex 一口气写完整个前端

很多团队在尝到 AI 编程的甜头后，第一反应是「让 Codex 把整个前端一口气写完」。听起来很爽，但实际踩坑的人不在少数：页面写到一半逻辑崩了、组件和样式纠缠在一起、测试完全缺失、构建脚本一团乱麻。问题不在于 Codex 不够强，而在于任务颗粒度太大。

一口气写完整个前端，意味着把「页面结构、交互逻辑、状态管理、样式、测试、构建配置」全部塞进同一个上下文。Codex 的注意力会被稀释，生成的代码往往结构混乱、难以维护，而且一旦中途需求变化，返工成本极高。

正确的做法是：用 Skills 把前端拆成 5 个清晰的职责域，每个 Skill 只负责一件事，让 Codex 像流水线一样逐段完成。这样既保留了 AI 的高效，又守住了代码质量的下限。

2. 核心思路：按职责域拆分，而不是按页面拆分

很多人拆任务喜欢「按页面拆」——先写首页，再写列表页，再写详情页。这其实是个误区。页面之间往往共享大量逻辑和组件，按页面拆会导致重复代码和上下文割裂。

更合理的拆分维度是职责域：

• 页面结构：JSX/模板、组件树、布局
• 交互逻辑：事件处理、状态管理、数据请求
• 样式系统：CSS/Tailwind/样式变量、主题
• 测试覆盖：单元测试、组件测试、端到端测试
• 构建与工程化：打包配置、环境变量、脚本、CI

每个职责域对应一组 Skills，Codex 在切换职责域时上下文更聚焦，产出的代码边界也更清晰。

3. 第一组 Skills：页面结构（Page Structure）

这一组 Skills 只负责「长什么样」，不负责「怎么动」。

核心职责：

• 生成组件树和 JSX/TSX 结构
• 定义布局（Layout）、路由骨架
• 占位数据（Mock Data）与静态展示
• 组件拆分与复用边界

推荐 Skill 清单：

• page-layout-generator：根据设计稿或需求生成页面骨架
• component-tree-planner：规划组件层级与 props 接口
• mock-data-provider：为页面生成静态占位数据

示例提示词：

使用 page-layout-generator 生成一个「商品列表页」的组件骨架，
包含搜索栏、筛选区、列表区和分页器，先不写任何交互逻辑。

为什么先做这一层： 页面结构是视觉和交互的载体，先定结构能让后续逻辑和样式有明确的挂载点，避免 Codex 在写逻辑时顺手改结构导致混乱。

4. 第二组 Skills：交互逻辑（Interaction Logic）

页面结构定好后，再让 Codex 填充「怎么动」。

核心职责：

• 事件处理函数
• 状态管理（useState/useReducer/全局状态）
• 数据请求与缓存（fetch/axios/React Query）
• 表单校验与提交逻辑

推荐 Skill 清单：

• state-manager：设计状态模型与更新逻辑
• data-fetcher：封装 API 请求、loading/error 状态
• form-handler：表单状态、校验与提交

示例提示词：

使用 data-fetcher 为商品列表页封装数据请求，
包含 loading、error、空数据三种状态，并接入已有的组件骨架。

关键点： 这一层只改逻辑，不动页面结构。如果发现结构不合理，应该回到第一组 Skills 调整，而不是在逻辑层顺手改 JSX。

5. 第三组 Skills：样式系统（Styling System）

样式是前端最容易失控的部分，必须单独隔离。

核心职责：

• 全局样式变量与主题（颜色、间距、字体）
• 组件级样式（CSS Modules / Tailwind / styled-components）
• 响应式与适配
• 动效与过渡

推荐 Skill 清单：

• theme-token-generator：生成设计令牌（Design Tokens）
• component-styler：为组件套用样式
• responsive-adapter：处理断点与响应式布局

示例提示词：

使用 theme-token-generator 生成一套包含主色、间距、圆角的设计令牌，
再用 component-styler 为商品卡片组件套用样式。

为什么单独拆： 样式和逻辑混在一起是前端维护的噩梦。把样式隔离成独立职责域，Codex 在调整视觉时不会误伤逻辑，反之亦然。

6. 第四组 Skills：测试覆盖（Testing）

很多团队让 Codex 写代码却漏了测试，这是最大的隐患。测试必须作为独立职责域纳入流程。

核心职责：

• 单元测试（组件渲染、工具函数）
• 交互测试（用户行为模拟）
• 端到端测试（关键路径）
• 测试数据与 Mock

推荐 Skill 清单：

• unit-test-writer：为工具函数和组件生成单测
• interaction-tester：用 Testing Library 模拟用户交互
• e2e-scenario-builder：编写关键路径的端到端用例

示例提示词：

使用 interaction-tester 为商品列表的「搜索 + 筛选」交互编写测试，
覆盖正常结果、空结果和请求失败三种场景。

关键点： 测试应该和逻辑同步推进，而不是最后补。每完成一组逻辑 Skills，就立刻让 Codex 补对应测试，形成「写一段、测一段」的节奏。

7. 第五组 Skills：构建与工程化（Build & Engineering）

最后一层是让整个项目「跑得起来、发得出去」。

核心职责：

• 构建配置（Vite/Webpack/Next.js）
• 环境变量与多环境配置
• 代码规范（ESLint/Prettier）
• CI/CD 脚本与部署

推荐 Skill 清单：

• build-configurator：生成或调整构建配置
• env-manager：管理环境变量与配置
• ci-pipeline-builder：生成 CI 工作流

示例提示词：

使用 build-configurator 为项目配置 Vite 的生产构建，
并让 ci-pipeline-builder 生成一个包含 lint、test、build 三步的 CI 工作流。

为什么放最后： 构建配置依赖前面四层的产物。先有页面、逻辑、样式和测试，再配置构建才有意义，否则容易在空项目上反复折腾配置。

8. 五组 Skills 的协作流程

五组 Skills 不是孤立的，它们应该按固定顺序协作，形成一条流水线：

推荐执行顺序：

1. 页面结构 → 搭骨架
2. 交互逻辑 → 填行为
3. 样式系统 → 上视觉
4. 测试覆盖 → 保质量（与 2、3 并行推进）
5. 构建与工程化 → 收尾上线

节奏建议： 每完成一个职责域，让 Codex 输出一份简短的「完成说明」，你检查边界是否清晰、有没有越界改动。发现问题就回退到对应职责域修正，而不是在下一个职责域里打补丁。

9. 实战示例：一个商品列表页的完整拆分

假设要做一个商品列表页，用五组 Skills 的完整流程如下：

第一步：页面结构

用 page-layout-generator 生成商品列表页骨架：
搜索栏、筛选区、商品卡片网格、分页器，组件拆分清晰，先不写逻辑。

第二步：交互逻辑

用 data-fetcher 封装商品列表请求，接入骨架；
用 form-handler 处理搜索和筛选表单，状态提升到列表页。

第三步：样式系统

用 theme-token-generator 生成设计令牌，
用 component-styler 为商品卡片和筛选区套用样式，适配移动端。

第四步：测试覆盖

用 interaction-tester 为搜索 + 筛选交互写测试，
覆盖正常、空结果、失败三种场景。

第五步：构建与工程化

用 build-configurator 配置生产构建，
用 ci-pipeline-builder 生成 lint + test + build 的 CI 流程。

每一步之间检查边界，确保 Codex 没有越界改动，最终得到一个结构清晰、可维护、有测试、能上线的完整前端。

10. 总结

让 Codex 一口气写完整个前端，本质上是把「架构设计」的责任甩给了 AI，结果往往失控。正确的姿势是用 5 组 Skills 把职责域拆清楚：

• 页面结构：只负责长什么样
• 交互逻辑：只负责怎么动
• 样式系统：只负责视觉与主题
• 测试覆盖：只负责质量保障
• 构建与工程化：只负责跑起来、发出去

按「结构 → 逻辑 → 样式 → 测试 → 构建」的顺序推进，每个职责域边界清晰、上下文聚焦，Codex 的产出质量会显著提升，你的代码也会更好维护。下次再让 Codex 写前端，先拆 Skills，再动手。