简介

有些任务一次即可验证：构建成功、测试通过，任务就完成了。但有些优化问题很难解决，需要在紧密的评测循环中经过多次迭代。为确定下一步方向，Codex 需要检查当前输出并为其评分、决定下一项更改，然后不断重复，直至结果真正达到理想水平。

这类用例很适合搭配自定义 UI：让 Codex 记录每次迭代的输出和生成产物，以便您直观地查看进展。 您可以在应用中观察 Codex 持续工作，而目标产物、模型输出或生成的资源则不断改进。 关键是为 Codex 提供必要的脚本，以生成评测指标和可供检查的产物。

从评测开始

在任务开始前，请明确如何衡量成功。理想的设置通常结合：

• 确定性检查： 脚本可直接评分的项目，例如违反约束的情况，或通过代码计算得出的确定性指标
• LLM 评判检查： 根据评分标准，对难以精确编码的质量进行评分，例如相似度、可读性、实用性或整体质量；这类检查可以基于文本或图像输出

如果主观部分很重要，请为 Codex 提供一个脚本，使其可以使用 Responses API 等方式调用模型，并返回结构化分数。目的不是取代确定性检查，而是针对原本需要人眼评估的部分，用一致的评判机制来补充这些检查。

如果评测输出采用机器可读格式、在每次运行后保存，并且便于随时间推移进行比较，这一循环的效果最佳。

为 Codex 设定停止规则

复杂任务往往会偏离方向，因为提示中只要求“继续改进”，却没有说明何时停止。请明确设定停止规则。

一种实用做法是：

1. 为总分设定目标。
2. 单独为 LLM 评判结果的平均分设定目标。
3. 让 Codex 继续迭代，直到两项分数都超过阈值，而不是只达到其中一项。

例如，如果目标是获得高质量产物，请让 Codex 持续迭代，直到总分和 LLM 平均分都超过 90%。这样一来，任务的进展便清晰可判断：Codex 能够知道结果是否仍低于目标、差距在哪里，以及最新更改是否带来了改善。

持续维护迭代日志

对于长时间运行的工作，如果 Codex 记录迭代过程，而不是仅依赖聊天上下文，可靠性会高得多。

这份持续更新的日志应记录：

• 当前最佳分数
• 上次迭代中做了哪些更改
• 评测结果显示哪些方面有所改善或变差
• Codex 接下来计划尝试什么

任务需要长时间运行时，这一点尤为重要。恢复任务时，这份日志会成为交接依据，也是本次运行的自我评测记录。

检查产物，而不只是日志

对于某些复杂任务，仅查看代码差异和指标输出还不够。Codex 还应查看自己生成的产物。

如果输出是视觉内容，例如生成的图像、布局或渲染状态，请让 Codex 直接检查该产物。例如，当输出以图像形式存储在磁盘上时，让 Codex 将当前结果与之前的最佳结果或预期评分标准进行比较。

这样可以让循环更加有效：

• 评测脚本给出分数
• 产物显示分数遗漏了哪些问题
• 下一项更改同时以二者为依据

这种组合比在各次运行之间盲目修改代码有效得多。

明确每次迭代的步骤

要求 Codex 每次都遵循同一循环：

1. 对当前基线运行评测。
2. 从分数和产物中找出最主要的失败模式。
3. 进行一项有针对性的更改，以解决该瓶颈。
4. 重新运行评测。
5. 记录新分数，并注明此次更改是否有效。
6. 继续迭代，直到达到所有阈值。

严格遵循这一流程很重要。如果每次迭代同时更改太多内容，Codex 就无法判断究竟是哪种思路提高了分数。如果跳过日志记录，任务过程就难以信赖，也很难恢复执行。