Claude Code /goal 一键设定目标，全自动迭代到完成
你是否遇到过这样的场景：让 Claude Code 重构模块时，每轮都要手动检查进度、发送下一步指令，稍一分神就忘了做到哪了？/goal 命令专为解决这类痛点而生——设定一个可验证的完成条件，Claude 就会自主多轮迭代，直到条件满足或你手动终止，全程无需逐轮干预。
本文从核心概念、基本用法、工作原理到注意事项，系统讲解 /goal 的使用方法。
一、核心概念与适用场景
1.1 核心定义
/goal 是 Claude Code 的会话级自动化命令，核心作用是设定明确的目标完成条件。触发后，Claude 会自主推进任务。每轮工作结束后，由独立的轻量评估模型（默认 Haiku）验证条件是否满足。未满足则自动开启下一轮，满足则立即停止并清除目标，全程无需人工干预。
1.2 典型适用场景
/goal 专为有可验证最终状态的大规模任务设计，常见场景包括：
代码迁移：将模块迁移至新 API，直至所有调用点编译通过且测试用例全部运行成功；
需求落地：实现设计文档需求，直至所有验收标准全部满足；
代码重构：拆分大型文件为模块化小组件，直至每个文件体积符合预设限制；
任务清理：处理标记的问题积压列表，直至队列完全清空；
质量管控：修复项目漏洞，直至所有 lint 检查无错误、测试覆盖率达标。
二、与其他自动化工作流的对比
Claude Code 提供多种会话自动化方式，/goal 与 /loop、Stop hook、Auto mode 各有侧重，可根据任务触发逻辑与停止条件选择。
| 工作流 | 下一轮启动时机 | 停止条件 | 核心特点 |
|---|---|---|---|
/goal |
上一轮任务完成后 | 轻量模型确认目标条件满足 | 会话级快捷指令，专注 “条件达成即停”，评估独立可信 |
/loop |
设定时间间隔到期后 | 手动停止，或 Claude 判断任务完成 | 时间驱动，适合周期性重复任务 |
| Stop hook | 上一轮任务完成后 | 自定义脚本或提示词判断 | 配置文件生效，支持全会话作用域，可自定义评估逻辑 |
| Auto mode | 单轮内工具调用需审批时 | Claude 判断单轮任务完成 | 仅自动审批工具调用，不启动新轮次，与 /goal 互补 |
/goal 是条件驱动的自主循环，Auto mode 是单轮内的自动化审批，二者可搭配使用，实现 “无人工干预的全流程自主任务处理”。
三、使用前提
使用 /goal 前需确认以下条件：
| 前提条件 | 说明 |
|---|---|
| Claude Code 版本 | 确保已升级到支持 /goal 的版本（输入 claude --version 查看） |
| 工作区信任 | 首次在项目目录启动 Claude Code 时，需接受信任对话框，否则 /goal 不可用 |
| 钩子系统启用 | 全局/局部设置中未开启 disableAllHooks，托管设置中未开启 allowManagedHooksOnly |
| API 额度充足 | /goal 会多轮消耗 Token，长时任务建议提前确认额度 |
若不满足条件，执行 /goal 时会提示具体原因，不会静默失败。
四、快速上手：基本用法详解
以下从设置目标、编写高效条件、查看状态、清除目标到会话恢复，逐步掌握 /goal 的完整用法。
4.1 设置目标
设置目标是 /goal 命令的核心操作，语法简洁，单个会话仅支持激活一个目标，新目标会自动替换已激活的目标。
语法格式
/goal <目标完成条件>
实用示例
# 示例1：测试与代码质量目标
/goal test/auth 目录下所有测试用例通过，且 lint 检查无错误
# 示例2：代码重构目标
/goal 将 src/utils.ts 拆分为5个以内工具模块，每个文件不超过200行
# 示例3：任务清理目标
/goal 处理完所有标记为"high-priority"的issue，直至任务队列清空
设置目标后，Claude 会立即启动第一轮任务，无需额外发送提示词。会话界面会显示 ◎ /goal active 状态指示器，实时展示目标运行时长。
4.2 编写高效的目标条件
目标条件的质量直接决定 /goal 的执行效果，评估模型仅能识别 Claude 输出中明确呈现的结果，无法独立运行命令或读取文件，需遵循可衡量、可验证、有约束三大原则。
三大核心原则
单一可衡量的最终状态：聚焦一个明确结果（测试退出码、文件数量、空队列等），避免模糊描述；
明确的验证方式：指定 Claude 需呈现的验证结果（如
npm test 退出码为0、git status 无修改）；关键约束条件：限定任务边界（如 “仅修改 test/auth 目录文件”“不删除现有功能代码”）。
正反示例对比
| 低效条件（模糊 / 不可验证） | 高效条件（明确 / 可验证） |
|---|---|
| 优化项目性能 | 优化 API 响应时间至 200ms 以内，且不修改核心业务逻辑 |
| 修复代码 bug | 修复登录模块所有 bug，所有测试用例通过，lint 检查无警告 |
| 整理项目文件 | 将 src 目录文件按模块拆分，每个文件不超过 300 行，无未使用依赖 |
补充说明
条件长度上限为 4000 字符，可满足复杂场景需求；
可添加轮次 / 时间限制避免无限运行，如
或运行20轮后自动停止。
4.3 查看目标状态
目标运行过程中，可随时查看实时状态，包括条件、运行时长、轮次、Token 消耗及最新评估理由。
语法
/goal
状态输出说明
目标条件：当前激活的完整目标描述；
运行时长：目标激活至今的耗时；
评估轮次：已完成的迭代轮次；
Token 消耗：当前目标累计消耗的 Token 数量；
最新理由：评估模型对 “未满足条件” 的原因说明（指导下一轮任务方向）。
若会话中无激活目标，会显示历史已完成目标的记录（时长、轮次、Token 消耗）。
4.4 清除目标
目标未完成时，可手动提前终止，支持多个别名命令，操作便捷。
语法（任意一个均可）
# 标准命令
/goal clear
# 等效别名
/goal stop
/goal off
/goal reset
/goal cancel
/goal none
补充说明
执行
/clear开启新会话时，会自动清除当前激活的目标；目标清除后，任务进度保留在会话中，可后续手动继续。
4.5 会话恢复目标
若会话意外中断（如终端关闭、网络断开），未完成的激活目标可恢复，已完成或已清除的目标不支持恢复。
恢复方式
通过 --resume 或 --continue 参数恢复会话：
# 恢复最近会话并激活未完成目标
claude --resume
注意事项
恢复后，目标条件保持不变，但运行时长、轮次计数、Token 消耗会重置清零；
恢复后 Claude 会从中断前的最后一轮结果继续推进任务。
五、高级用法：非交互式运行
/goal 支持非交互式模式，可通过命令行参数直接运行至目标完成，适合脚本集成、自动化流程或后台任务执行。
语法格式
claude -p "/goal <目标完成条件>"
实用示例
# 示例：自动化更新变更日志
claude -p "/goal CHANGELOG.md 包含本周所有合并PR的条目，格式符合项目规范"
操作说明
执行命令后，Claude 会一次性运行至目标完成，全程无交互；
需提前中断时，按
Ctrl+C即可终止任务；非交互式模式下，Auto mode 可搭配使用，自动审批工具调用，实现 “完全无人值守”。
六、工作原理深度解析
/goal 的核心是 ”主模型执行 + 轻量模型评估”的双模型循环机制，流程清晰且高效。
目标初始化：执行
/goal <条件>后，会话记录目标条件，立即触发主模型（Claude）启动第一轮任务；任务执行：主模型根据条件执行操作（编辑文件、运行命令、修改代码等），输出结果至会话；
独立评估：每轮任务结束后，系统将目标条件 + 会话历史发送至轻量评估模型（默认 Haiku）；
结果判定：评估模型返回二选一结果及简短理由：
条件未满足：返回 “否 + 原因”，主模型基于原因开启下一轮任务；
条件已满足：返回 “是 + 确认”，自动清除目标，终止循环；
计费说明：评估模型消耗的 Token 单独计费，因模型轻量，消耗远低于主模型，几乎可忽略不计。
核心优势：执行与评估分离，避免主模型 “自我判断” 的偏差，确保目标完成的客观性与准确性。
七、使用限制与注意事项
7.1 环境要求
/goal仅在已接受信任对话框的工作区中可用（评估模型依赖钩子系统）；禁用场景：
全局 / 局部设置
disableAllHooks时；托管设置中开启
allowManagedHooksOnly时；
触发限制时，命令会明确提示原因，而非静默失效。
7.2 关键注意事项
条件可验证性：评估模型仅能识别会话中明确输出的结果，避免依赖 “隐性状态”（如数据库数据、未输出的命令结果）；
目标单一性：单个会话仅支持一个激活目标，复杂任务可拆解为多个独立目标依次执行；
资源管控：长时任务建议添加轮次 / 时间限制，避免意外消耗大量 Token；
会话隔离：目标为会话级独立，不同会话的目标互不干扰。
八、常见问题
Q1：执行 /goal 后没有任何反应，也没有显示 ◎ /goal active？
检查是否已接受工作区信任对话框。首次在项目目录运行 Claude Code 时会弹出信任提示，必须接受后 /goal 才能正常工作。可输入 /status 确认当前工作区状态。
Q2：目标条件看起来已经满足了，但评估模型一直判定”未满足”？
这是条件描述不够明确导致的。评估模型只能识别 Claude 会话中明确输出的结果，如果你的条件依赖”隐性状态”（如数据库中的数据、未输出到会话的命令结果），评估模型无法感知。建议在条件中指定验证方式，例如将”数据库迁移完成”改为”运行 npm run migrate 输出成功信息，且所有测试通过”。
Q3：目标运行了很久还没停，Token 消耗很大怎么办？
立即输入 /goal stop 手动终止。后续设置目标时，建议在条件末尾加上轮次限制，如 或运行15轮后自动停止，避免无限循环消耗资源。
Q4：/goal 和 Auto mode 可以同时使用吗？
可以，而且推荐搭配。/goal 负责”多轮自动推进”，Auto mode 负责”单轮内自动审批工具调用”，两者互补。同时开启后可实现全程无人工干预的自主任务处理。
Q5：恢复会话后，之前的轮次计数和 Token 消耗还在吗？
不在了。恢复后目标条件保持不变，但运行时长、轮次计数、Token 消耗会重置清零。Claude 会从中断前的最后一轮结果继续推进。
九、总结
/goal 命令的核心流程是”设定目标→自主执行→独立评估→循环推进”，让你从逐轮指令中解放出来，专注于目标设计与结果验收。使用时牢记三点：条件要可衡量、可验证；长任务加轮次限制；搭配 Auto mode 实现全流程自动化。
下一步行动：打开终端，用 /goal “修复 src 目录下所有 lint 错误，直到 eslint 输出无错误信息” 体验一次全自动迭代。后续还可结合 Stop hook 自定义评估逻辑、MCP 协议扩展工具能力，让 /goal 适应更复杂的自动化场景。
