用 Codex 反覆攻克難題
說明如何把 Codex 用作可評分的改進迴圈，處理視覺、體驗和主觀質量類任務。
📖 本篇術語速查表
| 英文 / 縮寫 | 中文 | 一句話解釋 |
|---|---|---|
| Evals | 評估集 | 用一組可判定的例子衡量是否解決。 |
| 停止規則 | stop rule | 告訴 Codex 何時停、避免空轉。 |
| 迭代攻克 | iterate | 反覆嘗試逼近難題的解。 |
不想讀完？把下面這段提示詞丟給 AI 幫你跑完——幫你用 evals + 停止規則規劃一個難題的迭代攻克。
你是 Codex 難題迭代攻克規劃顧問，幫我用 evals 和明確停止規則規劃反覆攻克一個難題。
【角色】
你熟悉用 Codex 反覆攻克難題的方法：從 evals 開始、給明確停止規則、避免無效空轉。
【輸入】
- 我要攻克的難題：___
- 怎麼判斷算解決了（成功標準）：___
- 是否已有可判定的例子：___
- 可接受的嘗試成本：___
【工作流程】
1. 把成功標準變成可判定的 evals
2. 設計迭代方式（每輪改什麼、看什麼）
3. 給明確的停止規則（達標 / 多輪無進展即停）
4. 給從迭代到收斂的判斷
【輸出規範】
▌一、evals 設計（可判定）
▌二、迭代方式
▌三、停止規則
▌四、收斂 / 放棄的判斷
【硬約束】
- 沒有可判定標準先幫我建 evals，不盲目迭代
- 必須有停止規則，避免無限空轉燒成本
- 每輪基於 evals 結果調整，不憑感覺
- 多輪無進展要換思路或叫停
- 不替我假設成功標準，不清先問有些任務不能一次驗證完成。build pass、tests green 就結束的任務很簡單；但最佳化類任務、視覺類任務和主觀質量任務，經常需要反覆評分、觀察 artifact、做小改動，再重新評估。這個用例是把 Codex 當成 scored improvement loop 來用。
迭代任務必須有停止規則和迴歸判斷。否則 Codex 很容易在“繼續最佳化”裡漂移，或者把區域性變好誤判成整體變好。
官方頁面：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
- Codex workflows：https://developers.openai.com/codex/workflows
- Responses API：https://developers.openai.com/api/reference/resources/responses/methods/create
起始提示詞
我在這個 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 返回 structured scores。LLM judge 不是替代 deterministic checks，而是補充人眼通常會判斷的部分。
eval 輸出最好是 machine-readable，並且每輪都儲存，方便比較趨勢。
給 Codex 明確停止規則
“keep improving” 容易漂移。更穩的停止規則是：
- 設定 overall score 目標。
- 設定 LLM-judge average 目標。
- 要求 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 是三者結合：
- eval script 給出 score。
- artifact 告訴你 score 沒捕捉到什麼。
- next change 同時基於 score 和 artifact。
每次迭代都顯式
固定迴圈：
- 在 current baseline 上跑 evals。
- 從 scores 和 artifacts 找最大 failure mode。
- 做一個 focused change。
- 重新跑 evals。
- 記錄 new scores 和 change 是否有效。
- 繼續，直到 thresholds 達標。
如果一輪改太多，Codex 無法判斷哪條思路讓 score 變好。如果跳過 logging，長 session 會變得難以信任，也難以續跑。