Codex 的 /goal 模式，90% 的人都用错了！这才是官方正确打开方式
# Codex 的 /goal 模式，90% 的人都用错了！这才是官方正确打开方式
你有没有这种感觉：
跟 Codex 聊天式写代码，它像个听话但没脑子的实习生——你问一句，它动一下。
你稍微没说清楚，它就自由发挥，把“未来可以考虑”的功能当成当前需求给实现了。
直到你用了 `/goal`，才发现原来 Codex 也可以像外包团队一样，拿着施工图自己往前推进，干完活才来汇报。
但问题来了：**很多人根本不会用 /goal，或者用错了姿势，导致任务跑偏、时间失控、结果稀碎。**
今天我就把 Codex 官方对 /goal 的定位、适用场景、实战模板，以及我踩过的坑一次性讲透。
## 一、官方到底怎么定义 /goal？
Codex 官网上有一句非常显眼的描述：
> 当任务需要 Codex 跨回合持续工作以达到可验证的停止条件时，请使用 /goal。
翻译成人话就是：**你给 Codex 一个明确的目标、一套可验证的验收标准、几条不能碰的边界，然后它自己循环干活，直到满足条件才停。**
不是所有命令都适合套 /goal。官方列举了三个典型场景：
1. **长时间运行的编码工作**，有明确的成功条件和验证循环。
2. **代码迁移、大型重构、部署重试循环、实验、游戏和副项目**，Codex 可以持续取得有范围的进展。
3. **需要开展具有明确成功标准的长期实验的团队**。
一句话总结：**有目标、有验收、有边界，才配用 /goal。**
## 二、一个标准 /goal 长什么样？
很多人用 /goal 只会写一句“把这个功能做完”，然后祈祷 Codex 别翻车。
这跟把方向盘扔了让车自己开有什么区别？
官方推荐的结构是：**目标 + 验收标准 + 边界条件 + 优先级**。
给你一个可以直接抄的示例：
```
/goal 把这个 React 应用的登录页改成可用状态，修复当前报错，并确保 npm run build 通过。
完成标准：
- 登录表单能提交
- 错误提示正常显示
- 移动端布局不溢出
- npm run lint 和 npm run build 都通过
不要改后端接口；只改 src/app/login 相关文件。
优先保证功能可用，其次再美化 UI。
```
看到没？**目标、验收、边界、优先级全都有。** Codex 知道该干什么、干到什么程度算完、什么不能碰。
## 三、不知道要做什么，也能用 /goal？
有人会问：如果我自己都没想清楚目标，还能用 /goal 吗？
答案是：**可以，但别指望它帮你发明需求。**
/goal 也支持开放式探索。比如你让它“做一个类似百度首页的页面”，它能给你搞出来。
但你要是让它“做一个改变世界的产品”，它只会给你一堆泛泛而谈的代码。
所以我的建议是：**开放式探索可以，但必须给一个具象的参照物。** 比如“仿照 XXX 做一个简化版”，这样 Codex 才有方向。
## 四、用 /goal 前，先建立一份“工作契约”
很多人把 /goal 当成一个万能启动器，丢一句话就跑。
结果 Codex 干到一半，你不知道它在干嘛；它也不知道自己该不该停。
**正确的做法是：在 /goal 里写清楚一份工作契约。**
包括：
- 指定一个目标和停止条件；
- 告诉 Codex 先读哪些文件、文档、日志或计划；
- 定义哪些命令或产物能证明进展；
- 要求它分 checkpoint 工作，并保留简短进度记录；
- 运行时用 /goal 查看状态；
- 用 pause、resume、clear 控制节奏。
**千万别让一个 /goal 一路跑到黑。**
我试过一次让 /goal 连续跑 75 个小时，最后发现收益和损耗完全不成正比。
更聪明的做法是：让 Codex 定期给你一份紧凑的进度报告，包含：
- 当前 checkpoint；
- 已验证的内容；
- 剩余工作；
- 是否被阻塞。
如果报告开始含糊不清，别急着追加零散指令，而是**收紧 goal**：明确下一个 checkpoint、用哪个命令证明完成、什么情况应该暂停。
## 五、官方推荐的三个实战示例
直接抄作业：
**技术栈迁移：**
```
/goal 把这个项目从 [旧技术栈] 迁移到 [目标技术栈]。确保所有页面视觉表现保持一致，并用 Playwright 验证输出。
```
**原型创建：**
```
/goal 按 PLAN.md 实现第一版，为每个里程碑创建测试，并用 Playwright 验证输出。必要时参考给定截图。
```
**提示词优化：**
```
/goal 优化 [提示词文件或目录]，直到 eval 套件达到 [目标分数或通过率]。每次修改后运行 [eval 命令]，检查失败样例，并保持改动小而精准。达到目标，或后续修改需要产品/政策判断时停止。
```
这些示例的共同点：**目标明确、验证方式具体、停止条件清晰。**
## 六、我最推荐的搭配：/goal + PRD + spec
说实话，/goal 最香的地方，不是让你省掉思考，而是帮你把已经定义好的需求执行到位。
所以它最适合搭配的，是一份 PRD 或者 spec。
但这里有个大坑：**别直接丢一句“/goal 根据 PRD 把这个功能做完”。**
PRD 里全是“用户希望更方便”“页面需要足够清晰”“交互尽量自然”这种话。
对人来说好理解，对 Codex 来说，这就是自由发挥的许可证。
我之前就踩过坑：PRD 里写了一句“后续可以考虑支持多租户配置”，Codex 真的开始设计多租户的数据结构了。
你说它错了吗？文档里确实有这句话。但这显然不是当前版本该做的事。
**所以后来我加了一句魔法咒语：**
```
PRD 中出现的「后续」「未来」「可以考虑」「可扩展」内容，默认都视为非目标，除非 SPEC 或完成标准明确要求实现。
```
这句话能帮你减少 80% 的过度发挥。
## 七、完整可复用的 /goal 模板
如果你手上已经有 PRD 和 spec，直接用这个模板：
```
/goal 按照 docs/PRD.md 和 docs/SPEC.md 完成 [功能名] 的第一版实现。
执行规则：
- PRD 是产品目标和用户流程的来源
- SPEC 是技术实现和接口契约的来源
- 如果两者冲突，以 SPEC 为准，但必须在进度报告中说明
- PRD 中的未来规划默认不实现
- 不要修改与本功能无关的模块
工作方式：
- 先整理需求 checklist 和 checkpoint
- 每个 checkpoint 完成后运行相关测试
- 如果涉及页面，使用浏览器验证主要流程
- 如果构建或测试失败，优先修复失败项
完成标准：
- PRD 中当前版本核心流程全部可用
- SPEC 中定义的接口、状态、边界条件全部满足
- npm run test 通过
- npm run build 通过
- 关键页面或流程完成实际验证
停止条件：
- 所有完成标准满足后停止
- 遇到产品判断、文档冲突或需要扩大范围时暂停并说明
```
这个模板把**能不能改、做到什么程度、什么时候停、遇到冲突怎么办**都提前说清楚了。
## 八、最后一条忠告：别让一个 /goal 承包整个系统
如果你的 PRD 里有用户系统、支付系统、后台管理、消息通知、数据看板……
千万别写：
```
/goal 根据 PRD 完成整个系统
```
这会让任务变成无底洞，而且越到后面，状态越难判断。
**正确姿势是拆成多个 goal：**
```
/goal 按 PRD 和 SPEC 完成登录注册模块，完成后通过认证相关测试和页面验证。
```
```
/goal 按 PRD 和 SPEC 完成订单创建流程，暂不处理支付回调。
```
```
/goal 按 PRD 和 SPEC 完成支付回调和订单状态流转，确保相关测试通过。
```
每个 goal 都有清晰边界，你随时可以 pause、resume、clear，不会失控。
## 九、什么时候别用 /goal？
给你一个简单的判断标准：
- 如果任务一句话能说完，十分钟内能搞定，**别用 /goal**，直接对话就行。
- 如果任务需要反复读文档、改代码、跑测试、看页面、修失败项，**非常适合 /goal**。
- 如果还有 PRD 和 spec，那就更合适了。
**因为这时候 /goal 不是在帮你猜需求，而是在帮你执行已经定义好的需求。**
这才是它真正香的地方。
---
**行动号召：** 下次用 Codex 跑长任务，别再一句话甩过去了。先写清目标、验收标准、边界条件，再开 /goal。你会发现，Codex 的靠谱程度直接上一个台阶。
如果你有更好用的 /goal 模板，欢迎在评论区分享，咱们一起把 Codex 榨干。🚀