Claude Code /goal 命令实战指南：设好终点线，然后去喝咖啡
上周有个朋友跟我吐槽：
"我用 Claude Code 重构一个模块，改了 17 个文件。每改完一个，我就得看看结果，敲回车让它继续。整整坐了三个小时，我就干了一件事——按回车。"
我问他："那你有没有想过，你其实可以说一句'把这 17 个文件都迁移到新 API，直到测试全绿'，然后去喝杯咖啡？"
他愣住了。
这就是 /goal 命令干的事。2026 年 5 月 12 日，Anthropic 在 Claude Code 2.1.139 版本中悄悄加了这个功能——不是一个花哨的新界面，不是一个炫酷的 Agent 编排框架，就是一行斜杠命令。但它改变了一件根本性的事情：你和 AI 之间的工作关系。
从"你一步步喂指令"，变成了"你说目标，它自己跑到终点"。
但这句话听起来简单，用起来有一堆讲究。什么样的 goal 写得好？它背后怎么判断"做完了没有"？什么任务适合交给它，什么任务会让它原地打转烧光你的 token？
今天就来聊透这些。
它到底解决了什么问题？
在没有 /goal 之前，你用 Claude Code 的工作方式大概是这样的：
你给它一个指令，它执行一步，回来问你"接下来呢？"。你再给指令，它再执行一步，再回来问你。一个需要 20 步才能完成的任务，你得交互 20 次。
这就像你坐在副驾驶，对着司机说："前面路口左转。好，现在直行 200 米。好，看到红绿灯了吗？右转。"
有了 /goal，你的交互方式变成了：
/goal all tests in test/auth pass and the lint step is clean一句话，说清楚终点在哪。然后 Claude 自己规划路线，自己开车，自己处理沿途的各种意外——文件冲突、类型错误、依赖缺失——直到抵达你定义的那个终点。
这不是导航仪帮你做建议。这是自动驾驶。
/goal 是"你说目的地，它自己把你送到"。看起来只是少打了几行字，本质上是从"操作者"变成了"指挥者"。
具体来说，/goal 的工作流是这样的：你输入一个完成条件（completion condition），Claude 立刻开始执行第一轮工作。每轮结束后，一个独立的小模型会检查："条件满足了吗？"如果没有，自动触发下一轮。如果满足了，停下来，把控制权还给你。
整个过程中，你可以随时用 /goal（不带参数）查看进度——已经跑了多少轮、用了多少 token、评估员最近一次的判断理由是什么。
一句话：/goal 不是让 AI "更聪明"，而是让 AI "不停下来"。这是两件完全不同的事。
怎么写一个好的 goal？
这是整篇文章最重要的部分。因为 /goal 的效果好不好，90% 取决于你那句 condition 写得好不好。
先看一个反面教材：
# 糟糕的 goal
/goal improve the authentication module"改进认证模块"？改进到什么程度算改进了？加个日志算改进吗？重构完但测试挂了算改进吗？评估员根本无法判断这个条件是否满足。
结果就是两种情况：要么 Claude 原地打转，一轮又一轮地"改进"，烧掉你大把 token；要么评估员随便判一个"已完成"，因为它找不到具体的否定依据。
再看正面案例：
# 优秀的 goal
/goal Refactor JWT validation in src/auth/middleware.ts to use the
TokenService class. npm test exits 0 and tsc --noEmit has no errors.
Do not modify any file outside src/auth/. Or stop after 20 turns.看到区别了吗？好的 goal 有四个要素：
一、一个可测量的终态。"npm test exits 0" 是可测量的，"代码更好了"不是。Claude 会在执行过程中跑测试，测试结果会出现在对话记录里，评估员就能据此判断。
二、一个明确的验证方式。你得告诉 Claude 怎么证明它做完了。"tsc --noEmit has no errors"就是在说：你跑一下 TypeScript 编译器，没报错，就算过了。
三、不能动的边界。"Do not modify any file outside src/auth/"——这条约束防止 Claude 为了让测试通过而"创造性地"去改其他模块的代码。别笑，它真的会这么干。
四、一个刹车条件。"Or stop after 20 turns"——这是你的保险丝。没有这条，如果 Claude 卡在一个死循环里，它会一直跑下去，直到你发现或者按 Ctrl+C。
/goal 的 condition 最多支持 4000 个字符。但这不意味着你应该写一篇小作文。好的 condition 应该像一条好的测试断言：短、准、可验证。模糊的目标烧掉的不是时间，是你的 token 账单。
还有一个很多人忽略的细节：评估员只能看到 Claude 在对话中已经输出的内容。它不会自己去读文件，不会自己跑命令。所以你的 condition 必须是 Claude 的输出能够证明的。
比如，"所有 getUser 调用点都改成了 fetchUser"——Claude 可以跑一个 grep 来证明，grep 的结果会出现在对话里，评估员就能看到。但如果你写"代码风格符合团队规范"，评估员就没法判断了，因为它不知道你的团队规范是什么。
写 /goal 的黄金法则：如果你不能用一条命令的输出来验证它，它就不是一个好的 condition。
背后的"评估员"是谁？
这可能是 /goal 设计中最巧妙的部分。
你有没有想过一个问题：Claude 自己怎么知道它做完了？如果让做题的人自己判卷，它当然觉得自己做得很好。所以 Anthropic 做了一个关键设计——做题的和判卷的不是同一个人。
每次 Claude 完成一轮工作后，你的完成条件和整个对话记录会被发送给一个小而快的模型——默认是 Haiku。这个模型只做一件事：读对话，看条件，回答"满足了吗？"，给一个 yes/no 和一个简短理由。
如果答案是 no，这个理由会被反馈给 Claude，作为下一轮工作的指引。比如评估员可能会说："测试还有 3 个失败：test_login_expired、test_token_refresh、test_session_cleanup。"Claude 就知道接下来该修什么了。
如果答案是 yes，goal 自动清除，对话记录中会标注一条"achieved"。
这个设计有三个好处：
第一，避免自我验证的偏差。如果让 Claude 自己判断"我做完了"，它很可能在第三轮就宣布胜利——毕竟 LLM 天然有一种"讨好用户"的倾向。独立的评估员不在乎 Claude 的感受，只看结果。
第二，评估成本极低。Haiku 是一个快且便宜的模型，评估一次消耗的 token 与主工作轮次相比微乎其微。你不用担心"评估本身"会成为成本大头。
第三，评估理由是天然的调试工具。你随时可以用 /goal（无参数）查看评估员最近的理由。如果你发现同一个理由连续出现了三轮，说明 Claude 卡住了，你该介入了。
/goal 本质上是一个 session 级别的 prompt-based Stop hook 的封装。如果你想更精细地控制评估逻辑——比如用脚本而不是模型来判断——你可以直接在 settings 里配置自定义的 Stop hook。但对 99% 的场景来说，/goal 就够了。
做题的和判卷的分开，这不是偷懒，这是工程上的优雅。AI 系统中，最危险的事情就是让执行者自己评估自己。
哪些任务适合交给它？
不是所有任务都适合交给 /goal。这一点很关键。
我总结了一条判断标准：凡是你能写出验收标准的任务，都能交给 /goal。
什么叫"能写出验收标准"？就是你能说出一句话，让一个不了解项目的人也能判断"做完了没有"。
来看五个真实场景：
场景一：API 迁移
你要把一个模块里所有 v1 API 调用迁移到 v2。这可能涉及 20 个文件、50 个调用点。
/goal Migrate all v1 API calls in src/services/ to v2 SDK.
grep -r "api/v1" src/services/ returns no results.
npm test exits 0. Stop after 30 turns.完美适合 /goal。终态清晰（没有 v1 调用 + 测试通过），可机器验证（grep + npm test），范围明确（src/services/ 目录）。
场景二：测试驱动重构
/goal Refactor UserService to separate read and write operations
into UserQueryService and UserCommandService. All existing tests
pass. No file exceeds 300 lines. Stop after 25 turns.这种"测试当护城河"的场景是 /goal 的主场。Claude 可以大刀阔斧地重构，只要测试全绿，评估员就放行。
场景三：批量修复 lint 错误
/goal Fix all ESLint errors in src/. npx eslint src/ --max-warnings 0
exits 0. Do not change any test files. Stop after 15 turns.这种机械性的批量修复工作，人做起来枯燥到想打瞌睡，/goal 做起来一轮接一轮，不抱怨不走神。
场景四：文档生成
/goal Add JSDoc comments to all exported functions in src/utils/.
Every .ts file in src/utils/ has JSDoc on every export.
Stop after 20 turns.场景五：Issue 清队列
/goal Work through all GitHub issues labeled "good-first-issue" in
this repo. For each issue, create a fix, run tests. Continue until
no open issues with that label remain. Stop after 40 turns.但有一类任务你绝对不应该交给 /goal：
需要主观判断的任务。"让 UI 更好看"、"优化用户体验"、"提升代码质量"——这些都是人类才能判断的事情。评估员没法替你做审美决策。
探索性的研究任务。"调研一下市面上的状态管理方案"——这没有明确的终态，Claude 可以无限调研下去。
需要频繁人工决策的任务。如果每隔两步就需要你做一个架构决策，那 /goal 只会让你更晚发现问题。
一句话：/goal 是自动驾驶，不是自动设计。你负责"去哪"，它负责"怎么去"。
什么时候它会翻车？
说了这么多好的，该聊聊坑了。
/goal 最常见的翻车场景只有一个词：死循环。
什么时候会出现死循环？当 Claude 修了 A 问题导致 B 问题，修了 B 又引出 A 的时候。这在复杂的类型系统或相互依赖的模块中特别常见。
我见过一个真实案例：有人让 Claude 把一个大文件拆成小模块，要求"所有模块编译通过"。Claude 拆完之后发现循环依赖，修循环依赖的时候又破坏了类型定义，修类型定义的时候又引入新的循环依赖。跑了 30 轮，token 烧了一大笔，文件改得面目全非。
怎么防？三个办法：
第一，永远加轮次上限。or stop after 20 turns 是你的安全网。没有它，/goal 真的会一直跑下去。
第二，盯着评估员的理由。用 /goal（无参数）查看状态。如果连续三轮的理由没变化，说明 Claude 在原地踏步。果断 /goal clear，换个策略。
第三，不要贪心。"重构认证、加 OAuth、写测试、更新文档"——这是四个目标，不是一个。把复杂任务拆成一串独立的 /goal，每个都有自己的验收标准。
/goal 没有内置的 token 预算。这意味着如果你不设轮次上限，一个死循环可能会消耗数万甚至数十万 token。在你熟悉它的行为模式之前，建议从 stop after 10 turns 开始试，逐步调大。
另一个容易忽视的坑：版本控制。
在启动 /goal 之前，确保你在一个干净的 Git 分支上。/goal 做的所有修改都是真实的文件操作，不是沙盒。如果跑了 20 轮之后发现方向错了，你得有办法一键回退。git stash 或者在新分支上操作是最基本的安全措施。
没有刹车的自动驾驶，不叫自动驾驶，叫自杀。给你的 /goal 装上刹车——轮次上限、干净分支、实时监控。
和其他自治方案怎么选？
Claude Code 目前有三种"让 AI 自己干活"的方案。很多人搞混了，这里帮你理清。
| 方案 | 下一轮触发条件 | 什么时候停 | 适合场景 |
|---|---|---|---|
/goal | 上一轮执行完毕 | 评估员确认条件满足 | 有明确终态的任务 |
/loop | 时间间隔到了 | 你手动停止或 Claude 判断完成 | 周期性巡检、监控 |
| Stop hook | 上一轮执行完毕 | 你的脚本或 prompt 判断 | 需要自定义评估逻辑 |
简单说：/goal 是"跑到终点就停"，/loop 是"每隔 5 分钟检查一次"，Stop hook 是"你自己写规则来判断停不停"。
还有一个容易忽略的配合关系：/goal 和 Auto mode 是互补的。
Auto mode 解决的是"单轮内不要反复问我要不要执行这个工具调用"。/goal 解决的是"轮与轮之间不要问我要不要继续"。两个一起用，Claude 才能真正实现全自动。
你还可以在非交互模式下使用 /goal：
# 非交互模式：CI/CD 或脚本中使用
claude -p "/goal CHANGELOG.md has an entry for every PR merged this week"这意味着你可以把 /goal 集成到你的 CI 流程里——比如每次合并 PR 后自动更新 CHANGELOG，直到覆盖所有本周的合并。
/goal 跑完之后，用 --resume 恢复会话查看结果。如果 goal 是在运行中断的（比如笔记本合盖了），--resume 会自动恢复未完成的 goal，轮次计数和 token 统计从零开始重新计算。
选择的核心原则：如果你能写出一个"完成条件"，用 /goal。如果你需要周期性执行，用 /loop。如果你的判断逻辑复杂到需要写脚本，用 Stop hook。
你的第一个 /goal 挑战
聊了这么多，核心就一件事：/goal 让你从"AI 的操作员"变成了"AI 的指挥官"。你不再需要一步步告诉它怎么做，只需要说清楚"做到什么程度算完"。
今天回去试一件事：
打开你的项目，找一个你一直想做但嫌麻烦的任务——可能是给所有导出函数加 JSDoc，可能是把某个模块的 v1 API 调用迁移到 v2，可能是修完所有 lint 警告。
然后，用这个模板写你的第一个 goal：
/goal [具体做什么]. [怎么验证做完了].
[不要改动什么]. Stop after 15 turns.跑起来，然后去泡杯咖啡。
如果回来的时候发现目标达成了——恭喜，你刚刚把三小时的枯燥工作变成了一句话。
如果没达成——看看评估员卡在了什么理由上。这个理由本身就是最好的调试线索，也是你理解 AI 能力边界的第一手资料。
无论结果如何，你都迈出了最重要的一步：从亲自干活，到学会指挥 AI 干活。
这不是偷懒。这是进化。