/goal 功能的出现，彻底改变了这个局面。设一个目标，AI 就会自己一轮一轮跑下去，直到目标达成。OpenAI 的 Codex CLI 先走出了这一步，紧接着 Anthropic 的 Claude Code 也跟进了。这篇文章聊聊这两个 /goal 到底是什么、怎么用，以及怎么用才真正有效。
从「你来指挥」到「你定目标」
传统 AI 编程助手的工作模式是「回合制」——你说一句，它做一步，然后停下来等你。这种方式写个小函数没问题，但面对大型重构、全量迁移、多文件修改这种需要几十步甚至上百步才能完成的任务，人就变成了 AI 的「人工鼠标」。
/goal 的核心思路很简单：你只需要定义「什么算做完」，AI 自己决定「每一步怎么做」。
这听起来像是微小的变化，但实际体验完全不同。设定目标后，AI 在每一轮结束后会自动检查：目标达成了吗？没有？那就继续。你就可以去喝杯咖啡，回来发现整个任务已经跑完了。
Codex CLI 的 /goal：先发制人
OpenAI 在 2026 年 4 月 30 日发布的 Codex CLI 0.128.0 版本中，正式引入了 /goal 命令。这是三家主流 AI 编程工具（Codex、Claude Code、Gemini）中最早推出该功能的。
基本用法
在 Codex CLI 的终端界面中，输入 /goal 加上你的目标描述即可：
/goal Migrate all API calls in src/api/ from REST to GraphQL, ensure all tests pass
设置后，Codex 会进入「目标模式」。每一轮 Agent 完成操作后，如果用户没有输入新指令，Codex 会自动注入一条提示消息，引导模型选择下一个具体行动。整个过程中，目标需求会被映射到具体的证据——文件修改、测试结果、PR 状态等，模型只能标记已完成的项，不能随意修改目标。
TUI 控制面板
Codex 的 /goal 还提供了终端内的可视化控制面板，你可以：
- Create：创建新目标
- Pause：暂停当前目标（AI 停止工作但保留进度）
- Resume：恢复暂停的目标
- Clear：清除目标
这个设计很实用。比如你跑着一个大型迁移任务，中途发现某个依赖有问题，可以暂停目标，先手动修一下依赖，再恢复让 Codex 继续。
set_goal() 函数：让 AI 自己写目标
这是 Codex /goal 最有意思的一个特性。除了手动输入 /goal，你还可以通过 set_goal() 函数来编程式地设置目标。
X 上一位开发者 jxnlco 分享了这个技巧：
他的建议是：与其自己费劲写一个精准的目标描述，不如直接把需求告诉 Codex，让它自己来写目标。因为模型对自身能力的理解比你深，写出来的目标往往更具体、更可衡量、更不容易跑偏。
实际操作起来就是两步走：
第一步：跟 Codex 描述你想做什么
"我想把这个项目的所有组件从 Class 组件迁移到函数组件，用 React Hooks 重写，保持所有测试通过"
第二步：让 Codex 自己设目标
"请用 set_goal() 为这个任务设置一个详细的目标"
实战体验：目标+微操两不误
一位开发者 Thomas Ricouard 分享了他的使用体验：设定目标后，他仍然可以在每一轮中对细节进行微调（比如调整 FOV、云的效果、树的放置），而 Codex 会在完成这些微调后自动回到大目标继续推进。
这解决了一个很多人担心的问题——设定目标不代表完全放手。你可以随时介入调整方向，AI 会在处理完你的即时需求后回到主目标。就像项目管理中的「北极星指标」，团队（AI）朝着它走，但路上该拐弯还得拐弯。
Claude Code 的 /goal：后来居上
Anthropic 在 2026 年 5 月 11 日发布的 Claude Code 2.1.139 版本中，也加入了 /goal 命令。虽然比 Codex 晚了将近两周，但在功能设计上有自己的特点。
运行机制
Claude Code 的 /goal 实现方式和 Codex 有明显不同。核心区别在于评估器（Evaluator）：
每轮 Claude 完成操作后，系统会把目标和当前的对话历史发给一个独立的小模型（默认是 Haiku），由它来判断目标是否达成。这个评估器返回 yes 或 no，以及一个简短的理由。如果是 no，理由会作为下一轮的指导反馈给 Claude。
这个设计的好处是评估和执行分离——干活的是一个模型（比如 Sonnet 或 Opus），判断干没干完的是另一个模型。就像公司的执行团队和独立审计，互相独立才能避免「自己审自己」的问题。
基本用法
/goal all tests in test/auth pass and the lint step is clean
设置目标后会立即开始一轮操作，不需要额外输入。活动期间界面会显示 ◎ /goal active 的状态指示器，告诉你目标已经运行了多久。
查看当前状态：/goal（不带参数）
清除目标：/goal clear
写好目标的技巧
Claude Code 的官方文档给出了写有效目标的三个要素：
| 要素 | 说明 | 示例 |
|---|---|---|
| 可衡量的终态 | 测试结果、构建退出码、文件数量、空队列 | npm test exits 0 |
| 明确的验证方式 | Claude 如何证明目标达成了 | git status is clean |
| 关键约束 | 过程中不能改变的东西 | 不修改其他测试文件 |
官方还建议在目标中加入边界条款，比如 or stop after 20 turns，防止目标跑飞了无限循环下去。
与其他自动化方式的对比
Claude Code 除了 /goal，还有几种让 AI 持续工作的方式：
| 方式 | 下一轮何时启动 | 何时停止 |
|---|---|---|
/goal | 上一轮完成时 | 模型确认条件满足 |
/loop | 固定时间间隔后 | 你手动停止或 Claude 判断完成 |
| Stop hook | 上一轮完成时 | 你的脚本或提示词决定 |
| Auto mode | — | 单轮内自动批准工具调用，不启动新轮次 |
简单说：/goal 是「跑到终点线」，/loop 是「每隔 N 分钟跑一圈」，Stop hook 是「自己写裁判规则」。
Auto mode 和 /goal 是互补的：Auto mode 解决单轮内的确认问题（不用每次点「允许执行」），/goal 解决多轮间的衔接问题（不用每次输入下一条指令）。两者搭配使用，就是完全无人值守的自动化编程。
非交互模式
Claude Code 的 /goal 也支持非交互模式运行：
claude -p "/goal CHANGELOG.md has an entry for every PR merged this week"
这意味着你可以在脚本、CI/CD 流水线、定时任务中使用 /goal。比如设置一个每天凌晨跑的任务，让 Claude 自动检查并更新 CHANGELOG。
两家 /goal 的核心差异
既然 Codex 和 Claude Code 都有了 /goal，它们之间有什么不同？
| 维度 | Codex CLI /goal | Claude Code /goal |
|---|---|---|
| 发布时间 | 2026.04.30（v0.128.0） | 2026.05.11（v2.1.139） |
| 评估方式 | 模型自行判断 + 用户可随时介入 | 独立小模型评估（Haiku） |
| 控制面板 | TUI 可视化（创建/暂停/恢复/清除） | 命令行交互 |
| 编程式设置 | set_goal() 函数 | 仅命令行 /goal |
| 目标持久化 | 支持暂停/恢复 | 会话恢复时自动还原 |
| 非交互模式 | 支持 | 支持（-p 模式） |
| 自动批准 | 需配合 full-auto 使用 | 需配合 Auto mode |
最大的架构差异在评估环节。
Codex 的做法更「信任模型」——让正在干活的模型自己判断下一步做什么，用户随时可以介入微调。Claude Code 则用了一个独立的小模型来当裁判，避免了「既当运动员又当裁判员」的问题，但代价是多了一轮模型调用。
两种设计各有道理。Codex 的方式更灵活、更省 token，适合有经验的开发者能随时纠偏的场景。Claude Code 的方式更可靠、更不容易跑偏，适合让 AI 完全自主跑长任务时用。
怎么写好一个 Goal：实战模板
不管是 Codex 还是 Claude Code，/goal 的效果很大程度上取决于你写目标的质量。X 上一位开发者 klöss 分享了一个非常实用的目标模板：
整理成中文版，一个高质量的 Goal 应该包含这些部分：
GOAL（目标）：一个清晰、可衡量的结果，只写一个核心目标
CONTEXT（上下文）：仓库/文件/架构/当前状态，已知的假设、依赖和前期决策
CONSTRAINTS（约束）：什么不能改、必须遵守的标准/模式、禁止操作的文件
PRIORITY（优先级）：排好优先级，让 AI 知道先做什么
PLAN（计划）：先理解再行动，复杂操作前先复述理解
DONE WHEN（完成条件）：可验证的终态，预期行为保持或改善
VERIFY（验证）：测试/构建/lint/人工验证，说明什么无法验证及原因
STOP RULES（停止规则）：遇到高风险歧义就停下，不要自行编造架构或需求
这个模板的关键思路是：让 AI 知道边界在哪里，比告诉它要做什么更重要。
很多人的 /goal 写得像许愿：「把代码改好」或者「不要出错」。这种模糊的目标只会让 AI 到处乱跑。明确约束和验证条件，AI 才能在正确的轨道上高速运行。
一些实用建议
根据目前社区的实际使用反馈，总结了几个让 /goal 更好用的技巧：
1. 让 AI 自己写目标
不管是 Codex 的 set_goal() 还是直接在 Claude Code 里先聊再设目标，让模型帮你写目标描述效果往往更好。模型对自身能力的边界比你清楚，写出来的目标更现实、更具体。
2. 小模型评估 ≠ 小模型干活
Claude Code 的评估用的是 Haiku，但这不影响干活的质量。Sonnet 或 Opus 该怎么写代码还怎么写，Haiku 只是判断「完没完成」，不参与实际的代码生成。
3. 配合 Auto mode 使用
单独用 /goal，每轮的工具调用（读文件、执行命令、写文件）还是需要你确认。配合 Auto mode 打开后，才是真正的「设了就走」。但要注意：Auto mode 意味着 AI 有完全的执行权限，确保你信任当前的工作环境。
4. 给目标加边界
无论用哪家，都建议在目标里加上轮次或时间限制，比如 or stop after 20 turns。这是一种安全网——万一目标描述有歧义导致 AI 在原地打转，至少不会无限循环下去。
5. 大目标拆小
不要一上来就设一个「重写整个项目」的目标。把它拆成几个子目标，逐个完成。比如先迁移一个模块，确认测试通过，再迁移下一个。这样即使某个子目标出了问题，也不影响整体进度。
写在最后
/goal 功能的出现，意味着 AI 编程工具开始从「对话式助手」往「自主代理」的方向走了一步。这不只是多了一个命令——它改变了人和 AI 协作的基本模式。
以前是人来驱动每一步，AI 来执行。现在是人来定义终点，AI 自己规划路径、执行步骤、检查进度、调整策略。人的角色从「驾驶员」变成了「导航员」。
当然，这还远没有到完美的程度。目标描述的质量直接影响结果，AI 仍然可能在复杂任务中跑偏，长时间的自主运行也意味着更高的 token 消耗。但方向是对的——让 AI 真正成为能独立完成任务的伙伴，而不是需要你手把手教每一步的实习生。
如果你还没试过 /goal，今晚花 15 分钟，给你的 AI 编程工具设一个目标跑跑看。也许你会和 Miles Deutscher 有一样的感受：
