跳转到内容

Claude Code /goal 命令:给一个完成条件,让它自己跑到达标

约 10 分钟 难度:进阶 动手章

/goal <完成条件> 设定后立即用这个条件启动一轮;每轮结束后,一个独立的小模型(Claude API 上默认 Haiku)判断条件是否满足,不满足就自动继续下一轮,满足就清除 goal 并标记为「已达成」。它和 /loop 最大的区别:/loop 靠固定时间间隔驱动、有 7 天强制过期;/goal 靠「条件是否达标」驱动,官方文档里没有设默认的轮数或时长上限——这也是为什么它能被随手挂着跑一两天:只要终端进程别断、条件别被判定为满足,它就会一轮接一轮跑下去。真正限制它能跑多久的不是某个内置计时器,而是终端/进程要不要保持存活、以及要不要人工确认工具调用。

  • 命令格式/goal <条件描述>,比如 /goal all tests in test/auth pass and the lint step is clean
  • 已有活跃 goal 时,新设定的会直接替换旧的,不是叠加。
  • 长度上限:条件描述最多 4000 字符。
  • 有效条件的三要素
    1. 可衡量的终态(测试结果、构建退出码、文件数量……)
    2. 明确的验证方式(比如「npm test exits 0」)
    3. 必须保持不变的约束(比如「不修改其他测试文件」)
  • 想限制轮数或时长,必须主动写进条件里,比如「... or stop after 20 turns」——不写就没有上限。
项目说明
触发时机每轮(turn)结束后
评估模型Claude API 上默认 Haiku;第三方 provider 上用该平台配置的小型快速模型
自定义评估模型环境变量 ANTHROPIC_DEFAULT_HAIKU_MODEL(注意:这个变量是全局生效的,还会影响对话摘要等其他后台功能,不止 /goal
评估器权限不能调用工具,只能基于对话里已经展示的内容判断,不会自己去跑命令或读文件
结果处理No:继续下一轮,评估理由作为下一轮参考;Yes:清除 goal,标记「已达成」
评估花费计入小型快速模型用量,相对主模型花费通常可忽略
对比维度/goal/loop
下一轮启动条件上一轮结束后立即判断时间间隔到达后
停止条件评估模型确认条件已满足用户手动停止,或 Claude 自行判断完成
判定者独立的评估模型,每轮判断一次执行任务的模型自己判断
适用场景有明确可验证终态的任务需要按固定间隔重复执行的任务

还有一种更底层的方式是 Stop Hook:触发时机同 /goal(每轮结束后),但停止判定由你自己的脚本或提示词决定(可以是确定性检查,也可以是模型评估),配置在 settings 文件里,作用范围是所有会话/goal 只作用于当前会话,是对 Stop Hook 的一层快捷封装。三者不冲突:auto mode 解除单次工具调用的确认,/goal/Stop Hook 解除单轮之间的确认,是互补关系。

  1. 交互模式:正常在 CLI 里输入 /goal <条件>

  2. 非交互模式(-p

    claude -p "/goal CHANGELOG.md has an entry for every PR merged this week"

    默认文本输出下,条件未达成前不会打印任何内容,看起来像卡住了,建议加 --output-format stream-json --verbose 实时查看每条消息。用 Ctrl+C 中断未完成的 goal。

  3. Remote Control 与桌面客户端:同样支持 /goal

  • --resume--continue 恢复会话时,若结束时 goal 仍活跃,条件会被保留,但轮数计数、计时器、token 花费基线都会重置
  • 已达成或已被清除的 goal 不会被恢复。
  • /clear 开新对话会移除当前活跃的 goal。
操作命令说明
设定/goal <条件>已有活跃 goal 会被替换
查看状态/goal(不带参数)显示条件内容、已运行时长、已评估轮数、当前 token 消耗、评估器最近一次的理由
清除/goal clear同义词:stopoffresetnonecancel

官方文档里没有「暂停」命令,只有设定、查看状态、清除三种操作。

  • 版本需 Claude Code v2.1.139 及以上。
  • 工作区必须已通过 trust dialog 信任(评估器依赖 hooks 系统)。
  • 以下情况会导致 /goal 不可用(会提示原因,不是静默失败):任意设置层级启用了 disableAllHooks;managed settings 里设了 allowManagedHooksOnly
  • 官方文档没有直接说明上下文窗口/自动压缩对评估准确性的具体影响——评估器依赖「对话里已展示的内容」,如果上下文被压缩,理论上可能影响判断,但这是推测,不是文档原文,没有做过本机复现。
  • 「终端/进程必须保持存活」这条是从非交互模式的行为描述里推出来的,文档没有直接下这个结论,也没有本机验证过关掉终端后 goal 是否真的会中断。
  • 没有做过真正挂 48 小时以上的本机复现,本篇内容全部来自官方文档,实际长跑表现(比如评估器是否会因为长对话而判断变差)留待后续验证。
这一节有错或讲不清? 提个 Issue 直接改文档 请作者催更