概述
难度: 高级 | 时间跨度: 长期运行
当任务需要 Codex 在多个回合中持续朝可验证的停止条件前进时，使用 /goal。
最适合
- 具有明确成功条件和验证循环的长期编码工作
- 代码迁移、大规模重构、部署重试循环、实验、游戏以及 Codex 可以持续取得有限进展的副项目
- 需要运行具有明确成功标准的长期实验的团队
起步提示词
/goal 完成 [目标]，不停歇地持续工作，直到 [可验证的结束状态]
介绍
当你希望 Codex 持续朝一个持久目标前进，而不是在一个普通回合后就停止时，使用 /goal。它适用于有明确目标、验证循环，并且 Codex 有足够空间自行推进而无需你每一步都介入的工作。使用 /goal 后，Codex 可以独立工作数小时而无需你的输入。
/goal 是 Codex CLI 的实验性功能。通过 /experimental 启用，或在 config.toml 的 [features] 下添加 goals = true。然后通过 /goal <objective> 设置目标，用 /goal 查看当前目标，使用 /goal pause、/goal resume 或 /goal clear 来控制运行。
选择合适的工作
一个好的目标比单个提示大，但比开放式的待办清单小。它应该定义 Codex 要实现什么、不应该改动什么、如何验证进度，以及何时停止。
以下场景效果很好：
- 代码迁移：目标技术栈、等价检查、约束条件都清晰明确
- 大规模重构：Codex 可以在每个检查点后运行测试
- 实验、游戏或原型：Codex 可以持续改进一个可工作的产物
避免将目标用于松散的不相关工作清单。
设置循环
- 命名一个目标和一个停止条件
- 指向 Codex 必须首先阅读的文件、文档、issue、日志或计划
- 定义证明进度的命令或产物
- 告诉 Codex 以检查点方式工作，并维护一个简短的进度日志
- 使用
/goal在运行期间检查状态 - 在运行完成、受阻或改变方向时，暂停、恢复或清除目标
关键在于契约：Codex 应该在开始之前就知道”完成”意味着什么。如果目标是迁移，“完成”可能意味着新路径通过了合约测试，并且旧路径仍支持回滚。如果目标是游戏或原型，“完成”可能意味着应用可以构建、启动，并匹配输入参考或预期行为。
请 Codex 来帮忙：先就你想构建的内容进行对话，然后让它直接设定目标并开始工作。
让 Codex 独立工作
在目标执行期间，要求 Codex 提供精简的进度报告，让整个运行过程值得信赖。有用的状态更新应包含：
- 当前检查点
- 已验证的内容
- 剩余工作
- 是否受到阻碍
如果状态变得模糊，收紧目标而不是增加更多临时指令。明确告诉 Codex 下一个检查点是什么、用哪个命令来验证、什么情况下应该暂停。
当 Codex 跟随一个目标时，它可以独立工作数小时，你无需频繁查看。它会在相当确信已达成停止条件时自动停止，因此你应该将 /goal 视为一个无需监控的后台任务。
示例目标
代码迁移
无论你是将游戏迁移到新的技术栈、将移动应用迁移到新平台，还是将代码库迁移到新框架，都可以使用 /goal 让 Codex 执行迁移：
/goal 将此项目从 [旧技术栈或系统] 迁移到 [目标技术栈或系统]。
确保所有界面在视觉上完全一致，使用 playwright interactive 验证输出。
原型创建
无论是从零开始创建新应用、新游戏还是新功能，都可以用 /goal 让 Codex 完成一个精美的第一版。可以使用 PLAN.md 文件来指导第一版的创建，精确描述你想构建的内容。
/goal 实现 PLAN.md，为每个里程碑创建测试，并用 playwright interactive 验证输出。
[根据需要包含参考截图]
提示词优化
当你有一套评估套件时，可以使用 /goal 根据评估结果优化提示词。Codex 可以检查失败案例、更新提示词、重新运行评估，并持续迭代直到分数提升或达到停止条件。
/goal 优化 [提示词文件或目录] 中的提示词，直到评估套件达到 [目标分数或通过率]。
每次更改后，运行 [评估命令]，检查失败案例，保持提示词修改最小化和有针对性。
达到目标或进一步修改需要产品/策略指导时停止。