Codex /goal 实战指南：从"继续"到"验收单"

你有没有遇到过这种情况？打开 Codex，需求写了一大段。它开始干活，看起来挺认真。跑了一会儿，停了。你补一句：继续。过一会儿，又停了。你再补一句：还有几个文件没处理，测试还没跑，再检查一下。

折腾几轮后突然发现：表面上是 AI 在帮你写代码，实际上你坐在旁边当监工。它像一个刚来上班的新同事，每干完一小段就回头看你一眼：老板，我还能继续吗？

这就是很多人用 Codex 最烦的地方。不是它不会写，而是它经常不知道"什么时候才算干完"。

/goal 的本质

最简单的一句话：/goal 不是让 Codex 瞎跑更久，而是让 Codex 围着一个明确目标持续干，直到它认为目标完成、被暂停，或者需要你接手。

你可以把它理解成：别再一句一句催它"继续"，而是在开工前，先给它一张清清楚楚的验收单。

普通 prompt vs /goal

普通 prompt 像什么？像你对装修师傅说：帮我把厨房弄好一点。

这句话听起来没毛病，但师傅没法判断。换个水龙头算不算？擦干净台面算不算？重新铺瓷砖算不算？把墙砸了重做算不算？

/goal 更像你递过去一张单子：

水龙头要换成指定型号
台面不能动
水管不能漏
完工后拍照验收
如果发现墙里漏水，先停下来问我

这就不一样了。Codex 最需要的不是一句"加油"，而是一个能验收的终点。

坏目标 vs 好目标

很多人会这样写：

/goal 帮我优化这个项目

这句话的问题是：太像愿望了。什么叫优化？代码更短？速度更快？界面更好看？测试更多？这些都可能叫优化。Codex 看到这种目标，就像新员工拿到一句"你把公司变好一点"。他当然也想努力，但努力方向可能完全跑偏。

你要这样写：

/goal 修改 src/api 下的请求重试逻辑。

验收标准：
1. 现有测试全部通过。
2. 新增 3 个失败重试用例。
3. 重试次数、超时、日志字段都有测试覆盖。

限制条件：
1. 不修改公开 API。
2. 不删除已有日志字段。
3. 不改数据库结构。

交付物：
1. 列出改了哪些文件。
2. 写清楚跑了哪些测试。
3. 标出仍需人工确认的风险。

这才像一张能干活的单子。它不只告诉 Codex"你要做什么"，还告诉它"什么叫做完""哪里不能碰""最后交什么东西"。

/goal 万能模板

/goal 完成【这里写任务】。

背景：
【为什么要做这件事】

范围：
1. 只允许修改【目录/文件】。
2. 优先阅读【关键文件】。
3. 不要改【禁区】。

验收标准：
1. 必须通过【测试/命令】。
2. 必须能被验证。
3. 必须处理【边界场景】。

交付物：
1. 修改了哪些文件。
2. 跑了哪些命令，结果是什么。
3. 哪些地方需要人工复查。

停止条件：
如果发现【权限/线上配置/数据缺失】问题，先停下来说明，不要硬改。

实战示例：修复登录问题

/goal 修复登录后偶尔跳回登录页的问题。

背景：
用户反馈登录成功后，有时会重新回到登录页。请先检查 auth、session、cookie 相关逻辑。

范围：
1. 优先检查 src/auth、src/middleware、src/api/session。
2. 不修改数据库结构。
3. 不重写整个登录系统。

验收标准：
1. 现有测试全部通过。
2. 新增至少 2 个 session 保持相关测试。
3. 本地能复现并验证登录后不再跳回登录页。

交付物：
1. 说明根因。
2. 列出修改文件。
3. 给出测试结果。
4. 标出仍需人工确认的浏览器兼容风险。

停止条件：
如果问题依赖线上 cookie 配置或第三方登录后台权限，先停下来说明。

长任务记忆：三个文件

很多人让 Codex 跑长任务，最容易忽略一件事：它跑到后面会忘。不是说完全失忆，而是长任务里尝试太多，前面为什么失败、后面为什么换路，很容易乱。

建议提前建三个文件：

PLAN.md — 路线图，告诉它今天要从哪里走到哪里。

EXPERIMENTS.md — 试验记录，每试一个办法就记下来：试了什么，结果如何，为什么继续或放弃。

EXPERIMENT_NOTES.md — 草稿本，让它把中间想法、观察、临时判断写进去。

