---
title: "用 Codex 反复攻克难题"
description: "说明如何把 Codex 用作可评分的改进循环，处理视觉、体验和主观质量类任务。"
verifiedAt: "2026-05-06"
---

import { Cards, Card } from 'fumadocs-ui/components/card';

有些任务不能一次验证完成。build pass、tests green 就结束的任务很简单；但优化类任务、视觉类任务和主观质量任务，经常需要反复评分、观察 artifact、做小改动，再重新评估。这个用例是把 Codex 当成 scored improvement loop 来用。

> [!IMPORTANT]
> 迭代任务必须有停止规则和回归判断。否则 Codex 很容易在“继续优化”里漂移，或者把局部变好误判成整体变好。

官方页面：[https://developers.openai.com/codex/use-cases/iterate-on-difficult-problems](https://developers.openai.com/codex/use-cases/iterate-on-difficult-problems)

## 适合什么任务

| 场景 | Codex 应该做什么 |
|---|---|
| 每轮结果可以被评分，但最好结果需要多轮 | 每次只做一个 focused improvement，再 rerun eval |
| 输出有视觉或主观质量 | 同时使用 deterministic checks 和 LLM-as-a-judge score |
| 长时间 Codex session 需要清楚追踪进度 | 记录 scores、artifacts、changes 和下一步 plan |

相关官方说明：

- Custom instructions with AGENTS.md：[https://developers.openai.com/codex/guides/agents-md](https://developers.openai.com/codex/guides/agents-md)
- Codex workflows：[https://developers.openai.com/codex/workflows](https://developers.openai.com/codex/workflows)
- Responses API：[https://developers.openai.com/api/reference/resources/responses/methods/create](https://developers.openai.com/api/reference/resources/responses/methods/create)

## 起始提示词

```text
我在这个 workspace 里有一个困难任务，希望你用 eval-driven improvement loop 来处理。

改任何内容前：
- 阅读 `AGENTS.md`。
- 找到给当前 output 打分的 script 或 command。

Iteration loop：
- 每次只做一个 focused improvement。
- 每次有意义改动后，重新运行 eval command。
- 记录 scores 和改了什么。
- 直接检查 generated artifacts。如果 output 是视觉内容，使用 `view_image`。
- 持续迭代，直到 overall score 和 LLM average 都超过 90%。

约束：
- 不要在第一个勉强可接受的结果处停止。
- 除非新结果在 scores 或 artifacts 上明显更差，否则不要回退到早期版本。
- 如果 eval 有提升但仍低于目标，请解释 bottleneck 并继续。

输出：
- current best scores
- major iterations log
- remaining risks 或 weak spots
```

这个 prompt 先要求 Codex 找到评分脚本，再按固定 loop 改进。关键是不要停在第一个“还行”的结果。

## 从 Evals 开始

任务开始前先定义成功标准。实用 setup 通常结合两类评分：

| 类型 | 用法 |
|---|---|
| Deterministic checks | 脚本直接评分，例如 constraint violations 或可计算 metrics |
| LLM-as-a-judge checks | 对难以精确定义的质量打分，例如 resemblance、readability、usefulness、overall quality |

如果 subjective part 很重要，可以提供一个调用模型的脚本，例如用 [Responses API](https://developers.openai.com/api/reference/resources/responses/methods/create) 返回 structured scores。LLM judge 不是替代 deterministic checks，而是补充人眼通常会判断的部分。

eval 输出最好是 machine-readable，并且每轮都保存，方便比较趋势。

## 给 Codex 明确停止规则

“keep improving” 容易漂移。更稳的停止规则是：

1. 设置 overall score 目标。
2. 设置 LLM-judge average 目标。
3. 要求 Codex 同时超过两个阈值再停止。

例如高质量 artifact 可以要求 overall score 和 LLM average 都超过 90%。这样 Codex 能判断自己离目标差在哪里，最新改动是否有效。

## 保持 Running Log

长任务不要只依赖上下文记忆。让 Codex 维护 running log，记录：

- current best scores。
- last iteration 改了什么。
- eval 说哪里变好或变差。
- 下一步准备尝试什么。

这个 log 也是下一次 session 的 handoff 和当前 session 的自我评估记录。

## 检查 Artifact，而不只是 Logs

对视觉、布局、图片或渲染状态类任务，只看代码 diff 和 metric output 不够。Codex 应该直接检查生成物。

例如输出是图片时，让 Codex 用 `view_image` 看当前结果，并和 prior best 或 rubric 对比。

强 loop 是三者结合：

1. eval script 给出 score。
2. artifact 告诉你 score 没捕捉到什么。
3. next change 同时基于 score 和 artifact。

## 每次迭代都显式

固定循环：

1. 在 current baseline 上跑 evals。
2. 从 scores 和 artifacts 找最大 failure mode。
3. 做一个 focused change。
4. 重新跑 evals。
5. 记录 new scores 和 change 是否有效。
6. 继续，直到 thresholds 达标。

如果一轮改太多，Codex 无法判断哪条思路让 score 变好。如果跳过 logging，长 session 会变得难以信任，也难以续跑。

## 接下来去哪

<Cards>
  <Card title="Hooks 自动检查" description="把 eval、格式化、测试和评分脚本接成可重复的自动检查。" href="/docs/codex/official/03-extensions/11-hooks-checks" />
  <Card title="从数据到报告" description="需要长期记录 scores、artifacts 和趋势时，借用报告场景的结构。" href="/docs/codex/official/08-scenarios/92-data-to-report" />
  <Card title="UI 精修" description="视觉和体验类迭代可以继续看 granular UI changes 场景。" href="/docs/codex/official/08-scenarios/107-ui-polish" />
  <Card title="官方 Iterate use case" description="需要最新官方提示词和示例时回官方页面核验。" href="https://developers.openai.com/codex/use-cases/iterate-on-difficult-problems" />
</Cards>
