原文标题：A guide to /goal
原文作者：@dkundel，OpenAI 开发者关系成员
编译：Peggy

编者按：这篇文章来自 OpenAI 开发者关系成员 Dominik Kundel，对 Codex「goal mode / /goal」功能的使用经验进行总结。它讨论的并不是一个普通 prompt 技巧，而是 AI 编程工具正在发生的一次角色变化：Codex 不再只是响应单轮指令的代码助手，而开始成为一个可以围绕明确目标持续推进的执行型 Agent。

在 /goal 模式下，真正重要的不是把需求写得越长越细，而是为 Codex 设定清晰、可验证的退出标准。比如「部署时间降低 30%」「测试覆盖达到 100% parity」「LCP 降到 2.5 秒以下」。这些指标让 Codex 能够判断任务是否完成，也避免它在模糊目标中无限试错。与此同时，用户还需要提供足够的方向、工具和真实环境，让 Codex 能衡量进展、验证结果，而不是只在本地或假设条件下完成一个看似可行的方案。

文章尤其提醒，视觉类任务最容易让 Codex 陷入细节泥潭。与其要求「100% 像素级还原」，不如将视觉目标拆解为功能清单、设计系统规范和可评估指标。对于持续数小时甚至数天的长期任务，也需要通过 commit、draft PR、进度文档、Slack 更新或 side chat 等方式持续跟踪，避免最终只得到一堆不可追溯的改动。

这篇文章的信息增量在于，它把 /goal 重新定义为一种「长期任务管理机制」。当 AI 可以连续执行几十甚至上百小时，开发者的核心能力也随之变化：不只是让 AI 生成代码，而是为它定义目标、建立度量体系、配置执行环境，并在最后完成审查和复盘。换句话说，AI 编程正在从「写提示词」走向「管理一个持续工作的工程执行者」。

以下为原文：

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

目标模式非常强大。想要最大化发挥它的作用，使用 /goal 时有 7 件事值得注意。

设定清晰、可验证的标准

当你激活目标模式时输入的提示词，既可以作为初始提示，更重要的是，它会成为这个目标的退出标准。Codex 会在每一轮工作之后检查：这个目标是否已经完成。

因此，你的目标提示不应该写得过长，而应该聚焦于一个清晰标准：什么情况下，才算这个目标已经达成。

多数情况下，一个好的目标最好包含一个明确的数字指标，供模型判断是否完成。例如：

「将构建和部署时间减少 30%。」

「把这个功能从 TypeScript 迁移到 Rust，并达到 100% 的测试一致性。」

「优化应用脚手架，使生产环境中的最大内容绘制（Largest Contentful Paint，衡量页面主要内容加载速度的指标）低于 2.5 秒。」

这个提示不一定总要包含数字，但通常来说，数字会让后续步骤更容易推进。

如果你还不确定该如何定义目标，或者想先和 Codex 一起头脑风暴这个项目，也不必一开始就用目标模式开启对话。

Codex 可以自行设定目标。你可以先正常开启一段对话，等你准备好让 Codex 开始执行时，再让 Codex 根据前面的讨论内容设定目标。

你也可以随时编辑目标：在 Codex 应用中点击编辑按钮，或在 CLI 中再次使用 /goal。

尽可能提供指引

像「将构建和部署时间减少 30%」这样的提示，听起来很酷，也可能让 Codex 找到一些创造性的解决方案。但如果你已经大致知道问题可能出在哪里，这种提示也可能让 Codex 走上弯路。

所以，在可能的情况下，最好告诉 Codex 应该从哪里开始排查、可以使用哪些工具来完成目标，或者给出其他提示，避免它钻进错误方向。

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

同样，如果你想缩短构建时间，并且已经知道大部分时间消耗在哪个环节，最好在提示词中先把 Codex 指向那个区域。

另一种做法是，你可以先让 Codex 在计划模式（plan mode）下做一些初步研究，并让它创建一个计划文件，用来记录潜在方案。随后，再让你的目标引用这份计划。

让进展可衡量

如果你的目标很有野心，或者 Codex 有很多种方式可以逐步接近目标，那么很重要的一点是：你要给 Codex 提供衡量进展的工具。

对于某些任务来说，这一点可能天然成立。比如优化构建时间、提高测试覆盖率，因为 Codex 通常已经能使用相关工具，或者会自然地创建这些工具。

但对于其他目标，你最好先和 Codex 一起头脑风暴：哪些工具有助于判断进展？或者给它一些提示，让它知道该如何确认自己是否正在向目标靠近。例如，为两个截图创建视觉差异比对工具，或者为你正在调试的智能体创建一套评估集。

我曾让 Codex 根据一段视频复刻一些组件，当时 Codex 为自己创建了一个工具，用来比较截图并检查差异。后来，它还持续迭代这个工具，加入了不同的差异比对模式。