这就像你让师傅修家里的电路。今天拆了哪个插座，哪根线不通，哪个开关测过了，都要写在纸上。否则修到后面，他自己也容易绕回原地。

在 /goal 里加一句：

执行过程中请持续更新 PLAN.md、EXPERIMENTS.md 和 EXPERIMENT_NOTES.md。
每完成一个阶段，都记录尝试、结果和下一步判断。

这句话非常管用。因为它把 Codex 的"脑子里记着"变成了"文件里写着"。文件里的东西，你能看，它也能回头看。

复杂任务：先 checklist，再 /goal

有些任务不是写代码那么简单。比如把论文从 NeurIPS 格式改成 ICML workshop 格式。格式要求可能有 200 多条：字号、页边距、引用格式、匿名规则、标题格式、附录位置。

正确做法是先让 Codex 做一张清单：

请先阅读 ICML 格式要求，把所有规则整理成 checklist.md。
每条规则都写成可勾选项目，不要开始修改正文。

等它生成 checklist.md 以后，再开 /goal：

/goal 根据 checklist.md 把论文改成 ICML workshop 格式。

验收标准：
1. checklist.md 里的项目全部完成并勾选。
2. 不修改论文技术内容。
3. 保留原有实验结果和结论。
4. 最后说明还有哪些格式点需要人工复查。

这就是很重要的思路：不要让 Codex 判断"差不多好了没"，要让它判断"清单上还剩几项没做"。人也是这样。你让一个人"把屋子收拾好"，他可能觉得桌面干净就行。你给他一张清单：倒垃圾、擦桌子、拖地、洗杯子、整理电线，他就很难糊弄过去。

社区案例

a16z 的 Andrew Chen 提到，他让 Codex /goal 处理一个低层 eGPU 和 Mac 设备驱动项目，跑了 14 个小时，还在一点点推进。

也有开发者写下：

/goal ship the 18 features in BACKLOG.md before standup

第二天回来，18 个功能里已经完成 14 个，PR 提了，CI 也绿了。

这些案例听起来很爽。但建议别只看到"通宵干活"，更要看到背后的前提：它得有 backlog，有测试，有 CI，有边界，有能判断完成的证据。否则你把一个乱七八糟的生产仓库丢给它，说"帮我弄好"，那不是自动化，是开盲盒。

/goal 不是魔法棒

/goal 更像一辆能自己开一段路的车。路标清楚、目的地清楚、刹车好用，它就很香。你要是连目的地都没设，直接让它上高速，那就不是省心，是吓人。

基本命令：

/goal <你的目标>    设置目标
/goal               查看当前目标
/goal pause         暂停
/goal resume        继续
/goal clear         清除目标

千万不要等它跑偏了，才发现自己不会暂停。很多人用 Agent 最大的问题，不是不会启动，而是不会刹车。

新手建议：从三类任务开始

不要一上来就让它重构全项目。先从这三类开始：

第一，补测试：

/goal 为 src/utils/date.ts 补充单元测试。
验收标准：
1. 覆盖正常日期、非法日期、空值、时区边界。
2. npm test -- date 必须通过。
3. 不修改业务逻辑，只补测试。

第二，修一个明确 bug：

/goal 修复导出 CSV 时中文乱码的问题。
验收标准：
1. 导出的 CSV 用 Excel 打开中文正常。
2. 新增一个导出测试。
3. 不修改导出字段顺序。

第三，整理文档：

/goal 根据当前 README 和 scripts 目录，补充本地启动说明。
验收标准：
1. 新手照着 README 能跑起来。
2. 写清楚环境变量。
3. 写清楚常见报错和处理办法。
4. 不改代码。

这三种任务边界清楚，风险小，最适合练手。等你看懂它怎么跑、怎么记录、怎么交付，再让它做更复杂的事情。

核心原则

别写愿望，写验收。
别催继续，给清单。
别信口头完成，看测试和 diff。

你一旦理解这句话，用 Codex 的感觉会完全不一样。以前你像坐在旁边盯着一个新员工，每隔几分钟问一句：干完了吗？继续了吗？漏了吗？

现在你更像一个会安排工作的项目负责人：开工前把目标、边界、验收、刹车讲清楚，然后回来检查结果。

这就是 /goal 真正省心的地方。不是让 AI 替你做所有决定，而是让它少来问你那些本来可以提前写清楚的问题。