OpenAI的dominik kundel，发了一篇Codex新增的功能goal mode的指南，下为全文：

`/goal` 指南 🥅

我们推出了 goal mode（目标模式，或 `/goal`），目的是帮助你让 Codex 朝着一个具体成果持续推进。

当你设定目标后，Codex 会持续工作，直到目标达成为止；这可能需要几个小时，也可能需要几天。有些人已经让 Codex 围绕单一目标连续工作超过 120 小时。

Goal mode 非常强大。为了最大限度发挥它的作用，有几件事值得注意。下面是使用 `/goal` 时要记住的 7 点。

1. 设定清晰、可验证的标准

你在启动 goal mode 时定义的提示词，表面上可能是初始提示，但更重要的是，它会成为这个目标的“退出标准”。

Codex 会在每一轮之后检查目标是否已经达成。因此，你的目标提示不应该太长，而应该聚焦于一个清晰的判断标准：什么时候算完成。

多数情况下，一个好的目标会包含一个明确的数字，供模型判断目标是否达成。好的例子包括：

- “将构建和部署时间减少 30%。”- “把这个功能从 TypeScript 迁移到 Rust，并达到 100% 的测试等价性。”- “改进应用脚手架，让生产环境中的最大内容绘制时间低于 2.5 秒。”

如果你不确定如何最好地定义目标，或者想先和 Codex 一起头脑风暴项目，你不必一开始就用 goal mode 开启线程。

Codex 可以自己设置目标。所以你可以先正常开始对话；当你准备让 Codex 开始执行工作时，可以让 Codex 根据你们之前的对话来设置目标。

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

2. 尽可能提供指导

像“将构建和部署时间减少 30%”这样的提示很酷，甚至可能让 Codex 找到一些很有创意的解决方案。但如果你已经大概知道问题可能在哪里，这种提示也可能让 Codex 走很多弯路。

只要可能，就告诉 Codex 应该从哪里开始、可以使用哪些工具来达成目标，或者提供其他提示，避免 Codex 走错方向。

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

同理，如果你的目标是减少构建时间，而你知道大部分时间都耗在哪里，那就尽量在提示词中先把 Codex 指向那个区域。

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

3. 让进展可衡量

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

有些任务天然就容易衡量，比如优化构建时间或提高测试覆盖率，因为 Codex 往往已经有相应工具，或者会自然地创建这些工具。

对于其他目标，值得先和 Codex 头脑风暴一下：哪些工具会有帮助，或者提示它用什么方式判断自己是否在取得进展。

例如：

- 为两个截图之间的视觉差异创建计算工具；- 或者为你正在调优的 agent 创建一套评估集。

当我让 Codex 根据视频重建一些组件时，我让 Codex 为自己创建一个工具，用来对截图进行差异比较并检查差异。随着时间推移，它自己选择不断改进这个工具，加入了不同的 diff 模式。

`[图1]`

根据任务类型，你还需要考虑是否存在额外的衡量或检查标准。否则，Codex 可能会以为任务完成了，但你其实会认为还不完整。

例如：

- 实现 UI 时直接裁剪设计参考图并内联进去，以此达到“像素级完美”；- 或者通过减少测试覆盖范围来达到 100% 的测试通过率。

4. 创建真实的执行环境

为了让 Codex 真正朝目标取得进展，它需要在一个真实的环境中运行。

实际来说，如果你想优化部署时间或延迟问题，它应该能够访问与生产环境相似的部署和测试环境：

- 相同的技术栈；- 相同的标志位；- 类似的数据库。

举个例子，我们曾经在调试 **developers.openai.com** 的构建和部署时间优化。我们已经在使用 deploy previews，所以 Codex 可以部署到预览环境，并查看相关日志。

但我们的预览部署相比完整生产运行禁用了一些构建路径。因此，Codex 后来不得不手动部署到具有类似生产配置的相同环境中，来检查真实情况。

同样，你也可以让 Codex 使用 computer use 来测试实际应用。为了做一些 iOS 性能优化，**@ dimillian** 甚至使用了实体设备，以获得最准确的环境。

5. 谨慎设定视觉目标

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

如果你没有给出正确的指导和约束，它可能会陷入某些细节问题，而忽略整体目标。

比如，如果参考图中包含 Codex 需要生成的图形，无论是 SVG 图标还是图片，它可能会把大量精力花在精确还原这些图形上，而不是正确拆解问题。

此外，Codex 还需要工具来正确做视觉比较，这意味着会引入更多图像输入，整体 token 使用量也会更高，但不一定能让 Codex 更容易识别改进机会。

因此，图片通常更适合作为辅助上下文，帮助推动目标达成；但你应该寻找其他方式让 Codex 判断目标是否已经达成，比如：

- 功能清单；- 实现规格；- 是否遵循设计系统。

6. 跟踪进展

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

根据目标类型，我发现下面几种方法有助于跟踪进展：

- **让 Codex 在有意义的阶段提交 commit，并推送到 draft PR。** 这在你开发带有预览部署的网站时尤其有用。

- **让 Codex 更新一个给高管看的产物。** 这可以是一个 HTML 文件，你可以在应用内浏览器中一直打开；也可以用 Sites 部署给团队；还可以是一张用于跟踪进展的渲染图表，甚至是一份普通的 Markdown 文件。

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

- **使用其他聊天来询问状态更新。** 如果你只是想快速查看当前状态，可以运行 `/side` 开启一个新的 side chat，并在那里提问。因为它是从当前线程 fork 出来的，所以拥有截至目前的全部上下文，同时又是短生命周期的。

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

7. 清理并最终整理结果

很好，目标终于达成了！现在是不是可以直接把它 `$yeet` 给团队，然后收工？

一般来说，尤其是对于优化类任务，我发现让 Codex 回顾并审查已完成的工作会很有帮助。

你可以先用 `/review` 运行本地代码审查；但也值得让 Codex 更深入地反思：为了解决这个目标，它尝试过哪些不同方法，并据此做清理。

由于 Codex 会一直运行，直到达到目标，它可能尝试过若干效果不够好、甚至完全无效的方法，而这些尝试可能仍然残留在变更中。

开始给你的下一个任务设定 goal 吧

Codex 的 goal 功能是一个极其强大的工具，可以用来解决你遇到的一些最有意义的挑战。但提供正确的环境和指令，会让你更高效地达成目标。

你用 `/goal` 做过什么？

AI创造营