Codex 用例
迭代解决疑难问题
将 Codex 用作打分的改进循环来解决难题。
为 Codex 提供一个评估系统，例如脚本和可审查的产物，这样它就能不断改进一项艰难的任务，直到得分足够好。
适用场景
- 适用于每次迭代都可以打分，但最佳结果通常需要多次循环的问题
- 适用于输出结果带有视觉性或主观性，需要同时进行确定性检查和 LLM-as-a-judge（作为评判者的 LLM）评分的任务
- 适用于长时间的 Codex 会话，你希望清晰地追踪进度，而不是仅仅依赖上下文
目录
迭代解决疑难问题
将 Codex 用作打分的改进循环来解决难题。
为 Codex 提供一个评估系统，例如脚本和可审查的产物，这样它就能不断改进一项艰难的任务，直到得分足够好。
适用场景
- 适用于每次迭代都可以打分，但最佳结果通常需要多次循环的问题
- 适用于输出结果带有视觉性或主观性，需要同时进行确定性检查和 LLM-as-a-judge（作为评判者的 LLM）评分的任务
- 适用于长时间的 Codex 会话，你希望清晰地追踪进度，而不是仅仅依赖上下文
起始提示词
简介
有些任务很容易一次性验证：构建通过，测试变绿，你就完成了。但是有些优化问题很难解决，需要在紧凑的评估循环中进行多次迭代。为了明确改进的方向，Codex 需要检查当前输出，对其进行评分，决定下一步的修改，然后重复这个过程，直到结果真正变好。
这种类型的用例非常适合与自定义 UI 搭配使用，让你可以通过让 Codex 记录每次迭代的输出和生成的产物，来直观地检查进度。你可以看着 Codex 在应用中继续工作，同时目标产物、模型输出或生成的资产不断得到改进。关键在于为 Codex 提供必要的脚本以生成评估指标，以及用于检查的产物。
从评估开始
在任务开始之前，定义衡量成功的标准。最佳的设置通常会结合：
- 确定性检查： 脚本可以直接评分的内容，例如约束违规或使用代码计算的确定性指标
- LLM-as-a-judge（LLM 作为评判者）检查： 针对难以精确编码的特质进行基于评分标准的打分，例如相似度、可读性、有用性或整体质量——这可以依赖于文本或图像输出
如果主观部分很重要，请为 Codex 提供一个可以调用模型的脚本，例如使用 Responses API 并返回结构化的分数。重点不是要取代确定性检查，而是用一个一致的评判者来补充它们，以处理那些原本需要人类用肉眼评估的部分。
当评估输出易于机器读取、在每次运行后都会保存，并且易于随时间进行比较时，这种循环的效果最好。
提示: 要求 Codex 为你生成评估脚本，描述你想运行的检查。
为 Codex 设定停止规则
困难的任务经常会出现偏离，因为提示词只说了“不断改进”，却没有说明何时停止。请明确设定停止规则。
A practical pattern is:
- 为总分设定一个目标。
- 为 LLM 评判平均分单独设定一个目标。
- 告诉 Codex 继续运行，直到两者都高于阈值，而不仅仅是其中一个。
例如，如果目标是获得高质量的产物，请要求 Codex 持续运行，直到总分和 LLM 平均分均高于 90%。这能让任务变得清晰：Codex 可以判断自己是否仍低于目标，差距在哪里，以及最新的更改是否有所帮助。
维护循环的持续运行日志
当 Codex 对循环进行记录，而不是试图从会话线索中记住所有内容时，长时间运行的工作会变得更加可靠。
该持续运行日志应记录：
- the current best scores
- 上一次迭代更改了什么
- 评估显示哪些方面变好或变差了
- Codex 下一步计划尝试什么
当任务运行很长时间时，这一点尤为重要。该日志会成为下一次会话的交接点，以及当前会话的自我评估记录。
检查产物，而不仅仅是日志
对于某些困难的任务，代码差异和指标输出是不够的。Codex 应该查看它生成的产物。
如果输出是视觉性的（例如生成的图像、布局或渲染状态），请让 Codex 直接检查该产物，例如当输出以磁盘上的图像形式存在时，将当前结果与之前的最佳结果或预期的评分标准进行比较。
这会让循环变得更强大：
- 评估脚本报告分数
- 产物展示了分数遗漏的内容
- 下一步的更改会基于两者进行考量
这种组合比在运行之间盲目更改代码要有效得多。
让每一次迭代都明确
要求 Codex 每次都遵循相同的循环：
- 在当前基线上运行评估。
- 从分数和产物中找出最大的失败模式。
- 进行一项针对性的更改，以解决该瓶颈。
- 重新运行评估。
- 记录新的分数以及该更改是否有帮助。
- 继续，直到满足阈值要求。
这种纪律性至关重要。如果每次迭代同时更改太多内容，Codex 将无法判断是哪个想法提升了分数。如果它跳过了日志记录，会话就会变得难以信任，也难以恢复。
