把一句话的需求丢给 Codex，比如「帮我优化首页」，它很可能同时动 UI 和文案，连布局一起改。顺手还删掉一些它觉得没用的代码。改得快，但你不知道它改了哪里，也不知道能不能放心交付。
稳定的做法是让需求先经过拆解，再进入执行。整条链路走六步。
六步法
| 步骤 | 名称 | 目的 |
|---|---|---|
| 1 | 需求拆解 | 先让它知道要做的项目是什么，避免不了解结构就乱改 |
| 2 | 制定计划 | 先列出要做什么，确认后再动手 |
| 3 | 小步实现 | 一次只改一块，出错好回滚 |
| 4 | 测试 | 运行检查并手动验证 |
| 5 | 代码审查 | 看 diff，检查改得对不对 |
| 6 | 提交与复盘 | 提交代码并沉淀经验 |
需求不会直接变成交付物，中间必须经过理解，计划，修改和验收这几步。这一篇讲前两步。
背景先交代清楚
| 要回答的问题 | 示例 |
|---|---|
| 项目处于什么阶段 | 这是一个已经上线的官网页面 |
| 当前遇到什么情况 | 首页转化率低，用户不知道产品卖点 |
| 为什么现在要改 | 准备发布新版，需要优化首屏表达 |
| 属于什么类型 | UI 优化，Bug 修复，新功能，重构 |
模糊的说法换成具体说法
| 模糊说法 | 更清楚的说法 |
|---|---|
| 优化首页 | 优化首页首屏标题，副标题和 CTA 按钮 |
| 页面不好看 | 调整卡片间距，字体层级和按钮样式 |
| 登录有问题 | 修复点击登录按钮后没有跳转的问题 |
| 做一个后台 | 新增用户列表页，含搜索，筛选和分页 |
好的需求能回答一件事，这次到底要解决哪一个具体问题。比如这次主要解决三个问题，首屏标题表达不清楚，CTA 按钮不明显，移动端首屏内容太拥挤。
划出不能碰的地方
它很容易为了完成当前任务顺手改别处，所以要提前画边界。
| 不能动的内容 | 说明 |
|---|---|
| 登录逻辑 | 只改 UI，不改认证流程 |
| 接口地址 | 不改 API 请求路径 |
| 数据结构 | 不改数据库字段 |
| 路由结构 | 不改已有页面路径 |
如果你知道大概的文件位置，也提前告诉它。改首页可能落在 app/page.tsx 或 components/Hero.tsx，改样式可能落在 globals.css 或 tailwind.config.js，改登录可能落在 login/page.tsx 或 auth.ts。这样能减少它全项目乱找的概率。
什么算完成，怎么验证
不要只说做完就行。UI 优化的完成标准是页面视觉明显改善，移动端不乱。Bug 修复的标准是原来的报错消失，相关功能正常。新功能的标准是用户能完整走通操作流程。
验证方式也要提前写下来，页面预览，构建测试，手动流程测试这几类按项目情况选。风险同样要摆到台面上，比如小需求被改成大重构，或者改了全局样式把其他页面一起污染，再或者新增了不必要的依赖。
第一段提示词可以照着写
请先帮我做需求拆解，不要立刻修改代码，按下面结构输出。
- 背景是什么。当前项目大概是什么，为什么要做这个需求，它属于新功能还是 Bug 修复。
- 要解决什么问题。当前具体问题是什么，本次解决到什么程度，哪些内容不在范围内。
- 哪些文件可能相关。根据项目结构判断，先列出来，不要直接修改。
- 哪些功能不能动。不要改哪些逻辑，不要动哪些接口，不要影响哪些页面。
后面三块是完成标准，需要的测试，以及有哪些风险。最后再给一个简短的执行建议，说明建议先做哪一步，是否需要确认后再修改。
第二步是先要一份计划
需求拆解完，别急着让它写代码。它的默认倾向是看到需求就直接开干，没理解项目结构就可能改错文件，没确认边界就可能做了不该做的功能，一次改太多出错后还不好回滚。
所以在提示词最前面写清楚。先不要写代码，也不要修改任何文件，先根据需求和项目结构给一个修改计划，确认后再执行。CLI 或者 App 里也可以直接输入 /plan，先让它输出计划，再决定要不要动手。
