配了三年 Claude Code，今天才发现它从来不是靠你一步步喂的——/goal 把这件事变成了自主循环

小智·AI工具控 内容创作者 2026-09-05 12 阅读

你今天花了多久盯着 Claude Code 的输出，等它问你要不要继续？

大多数人的 Claude Code 用法是这样的：提一个问题，等它回答，再提下一个。它就像一个超级实习生——每次只做一步，你需要全程扶着它走。

这件事，在今年五月被彻底变了。

/goal 是什么

/goal 是 Claude Code 2.1.139（2026 年 5 月 12 日）加入的一个命令，它的核心思想很简单：你告诉 AI 最终目标是什么，然后让它自己循环迭代，直到目标达成。

不再是一步一确认，而是设定终点，让 AI 自己跑。

# 最基本的用法
/goal all tests pass and CI is green

# 带次数上限
/goal all tests pass, stop after 10 tries

# 实时查看进度
/goal

你打 /goal 然后回车，Claude Code 就进入了自主循环：它规划、执行、检查结果、再规划、再执行——直到验证条件满足，或者达到你设定的上限。

它和 /loop 有什么区别

这是最常被问的问题。

/loop 是定时循环：每隔一定时间（比如每 5 分钟）跑一次相同的检查。适合”每隔半小时看看 CI 状态”这种场景。

/goal 是目标循环：一直跑到目标达成。适合”把认证模块的所有测试改绿”这种有明确终点的场景。

两者解决不同问题：/loop 解决的是”我要持续监控某件事”；/goal 解决的是”我要把这件事做完，不需要我一直盯着”。

而 /diff（09-03 那篇）解决的是”我想看见每一轮它到底改了什么”——那是透明性问题。

三件事是互补的，不是替代关系。

验证器机制：为什么它不会无限制跑下去

/goal 最关键的设计，是把”干活”和”验收”分开。

Claude Code 跑任务的那个模型，不负责判断目标是否达成。每次它觉得自己完成了，就停下来，把结果交给一个独立的验证模型去检查——默认用 Haiku 4。

这个验证模型看的是当前代码库的实际情况，不看对话记录。它判断条件是否满足，然后把结果告诉你：

  • Not yet met：条件还没达到，Claude 继续干，验证理由当成下一轮的改进方向
  • Met：目标达成，循环结束
  • Impossible：目标不可达，记录失败原因，等你重新设定

你可以在对话里看到每一轮验证的判断，按 Ctrl+O 可以读它的推理过程。

三个真实场景

场景一：修复历史遗留 bug

你有一个 module，五年没人动过，47 个测试，23 个失败。传统做法是每次改一点，跑测试，看结果，再改。一下午能修四五个就不错。

用 /goal：

/goal all 47 tests in test/auth pass, stop after 20 tries

然后你可以去开会，回来的时候它已经告诉你结果了——要么全部通过，要么它在第 15 轮卡住了，理由是”某个 mock 依赖外部服务，超时”。

场景二：代码重构达标

你想把某个旧模块重构完，但要保证重构后性能不降。

/goal Lighthouse score above 90, stop after 5 tries

它会自动调整实现，跑性能测试，验证分数，不满足就继续改。

场景三：无人值守的依赖升级

凌晨两点，你不想手动盯着 Claude Code 跑依赖升级。

/goal npm audit fix succeeds, stop after 3 tries

它跑了三轮，第三轮成功了。然后它会告诉你具体改了什么、为什么这样改。

不会跑成无限循环

/goal 内置了三个保护机制：

第一，错误清零。 环境问题（认证失败、积分用完、上下文溢出）会直接停止循环，不会无意义地重试。你修好问题，重新跑 /goal 就行。临时性错误（限速、服务器过载）不会触发停止。

第二，stall 检测。 如果 Claude 连续多个回合光说不练——只输出文字不动工具——循环会自动停止，提示你检查方向。

第三，预算可见。 打 /goal（无参数）可以实时看到当前轮次、已用时间和 token 消耗。你随时知道烧了多少钱。

非交互模式：直接进 CI

/goal 支持 -p 非交互模式，直接进 shell 脚本和 CI pipeline：

claude -p "/goal all tests pass" --cwd ./my-project

这意味着你可以在 GitHub Actions 里跑一个 job，让 Claude Code 自己把失败的单测修完，不占用你的 GitHub Actions minutes。

谁不适合用 /goal

/goal 要求目标可量化。”把页面做得更好看”不行；”Lighthouse 分数到 90 以上”可以。目标越具体，验证模型越能准确判断。

太模糊的目标会拖很久，或者验证模型始终返回”not yet met”，直到耗尽你的次数上限。这不是 bug，是设计：你设了一个无法客观判断的终点，AI 没办法替你决定什么时候停。

一个判断标准： 如果你不能用一句话把成功标准写出来，这个任务就不适合 /goal。

三步开始

  1. 确认你的目标可以被自动化验证（测试结果、CLI 退出码、分数阈值）
  2. 输入 /goal + 你的目标条件
  3. 去做别的事，回来查看结果

Claude Code 的进化方向一直很清楚：减少人工干预，把”重复确认”这件事彻底去掉。/goal 是这条线上目前最彻底的一步。

评论区

0 条评论

登录后可评论。

小智·AI工具控 12 阅读