Claude Code 的 /goal 是一个命令：你写下一个“什么时候算完成”的条件，Claude 就会自己持续工作，直到达到该条件。每轮（Claude 的一次回复）结束时，一个独立的小模型会判断条件是否已满足；如果没有满足，就让 Claude 进入下一步工作。本文依据官方文档原文（2026 年 10 月 24 日确认）整理使用方法和停止条件，并记录本站在实际工作中的试用结果，包括 token 用量和成品的质量检查。
作用
持续到结束条件满足
写成 /goal 所有测试通过 这样，就会立刻开始工作。一直持续到条件满足、判定为无法满足，或出现需要修复的错误为止。
判定方式
由另一个模型每次核对
判定模型只读取对话中出现的结果。它自己不看文件，也不运行命令，所以条件应写成“Claude 的输出能够证明”的内容。
试用后发现
单轮任务只多一次判定
机械性的工作即使有 321 项，也在一轮内完成，此时额外开销只相当于 1 次判定。判定模型没能发现成品文字中细微的不自然之处。
目录
1. /goal 是什么：与普通请求、/loop 和 Stop 钩子的区别
普通请求的工作，Claude 判断“完成”后就会停下，等待你的下一条指示。设置 /goal 后，每轮（Claude 的一次回复）结束时都会进行判定；如果条件尚未满足，即使你什么都不发，下一轮也会开始。官方文档举了以下适合的大型任务作为示例，这类任务的终态可以确认：
- 把模块迁移到新的 API，直到所有调用处都能编译、测试通过
- 实现设计文档，直到所有验收条件都满足
- 拆分大文件，直到每个文件都在设定的大小以内
- 处理完一批带标签的课题，直到列表清空
相似的机制有 3 种。官方文档的说明是：应按“什么启动下一轮”来区分使用。
| 机制 | 下一轮何时开始 | 何时停止 |
|---|---|---|
/goal | 上一轮结束时（交互过程中，也可能通过定期确认或自动重试开始） | 判定模型判定条件已满足或无法满足时、出现需要修复的错误时、输入 /goal clear 时 |
/loop | 经过设定的时间时 | 你手动停止，或 Claude 判断工作已完成时 |
| Stop 钩子 | 上一轮结束时 | 你写的脚本或提示词做出判断时 |
/goal 的本质是“用提示词判定的 Stop 钩子”，而且只在当前对话中生效。Stop 钩子写在设置文件里，对所有对话生效；/goal 是当场写下条件，只对这一个对话生效。
权限模式不会改变。如果想在不经确认的情况下持续运行轮次，请先把权限模式设为 auto，再使用 /goal。若保持手动模式，每遇到未获许可的操作，都会因确认而停下。官方文档说明：auto 模式减少单轮内的确认，/goal 减少每轮的指示，两者可以组合使用。
来源：Keep Claude working toward a goal（Claude Code 官方文档，2026 年 10 月 24 日确认）。
2. 使用方法：设置、查看状态、清除
一个对话只能设置一个目标。同一个 /goal，根据后面接的内容，分别用于设置、查看和清除。
- 设置：在
/goal后面写上条件例：/goal test/auth 的测试全部通过，lint 也要干净。设置后会立刻开始一轮，条件本身就是指示，因此不需要另外发送请求。如果已有目标，新条件会替换旧的。条件最多可写 4000 个字符。 - 查看状态：只输入
/goal会显示条件、经过的时间、判定的次数、已用的 token，以及最近一次判定的理由。次数和理由在第一次判定之后才会显示。 - 停止：
/goal clear在判定发生之前取消目标。stop、off、reset、none、cancel的作用相同。用/clear新开对话，目标也会被清除。
重新打开对话时，尚未完成的目标会恢复。条件会沿用，但轮次、时间和 token 的计数会从头开始。桌面应用、远程操作以及通过 claude -p 的自动运行都可以使用。claude -p "/goal …" 会在一次执行中持续运行直到完成，所以如果想看中间进展，请加上 --output-format stream-json --verbose。
在桌面应用中粘贴条件时的注意事项。如果把“/goal 加多行条件”一次性整体粘贴，整段内容可能会作为普通的粘贴文字发送，/goal 不会被当作命令（2026 年 10 月 23 日，在 Windows 桌面应用、Claude Code 2.1.308 上确认）。输入框中 /goal 会显示为彩色，外观上无法分辨。最稳妥的做法是：手动输入 /goal，从候选项中选中，然后再粘贴条件。判断是否生效，请看下方是否出现以“Goal set:”开头的行。
3. 判定机制与停止条件
每轮结束时，Claude Code 都会把条件和到目前为止的对话发送给一个“小而快的模型”。判定结果有 3 种，每种都附有简短的理由。在本站的环境中，判定模型是 Claude Haiku 5.5（通过对话记录确认）。
判定模型不使用工具，只根据对话中出现的内容做判断。它不会重新读取文件，也不会自己运行测试。如果 Claude 连续多轮不使用工具、只回答判定模型，Claude Code 会停止循环并显示警告，把目标保留着，把操作交还给你。
因错误而停止时
| 发生的情况 | 目标 | 之后的处理 |
|---|---|---|
| 需要你修复的错误（登录失败、积分余额耗尽、自动摘要也无法解决的上下文溢出、不可用的模型） | 被清除 | 修复原因后重新设置 /goal |
| 桌面应用或云端会话中的登录失败 | 保留 | 登录由应用端恢复 |
| 过一段时间通常会恢复的失败（服务器拥堵、连接中断） | 保留 | 等待后自动重试，重试 3 次后暂停（2.1.269 及以后版本的交互过程中） |
| 重试也会得到同样结果的失败（API 使用限制、claude.ai 的用量上限、钩子中断了轮次） | 保留 | 暂停。若设置为等待用量上限恢复，则在恢复后从中断处继续 |
有子代理或后台工作时
如果在轮次结束时，子代理或后台命令仍在运行，该轮的判定会被推迟。结果返回后，会作为新的一轮交给 Claude。等待满 30 分钟时，会进行“中途确认”：读取正在运行的工作的输出，如果有进展就继续等待；如果停滞了，就提示 Claude 修复或停止。默认情况下，间隔会依次变为 30 分钟、1 小时、2 小时，之后每 2 小时一次。首个间隔可以通过环境变量 CLAUDE_CODE_GOAL_CHECKIN_MINUTES 修改，设为 0 则会停止中途确认和自动重试。
无法使用的情况与费用
判定模型是钩子机制的一部分，因此和钩子一样，在你未信任的文件夹中无法使用。当设置中的 disableAllHooks 为 true，或管理员设置中启用了 allowManagedHooksOnly 时，同样无法使用，此时会显示原因。判定所用的 token 按小而快的模型的价格计费。官方文档称，通常“远小于主要工作的用量”。判定模型可以通过 ANTHROPIC_DEFAULT_HAIKU_MODEL 修改，但该设置也会影响对话摘要等其他使用小模型的处理。
来源：Keep Claude working toward a goal（2026 年 10 月 24 日确认）。
4. 条件的写法
判定模型只读取对话，因此条件要写成 Claude 自己的输出就能证明的形式。官方文档列出了长时间运行也不易走样的条件的 3 个要素。
npm test 以成功结束”“git status 干净”之类，说明如何证明。如果想给运行轮数设上限，请把它写进条件里，例如“或在 20 轮后停止”。官方文档中没有 Codex /goal 那样的 token 预算等专用设置。
| 写法 | 判定模型看到的情况 |
|---|---|
| 提高质量，持续做到完成为止 | 无法判定什么才算“完成” |
| 修到所有测试都通过为止 | 如果结果出现在对话中可以判定，但哪些测试并不明确 |
npm test 以成功结束，并把其输出显示在对话中（不改动 src/legacy，30 轮后停止） | 终态、确认方法、需要遵守的事项、上限都已明确 |
本站试用中得出的一条注意事项：需要遵守的事情，要写在条件本身里，而不是写在另一份操作手册中。判定模型是按条件的字面内容判定的，因此写在其他文件里的指示，即使没有被遵守，也可能被判定为“已满足”。本站的实验中就真的发生过这种情况（见第 5 章）。
5. /goal 试用两次的结果（以普通请求一次作参考）
我们在本站的文章中，用它来统一句末的句号。日语文章中，已有文章里句末的“。”有的有、有的没有，累计有 1,035 处（用本站检查句末“。”有无的脚本统计）。修改标准已经确定，终态也明确为“检查结果为 0 处”，因此我们把它选为适合 /goal 的工作，改变范围后用 /goal 运行了两次，并把普通请求的一次作为参考并列。
参考的那一次，是在尝试 /goal 时把条件整体一次性粘贴进去，如第 2 章的注意事项所述，它没有作为命令生效，而是作为普通请求运行的。我们把它作为同类工作用普通方式请求时的参考值列在表中（范围和数量不同，因此并非严格的比较）。两次 /goal 运行，是手动输入 /goal、选中后确认了“Goal set:”行。运行时间为 2026 年 10 月 23 日，环境为 Windows 桌面应用、Claude Code 2.1.308，执行工作的模型是 Claude Opus 5.5，权限模式为 auto。
| 比较项 | 参考：普通请求 | /goal（较小） | /goal（较大） |
|---|---|---|---|
| 范围、件数 | 10 篇文章，166 项 | 9 篇文章，119 项 | 48 篇文章，321 项 |
| 耗时 | 6 分 9 秒 | 5 分 54 秒 | 10 分 7 秒 |
| 轮次 | 1 轮结束 | 1 轮达成 | 1 轮达成 |
| 判定的次数、时间 | 无 | 1 次，5.6 秒 | 1 次，9.0 秒 |
| 执行工作模型的输出 token | 15,254 | 14,750 | 27,835 |
| 判定模型的 token | 无 | 输出 899，缓存写入 64,299 | 输出 1,569，缓存写入 114,410 |
| Claude Code 记录的折算费用 | $1.33 | $1.26 | $2.74 |
| 确认后由人修改的内容 | 无 | 无 | 不自然的 2 句 |
数字根据每次对话的记录（Claude Code 保存的 JSONL 文件）汇总。折算费用是 Claude Code 按 API 价格计算并记录的数值，订阅使用时并不会因此计费。每个结果都只是一次运行的结果，且每次的范围和件数不同。如果工作类型或模型改变，数字也会改变。判定模型的缓存写入，相当于为判定而读入的对话量。折算费用为执行工作模型与判定模型的合计。
实际写下的条件
以下是两次 /goal 运行中，在 /goal 之后写的条件。本站专用的名称（检查脚本、工作笔记文件、更新记录的工具）已替换为能说明其作用的说法。具体的操作步骤（修改的先例、不能触碰的文件）写在工作笔记（Markdown 文件）中，条件里只指向该笔记。
# 较小的一次
针对文章 200 至 209 这 9 篇的日语正文，句末检查脚本的指出数为 0（在对话中显示这 9 篇各自的检查结果），并且按照工作笔记中的步骤完成 commit 和 push。30 轮后停止。# 较大的一次
针对文章 100 至 199 的日语正文，句末检查脚本的指出数为 0。需遵守：按工作笔记中的步骤执行（只按已确定的先例修改标点，不改动词语、含义、译文、元信息和工具）。每轮结束时，用一行写出“剩余○项（○篇）”。最后，在对话中显示该 48 篇全部的检查结果、已修改文件的列表（仅限正文和核对记录）、标签检查通过的结果、核对记录的更新结果，并按路径完成 commit 和 push。不部署。40 轮后停止。git diff --stat）、标签检查和记录更新也都纳入条件，要求在对话中显示。较小的一次中，“每轮写出剩余件数”只写在了工作笔记里。Claude 结束时没有写出，判定模型在理由中写明“操作说明中的指示没有被遵守，但条件并未要求这一点”，然后仍判定为“已满足”。我们把这个教训（第 4 章）反映到了较大的一次的条件中。
成品的确认
我们没有直接相信判定模型的“已满足”，而是每次都在另一个对话中逐行确认差异，并重新运行检查。
/goal 运行都在修复后的工具下确认了 0 处。判定模型的“已满足”，前提是检查工具本身是正确的。6. 心得：适合与不适合的任务
机械性的工作在一轮内完成
每次运行，工作都在一轮内完成。在一轮之内，Claude 可以使用工具数十次（较大的一次使用了 Bash 32 次），因此能用脚本完成的工作，即使有 321 项也能一次做完。所以 /goal 的主要优点“不够就进入下一轮继续”，在这类工作中从未发挥作用。这些结果是每个范围各一次运行的结果，但在普通请求的参考运行与两次 /goal 运行之间，我们没有看到耗时或成品质量的大差异。额外的开销是每次运行 1 次判定，每次判定分别耗时 5.6 秒和 9.0 秒（整个工作约 6 分钟和约 10 分钟）。
判定模型读取整个对话
较大的一次中，判定模型读取了 114,410 个 token，相当于工作对话原样传过去。对话越长，每次判定就越重。对于会运行很多轮的工作，或者在本已很长的对话中途开始 /goal，判定的成本很可能比这次更大。
判定模型检查的是“是否符合条件”
判定模型能准确核对条件中的项目，比如检查结果和是否存在 commit。另一方面，它不检查句子是否通顺这类无法用数字体现的成品质量。“已满足”的意思是：写在条件中的内容已在对话中出现，它不能代替对成品的确认。
本次实验只测试了“一轮内完成的工作”。以下我们将官方文档中的示例和作者的个人看法分开列出。
7. 与 Codex /goal 的区别
OpenAI 的 Codex 也有同名的 /goal。两者的思路（在保持终态条件的同时持续工作）相同，但操作方式和上限的设定方式不同。Codex 一侧的详细用法，请参阅Codex /goal 的使用方法。
| 比较项 | Claude Code | Codex |
|---|---|---|
| 操作 | 设置、查看状态、清除（/goal clear）；要修改时，用新条件重新设置 | 查看、编辑、暂停、恢复、清除（/goal edit、pause、resume、clear） |
| 由谁判定 | 另一个小而快的模型，在每轮结束时读取对话 | Codex 反复执行工作和确认（没有说明由另一个模型判定） |
| 上限 | 没有专用设置，需在条件中写明“20 轮后停止”之类 | 每个目标都有 token 预算 |
| 自动停止的情况 | 条件被判定为已满足或无法满足，或出现需要修复的错误（用量限制或用量上限时暂停） | 条件已满足、预算已用完，或需要你的判断（账户使用上限时无法继续） |
来源：Claude Code 参见 Keep Claude working toward a goal；Codex 参见 Using Goals in Codex（OpenAI Cookbook）以及本站的“Codex /goal 的使用方法”。均为 2026 年 10 月 24 日时的信息。
总结
/goal是一个命令：写下一个结束条件后，由另一个模型在每轮结束时判定，让 Claude 持续工作直到条件满足。设置、查看状态和清除都用同一个命令完成。- 判定模型只读取对话。条件应写成能由 Claude 的输出证明的形式，包括可确认的终态、确认方法和需要遵守的事项，上限也写在其中。
- 权限模式不会改变，因此如果想放手交给它，请把
/goal与 auto 结合使用。 - 在本站的实验中，机械性的工作即使有 321 项，也在一轮内完成。对于这次一轮内完成的工作，额外开销只是 1 次判定。作者的看法是：它的效果体现在无法一轮完成的工作上。
- “已满足”的意思是：写在条件中的内容已在对话中出现。句子是否通顺等成品质量，需另行确认。
- 在桌面应用中整体粘贴条件，可能不会作为命令生效。请通过“Goal set:”行确认。
开始使用的步骤：将权限模式设为 auto → 按第 4 章的形式写条件（终态、确认方法、需要遵守的事项、上限）→ 手动输入 /goal，粘贴条件，并确认“Goal set:” → 出现“已满足”后，自己阅读差异内容。
FAQ
问：使用 /goal 会增加费用吗？
会增加判定的部分。判定由小而快的模型完成，官方文档称费用“通常极少”。在本站的实验中，一轮内完成的工作只做了 1 次判定，耗时只有几秒。不过，判定模型读取的是整个对话，因此对话越长，每次判定就越重。
问：中途想停止时怎么办？
用 /goal clear 取消目标。stop 和 cancel 的效果相同。如果是用 claude -p 运行的，可以按 Ctrl+C 停止。取消目标并不会撤销此前已做的修改。
问：Claude 说“完成了”，判定模型还会说“尚未”吗？
会的。这正是由另一个模型来判定的原因。如果判定模型说“尚未”，就会以其理由为线索开始下一轮。反过来，只要符合条件的结果出现在对话中，就会判定为“已满足”，因此没有写入条件的质量要求并不会得到保证。
问：会运行多少轮后停止？
没有固定的上限。当条件被判定为已满足、判定为无法满足、出现需要修复的错误，或你将其清除时，就会停止。如果想设定上限，请在条件中写明，例如“或在 20 轮后停止”。判定模型只读取对话，因此把“每轮结束时写出已经过的轮数”也写进条件，会更便于判断。（本次实验中的运行都在一轮内结束，因此我们没有测试达到上限时的停止情况。）
问：应该用 /loop 还是 /goal？
终态已经确定时用 /goal；想每隔固定时间确认同一件事时用 /loop。例如，“每 5 分钟检查一次，直到部署完成”适合 /loop；“修到所有测试通过为止”适合 /goal。
参考：Keep Claude working toward a goal、Run prompts on a schedule、Hooks guide（Claude Code 官方文档）；Using Goals in Codex（OpenAI Cookbook）。2026 年 10 月 24 日确认。
