AI 编程最大的效率黑洞:你一直在当监工——Codex /goal 模式让不达目的不罢休

你有没有数过，用 AI 编程代理完成一个稍微复杂的任务，你要输入多少次”继续”？

迁移一个 API 客户端，你说”把 v1 迁移到 v2″，AI 跑一轮改了三个文件，测试挂了，你说”继续修”；它又改了两个，测试过了但 lint 报了，你说”继续”；lint 修完发现有个 edge case，你说”继续”……一个本来 30 分钟能搞完的迁移，你坐在那里当了 40 分钟的人肉”继续”按钮。

2026 年 4 月 30 日，OpenAI 在 Codex CLI 0.128.0 里加了一个新命令：/goal。它做的事情很简单——设一个目标，然后 AI 自己循环，直到目标完成或你叫停。

01 它不是一个新命令，而是一个新的运行方式

/goal 看起来就是一个斜杠命令，但它改变了 Codex 的运行模式。

普通模式下，你给 Codex 一条指令，它执行一次，然后停下来等你。每次对话都是独立的——上一轮改了什么、测试结果如何、还剩什么没做，都得你手动告诉它，或者它自己从上下文里猜。

/goal 模式下，你定义一个目标——比如”把所有 API v1 客户端迁移到 v2 并保持测试通过”——然后 Codex 进入一个循环：

1. 1. 分析目标，拆出当前应该做的一步
2. 2. 执行这一步（改代码、跑测试、读文件……）
3. 3. 检查结果，判断目标是否完成
4. 4. 如果没完成，回到第 1 步继续
5. 5. 如果完成了，停下来报告

你可以把它理解成：普通模式是”你说一句它做一步”，/goal 模式是”你告诉它终点在哪，它自己走过去”。就像导航——你不用每一百米喊一声”继续直走”，设好目的地，它自己规划路线。

和普通提示最大的区别在于：目标是持久化的。你关掉终端、重启电脑、甚至过了三天再回来，目标还在——/goal resume 就能接着干。

02 为什么”手动继续”是 AI 编程最大的效率黑洞

AI 编程代理已经很强了——单轮任务的完成率很高，代码质量也在持续提升。但真实项目的任务几乎从来不是单轮的：

• • 迁移类任务——”把旧 API 迁移到新 API”，可能涉及几十个文件、上百个调用点，每改一处都可能触发新的编译错误
• • 测试类任务——”把测试覆盖率提到 80%”，写测试、跑测试、修失败、再跑，循环十几次
• • 重构类任务——”重构这个模块但不改变行为”，改了代码要确保所有测试通过、类型检查通过、lint 通过
• • 调试类任务——”找到并修复这个 flaky test”，需要复现、定位、修复、验证

这些任务的共同特征是需要多轮迭代，而每一轮之间，你需要：

1. 1. 看上一轮的结果（测试通过了吗？报错了吗？）
2. 2. 决定下一步做什么（修这个报错？跑全部测试？）
3. 3. 把决策告诉 AI（”继续修” / “跑一下全部测试” / “看一下这个报错”）

这三步几乎不需要任何创造力——它们是机械的判断-决策-传达循环。但你必须做，因为 AI 不知道”目标是什么”，它只知道”你刚才说了什么”。

这就是 /goal 解决的核心问题：**把机械的迭代循环交给机器，把创造性判断留给人。**你定义”什么算完成”，AI 负责循环到完成；你随时可以暂停、检查、调整方向。

03 五层架构：一个目标从创建到完成的全过程

/goal 不是简单的”循环执行”——它是一个五层架构，每一层负责目标生命周期的不同方面。