---
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="/zh-Hant/docs/codex/official/03-extensions/11-hooks-checks" />
  <Card title="從資料到報告" description="需要長期記錄 scores、artifacts 和趨勢時，借用報告場景的結構。" href="/zh-Hant/docs/codex/official/08-scenarios/92-data-to-report" />
  <Card title="UI 精修" description="視覺和體驗類迭代可以繼續看 granular UI changes 場景。" href="/zh-Hant/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>