图片：Codex 生成的一张截图，用于对两个画面帧进行视觉对比。

根据任务不同，你还需要考虑是否有一些额外标准需要被测量或检查。否则，Codex 可能会以为任务已经完成，但在你看来其实还不完整。

比如，Codex 可能为了「像素级还原」某个 UI，直接裁剪设计参考图并内嵌到页面里；或者为了让测试通过率达到 100%，反过来削减测试覆盖范围。这些都不是你真正想要的完成方式。

创建一个真实的环境

如果你希望 Codex 真正朝目标取得有效进展，它就需要在一个足够真实的环境中运行。

在实践中，这意味着：如果你想优化部署时间或延迟问题，Codex 应该能访问部署和测试环境，而且这些环境要尽可能模拟生产环境。也就是使用相同的技术栈、相同的配置开关，以及类似的数据库。

举个例子，我们曾经在调试 developers.openai.com 的构建和部署时间优化。当时我们已经在使用部署预览，因此 Codex 可以利用这些预览环境进行部署，并查看相关日志。但问题在于，我们的预览部署和完整生产环境相比，禁用了一些构建路径。

因此，Codex 最后不得不进行手动部署，把代码部署到与生产配置更接近的环境中，才能真正检查问题所在。

类似地，你也可以让 Codex 使用 computer use（让模型操作真实应用界面的能力）来测试实际应用。为了优化 iOS 上的一些性能问题，@dimillian 甚至使用了实体设备，以获得最准确的测试环境。

谨慎设定视觉目标

给 Codex 一个视觉目标，比如「根据这张图片 100% 像素级还原这个 UI」，确实很诱人。但根据具体设置不同，这也可能带来麻烦。

如果你没有给出合适的指引和约束，Codex 可能会在某些细节上越陷越深，反而忽略整体目标。比如，如果参考图中包含一些图形元素，而你期待 Codex 生成这些元素——无论是 SVG 图标还是图片——它可能会把大量精力耗在「如何精确复刻这些素材」上，而不是正确拆解整个问题。

此外，Codex 需要工具才能正确进行视觉比较。这意味着更多图片输入、更高的整体 token 消耗，但并不一定能给 Codex 提供一种简单方式，让它识别真正有价值的改进机会。

所以，图片通常更适合作为目标上下文，而不是唯一的完成标准。你应该寻找其他方式，让 Codex 判断目标是否已经达成，例如功能清单、实现规范、是否符合设计系统等。

跟踪进展

如果 Codex 最终在后台工作数小时甚至数天，甚至是在另一台机器上运行，你很容易忘记它到底推进到哪里、已经做了哪些工作。

根据不同目标，我发现下面几种方式很有帮助：

·让 Codex 在关键节点提交代码，并推送到一个草稿 PR。尤其是当你在做网站，并且有预览部署时，这会非常有用。

·让 Codex 更新一份面向管理层的交付物。它可以是一个 HTML 文件，你可以在应用内浏览器里一直打开；也可以是·一个通过 Sites 部署给团队查看的页面；可以是一张渲染后的进度图，也可以只是一份普通的 Markdown 文件。

指示 Codex 主动发布进展更新。你也可以把这写进目标里：让 Codex 在取得重要进展时，把更新发送到 Slack 频道，或者你希望记录进展的其他地方。

使用其他聊天窗口询问状态。如果你只是想快速了解当前状态，可以运行 /side 启动一个新的侧边聊天，并在那里提问。因为它会从当前线程分叉出来，所以拥有截至目前的全部上下文，但生命周期很短。

在 Codex 应用中的另一个替代方法是：开启一个普通新聊天，让 Codex 阅读另一个目标线程，并回答你的问题。如果你让 Codex 设置一个自动化任务，定期检查进展，这种方式会尤其强大。

清理并最终确认结果

太好了，目标终于完成了！现在是不是就可以直接把成果甩给团队，然后收工？

通常来说，尤其是在优化类任务中，我发现让 Codex 回顾并审查自己完成的工作会很有帮助。你可以先用 /review 运行一次本地代码审查，但也值得让 Codex 更深入地反思：它为达成目标尝试过哪些路径？哪些尝试有效？哪些尝试无效？然后据此清理代码。

因为 Codex 会一直工作，直到达到目标，所以它可能尝试过一些效果不够好、甚至完全无效的方法，而这些残留改动可能还留在最终代码中。

给你的下一个任务也设一个 goal

Codex 的目标功能是一个极其强大的工具，可以帮助你解决一些最有意义的工程挑战。但只有当你提供了正确的环境和指令，它才能更高效地抵达目标。

你用 /goal 做过什么？

[原文链接]