编者按:这篇文章来自 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 可能为了「像素级还原」某个 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 做过什么?
