Codex 官方：/goal 的正确打开方式

自从最后 Tibo 发了一条声明说修复了 Codex 订阅用量的 bug 之后，很明显的感觉是订阅掉的慢了。

以至于现在使用 /goal 这个模式，也可以稍微变得肆无忌惮了。

等等，说到 /goal ，其实 Codex 官网上有一个非常实用的用法，下面就来跟大家聊聊。

Codex 官方对 /goal 有一句非常显眼的描述：

当任务需要 Codex 跨回合持续工作以达到可验证的停止条件时，请使用 /goal。

不是任何命令都适合用 /goal 模式，适合使用 /goal 的场景主要有：

• 长时间运行的编码工作，具有明确的成功条件和验证循环。
• 如果你的项目涉及代码迁移、大型重构、部署重试循环、实验、游戏和副项目，Codex 可以在这些项目中继续取得有范围的进展。
• 需要开展具有明确成功标准的长期实验的团队。

上面这三点有一个明确的使用 /goal 的标准，大白话来说就是：

/goal 达成你希望 Codex 能够完成的最终目标，并通过具体可验证的方式来确认结果有效，同时保证遵守的限制条件不被破坏。

给大家举个适合使用 /goal 的例子：

## 给定清晰的边界目标

/goal 把这个 React 应用的登录页改成可用状态，修复当前报错，并确保 npm run build 通过。


## 写明验收标准

完成标准：
- 登录表单能提交
- 错误提示正常显示
- 移动端布局不溢出
- npm run lint 和 npm run build 都通过

## 给定条件边界

不要改后端接口；只改 src/app/login 相关文件。

## 给定优先级

优先保证功能可用，其次再美化 UI。

这个是你知道使用 /goal 来做什么的情况下。具有明确的目标和可验证条件。

那如果你不知道使用 /goal 来做什么，还适合用这个 slash 吗？

也是可以的。

/goal 还适用一种场景是开放式探索，就是你不知道你要做啥的时候，/goal 仍旧能顶上。

比如

当然这个例子有点极端了。

不过呢，你让他做一个百度或者阿里倒是可以的。

这突然让我想到了，古法编程时期的很多需求，如今看来，确实可以成为落地的需求。

如果你在 Codex 上输入 /goal 没有看到斜杠命令在列表中出现的话，那你需要在 config.toml 中启用 features.goals。

[features]
goals = true

你也可以在 Codex Cli 中运行启动 /goal 。

/goal 的用法比较简单，目前支持

/goal pause  ## 暂停执行目标
/goal resume ## 暂停恢复目标
/goal clear ## 清除执行目标

上面提到了使用 goal 的场景和使用方式，如果你要使用 /goal ，你需要建立一个工作契约：

1. 指定一个目标和一个停止条件。
2. 告诉 Codex 先读哪些文件、文档、issue、日志或计划。
3. 定义哪些命令或产物可以证明进展。
4. 要求 Codex 分 checkpoint 工作，并保留简短进度记录。
5. 运行时用 /goal 查看状态
6. 当完成、阻塞或方向改变时，用 pause、resume 或 clear 控制它。

这里给大家一个实操建议，千万不要一个 /goal 命令一路走到黑，我之前也使用 /goal 执行过一个 75h 的命令，但其实收益与时间损耗系数并不成正比。

你在使用 goal 的时候，最好让 goal 给 Codex 一份紧凑的进度报告，定期报告状态更新操作，包括

• 当前的 checkpoint；
• 已验证的内容；
• 剩余工作；
• 是否被阻塞。

如果状态报告变得含糊，不要一直加零散指令，而是收紧 goal：明确下一个 checkpoint、用哪个命令证明完成、什么情况应该暂停。

官方文档的定位是：/goal 更像一个后台任务。你给它清楚目标后，它可以长时间独立工作，并在确信达到停止条件时停下。

这里有几个示例，大家可以参考

技术栈迁移：

/goal 把这个项目从 [旧技术栈] 迁移到 [目标技术栈]。确保所有页面视觉表现保持一致，并用 Playwright 验证输出。

原型创建：

/goal 按 PLAN.md 实现第一版，为每个里程碑创建测试，并用 Playwright 验证输出。必要时参考给定截图。

提示词优化：

/goal 优化 [提示词文件或目录]，直到 eval 套件达到 [目标分数或通过率]。每次修改后运行 [eval 命令]，检查失败样例，并保持改动小而精准。达到目标，或后续修改需要产品/政策判断时停止。

说实话，我现在觉得 /goal 最适合搭配的东西，是一份 PRD 或者 spec。

因为 /goal 本质上解决的是持续执行的问题。

但持续执行有一个前提：

它必须知道自己到底在持续执行什么。

如果你只是丢一句：

/goal 根据 PRD 把这个功能做完

那基本上就等于你把一个大方向交给 Codex，然后让它自己猜哪些是必须做的，哪些是可以不做的，哪些地方遇到冲突应该停下来问你。

这种做法风险比较大。

尤其是 PRD 这种文档，很多时候写的是「产品意图」和「用户体验」，里面会有大量类似：

• 用户希望可以更方便地完成某个流程；
• 页面需要足够清晰；
• 交互尽量自然；
• 后续可以支持某个能力。

这些描述对人来说很好理解，但对 Codex 来说，如果没有验收标准，很容易跑偏。

