Codex 迭代修復迴圈：review → repair → validate 自動把壞掉的程式/文件修到通過

與其讓 AI「一次寫對」，不如讓它跑一個會自我修正的迴圈：審查→修復→驗證→把沒過的問題餵回去再修。OpenAI Cookbook 這個範例把這套閉環講得很清楚，三段 prompt 直接可改用。

[ Log in to see the full prompt ]

## 這是什麼／解決什麼痛點 這是把「修 bug／修過時的程式範例」從「賭 AI 一次改對」升級成「會自我迭代的閉環」。原始範例的具體場景是維護技術文件裡那些壞掉、過時的程式碼範例（用到已淘汰的模型或 API），但這套架構對任何「修到測試/檢查通過」的任務都適用。痛點是：AI 單次修復常常顧此失彼、或宣稱修好其實沒過；把流程拆成「審查 → 修復 → 驗證 → 回饋再修」的迴圈，就能讓它靠驗證結果一輪一輪逼近正確。 ## 為什麼這個來源值得用 這篇策展的是 **OpenAI Cookbook 官方 codex 範例** 裡的「Build iterative repair loops with Codex」。OpenAI Cookbook 是 OpenAI 官方維護、業界廣泛引用的範例庫，這個 Codex 範例示範的是「agentic 自我修正」這個正在普及的關鍵模式，可信度與實用性都高。 ## 核心三階段（原範例的精髓） 1. **REVIEW（審查）**：檢視目標、用 JSON schema 輸出結構化 findings，但「不改任何檔案」——把診斷與動手分開，讓初步判斷保持聚焦。原範例特別要求「只回最關鍵的幾個 finding」而非窮舉。 2. **REPAIR（修復）**：只對「一份副本」做最小、針對性的修改，依據 findings ＋ 上一輪的驗證 delta，並要求「保留原本的教學/業務流程」，最後回報變更摘要。 3. **VALIDATE（驗證）**：實際執行檢查、由 LLM 裁判依 rubric 逐項獨立評分（例：API 是否現代化、環境能否重現、產物能否跑通），附上執行證據，並把「仍未通過」整理成 delta 餵回下一輪。 關鍵設計是**階段間的結構化交接**：每輪把 review findings、repair 摘要、validation 結果寫進一份 record（如 `record.json`），讓你事後能稽核「它是怎麼收斂的」，而不必逐一翻每次改動。 ## 怎麼用 1. 用右側 full_prompt 的三段 prompt，分別當成 review / repair / validate 三個步驟。 2. 把 `{{ARTIFACT_PATH}}`、`{{BUSINESS_RULES}}`（你的偏好標準，如指定模型版本、要淘汰的 API）、`{{VALIDATION_CASES}}`（驗證 rubric）填好。 3. 串成迴圈：validate 沒過 → 把 delta 餵回 repair → 重跑，設一個 `{{MAX_ITERATIONS}}` 上限避免無限迴圈。 4. 修復務必動「副本」，跑通驗證再覆蓋原檔。 ## 何時用 適合「有明確驗證標準、但一次未必修得對」的任務：修壞掉的程式碼範例、把舊 API 升級到新版、修到測試全綠、批次更新一堆過時文件。任務若無法自動驗證對錯，這套迴圈的價值會大打折扣。 📎 來源：openai/openai-cookbook 的 examples/codex 範例「Build_iterative_repair_loops_with_Codex.ipynb」（版權 © 2025 OpenAI，MIT 授權）— 本篇為繁中改寫整理，原始 notebook 見上方連結。