别再一步步确认了：/goal让AI编程真正自己干活

从「你来指挥」到「你定目标」

传统 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 的官方文档给出了写有效目标的三个要素：

官方还建议在目标中加入边界条款，比如 or stop after 20 turns，防止目标跑飞了无限循环下去。

与其他自动化方式的对比

Claude Code 除了 /goal，还有几种让 AI 持续工作的方式：

简单说：/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 的做法更「信任模型」——让正在干活的模型自己判断下一步做什么，用户随时可以介入微调。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 有一样的感受：