你打开 Codex，把需求写了一大段。它开始干活，看起来挺认真。跑了一会儿，它停了。
你只好补一句：继续。
过一会儿，它又停了。
你再补一句：还有几个文件没处理，测试还没跑，再检查一下。
折腾几轮以后，你突然发现一件很尴尬的事：表面上是 AI 在帮你写代码，实际上你坐在旁边当监工。它像一个刚来上班的新同事，每干完一小段就回头看你一眼：老板，我还能继续吗？
这就是很多人用 Codex 最烦的地方。不是它不会写，而是它经常不知道“什么时候才算干完”。
今天讲一个很实用的功能：/goal。
最简单的一句话：/goal 不是让 Codex 瞎跑更久，而是让 Codex 围着一个明确目标持续干，直到它认为目标完成、被暂停，或者需要你接手。
你可以把它理解成：别再一句一句催它“继续”，而是在开工前，先给它一张清清楚楚的验收单。
/goal 不是愿望清单，是验收单
普通 prompt 像什么？
像你对装修师傅说：帮我把厨房弄好一点。
这句话听起来没毛病，但师傅没法判断。换个水龙头算不算？擦干净台面算不算？重新铺瓷砖算不算？把墙砸了重做算不算？
/goal 更像你递过去一张单子：
- 水龙头要换成指定型号
- 台面不能动
- 水管不能漏
- 完工后拍照验收
- 如果发现墙里漏水，先停下来问我
这就不一样了。Codex 最需要的不是一句“加油”，而是一个能验收的终点。
很多人写 /goal，第一步就写错了
很多人会这样写：
/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 配置或第三方登录后台权限，先停下来说明。
这就是好用的 /goal。不是写得长，而是写得能验收。
长任务一定要给 Codex 三个小本子
很多人让 Codex 跑长任务，最容易忽略一件事：它跑到后面会忘。
不是说它完全失忆，而是长任务里尝试太多，前面为什么失败、后面为什么换路，很容易乱。
所以我建议你在项目里提前建三个文件：
- PLAN.md
- EXPERIMENTS.md
- EXPERIMENT_NOTES.md
大白话讲：
PLAN.md 是路线图，告诉它今天要从哪里走到哪里。
EXPERIMENTS.md 是试验记录，每试一个办法，就记下来：试了什么，结果如何，为什么继续或放弃。
EXPERIMENT_NOTES.md 是草稿本，让它把中间想法、观察、临时判断写进去。
这就像你让一个师傅修家里的电路。你不能只让他满屋子试，还不做记录。今天拆了哪个插座，哪根线不通，哪个开关测过了，都要写在纸上。否则修到后面，他自己也容易绕回原地。
用 Codex 做长任务也是一样。
你可以在 /goal 里加一句：
执行过程中请持续更新 PLAN.md、EXPERIMENTS.md 和 EXPERIMENT_NOTES.md。 每完成一个阶段，都记录尝试、结果和下一步判断。
这句话非常管用。因为它把 Codex 的“脑子里记着”变成了“文件里写着”。文件里的东西，你能看，它也能回头看。
遇到大目标，先让它拆 checklist
有些任务不是写代码那么简单。
比如你要让 Codex 把一篇论文从 NeurIPS 格式改成 ICML workshop 格式。你直接写：
/goal 把论文改成 ICML 格式
这就有点危险。
因为格式要求太多，可能有 200 多条。字号、页边距、引用格式、匿名规则、标题格式、附录位置，全都可能有细节。
正确做法是先让 Codex 做一张清单：
请先阅读 ICML 格式要求，把所有规则整理成 checklist.md。 每条规则都写成可勾选项目，不要开始修改正文。
等它生成 checklist.md 以后，再开 /goal：
/goal 根据 checklist.md 把论文改成 ICML workshop 格式。
验收标准： 1. checklist.md 里的项目全部完成并勾选。 2. 不修改论文技术内容。 3. 保留原有实验结果和结论。 4. 最后说明还有哪些格式点需要人工复查。
这就是一个很重要的思路：不要让 Codex 判断“差不多好了没”，要让它判断“清单上还剩几项没做”。
人也是这样。你让一个人“把屋子收拾好”，他可能觉得桌面干净就行。你给他一张清单：倒垃圾、擦桌子、拖地、洗杯子、整理电线，他就很难糊弄过去。
真实案例可以看，但别神化
社区里已经有一些很夸张的 /goal 案例。
比如 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 pause 暂停
/goal resume 继续
/goal clear 清除目标
如果你用的是 CLI，也建议先看一眼版本：
codex --version
再进入 Codex 后试一下：
/goal
如果能看到相关提示，说明你的环境里可以用。
千万不要等它跑偏了，才发现自己不会暂停。很多人用 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. 不改代码。
这三种任务边界清楚，风险小，最适合练手。等你看懂它怎么跑、怎么记录、怎么交付，再让它做更复杂的事情。
最后给你一句口诀
用 /goal 前，记住这句话：
别写愿望，写验收。 别催继续，给清单。 别信口头完成，看测试和 diff。
你一旦理解这句话，用 Codex 的感觉会完全不一样。
以前你像坐在旁边盯着一个新员工，每隔几分钟问一句：干完了吗？继续了吗？漏了吗？
现在你更像一个会安排工作的项目负责人：开工前把目标、边界、验收、刹车讲清楚，然后回来检查结果。
这就是 /goal 真正省心的地方。不是让 AI 替你做所有决定，而是让它少来问你那些本来可以提前写清楚的问题。
请你现在就拿一个小项目试一次。不要选生产仓库，不要选大重构。就选一个补测试、修文档、改小 bug 的任务，把上面的模板复制进去，跑完以后看三样东西：
- diff 有没有越界
- 测试有没有真跑
- 交付物有没有说清风险
这三样都过了，你才算真正摸到 /goal 的门道。
