5 月初有个开发者发了个截图，看完我倒抽一口气：他用 Claude Code 的新命令 /goal 让 AI 自己跑一个看似简单的任务，回来一看，14 小时，账单 200 美金。
任务最后没做完。
这件事的背景，是过去两周 AI 编程工具圈的一个安静拐点：
- 4 月底 ，OpenAI 给 Codex CLI 加了
/goal命令（v0.128.0）。 - 5 月 11 日，Anthropic 在 Claude Code v2.1.139 上线了同名同形态的命令。
- 5 月中 ，第三方甚至已经做出了
claude-goal这种带持久化的开源加强版。
我把两边的官方文档、开发者测评、踩坑案例全部撸了一遍。看完一句话总结：
/goal 不是一个 slash 命令，是 AI 编程的操作范式从"对话式"切换到"代理式"的标志性事件。
但它打开的是潘多拉盒子。这篇我把"它到底是什么、怎么用、什么时候用、怎么不翻车"讲清楚，并给你一个可复用的3-Check 终点线框架。
一、/goal 解决了什么------一个被忽视的瓶颈
过去你用 Claude Code 或 Codex CLI 是这样的：
erlang
你：把 auth 模块迁移到新 API
AI：好，我看一下...（动了 5 个文件）✅完成第一轮
你：继续，跑一下测试
AI：测试失败 3 个 ✅完成第二轮
你：修一下
AI：✅完成第三轮
你：lint 也跑一下
...每一轮你都得回来按一下"继续"。哪怕你把 auto-approve 打开了，AI 跑完一回合还是会主动停下来等你。
为什么会停？因为模型自己不知道"我是不是干完了"。任务完成的判断权一直在你手里。
/goal 直接干掉这个瓶颈。它让你一次性把"终点线"写下来，然后 AI 自己跑，自己判断到没到终点。
写法长这样（两边语法几乎一样）：
bash
/goal all tests in test/auth pass and the lint step is clean设完之后：
- AI 立刻开干，不需要你再发一句"开始"
- 每跑完一轮，一个独立的小模型 会读完整个对话记录，回答一个问题："条件满足了吗？"
- 没满足，AI 自己接着跑下一轮；满足了，循环关掉，告诉你"done"
这是从"对话式协作"到"代理式自治"的真正切换。操控权从"每一步"上交到"终点线定义"这一步上。
二、Codex 和 Claude 的 /goal 长啥样------对比与差异
这两个工具的 /goal 命令形态高度一致------其实是行业共识在落地。但内部设计有差异，影响你选哪个：
| 维度 | Codex /goal |
Claude Code /goal |
|---|---|---|
| 上线时间 | v0.128.0（4 月底） | v2.1.139（2026-05-11） |
| 评估者模型 | 内置小型 validator | Haiku（可配置 small fast model） |
| 状态管理 | 持久化、可跨会话 pause/resume | 单会话生效，可 --resume 续跑 |
| 控制命令 | /goal pause、/goal resume、/goal clear |
/goal clear（别名：stop/off/reset/cancel） |
| 评估者反馈 | yes/no | yes/no + 一句话理由，作为下一轮提示 |
| 与官方文档 | 文档不全，部分版本看不到 | 官方文档完整，含写法指南 |
| 多目标 | 单线程一个 goal | 单会话一个 goal |
两个关键区别值得记住：
-
Claude 的 evaluator 会"递理由"。它不只告诉 AI "没完成"，还会附一句"还有 3 个测试失败"，下一轮 AI 就拿这句话当指引。这让循环收敛更快。
-
Codex 的 goal 是持久的状态 。它把目标存进 thread-level state，崩了、重启了、跨天了，依然存在。Claude 的 goal 在会话内有效，要靠
--resume才能续。
实战上：
- 想搞多天迁移、跨环境部署这种长周期工程 → Codex
- 想搞几小时内能完成的代码任务，并且看重代码质量 → Claude Code
三、工作原理------为什么是"两个模型互相检查"
这是 /goal 设计上最巧妙的地方。
很多人第一反应是："AI 自己判断有没有完成？那它肯定会觉得自己完成了啊。"
确实。大模型的"自我评估"是出名的不靠谱------它会觉得测试通过了（其实没跑）、觉得代码改完了（其实漏了几个文件）、觉得目标达成了（其实只做完一半）。
所以 /goal 用了一个关键的分权设计：
干活的模型（Opus/GPT-5 级别） ←独立→ 判终点的模型（Haiku/小模型）干活的负责执行。判终点的只读对话记录，不能调用工具，只回答一个问题：条件满足了吗？
这种主审分离避免了一个模型既当裁判又当运动员。
但这设计也带来了一个关键限制：
评估者只能看到对话里出现的东西 。如果 Claude 说"我觉得测试都过了"，但实际没跑
npm test，评估者无法判断。
所以你的条件必须可以被 AI 的输出"证明"。"测试通过"行，因为 AI 会跑测试、把结果打印出来；"代码写得优雅"不行，因为这事 AI 嘴里说一句"优雅"，评估者只能信。
四、3-Check 终点线框架------核心可复用工具
写好 /goal 条件这件事，决定了你是 20 分钟干完一件事，还是 14 小时烧 200 美金。
下面这个框架是我把 Anthropic 官方文档 + 多个开发者实战总结归一化出来的。每条 /goal 命令在执行前，过一遍这 3 关 + 1 个保险：
Check 1：可观测的终点（Measurable End State）
终点线必须是外部可观测的，不能是"感觉良好"。
- ❌ 「代码变好了」「应用准备上线了」
- ✅ 「
test/auth目录下所有测试通过」 - ✅ 「
CHANGELOG.md里每条本周合并的 PR 都有一行记录」 - ✅ 「
src/下每个文件少于 300 行」
判断标准：如果一个陌生人接手你的电脑，他能用一个命令检查"完成了没"吗？ 能就过关。
Check 2：明示的验证方式（Stated Check）
不能假定 AI 知道怎么验证，要把用什么命令、看什么输出写出来。
- ✅ 「
npm test退出码为 0」 - ✅ 「
tsc --noEmit无报错」 - ✅ 「
git status干净」
这一关的本质：让评估者只需要"读"，不需要"猜" 。AI 跑了 npm test 把结果贴进对话，评估者一眼就能判。
Check 3：约束护栏（Constraints）
明确写出不许改什么、不许动什么 。/goal 跑起来后没有人盯着，你必须提前画好雷池。
- ✅ 「除了
payment/下的文件，不许改其它任何文件」 - ✅ 「不许新增 npm 依赖」
- ✅ 「不许修改测试用例本身」
不写这条的代价：AI 可能会通过"删掉失败的测试"来让"测试通过"成立。是的，真的有人遇到过。
+ 1 保险：硬性截止条款（Hard Cap）
这一条不写，等于给信用卡画了张空白支票。
在条件最后加一句兜底，让评估者看到时间/次数到了直接收工：
arduino
... or stop after 30 turns
... or stop after 60 minutes
... or stop after 100K tokens consumed这个简单的兜底，能把 14 小时 200 美金的事故压到 30 分钟 5 美金。
一个完整的好条件长什么样
错误示范（已知踩坑）：
bash
/goal make the auth tests pass正确示范：
bash
/goal all tests in test/auth pass (npm test exits 0),
no other test files are modified,
git diff contains only files under src/auth/,
or stop after 25 turns照着这个套路写，你的 /goal 跑起来基本不会失控。
五、适合场景 vs 不适合场景
整理两边官方文档和上百个实战案例，结论清晰：
✅ 高成功率场景（建议放心用）
- 测试驱动的修复/迁移 ：终点是
pytest/npm test通过 - 代码尺寸约束的拆分：终点是每文件 < N 行
- 批量处理 Issue 队列：终点是 backlog 清空
- 文档/配置生成：终点是文件存在且 lint 通过
- API 迁移：终点是 build 通过且 grep 不到旧调用
⚠️ 高风险场景（别用 /goal，用普通对话）
- UI 打磨、视觉设计：评估者读不出"好不好看"
- 业务判断：要不要砍这个功能，AI 自己定不了
- 数据迁移、删除操作：跑岔了不可逆
- 跨多个不相关系统：评估者撑不住复杂度
- 没有清晰"完成"定义的探索性工作：会陷入死循环
六、为什么这件事是 AI 编程的真正分水岭
回到那个 200 美金的故事。
如果这只是一个 slash 命令、一个工具更新，开发者社区不会这么炸。它真正撬动的，是AI 编程的操作单位变了：
- 2022-2024：操作单位是「一个 prompt」------你问一句，它答一句
- 2024-2026 早期：操作单位是「一个 turn」------你给任务，它做一回合
- 2026 年 5 月起：操作单位是「一个 goal」------你画条线，它自己跑到达成
每一次升级，你需要管的颗粒度变粗了，但每个颗粒度内 AI 的自治权变大了。
这就是为什么 OpenAI 和 Anthropic 在 14 天内做出几乎一样的命令------他们不是在抄对方，他们是在响应同一个产业拐点 ：当模型能力强到一定程度，人在循环里的位置必须往上提。
人的角色从"每一步审查者"变成"终点线定义者"。这不只是效率问题------是写软件这件事本身的范式变化。
老经验里有句话叫"问得好比答得好重要"。在 /goal 时代，写终点线比写需求重要。
七、上手行动清单（今天就能做）
不论你用 Codex 还是 Claude Code：
- 先升级到 Codex 0.128.0+ 或 Claude Code 2.1.139+
- 挑一个低风险任务试水：比如"补全测试覆盖率"或"把 console.log 全部改成 logger.info"
- 用 3-Check 框架写条件：可观测 + 验证方式 + 约束护栏
- 必加兜底 ：
or stop after 20 turns------记住，第一次跑用 20 turn 帽，不要直接给 200 - 盯一下前 10 分钟 ：看 evaluator 给的理由是不是合理，方向跑偏了立刻
/goal clear - 跑成功了再放心走开：连续 3 次 30 分钟内成功完成后，再尝试通宵跑
- 不要用免费/低额度账号跑长任务：账号没硬上限，你也没法睡安稳
最后
我在文章开头说 200 美金的故事，不是为了吓你不要用 /goal。
恰恰相反：它是 2026 年最值得你立刻投入学习的一个工具。但有一个判断框架的人和没有的人，在使用同一个工具时，结果是 5 美金和 200 美金的差别。
/goal 不会取代你写代码，但它会取代你"盯着 AI 写代码"这件事。剩下的时间你拿去做什么，决定了你能不能在这一轮 AI 工具升级里真的拉开差距。
终点线，是你今天最应该练的一项写作技能。
参考资料：