/goal 使用指南

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

OpenAI Developers@OpenAIDevs·5月22日回复 @OpenAIDevs

/goal 已从一个实验正式毕业——无论任务大小，Codex 都能帮您完成工作。

在 Codex 应用、IDE 扩展或 CLI 中使用目标模式，给 Codex 一个明确的里程碑，它就会持续工作直到达成目标，即使跨越数小时或数天。

您可以随时查看进度，并…显示更多461331.3K438K

目标模式非常强大，以下几点能帮助您充分利用它。使用 /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 训练模型时自己生成数据集。

Vaibhav (VB) Srivastav@reach_vb·5月23日几天前 @swyx 发起了一个挑战：用 JAX/Flax/Optax 编写一个约 10M 参数的 transformer，在免费 Colab 上运行，并用你的 agent 训练它做加法！

我给 Codex 截图 + /goal。

它通过 Chrome 控制 Colab，使用我已登录的会话，处理运行时/编辑…显示更多引用 Vaibhav (VB) Srivastav@reach_vb·5月23日 文章一个提示，一个目标，以及一次用 Codex 的 Colab 运行！几天前 @swyx 发起了一个挑战：用 JAX、Flax 和 Optax 编写一个大约 1000 万参数的 transformer，在免费 Colab 上运行，并训练它做简单的加法。

我想看看 Codex 是否…141813620K

类似地，如果您想减少构建时间，并且知道大部分时间花在哪里，请尝试在提示中先指出那个区域。

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

3. 让进展可衡量

如果您的目标雄心勃勃，或者有各种方式让 Codex 接近目标，那么给 Codex 提供衡量进展的工具就很重要。

对于某些任务，这可能理所当然，比如改善构建时间或增加测试覆盖率，因为 Codex 通常已经拥有或自然会创建这些工具。

对于其他目标，值得与 Codex 一起头脑风暴哪些工具有用，或者提示它找到了解进展的方法。例如，提供工具来计算两个截图之间的视觉差异，或者为正在调整的 agent 创建一个评估套件。

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

Codex 生成的用于视觉比较两帧的截图

Codex 生成的用于视觉比较两帧的截图

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

4. 创建逼真的环境

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

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

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

Thomas Ricouard@Dimillian·20小时前今天我在物理设备上运行 Codex Remote，记录各种分析跟踪，然后生成报告，说明我们可能获得的最大收益。我们正在优化线程视图，并且有很多优化即将到来。1611438.5K

5. 谨慎对待视觉目标

给 Codex 一个视觉目标，比如“根据此图像实现完全像素完美的 UI”，这很诱人，但取决于设置，也可能带来一些麻烦。

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

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

相反，图像通常可以作为朝着目标推进的有用上下文，但您应该找到其他方式让 Codex 确认目标已达成，例如功能清单、需要实现的规范、对设计系统的遵守等。

6. 跟踪进度

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

• 让 Codex 在有意义的步骤进行提交并推送到草稿 PR。 这尤其有助于当您处理带有预览部署的网站时。
• 让 Codex 更新面向高层的产物。 可以是一个 HTML 文件，您可以在应用内浏览器中打开，甚至可以使用 Sites 部署给团队，也可以是一张绘制进展图表的图像，或一个纯 markdown 文件。
• 指示 Codex 发布更新。 您可以要求 Codex 在目标执行过程中，将重大进展通知到 Slack 频道或其他您希望记录进展的地方。
• 使用其他对话询问状态更新。 如果您只是想快速了解当前状态，可以运行 /side 启动一个新的侧边对话并提问。由于它分叉了当前线程，因此拥有截至该点的所有上下文，但也是短命的。在 Codex 应用中，另一种方法是让 Codex 在一个新的常规对话中读取另一个目标线程并回答您的问题。如果您让 Codex 安排一个自动化任务定期检查，这会特别强大。

7. 清理与最终确定结果

太好了，目标终于达成了！那么直接 $yeet 给团队然后收工吗？

通常我发现，特别是对于优化任务，让 Codex 反思所做的工作并审查它是有帮助的。您可以先运行 /review 进行本地代码审查，但也可以让 Codex 更深入地反思解决问题所尝试的不同方法，并进行相应的清理。

由于 Codex 会一直执行直到达成目标，它可能尝试了几种效果不够好或根本无效的方法，而这些方法可能仍保留在变更中。

是时候为你的下一个任务设定目标了

Codex 中的目标功能是一个极其强大的工具，可以解决您遇到的一些最具挑战性的问题，但提供合适的环境和指令将使您更有效地达成目标。

你用 /goal 做过什么？