Codex 可以长时间持续工作，尤其是在有 /goal 为其设定一个持久目标的情况下。更困难的部分在于，当它连续工作数小时或数天、发现新的实现细节、并经历多种验证方式时，如何保持方向感。
一旦开始实施，早期的假设往往会发生变化。协作模式需要在保留目标的同时，给你和 Codex 都留出根据新证据调整计划的空间。
在过去几周里，我一直在使用五种实践方法：
- 让 Codex 规划工作并维护路线图。
- 保持主线程专注于协调。
- 在每个里程碑之后审计路线图并审查代码。
- 使用本地线程进行 Computer Use 测试。
- 通过简洁的更新和仪表板报告进度。
由 Codex 中的 GPT Image 2 生成
1. 让 Codex 规划工作并维护路线图
我通常以对话开始，而不是直接使用 /plan 模式。我描述我想要构建的内容，口述粗略的想法，分享限制条件，然后让 Codex 提问，直到它拥有足够的上下文来提出初步计划。
这保持了早期讨论的灵活性。我不需要在 Codex 开始提供帮助之前，就把不成熟的想法变成正式的规范。它可以向我提问，反馈它所理解的内容，识别差距，并逐步将对话转化为一个可行的计划。
随着项目的成型，我要求 Codex 设定当前的 Goal。Goal 模式为 Codex 提供了一个持久的目标，使其能够在多次交互中持续朝着同一结果努力，直到目标完成、受阻或被替换。
我可以自己使用 /goal 来设定目标，但我通常让 Codex 来做这件事。Goal 模式通过工具暴露出来，因此 Codex 可以综合我们的对话、项目上下文以及它到目前为止学到的所有信息，形成一个清晰的目标。它还可以定义在认为该目标完成之前所需的证据。
对于较大的项目，我要求 Codex 将更广泛的路线图写入 GOALS.md。这是一个项目约定，而不是 Codex 的内置功能，文件名可以根据你的喜好来定。
我通常按照里程碑来组织 GOALS.md，而不是一个扁平的任务列表。每个里程碑记录：
- 预期成果
- 当前范围内的任务
- 重要决策
- 已知的阻碍因素
- 继续推进前所需的证据
Codex 会在项目开发过程中维护这个文件。新的发现可能会改变某个里程碑的范围，引入另一个里程碑，或改变完成所需的证据。
一次只激活一个 Goal 模式目标。当一个里程碑完成后，Codex 会更新 GOALS.md，激活下一个目标，并继续朝着它努力。
2. 保持主线程专注于协调
一旦路线图就位，我会让主线程专注于目标、限制条件、决策和当前项目状态。
它决定下一步应该做什么，委派有边界的任务，并评估结果。它不需要承载每一个实现细节。
一个工作线程可能会花一个小时阅读不熟悉的代码、尝试几种方法或追踪一个失败的测试。协调者只需要知道影响整个项目的信息：
- 工作线程学到了什么
- 发生了什么变化
- 支持性证据
- 下一步应该做什么
Codex 可以将这项工作委派给 subagent 或创建一个单独的线程。从功能上讲，它们可以执行相同的任务。当我预计稍后需要重新审视这项工作时，我会使用单独的线程，因为它在 Codex 应用中保持可见，并保留自己的历史记录。
当多个工作并行运行时，这一点尤其有用。主线程可以继续协调项目，同时每个调查、实现或审查都保持易于检查。
3. 在每个里程碑之后审计路线图并审查代码
GOALS.md 反映的是 Codex 上次更新时所知道的情况。到里程碑结束时，项目通常会发现一些新东西。
在继续前进之前，我会让另一个线程将路线图与当前状态进行比较：
- 这个里程碑真的完成了吗？
- 下一个目标仍然是正确的吗？
- 是否有任何里程碑缺失？
- 新证据是否改变了工作的顺序？
- “完成”的定义是否仍然成立？
我在每个里程碑结束时运行此审计，并且每当新证据实质上改变了项目方向时也会运行。
我还会对实现运行 /review。
假设登录流程的实现和远程测试都已完成。路线图审计可能会注意到没有人测试过真实登录浏览器中的流程。同时，/review 可能会发现新路径存储令牌的方式不正确，尽管远程测试通过了。
协调者更新 GOALS.md，委派修复令牌的任务，添加缺失的浏览器验证，然后才激活下一个里程碑。
我通常将审计和审查放在单独的线程中。Subagent 可以执行相同的工作，但单独的线程会留下一个可见的记录，我以后可以回顾。
4. 使用本地线程进行 Computer Use 测试
我的大多数 Codex 会话都在远程实例上运行，这样即使我的笔记本电脑合上，工作也能继续进行。但某些检查仍然依赖于我的本地机器：
- 已登录的浏览器
- 本地凭据
- Xcode
- macOS 权限
- iOS 模拟器
远程协调者可以为其中一项检查创建一个本地线程。我应用远程差异或检出相关分支或提交，以便本地线程测试正确的代码。
本地线程操作浏览器或应用程序，并返回截图、日志和发现。当检查失败时，远程工作线程修复问题，然后本地线程再次测试。
一个典型的循环如下：
- 远程工作线程实现登录流程。
- 远程测试通过。
- 本地线程使用 Codex Chrome 扩展程序。
- 浏览器测试发现一个重定向错误。
- 远程工作线程修复它。
- 本地线程重复检查。
项目默认保持在远程。我的电脑只在需要执行检查时才加入。当我重新打开笔记本电脑时，远程线程也可以持续检查本地线程是否再次可用。
5. 通过简洁的更新和仪表板报告进度
工作线程通常报告一个任务。当我回到项目时，我需要了解整体状态：
- 完成了什么
- 发生了什么变化
- 还剩下什么
- 需要做什么决策
每当项目状态发生变化时，我都会要求 Codex 使用三个简短的部分进行报告：
**已完成的工作
下一步计划
任何阻碍因素**
这几乎就像每天与 Codex 进行站会，只不过可能是每小时一次。
Codex 可以通过 Slack 发送相同的更新，可以是直接消息，也可以在专门的项目频道中发送。
当我在 Codex 应用中时，我也会使用 /side 来检查进度，而不会中断主线程。从侧边线程，我可以要求总结已完成的工作、剩余的工作，以及是否需要我的帮助——例如，手动点击、批准或其他点击操作。
从侧边线程获取总结
要求侧边线程将我的指令传递给主线程
然后我可以澄清指令、解决阻碍因素、添加上下文，或要求侧边线程将更新后的指导发回给主线程。
对于有多个里程碑或并行工作流的项目，我还会维护一个 progress-dashboard.html。这是一个自定义的项目产物，而不是 Codex 的内置 UI。它可以显示：
- 活跃的目标
- 已完成的里程碑
- 证据
- 阻碍因素
- 决策
- 最近的更新
当我几小时后回来时，无需阅读每个工作线程就能了解项目状态。Codex 还可以将仪表板部署为 Site，使其可以远程访问。
总结
当一个项目可能发现新信息、涉及几个独立的工作部分、或需要来自多个环境的证据时，我会使用这种结构。
工作流程遵循一个简单的循环。Codex 将最初的对话转化为路线图，激活一个里程碑，委派工作，并在继续前进之前检查结果。本地线程处理需要我机器参与的检查，而更新和仪表板帮助我在无需从头重建所有内容的情况下回到项目。
重要的是保持项目状态足够新，以便下一个决策能够反映 Codex 实际学到的东西。
试试看
将此内容粘贴到一个新的 Codex 线程中：
将此作为一个长期运行的项目进行协调。
首先通过询问我试图构建什么来开始。让我以对话的方式描述粗略的想法和限制条件，然后将该讨论转化为一个初步计划。
创建 GOALS.md 作为共享路线图。围绕里程碑组织它，包括每个里程碑的预期成果、范围、决策、阻碍因素和所需证据。
一次设定并维护一个 Goal 模式目标。活跃的目标应对应于当前的里程碑。
保持此线程专注于目标、限制条件、决策和项目状态。将实现工作委派给 subagent 或新线程。
要求工作线程返回结论、变更和证据，而不是完整的记录。
当我可能希望稍后检查、继续或审查工作时，使用单独的线程。对于不需要自己可见历史的有边界工作，使用 subagent。
在每个里程碑之后，使用单独的线程来审计 GOALS.md 与当前状态，并对实现运行 /review。在激活下一个目标之前更新路线图。
对于依赖于我的浏览器、桌面应用程序、权限、凭据或设备状态的 Computer Use 测试，使用本地线程。
*当项目状态发生变化时，仅报告： - 已完成的工作 - 下一步计划 - 任何阻碍因素*
当项目跨越多个里程碑或工作线程时，维护 progress-dashboard.html。在达成约定的证据之前，不要声明完成。
或者，你也可以截取本文的 Appshot 并询问 Codex：
根据本文创建一个名为 orchestrate-projects 的可复用 Codex 技能。
保留以下实践：
*- 让 Codex 询问我并创建初始计划 - 使用 GOALS.md 作为基于里程碑的路线图 - 一次保持一个 Goal 模式目标活跃 - 保持主线程专注于协调 - 在每个里程碑之后审计路线图并运行 /review - 对于我可能希望重新审视的工作，使用单独的线程 - 对于 Computer Use 测试，使用本地线程 - 通过简洁的更新、Slack 和 progress-dashboard.html 报告进度*
