场景 026 · Codex Use Case

迭代解决困难问题

给 Codex 可运行的评测脚本和可检查的产物,让它持续改进困难任务,直到分数达标。

EngineeringAnalysis
Iterate on difficult problemsEngineeringAnalysis

原文核对:2026-10-13 · 中文正文 · 英文提示词与演示

场景定位

给 Codex 可运行的评测脚本和可检查的产物,让它持续改进困难任务,直到分数达标。

难度
高级
时间跨度
长时间运行

适合用于

  • 每轮可以评分、但通常需多次尝试的问题。
  • 同时需要确定性检查和模型评审的视觉或主观输出。
  • 需要明确记录进度的长时间 Codex 任务。

起步提示词

英文原文 · 可复制后按实际材料修改

I have a difficult task in this workspace and I want you to run it as an eval-driven improvement loop.

Before changing anything:
- Read `AGENTS.md`.
- Find the script or command that scores the current output.

Iteration loop:
- Make one focused improvement at a time.
- Re-run the eval command after each meaningful change.
- Log the scores and what changed.
- Inspect generated artifacts directly. If the output is visual, use `view_image`.
- Keep going until both the overall score and the LLM average are above 90%.

Constraints:
- Do not stop at the first acceptable result.
- Do not revert to an earlier version unless the new result is clearly worse in scores or artifacts.
- If the eval improves but is still below target, explain the bottleneck and continue.

Output:
- current best scores
- log of major iterations
- remaining risks or weak spots

简介

有些任务构建和测试通过即完成;困难优化问题则需要紧密的评测循环。Codex 要检查当前产物、评分、决定下一处修改,再反复迭代直到结果足够好。

可让 Codex 记录每轮输出和产物,配合自定义 UI 直观查看进展。关键是提供计算指标的脚本和可检查的产物,使目标文件、模型输出或素材持续改善。

从评测开始

开始前定义成功标准,通常结合:

  • 确定性检查:脚本直接计算的约束违规或其他确定性指标。
  • 模型评审:按评分标准评价相似度、可读性、实用性或整体质量,可使用文本或图像输出。

主观质量重要时,提供一个通过 Responses API 等调用模型、返回结构化分数的脚本。它补充确定性检查,为原本需要人工观察的部分提供一致评审。

评测结果应可机器读取、每轮保存,并便于跨时间比较。

可以描述所需检查,让 Codex 编写评测脚本。

明确停止规则

“持续改进”却没有停止条件,容易偏离目标。

实用做法:

  1. 设置整体分数目标。
  2. 单独设置模型评审平均分目标。
  3. 要求两者都超过阈值才停止。

例如要求整体分数和模型平均分都超过 90%,使 Codex 能判断是否达标、差距在哪,以及最新修改是否有效。

持续记录迭代

长时间任务应保留工作记录,不只依赖聊天上下文。

记录应包含:

  • 当前最佳分数。
  • 上一轮修改。
  • 评测显示哪些变好或变差。
  • 下一步准备尝试什么。

任务持续越久越重要;日志既是恢复时的交接点,也是本轮自我评估记录。

检查实际产物

有些任务仅看代码差异和指标不够,还必须查看实际产物。

图像、布局或渲染状态等视觉输出,应直接打开产物,例如磁盘图片,与此前最佳结果或评分标准比较。

这样形成更完整的循环:

  • 评测脚本报告分数。
  • 产物揭示分数遗漏的问题。
  • 下一次修改结合两者决定。

这比每轮盲目修改代码更有效。

明确每一轮操作

要求每次遵循相同循环:

  1. 评测当前基线。
  2. 结合分数和产物找出最大失败模式。
  3. 针对瓶颈做一项聚焦修改。
  4. 重新评测。
  5. 记录新分数和修改效果。
  6. 持续到阈值达标。

一次改太多就难以判断有效因素;跳过记录则难以信任和恢复任务。

展开英文原文对照

Give Codex an evaluation system, such as scripts and reviewable artifacts, so it can keep improving a hard task until the scores are good enough.

Introduction

Some tasks are easy to verify in one shot: the build passes, the tests go green, and you are done. But there are some optimization problems that are difficult to solve, and need many iterations with a tight evaluation loop. To know which direction to go in, Codex needs to inspect the current output, score it, decide the next change, and repeat until the result is actually good.

This type of use case pairs well with a custom UI that lets you inspect progress visually, by having Codex log the outputs and generated artifacts for each iteration. You can watch Codex continue working in the app while the target artifact, model output, or generated asset keeps improving. The key is to give Codex the necessary scripts to generate the evaluation metrics and the artifacts to inspect.

Start with evals

Before the task begins, define how success will be measured. The best setup usually combines:

  • Deterministic checks: things the scripts can score directly, such as constraint violations or deterministic metrics computed with code
  • LLM-as-a-judge checks: rubric-based scores for qualities that are harder to encode exactly, such as resemblance, readability, usefulness, or overall quality - this can rely on text or image outputs

If the subjective part matters, give Codex a script that can call a model for example using the Responses API and return structured scores. The point is not to replace deterministic checks, it’s to supplement them with a consistent judge for the part humans would otherwise assess by eye.

The loop works best when the eval output is machine-readable, saved after every run, and easy to compare over time.

Tip: Ask Codex to generate the evaluation script for you, describing the checks you want to run.

Give Codex a stopping rule

Hard tasks often drift because the prompt says “keep improving” without saying when to stop. Make the stopping rule explicit.

A practical pattern is:

  1. Set a target for the overall score.
  2. Set a separate target for the LLM-judge average.
  3. Tell Codex to continue until both are above the threshold, not just one.

For example, if the goal is a high-quality artifact, ask Codex to keep going until both the overall score and the LLM average are above 90%. That makes the task legible: Codex can tell whether it is still below target, where the gap is, and whether the latest change helped.

Keep a running log of the loop

Long-running work is much more reliable when Codex keeps notes about the loop instead of relying only on the chat context.

That running log should record:

  • the current best scores
  • what changed on the last iteration
  • what the eval said got better or worse
  • what Codex plans to try next

This is especially important when the task runs for a long time. The log becomes the handoff point when the task resumes and the self-evaluation record for the current run.

Inspect the artifact, not just the logs

For some difficult tasks, the code diff and metric output are not enough. Codex should look at the artifact it produced.

If the output is visual, such as a generated image, layout, or rendered state, let Codex inspect that artifact directly, for example when the output lives on disk as an image and compare the current result to the prior best result or to the intended rubric.

This makes the loop stronger:

  • the eval script reports the score
  • the artifact shows what the score missed
  • the next change is grounded in both

That combination is much more effective than changing code blindly between runs.

Make every iteration explicit

Ask Codex to follow the same loop every time:

  1. Run the evals on the current baseline.
  2. Identify the biggest failure mode from the scores and artifacts.
  3. Make one focused change that addresses that bottleneck.
  4. Re-run the evals.
  5. Log the new scores and whether the change helped.
  6. Continue until the thresholds are met.

This discipline matters. If each iteration changes too many things at once, Codex cannot tell which idea improved the score. If it skips logging, the task becomes hard to trust and hard to resume.