用 Codex 推进复杂任务时，最常见的情况不是它做不了，而是它做完一步就停。
你推一下，它走一步；再推一下，它再走一步。每一轮都要你帮它判断：够了吗？方向对吗？还要继续吗？
Goals 模式优化的就是这个问题。
你不再告诉它每一步该怎么做，而是告诉它最终目标。它自己跑，自己检查，没到就继续，到了才停下。
Goals 和普通 prompt 到底差在哪
普通 prompt 的循环是：你说 → Codex 做 → 汇报 → 等你。
Goals 的循环是：Codex 做 → 检查"达标了吗" → 没达标且预算没花完 → 从最新状态继续。
普通 prompt 里，你可能会说："这个 checkout 模块性能有问题，看看。"
- Codex 分析之后，告诉你卡在哪里，然后等你下一步指令
- 你再让它改
- 改完以后，你再让它跑 benchmark
- 跑完以后，你再确认有没有引入新问题
- 最后你还要决定：继续不继续
- 每一步，都是你在推
Goals 模式下，你可以这样说：
/goal 将 p95 checkout 延迟降到 120 毫秒以下，以 checkout benchmark 验证，正确性测试套件全绿。仅使用 checkout 服务、benchmark 夹具和相关测试。每次迭代后记录改动、benchmark 结果和下一步要试的实验。如果 benchmark 跑不起来或无有效路径，停止并报告已尝试路径和阻塞点。
这时候，Codex 不再只是执行一句话。它会自己跑 benchmark、找热路径、改代码、重跑验证。延迟从 180 毫秒降到 135 毫秒——还没到 120，它知道没达标，会继续。降到 115 毫秒了，但测试挂了一个——它也知道这不算完成。一直到 benchmark 结果和测试结果同时满足条件，它才会标记完成。
这就是 Goals 和普通 prompt 的核心差别。
怎么用
先更新到最新版，并启用 goals：
npm install -g @openai/codex@latest
codex features enable goals
然后记住五个命令：
/goal <目标>— 设置新目标/goal— 查看当前状态/goal pause— 暂停/goal resume— 恢复/goal clear— 清除
设置完一个 Goal 之后，Codex 会自动进入工作循环。
怎么写一个好 Goal
好的 Goal，会给一个能检查的完成合约。最好包含六个要素：
1. 明确目标
不要只说"优化一下性能"。要说清楚优化到什么程度。
"将 p95 checkout 延迟降到 120 毫秒以下。"
2. 验证方式
Codex 必须知道用什么来判断任务完成。
- "以 checkout benchmark 验证。"
- "正确性测试套件必须全绿。"
3. 作用范围
复杂任务最怕越改越远。告诉它哪些地方能动，哪些地方不能动。
"仅使用 checkout 服务、benchmark 夹具和相关测试。"
4. 迭代记录
Goals 的价值不只是自动跑，还要让过程可追踪。
"每次迭代后记录改动、benchmark 结果和下一步要试的实验。"
这样你回来以后，不会只看到一个结果，而是能看到它为什么这么做。
5. 停止条件
不是所有任务都能顺利完成。提前告诉它什么时候应该停。
"如果 benchmark 跑不起来，或无有效路径，停止并报告已尝试路径和阻塞点。"
否则 Agent 很容易陷入无意义循环。
6. 成功标准
最后要有一个清晰的完成定义。不是"看起来好了"，而是：
- benchmark 达标
- 测试通过
- 改动范围合规
- 过程记录完整
对调试、优化、迁移、测试、论文复现这类复杂任务来说，Goals 模式不是一个更好用的 prompt。它真正改变的是 Codex 的工作方式。