/goal：5 月 11 日随 v2.1.139 发布。你给一个完成条件，Claude 自己干活、自己检查、不满足就继续。听起来简单，用好有讲究。
平时用 Claude Code，你说一句它做一步，做完了停下来等你确认。/goal 改变的是这个节奏：你设定一个完成条件，Claude 自己一轮一轮地干下去，每轮结束由一个独立的小模型（Haiku）来判断条件是否满足，满足了自动停，不满足继续下一轮。你不用一直盯着按回车。
评估器（evaluator）只读对话记录，不跑命令也不读文件。它能判断的，只有 Claude 已经在对话里展示出来的东西。这条很关键，后面会反复提到。
条件写得好不好，直接决定 /goal 能不能正常停下来。官方文档给了一条原则：把条件写成 Claude 自己的输出能够证明的东西。
一个好的条件包含三样东西：终止状态（什么叫「做完了」）、检验方式（Claude 用什么命令来证明）、约束（过程中不能动什么）。缺第三条最容易出问题——比如你让它把测试跑通，它可能把测试文件删了来「通过」。
⚠️ 最后那句「or stop after 20 turns」不是可选的。没有轮次上限的话，如果任务卡住了，Claude 会一直跑下去，一直消耗 token。20 轮还是 30 轮看你的任务复杂度，但一定要加。
/goal 适合那种「任务本身需要反复确认结果」的工作。你让它改一个 bug，改完跑测试没过，再改，再跑，直到过了——这种循环以前你得手动按好几轮回车，现在 /goal 帮你自动化了。一次性的问答不需要用它，直接对话就够。
官方给了四个典型场景：
Claude Code 里有好几种让 AI 「自动往下跑」的方式，容易混。官方做了区分：
| 方式 | 下一轮怎么触发 | 什么时候停 |
|---|---|---|
/goal | 上一轮结束后自动 | 独立模型确认条件满足 |
/loop | 按时间间隔 | 你手动停，或 Claude 自判完成 |
| Stop hook | 上一轮结束后自动 | 你自己的脚本或 prompt 决定 |
| Auto mode | 不启动下一轮（仅单轮） | Claude 自判本轮工作完成 |
/goal 独特的地方在于那个独立的评估器。auto mode 只是在一轮内自动批准工具调用，不会自己启动下一轮。/goal 会。而且评估器是另一个模型（Haiku），不是 Claude 自己判断自己，多了一层制衡。
/goal 可以用 -p 参数直接从命令行传入，不需要打开交互式对话。整个循环在一次调用里跑到满足为止。
这个用法适合接到 CI 流程、定时脚本、或者后台批处理任务里。不需要人守着，跑完自动退出。中断的话 Ctrl+C。
还有一个细节：如果会话中断了，用 --resume 或 --continue 恢复时，goal 的条件会保留，但轮次计数、计时器和 token 消耗基准都重置。已经完成或手动清除的 goal 不会被恢复。
OpenAI 的 Codex CLI 也有 /goal 命令，但目前是 Experimental 状态，需要手动开启 features.goals = true。核心区别在三点：
Claude Code 有独立评估器。每轮结束由 Haiku 判断条件是否满足，不满足自动起下一轮。Codex 没有评估器，/goal 相当于把目标挂在线程上当参考，推进还是得你手动。
Claude Code 支持 headless 闭环。claude -p "/goal 条件" 传进去自动循环到满足。Codex 官方没有文档化这个用法，没有评估器也不会自动闭环。
成熟度不同。Claude Code 的 /goal 是正式发布，Codex 那边还是实验性的。
一句话：Claude Code 的 /goal 真正独特的形态是「headless 跑到外部条件满足」，靠独立评估器驱动。Codex 目前没有等价物。
第一，条件能不能被验证。如果评估器没法从对话记录里判断「做没做完」，goal 就不会自己停，你的 token 会一直在烧。
第二，加轮次上限。「or stop after N turns」写进条件里，不是建议，是必要的。
第三，想清楚约束。你要 Claude 做什么和不能动什么，都得说。不然它可能用你没预料到的方式「满足」条件。