/goal 使用指南

我们推出了目标模式（即 /goal），帮助你让 Codex 朝着具体成果推进。当你设定一个目标后，Codex 会持续工作直到目标达成，无论这需要几小时还是几天。有些人曾让 Codex 为一个目标连续工作 超过 120 小时。

目标模式非常强大，你可以通过一些方法充分发挥它的作用。以下是使用 /goal 时需要牢记的 7 个要点。

1. 清晰且可验证的标准

你在激活目标模式时定义的提示词，既是初始提示，更重要的是它将成为目标的退出标准。Codex 会在每次操作后检查目标是否已达成。因此，你的目标提示词不应过于冗长，而应聚焦于明确的目标达成标准。

大多数情况下，一个好的目标包含一个明确的数字，让模型在达成该数字后认为目标完成。好的例子：

"将构建和部署时间减少 30%。"
"将此功能从 TypeScript 迁移到 Rust，并达到 100% 的测试覆盖率。"
"改进应用脚手架，使生产环境中的最大内容绘制时间低于 2.5 秒。"

\提示词不一定非得是数字，但通常数字有助于后续技巧的实施。*

如果你不确定如何最好地定义目标，或者想先与 Codex 一起集思广益，你不必一开始就使用目标模式启动线程。

Codex 可以自行设定目标，因此你可以先开始对话，当你准备好让 Codex 开始工作时，可以 让 Codex 根据你的对话内容来设定目标。

你也可以随时编辑目标，只需在 Codex 应用中按下编辑按钮，或在 CLI 中再次使用 /goal 即可。

2. 尽可能提供指导

发送像 "将构建和部署时间减少 30%" 这样的提示可能很酷，甚至能发现一些创造性的解决方案。但如果你对问题所在有想法，它也可能让 Codex 白费力气。

在可能的情况下，给 Codex 一个工作起点，告诉它可以使用哪些工具来实现目标，或者提供任何其他提示，避免 Codex 走错方向。

例如，我的同事 @reach_vb 在一次实验中就是这样做的：他告诉 Codex 可以使用 Chrome 浏览器进入 Google Colab，并设定了可接受的限制，比如在让 Codex 训练模型时自行生成数据集。

同样，如果你希望减少构建时间，并且知道大部分时间花在哪里，试着在提示词中首先将 Codex 指向那个区域。

或者，你甚至可以 让 Codex 在计划模式下进行初步研究，并让 Codex 创建一个计划文件，用于记录可能的方案。然后让你的目标引用该计划。

3. 让进展可衡量

如果你的目标很有挑战性，或者 Codex 有多种方式可以接近目标，那么 给 Codex 提供衡量进展的工具 就很重要。

对于某些任务，这可能是理所当然的，比如改进构建时间或提高测试覆盖率，因为 Codex 通常已经拥有这些工具，或者会自然创建它们。

对于其他目标，值得 与 Codex 一起集思广益，看看哪些工具有用，或者暗示它如何了解自己的进展。例如，创建工具来计算两个截图之间的视觉差异，或者为正在调整的 Agent 创建一个评估套件。

当我让 Codex 根据视频重新创建一些组件时，我让 Codex 为自己创建了一个工具，以便能够对比截图并检查差异。它选择随着时间的推移改进该工具，以拥有不同的差异模式。

Codex 生成的一张用于视觉对比两个帧的截图

根据你的任务，你还需要考虑是否有额外的标准需要衡量/检查，这些标准可能会让 Codex 认为任务已完成，但你却认为不完整。例如，通过裁剪设计灵感并将其内联以实现“像素级完美”的 UI，或者通过减少测试覆盖率来达到 100% 的通过率。

4. 创建真实的环境

要让 Codex 真正朝着目标取得进展，它需要 在真实的环境中运行。在实践中，这意味着如果你试图改进部署时间或延迟问题，它应该 能够访问模拟生产环境的部署和测试环境。即相同的技术栈、相同的标志、相似的数据库。

举个例子，我们正在为 developers.openai.com 调试构建和部署时间的改进。我们已经使用了部署预览，因此 Codex 可以使用它们进行部署并查看相关日志，但与完整的生产运行相比，我们的预览部署禁用了某些构建路径。因此，Codex 不得不手动部署到具有类似生产配置的相同环境中，以检查环境。

同样，你可以让 Codex 使用计算机使用来测试实际应用。为了改进 iOS 上的某些性能，@dimillian 甚至使用了物理设备来获得最准确的环境。

5. 谨慎对待视觉目标

给 Codex 设定一个视觉目标，比如 "根据这张图片实现 100% 像素级完美的 UI" 很诱人，但根据具体设置，也可能带来一些麻烦。

如果你没有给它正确的指导和约束，它可能会在一些问题上钻牛角尖，而忽略了整体目标。例如，如果参考图包含 Codex 需要生成的图形（无论是 SVG 图标还是图像），它可能会在追求这些图形的准确性上迷失方向，而不是恰当地分析问题。

此外，Codex 需要工具来进行正确的视觉比较，这意味着更多的图像输入和更高的总体 token 使用量，而不一定能让 Codex 轻松识别机会。

相反，图像通常可以作为有用的上下文来推动目标实现，但你应该 寻找其他方式让 Codex 确认目标已达成，例如功能清单、待实现的规格说明、对设计系统的遵循等。

6. 跟踪进展

如果 Codex 最终在后台（甚至在另一台机器上）工作数小时或数天，很容易失去对 Codex 进展或已完成工作的了解。根据目标的不同，我发现以下几种方法有助于跟进：

让 Codex 在有意义的步骤进行提交并推送到草稿 PR。 如果你在带有预览部署的网站上工作，这尤其有用。
让 Codex 更新一个面向管理层的工件。 这可以是一个 HTML 文件，你可以在应用内浏览器中保持打开，甚至可以使用 Sites 部署给你的团队；也可以是一张渲染后的图表图像来跟踪进展，甚至是一个纯 Markdown 文件。
指示 Codex 发布更新。 你也可以在目标中要求 Codex 将重大进展反馈到 Slack 频道或其他你希望记录进展的地方。
使用其他聊天窗口询问状态更新。 如果你只是想快速检查当前状态，可以运行 /side 启动一个新的侧边聊天并提问。因为它会分叉当前线程，所以拥有到目前为止的所有上下文，但也是短暂的。在 Codex 应用中的替代方法是，在一个新的常规聊天中让 Codex 读取另一个目标线程并回答你的问题。如果你让 Codex 安排一个自动化任务定期检查，这会特别强大。