以前用 AI 写代码，是一步一步指挥。
先做 A，再做 B，然后 C。每一步都要你盯着，每一步都要你确认。
现在不一样了。
Codex CLI 0.128.0 加了一条命令：/goal。给它一个目标，它自己一轮接一轮往下推进。直到目标达成，或者 token 烧到上限，才停。
社区里已经有人连续跑了 21 小时。烧掉 9 亿 token。
OpenAI 总裁 Greg Brockman 在 X 上说了一句话：「codex now has a built in Ralph loop++」。
不是又一个提示词模板
先说清楚 /goal 到底是什么。
它不是一个花哨的 prompt 格式。是 Codex 内部新增的一整套目标生命周期管理机制。四个层面：
持久化。目标作为独立状态存起来，跟对话历史是两回事。/compact 压缩对话不会破坏目标。关掉终端，下次 codex resume 还能续上。
运行时延续。每一轮空闲后，Codex 自动注入一段叫 continuation.md 的提示词，让模型决定下一步。不需要你手动催。
完成审计。这是最被低估的部分。模型想标记「完成」，必须先跑一遍审计：把目标映射成清单，逐条检查证据。不能靠「测试跑过了」就算完。
Token 预算。烧到上限不会粗暴中断。会让模型把当前工作收尾，输出进度报告，然后停。
它解决了什么痛点
想了想，/goal 真正解决的是三个以前没办法解决的问题。
目标会丢。 普通 prompt 写在对话流里。上下文超了触发压缩，目标就可能被吃掉。/goal 把目标存在对话之外，压缩不影响。
模型会偷懒。 长任务里模型习惯早早声称「做完了」。/goal 的审计机制压住了这种倾向。它要求模型把每一条验收标准映射到具体证据，不确定就视为未达成。
跑飞没人管。 以前用外部脚本驱动 Ralph Loop，跑飞了只能眼睁睁看着烧 token。/goal 有原生的暂停/恢复/预算机制。烧到上限会软停止，不是裸停。
什么时候该用，什么时候不该用
不是所有任务都该套 /goal。
适合的场景：批量修 bug、批量生成测试、按规格文档实现完整功能、代码考古出报告、长程重构。
不适合的场景：单轮就能完成的小任务、说不清「完成长什么样」的探索、需要你不断拍板的决策、破坏性操作。
有一个最容易踩的坑：Plan 模式下 /goal 不延续。UI 上显示「Goal active」，但 Codex 实际上不会自己往下推。必须先退出 Plan 模式再启动 /goal。
五段式黄金模板
/goal 对提示词的要求比普通对话高一个数量级。
原因是审计机制需要把你的目标映射成清单。如果你写的是「优化一下」「清理所有」这种虚词，清单建不起来，审计就失效。
经过实践固定下来的模板：
/goal <一句话目标>
Scope: 作用范围，其他不要碰
Constraints:
- 硬性约束（可机械识别）
Done when:
1. 可验证的产物（引用具体文件或命令）
2. ...
Stop if:
- 停止条件（防止越界）
Use a token budget of <N> tokens.每一段都有存在的理由。Scope 画边界防扩散。Constraints 设红线。Done when 给审计清单。Stop if 防钻牛角尖。Token budget 给软停止。
缺任何一段，跑出来的质量都会打折扣。
一个更宏观的观察
最近半年，prompt 写法在变。
以前是过程指挥。先做 A，再做 B，然后 C。
现在是结果声明。我要这个，完成标准是 X、Y、Z，达到了才算完成。
/goal 是这个方向走得最远的产物之一。它把「过程指挥」压到最低，把「结果声明」提到最高。
但反过来，这也提高了对「会写需求」的要求。
模型越来越能干。但它干得好不好，反过来更依赖你能不能把「到底要啥」说清楚。
以前 prompt 糊一点没事，反正它只跑几秒钟。现在它能跑一整天。你那条糊掉的 goal，换来的就是一整天的糊产出。
/goal 的真正价值不在于「它能跑一整天」。在于它把这件事从一个需要外部脚本反复试错的工程，变成了一条可以直接在终端里下的命令。
剩下的事，是把目标写清楚。
SOURCES
- Codex CLI 0.128.0 Release --- 2026-04-30
- Simon Willison: Codex CLI 0.128.0 adds /goal
- OpenAI: Unrolling the Codex agent loop
- goal-prompt-builder Skill --- MIT 协议
- continuation.md 源码