跟进长期目标

介绍

当你希望 Codex 持续朝一个稳定目标工作，而不是在一个普通回合后停下时，使用 /goal。它适合目标清楚、有验证循环，并且 Codex 有足够空间在不反复询问你的情况下推进的工作。

设置目标用 /goal <objective>，查看当前目标用 /goal，需要控制运行时使用 /goal pause、/goal resume 或 /goal clear。

如果 slash command 列表里没有 /goal，在 config.toml 里启用 features.goals。也可以运行 codex features enable goals，或让 Codex 帮你运行。

[features]
goals = true

选择合适的工作

好的 goal 应该比一次 prompt 更大，但比开放 backlog 更小。它应该定义 Codex 要达成什么、不该改变什么、如何验证进展，以及何时停止。

避免把 goal 用在一串松散、互不相关的工作上。

• 目标 stack、parity checks 和约束清楚的代码迁移。
• Codex 可以在每个 checkpoint 后运行测试的大型重构。
• Codex 可以持续改进工作产物的实验、游戏或原型。

设置循环

关键是契约。Codex 开始前应该知道什么叫完成。如果目标是迁移，done 可能是新路径通过 contract tests，旧路径仍有 rollback。如果目标是游戏或原型，done 可能是应用能构建、启动，并匹配输入参考或预期行为。

也可以先和 Codex 讨论你要构建什么，再让它直接设置 goal 并开始工作。

• 命名一个目标和一个停止条件。
• 指向 Codex 必须先阅读的文件、文档、issue、日志或计划。
• 定义证明进展的命令或交付物。
• 要求 Codex 分 checkpoint 工作，并保持简短进度日志。
• 运行过程中用 /goal 检查状态。
• 当运行完成、受阻或方向改变时 pause、resume 或 clear goal。

让 Codex 独立工作

运行 goal 时，要求紧凑进度报告，让过程更容易信任。一个有用的状态更新应该说明当前 checkpoint、已验证内容、剩余内容，以及是否受阻。

如果状态变得含糊，不要叠加更多一次性指令，而是收紧 goal：明确下一个 checkpoint、证明它的命令，以及什么情况应该暂停。

Codex 跟进 goal 时，可以在不需要你盯着的情况下独立工作许多小时。它会在确信达到停止条件时停止，所以可以把 /goal 当成不必持续监控的后台任务。

示例目标

迁移：无论是把游戏迁到新 stack、把移动应用迁到新平台，还是把代码库迁到新框架，都可以用 /goal 让 Codex 持续运行迁移。

原型创建：从零创建应用、游戏或新功能时，可以用 /goal 让 Codex 完成 polished first version。PLAN.md 可以描述你要构建的第一版，让 Codex 按计划推进。

提示词优化：当你有 eval suite 时，可以用 /goal 按 eval 结果优化 prompts。Codex 可以检查失败、更新 prompt、重新运行 evals，并持续迭代直到分数提升或达到停止条件。