继 Codex 在 2026 年 4 月推出 /goal 之后，Anthropic 也在 5 月通过 Claude Code 2.1.139 上线了同名命令。这是一个让 Claude 「不达目标不罢休」的新工作流：只要你在会话里写下一个完成条件，Claude 会在每轮结束后自动让一个小型快速模型判断目标是否达成，没达成就继续下一轮，直到条件满足才把控制权交还给你。
本文系统讲清楚 Claude Code goal 模式的 6 大要点，包括评估器循环工作机制、与 /loop 和 Stop hook 的区别、有效条件的写法、3 种模式（interactive / -p / Remote Control）、风险与最佳实践。
核心价值: 读完本文，你将能在 10 分钟内把团队的代码迁移、issue 清理、文档验收等长周期任务交给 Claude Code goal 模式自动完成，并知道在哪些场景下应该改用其他自主工作流。
Claude Code goal 模式核心要点
在动手之前，先把 Claude Code goal 模式的 6 个关键事实摆清楚。这 6 点决定了你写出来的条件能不能正确执行，也决定了你应不应该选用 /goal 而不是其他自主工作流。
| 要点 | 内容 | 影响 |
|---|---|---|
| 命令格式 | /goal <condition> |
直接在会话里设置，无需配置文件 |
| 评估器 | 默认 Haiku 小型快速模型 | 由「另一个模型」判断完成度，独立于干活的模型 |
| 作用域 | 当前会话 (session-scoped) | 不会影响其他会话，更适合临时任务 |
| 触发节奏 | 每轮结束后立即评估 | 完成即停，没完成就启动新一轮 |
| 条件上限 | 最长 4000 字符 | 可以容纳详细验收标准 |
| 退出方式 | 评估通过 / /goal clear / Ctrl+C |
三种退出路径，主动 + 被动结合 |
很多用户第一次看到 /goal 会想到普通的循环命令，但它本质上是 Anthropic 把 prompt-based Stop hook 封装成了会话级别的快捷指令。这个底层定位决定了它和传统的 cron 风格自动化非常不同。
如果你的团队还没有用过 Claude Code 的高级 Hook 机制，可以先通过 API易 apiyi.com 平台体验 Claude Sonnet / Opus / Haiku 的 API，熟悉 Anthropic 的工具链生态，再升级到 Claude Code 自身的 goal 模式会更顺手。
Claude Code goal 模式工作机制详解
要正确使用 /goal，必须搞清楚它每一轮发生了什么。官方文档把整个机制描述为「在每轮结束后追加一个评估器」，看起来简单，但细节决定了它的能力边界。
主模型负责干活，小型快速模型负责判断完成。两个模型分工的好处是评估者保持中立、用更便宜的算力做决策；坏处是评估器只能读到主模型已经在对话里展现的内容，看不到文件系统或外部命令的真实状态。
每轮结束后的判断流程可以拆成 4 步：
- 打包上下文：把当前 condition 和整段对话转录发给评估器
- 模型决策：评估器返回一个 yes/no + 一句 reason
- 路由分流：no 把 reason 作为指导发回主模型继续干活，yes 自动清除目标并标记 achieved
- 指示器刷新：UI 上的
◎ /goal active持续显示 elapsed、turns、tokens 三个指标
写条件时一定要记住第 1 步的限制：评估器只看转录，所以条件必须是「主模型能在对话里证明的事」。例如「npm test 退出码为 0」是好条件，因为主模型会运行测试并把结果贴回来；「生产环境的数据库没有脏数据」是坏条件，因为它无法从对话里得到验证。
评估器的成本通常可以忽略不计。Haiku 系列的单价远低于 Sonnet/Opus，每轮只评估转录摘要，整段长会话也只产生少量 token 消耗。需要进一步压低评估器成本的团队，可以通过 API易 apiyi.com 把 Claude Code 的小型快速模型指向 Haiku 4.5 或 Haiku 3.5，并按 workspace 维度做配额控制。
Claude Code goal 模式与其他自主工作流的对比
Claude Code 一共提供了 4 种把会话「跑下去」的机制，新手最容易把它们混在一起。下表把 4 个机制按触发条件、停止条件、典型场景对齐，便于选型。
| 机制 | 触发节奏 | 停止条件 | 适用场景 |
|---|---|---|---|
/goal |
上一轮结束即触发 | 评估器判定条件达成 | 有明确验收标准的长任务 |
/loop |
固定时间间隔触发 | 用户手动或 Claude 判定完成 | 周期性轮询、状态检查 |
| Stop hook | 上一轮结束即触发 | 用户脚本或自定义 prompt 判定 | 团队级别、跨会话生效 |
| Auto mode | 单轮内的工具调用 | 当轮工具序列结束 | 减少每个工具的确认弹窗 |
要点是 /goal 和 Stop hook 几乎做同一件事，但 /goal 只对当前会话生效、可以在终端里临时输入。Stop hook 要写进 settings 文件，作用范围是整个 scope 的所有会话，更适合团队级别的硬性约束。
Auto mode 和 /goal 完全互补：Auto mode 处理「一轮内不停被工具确认打断」的问题，/goal 处理「需要跨多轮才能完成」的问题。在长任务里把这两个机制叠加使用，整个流程几乎可以做到无人值守。对于没在自有环境跑 Claude Code 的团队，可以先通过 API易 apiyi.com 把 Claude 接入到本地脚本里测试相同的循环逻辑，再决定是否升级到完整的 Claude Code 工具。
Claude Code goal 模式有效条件的 3 大要素
条件写得不好，是 /goal 真正失败的主因。Anthropic 官方文档明确指出，一个能撑住几十轮的好条件，必须同时具备 3 个要素。
第一是 一个可测量的终点。终点必须是离散、可观察的事件：测试退出码、文件数量、队列剩余条目、构建是否绿。模糊的指标会让评估器在 yes/no 之间反复横跳，让 /goal 退化成无穷循环。
第二是 明确的验证方式。条件里要直接写明 Claude 应该如何证明终点已经达到，例如「npm test 输出包含 PASS」「git status 输出为空」。验证方式越具体，评估器越不容易被表述歧义骗过。
第三是 不能改变的约束。如果某些文件、某些配置必须保持不变，要在条件里直接禁止，例如「不要修改 tests/legacy/ 下任何文件」。这样可以避免主模型为了「过关」而做出破坏性改动。
把 3 个要素组合起来，一个高质量的 /goal 条件大致长这样：「所有 tests/auth 下的测试通过、且 npm run lint 退出码为 0，不要修改 tests/legacy/ 任何文件，最多运行 20 轮」。最后的「最多运行 20 轮」是一个推荐的兜底，防止极端情况下 /goal 无限循环。
由于条件支持最长 4000 字符，你完全可以把一个迷你 PRD 塞进去。如果你正在用 API易 apiyi.com 平台调用 Claude 模型做 Agent 调度，也可以借鉴这套写法来设计你自己的评估器 prompt，让 Agent 的停止条件同样清晰可测。
Claude Code goal 模式 3 种运行模式实战
/goal 同时支持 interactive、非交互 (-p) 和 Remote Control 三种调用方式。掌握这三种用法，才能把它真正放进 CI、本地脚本和远程协作的实际工作流。
交互模式快速上手
# 在 Claude Code 会话里直接键入
/goal all tests in test/auth pass and the lint step is clean, or stop after 20 turns
设置完之后，UI 上会出现 ◎ /goal active 指示器，实时显示 elapsed、turns、tokens 三个指标。任何时候输入 /goal 不带参数都可以查看状态，输入 /goal clear（或 stop / off / reset / none / cancel 别名）可以提前终止。
非交互模式（适合 CI）
claude -p "/goal CHANGELOG.md has an entry for every PR merged this week, or stop after 15 turns"
-p 模式会让 /goal 一直跑到条件满足或者你用 Ctrl+C 中断为止，非常适合塞进 GitHub Actions、GitLab CI、Jenkins Pipeline 等自动化流程。如果你正在通过 API易 apiyi.com 做 Claude API 的统一调度，也可以把同样的循环模式封装成自有脚本，让非 Claude Code 客户端也享受类似能力。
会话恢复
claude --resume <session-id>
# 或
claude --continue
恢复会话时，active 状态的 goal 会被一起带回来，但 turns / timer / token 三个计数会从 0 重新开始。这条特性对长周期重构特别友好：周末关掉电脑也不怕中断，周一接着开就行。
查看常见目标条件模板（点击展开）
# 模板 1: 代码迁移
/goal migrate all usages of legacy_api.* to new_api.* in src/, run npm test until exit 0, do not modify tests/legacy/, or stop after 30 turns
# 模板 2: Issue backlog 清理
/goal close all GitHub issues labeled "needs-triage" by either resolving or relabeling, run gh issue list --label needs-triage and verify the output is empty, or stop after 25 turns
# 模板 3: 设计文档验收
/goal implement every acceptance criterion in docs/design.md, prove each by referencing the exact section, do not edit docs/design.md itself, or stop after 40 turns
# 模板 4: 文件拆分
/goal split src/megafile.ts into modules under src/parts/ where each file is < 300 lines, run npm run typecheck until exit 0, or stop after 20 turns
Claude Code goal 模式风险与最佳实践
/goal 把决定权交给了模型，所以风险点和传统命令完全不同。下表是当前最值得重视的 4 类风险及对应的缓解动作。
| 风险 | 触发条件 | 缓解动作 |
|---|---|---|
| 成本失控 | 评估器误判或条件过于宽松 | 条件里加入「or stop after N turns」上限 |
| 评估器幻觉 | 条件无法从转录验证 | 用「跑 X 命令验证 Y 输出」的可观察句式 |
| 破坏性改动 | 主模型为通关而修改不该动的文件 | 在条件里加入「do not modify …」约束 |
| 工作区误用 | 在未授信的环境意外触发 | 必须接受 trust dialog；可用 disableAllHooks 一键禁用 |
第一个风险最直接。Codex 和 Claude Code 当前都没有「按目标设置支出上限」的官方能力，长任务一旦失控很容易跑出比预期高一个量级的 Token。最稳的做法是把 turns 上限直接写进条件，再叠加平台层面的预算告警。
为评估器准备稳定的小模型也很关键。如果你的小型快速模型走的是 Haiku，那么评估速度和成本都比较可控；如果走到 Sonnet 这种偏大的模型，整个 /goal 的评估开销会显著上涨。开发团队可以通过 API易 apiyi.com 平台单独为 Haiku 配置一份 base_url 与配额，把评估器和主模型的成本完全分离监控。
最后是合规要点。/goal 依赖 Anthropic 的 Hook 系统，要求工作区接受过 trust dialog，并且 disableAllHooks 或 allowManagedHooksOnly 未被设置。如果团队用统一的管理策略禁掉了 Hook，那 /goal 也会被一并禁用，命令会直接告诉你原因而不是静默失败。
常见问题
Q1: /goal 和我自己写一个 while 循环脚本相比，多了什么？
多了一个独立的、由模型驱动的评估器。自写 while 循环必须靠你自己定义停止条件并写代码判定，/goal 则把判定交给小型快速模型，可以处理「让模型读对话理解是否完成」这类非程序化的场景。
Q2: 使用 /goal 是不是很容易烧 Token？
风险存在但可控。两个建议：一是条件里强制写 turns 上限，二是把评估器固定到 Haiku 小模型。通过 API易 apiyi.com 接入 Claude 系列时，可以单独给评估器申请一组配额，便于细粒度监控。
Q3: /goal 和 /loop 到底应该怎么选？
如果任务有明确的「完成态」，选 /goal；如果任务是周期性的状态轮询（例如每 10 分钟检查一次部署进度），选 /loop。两者底层机制完全不同，混用反而会让停止条件变模糊。
Q4: 国内能用 Claude Code 的 /goal 模式吗？
可以。/goal 是 Claude Code 客户端的命令，只要客户端能连通 Anthropic 提供的模型即可。开发者通常会把 Claude API 通过 API易 apiyi.com 这类聚合中转平台接入，环境配好后 /goal 与海外用户表现一致。
Q5: Codex /goal 和 Claude Code /goal 谁更值得选？
两者面向的工作流不同。Codex /goal 强调「持久化工作流」、可以跨进程重启；Claude Code /goal 是会话作用域，配合 –resume 也能跨天恢复。复杂多日任务选 Codex，常规一两天的迭代任务选 Claude Code 更顺手。
总结
Claude Code goal 模式的本质，是 Anthropic 把「评估器循环」从 Hook 配置文件里解放出来，做成了任何会话都能临时使用的一行命令。它解决的核心痛点是：当一个任务必须跨多轮才能完成、但人不想守在终端前每轮按回车时，让一个小型快速模型当判官，决定 Claude 什么时候才算真的把事做完。
落地建议是三步走：先把条件按「终点 + 验证 + 约束 + turns 上限」四件套写完整，再决定使用 interactive、-p 还是 Remote Control 模式，最后通过 API易 apiyi.com 等平台把评估器配额和主模型分开监控。这样可以同时拿到自主工作流的效率，又不至于在 Token 成本上失控。
作者: APIYI 技术团队
联系: 通过 API易 apiyi.com 获取 Claude 全系列模型与 Claude Code 接入支持
更新时间: 2026-05-13
