自从 Tibo 最终修复了 Codex 订阅用量的 bug 后大家普遍感受到订阅掉的速度明显变慢。结果，/goal 这个模式也被滥用了。

了解 /goal 的真正价值

Codex 官方对 /goal 的描述非常直白：

并非所有命令都适合用 /goal。以下三种场景最适合：

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

主要原则

/goal 要达成你期望 Codex 完成的最终目标。并方式确认结果，同时保证不破坏任何限制条件。

至于实战案例。React 登录页升级

/goal 把这个 React 应用的登录页改成可用状态，修复当前报错，并确保 npm run build 通过。## 写明验收标准
- 登录表单能提交
- 错误提示正常显示
- 移动端布局不溢出
- npm run lint 和 npm run build 都通过
## 给定条件边界
不要改后端接口；只改 src/app/login 相关文件。## 给定优先级
优先保证功能可用，接下来再美化 UI。话说回来，

你可能遇到的痛点

• 目标模糊导致耗时过长：如果没有明确停止条件。Codex 会一直执行下去，浪费大量时间。
• 过度发挥：当仅提供 PRD 时Codex 可能会把“未来规划”误认为是当前目标，这样就能实现不必要的功能。按理说，
• 状态管理困难：缺少进度报告会让你难以判断是否可以继续或需要暂停。说起来，

方法的观点是。建立工作契约

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

/goal 的基本操作

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

Coding 开启技巧

If you don't see slash command in list。enable it in config.toml:

goals = true

至于实践建议，不要一路走到黑

• 耗时75小时但收益低——让 goal 给一份紧凑进度报告，包括 checkpoint、已验证内容、剩余工作和是否被阻塞。若报告含糊，请收紧 goal：明确下一个 checkpoint 和证明完成的方法。

/goal 的实际示例

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

/goal 原型创建示例

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

提示词调整示例

/goal 调整，直到 eval 套件达到。每次修改后运行，检查失败样例，并保持改动小而精准。达到目标后停止，

为什么配合 PRD + spec 最佳？

/PRD 决定方向；spec 决定边界，/goal 执行与验证！这三者结合可以明显提高 Codex 的执行质量与稳定性。如果只给 PRD 而没有 spec。会导致 Codex 在“未来规划”上过度发挥，从而浪费资源并偏离当前需求。在没有 spec 时可以先让 Codex 输出一份轻量 spec。再启动 /goal，让整个过程更可控、更高效。

下面是一份完整模板，可直接复制使用：

/goal 按照 docs/PRD.md 和 docs/SPEC.md 完成 的第一版实现。

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

再看步骤，1. 整理需求 checklist 和 checkpoint。2. 每个 checkpoint 完成后运行相关测试。3. 页面需使用浏览器验证主要流程。4. 建立或测试失败时优先修复。

完成标准的观点是，- PRD 当前版本主要流程全部可用。- SPEC 定义接口、状态及边界满足。- npm run test & npm run build 通过。

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

这里提醒 不要一次性让 /goal 承包整个巨大 PRD，那会导致任务过长且难以评估进度。最好拆分为多个小 goal，例如登录注册模块 → 订单创建 → 支付回调等。每个 goal 有清晰边界且方便随时 pause/resume/clear。老实说，

快速判断

情况	是否开启 /goal
一句话描述且十分钟内能完成	❌
需要反复读文档、跑测试、查看页面	✅
有 PRD 与 spec 且已拆解为小任务	✅

这样。你就能避免“猜需求”的风险，让 Codex 专注于已定义好的需求，实现更高效、更可靠的自动化开发体验。

---