概览
为 Codex 提供一套评估系统，例如脚本和可审查的产物，让它能够持续改进一项困难任务，直到分数足够好为止。
适合场景
- 适用于每次迭代都可以评分、但通常需要多轮尝试才能得到最佳结果的问题
- 适用于输出具有视觉性或主观性、既需要确定性检查又需要 LLM 充当评审打分的任务
- 适用于长时间运行的 Codex 会话，在这种情况下你希望清晰跟踪进展，而不是依赖上下文
持续迭代，直到评估通过
我在这个工作区中有一个困难任务，我希望你将它作为一个由评估驱动的改进循环来执行。 在做任何修改之前： - 阅读 `AGENTS.md`。 - 找到用于给当前输出打分的脚本或命令。 迭代循环： - 每次只做一个聚焦的改进。 - 每次有意义的更改后，重新运行评估命令。 - 记录分数以及改了什么。 - 直接检查生成的产物。如果输出是可视化的，请使用 `view_image`。 - 持续进行，直到总体分数和 LLM 平均分都超过 90%。 约束： - 不要在第一个可接受结果出现时就停止。 - 除非新结果在分数或产物上明显更差，否则不要回退到更早的版本。 - 如果评估有所提升但仍低于目标，请说明瓶颈并继续。 输出： - 当前最佳分数 - 主要迭代日志 - 剩余风险或薄弱点
简介
有些任务可以一次性轻松验证：构建通过、测试全绿，然后你就完成了。但还有一些优化问题很难解决，需要在紧密的评估循环中进行多次迭代。为了知道下一步该往哪个方向走，Codex 需要检查当前输出、为其评分、决定下一次改动，然后反复执行，直到结果真正足够好。
这类用例很适合搭配自定义 UI，通过让 Codex 记录每次迭代的输出和生成产物，以可视化方式检查进展。 你可以在应用中看到 Codex 持续工作，同时目标产物、模型输出或生成的资源不断改进。 关键在于，为 Codex 提供必要的脚本来生成评估指标，以及可供检查的产物。
从评估开始
在任务开始前，先定义如何衡量成功。最佳配置通常会结合以下两类：
- 确定性检查： 脚本可以直接评分的内容，例如约束违规情况，或通过代码计算出的确定性指标
- LLM 充当评审的检查： 基于评分标准对那些难以精确编码的质量进行打分，例如相似度、可读性、实用性或整体质量——这可以依赖文本或图像输出
如果主观部分很重要，请为 Codex 提供一个脚本，能够调用模型，例如使用 Responses API，并返回结构化分数。重点不是替代确定性检查，而是用一个一致的评审机制来补充那些原本需要人类肉眼判断的部分。
当评估输出可机器读取、每次运行后都会保存、并且易于随时间比较时，这种循环效果最佳。
提示：你可以让 Codex 为你生成评估脚本，并描述你想运行的检查项。
给 Codex 一个停止规则
困难任务常常会偏离方向，因为提示词只说“持续改进”，却没有说明何时停止。要把停止规则说清楚。
一种实用模式是：
- 为总分设定目标。
- 为 LLM 评审平均分单独设定目标。
- 告诉 Codex 只有当两者都高于阈值时才停止，而不是只满足其中一个。
例如，如果目标是高质量产物，就让 Codex 持续进行，直到总分和 LLM 平均分都超过 90%。这样任务就变得清晰可判断：Codex 可以知道自己是否仍低于目标、差距在哪里，以及最近一次改动是否有帮助。
为循环保留持续更新的日志
当 Codex 为循环持续记笔记，而不是试图记住线程中的所有内容时，长时间运行的工作会可靠得多。
这份持续日志应记录：
- 当前最佳分数
- 上一次迭代改了什么
- 评估指出哪些地方变好了或变差了
- Codex 下一步计划尝试什么
当任务运行很长时间时，这一点尤其重要。这份日志会成为下一次会话的交接点，也是当前会话的自我评估记录。
检查产物，而不只是日志
对于某些困难任务，仅看代码 diff 和指标输出还不够。Codex 应该查看它生成的产物本身。
如果输出是可视化的，例如生成的图像、布局或渲染结果，应让 Codex 直接检查该产物；例如当输出以图像形式保存在磁盘上时，将当前结果与之前的最佳结果或预期评分标准进行比较。
这样会让循环更强健：
- 评估脚本报告分数
- 产物显示分数遗漏了什么
- 下一次改动同时基于这两者
这种组合比在两次运行之间盲目改代码要有效得多。
让每次迭代都明确可见
让 Codex 每次都遵循同样的循环：
- 对当前基线运行评估。
- 根据分数和产物识别最主要的失败模式。
- 做一个有针对性的改动来解决该瓶颈。
- 重新运行评估。
- 记录新的分数，以及这次改动是否有帮助。
- 持续进行，直到达到阈值。
这种纪律很重要。如果每次迭代同时改动太多内容，Codex 就无法判断究竟是哪一个想法提升了分数。如果它跳过日志记录，会话就会变得难以信任，也难以恢复。