所以我比较推荐的做法是，不要直接让 /goal 依照 PRD 直接开干，而是让 PRD 和 spec 结合输出一份执行蓝图。

大概是这样：

/goal 根据 docs/PRD.md 和 docs/SPEC.md 实现 [功能名]。

开始前先阅读这两个文档，并整理出：
1. 必须实现的需求
2. 明确不做的非目标
3. 需要验证的验收标准
4. 可能存在歧义或冲突的地方
5. 建议的 checkpoint 执行顺序

如果 PRD 和 SPEC 有冲突，先暂停并说明，不要自行决定。
每完成一个 checkpoint 后运行对应测试。
只有当所有验收标准满足、构建通过、关键流程验证完成时才停止。

这段 prompt 的重点在先把大作文拆成 checklist，再开始执行。

我自己的使用经验是，PRD 和 spec 最好分工明确：

• PRD 负责告诉 Codex：为什么要做、用户是谁、核心流程是什么、体验上不能偏离什么。
• spec 负责告诉 Codex：接口怎么设计、数据怎么流转、边界条件有哪些、哪些测试必须通过。
• /goal 负责把这两份文档变成一个可以持续推进的执行循环。

一句话总结就是：

PRD 决定方向，spec 决定边界，/goal 负责推进和验证。

这三个东西配合好了，Codex 的执行质量会明显稳定很多。

我之前踩过一个坑，就是把 PRD 写得很完整，然后直接让 /goal 去实现。结果 Codex 的确很努力，但它会把一些 TODO 也当成当前版本需求来做。

比如 PRD 里写了一句：

后续可以考虑支持多租户配置。

它可能真的会开始设计多租户的数据结构。

你说它错了吗？

也不完全错，因为文档里确实出现了这个方向。

但这显然不是当前阶段应该做的事情。

所以后来我会在 goal 里面加一句非常重要的话：

PRD 中出现的「后续」「未来」「可以考虑」「可扩展」内容，默认都视为非目标，除非 SPEC 或完成标准明确要求实现。

这个小限制非常有用，可以显著减少 Codex 的过度发挥。

如果你手上只有 PRD，没有 spec，我建议不要直接开 /goal 实现，而是先让 Codex 生成一份轻量 spec。

比如：

阅读 docs/PRD.md，先不要写代码。
请把它整理成一份 implementation spec，包含：
- 当前版本必须实现的功能
- 不做的非目标
- 数据结构和状态流转
- UI 页面和关键交互
- 验收标准
- 测试建议
- 需要我确认的问题

等这份 spec 确认之后，再开 /goal。

这样会比边读 PRD 边写代码要稳定很多。

如果你已经有 PRD 和 spec，那就可以更激进一点，直接让 /goal 开始跑。

我比较常用的完整模板是这个：

/goal 按照 docs/PRD.md 和 docs/SPEC.md 完成 [功能名] 的第一版实现。

执行规则：
- PRD 是产品目标和用户流程的来源
- SPEC 是技术实现和接口契约的来源
- 如果两者冲突，以 SPEC 为准，但必须在进度报告中说明
- PRD 中的未来规划默认不实现
- 不要修改与本功能无关的模块

工作方式：
- 先整理需求 checklist 和 checkpoint
- 每个 checkpoint 完成后运行相关测试
- 如果涉及页面，使用浏览器验证主要流程
- 如果构建或测试失败，优先修复失败项

完成标准：
- PRD 中当前版本核心流程全部可用
- SPEC 中定义的接口、状态、边界条件全部满足
- npm run test 通过
- npm run build 通过
- 关键页面或流程完成实际验证

停止条件：
- 所有完成标准满足后停止
- 遇到产品判断、文档冲突或需要扩大范围时暂停并说明

这个模板看起来有点长，但实际用起来很省心。

因为这其实把「能不能改」「做到什么程度」「什么时候停」「遇到冲突怎么办」都提前说清楚了。

这其实就是 /goal 最吃香的地方。

普通对话里，Codex 往往是你问一轮，它做一步。

但 /goal 更像是你给它一张施工图，再告诉它验收方式，它自己按阶段往前推。

当然，这里也有一个很现实的建议：

不要让一个 /goal 承包整个巨大 PRD。

如果你的 PRD 里面有用户系统、支付系统、后台管理、消息通知、数据看板，那最好不要写：

/goal 根据 PRD 完成整个系统

这个很容易变成超长时间任务，而且后面状态会越来越难判断。

更好的方式是把 PRD 拆成多个 goal：

/goal 按 PRD 和 SPEC 完成登录注册模块，完成后通过认证相关测试和页面验证。


/goal 按 PRD 和 SPEC 完成订单创建流程，暂不处理支付回调。


/goal 按 PRD 和 SPEC 完成支付回调和订单状态流转，确保相关测试通过。

这样每一个 goal 都有清晰边界，也方便你随时 pause、resume、clear。

最后给大家一个我自己的判断标准：

如果一个任务可以用一句话说完，并且十分钟内能完成，那就没必要开 /goal。

如果一个任务需要反复读文档、改代码、跑测试、看页面、修失败项，那就非常适合 /goal。

如果这个任务还有 PRD 和 spec，那就更适合。

因为这时候 /goal 不是在帮你猜需求，而是在帮你执行已经定义好的需求。

这才是它真正好用的地方。