微信扫码
添加专属顾问
我要投稿
告别一步步确认,让AI编程助手真正自己干活,/goal功能让你只需设定目标,AI就能自动完成多步任务。核心内容: 1. /goal功能如何改变AI编程从“回合制”到“目标制” 2. OpenAI Codex CLI与Anthropic Claude Code的/goal功能详解 3. 高效使用/goal的实用技巧与场景
⭐ 设为星标 · 第一时间收到推送
传统 AI 编程助手的工作模式是「回合制」——你说一句,它做一步,然后停下来等你。这种方式写个小函数没问题,但面对大型重构、全量迁移、多文件修改这种需要几十步甚至上百步才能完成的任务,人就变成了 AI 的「人工鼠标」。
/goal 的核心思路很简单:你只需要定义「什么算做完」,AI 自己决定「每一步怎么做」。
这听起来像是微小的变化,但实际体验完全不同。设定目标后,AI 在每一轮结束后会自动检查:目标达成了吗?没有?那就继续。你就可以去喝杯咖啡,回来发现整个任务已经跑完了。
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 状态等,模型只能标记已完成的项,不能随意修改目标。
Codex 的 /goal 还提供了终端内的可视化控制面板,你可以:
这个设计很实用。比如你跑着一个大型迁移任务,中途发现某个依赖有问题,可以暂停目标,先手动修一下依赖,再恢复让 Codex 继续。
这是 Codex /goal 最有意思的一个特性。除了手动输入 /goal,你还可以通过 set_goal() 函数来编程式地设置目标。
X 上一位开发者 jxnlco 分享了这个技巧:
他的建议是:与其自己费劲写一个精准的目标描述,不如直接把需求告诉 Codex,让它自己来写目标。因为模型对自身能力的理解比你深,写出来的目标往往更具体、更可衡量、更不容易跑偏。
实际操作起来就是两步走:
第一步:跟 Codex 描述你想做什么
"我想把这个项目的所有组件从 Class 组件迁移到函数组件,用 React Hooks 重写,保持所有测试通过"
第二步:让 Codex 自己设目标
"请用 set_goal() 为这个任务设置一个详细的目标"
一位开发者 Thomas Ricouard 分享了他的使用体验:设定目标后,他仍然可以在每一轮中对细节进行微调(比如调整 FOV、云的效果、树的放置),而 Codex 会在完成这些微调后自动回到大目标继续推进。
这解决了一个很多人担心的问题——设定目标不代表完全放手。你可以随时介入调整方向,AI 会在处理完你的即时需求后回到主目标。就像项目管理中的「北极星指标」,团队(AI)朝着它走,但路上该拐弯还得拐弯。
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。
既然 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 完全自主跑长任务时用。
不管是 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 有一样的感受:
参考链接
— 完 —
围观朋友圈查看每日最前沿AI资讯
一键关注 👇 点亮星标
每日科技资讯和提效工具分享
本文章由快发 api.kuaifa.art 自动排版
53AI,企业落地大模型首选服务商
产品:场景落地咨询+大模型应用平台+行业解决方案
承诺:免费POC验证,效果达标后再合作。零风险落地应用大模型,已交付160+中大型企业
2026-05-14
MiniMax 推出了 Mavis,活脱脱的 Agent「三省六部」
2026-05-13
BP Claw 破解 AI 编码输入难题 ——FlinkSpec 需求智能化实践|得物技术
2026-05-13
AI-Generated UI 技术深度解析:模型流式输出与 UI 渲染实践
2026-05-12
AI 交互的范式转变:从"回合制"到"实时协作"
2026-05-12
回敬 Codex,Claude Code 推出 /goal 功能,不干完不睡觉
2026-05-12
再也不用盯着几十个终端窗口!Claude Code推出Agent视图,一屏管所有
2026-05-11
Agent 烧钱如流水?Agentic OS (ANOLISA) 帮你逐笔看清 Token 账单
2026-05-11
IGA Pages × TRAE :TRAE 如何快速实现一键部署
2026-04-15
2026-03-31
2026-02-14
2026-03-13
2026-04-07
2026-03-17
2026-03-17
2026-04-07
2026-03-21
2026-02-20
2026-05-09
2026-05-09
2026-05-09
2026-05-08
2026-05-07
2026-04-26
2026-04-22
2026-04-18