AI 編碼讓實作速度越來越快。
許多人可能已經處於人類無法跟上審查所有實作的狀態。
作為解決方案之一，本文介紹了自製 Skill「codex-review」的最新版本，該 Skill 將審查角色分配給 Codex 子 Agent，並重複修正與重新審查，直到重要的問題被解決。
六個月前實際建立的 Skill
事實上，這個 Skill 的基礎是在大約六個月前建立的。我一直逐步改進它，並持續定期使用。
https://x.com/makaneko_AI/status/2005475035075707092
之前的版本是以 Claude Code 負責實作，並呼叫 Codex 作為審查者來重複修正與重新審查的方式介紹的。當時 Claude Code 在實作任務上很強，而 Codex 只是「聰明」，所以採用了那樣的配置。
然而，AI 環境已經完全改變。Codex 現在在實作方面更強、更聰明（除了 Fable 5），而且許多人可能只用 Codex 就能完成實作任務。
為了適應這樣的環境，我重新整理了內容，讓迴圈在 Codex 內部運行。
最新版本變更的三件事
基本流程與前一個版本相同。
分開實作負責人與審查負責人 ↓ 審查者以唯讀模式查看 ↓ 如果有重要問題提出則失敗 ↓ 修正 ↓ 使用相同方法重新審查 ↓ 反覆直到通過
最新版本的關鍵點是以下三項：
1. 針對 GPT-5.5 最佳化
2. 專注於重要問題
3. 提升整體準確性
我將依序說明。
1. 針對 GPT-5.5 最佳化
截至 2026/06/18，OpenAI 最新的 GPT-5.5 系列定位為擅長 Agent 基礎編碼與實務工作的模型。據說即使面對多步驟、模糊的任務也能自主進行。
查看官方 GPT-5.5 指南，它提到「與其塞入詳細程序，不如簡潔地寫出期望結果，效果會更好」。
因此，在最新版本中，我停止列出詳細的模板，並加強了審查者必須遵循的規則。
https://x.com/makaneko_AI/status/2049848091860463995
2. 專注於重要問題
Codex 有一個傾向，無論好壞，它會利用其智慧提出細節問題。
因此，在最新版本中，我明確告訴審查者「只挑出 P0/P1 等級（最高/高優先級）的問題，不要處理細微的風格問題」。
這樣一來，不必要的重複細微修正減少了，更容易順利進行。
3. 提升整體準確性
我在小細節上整體提升了準確性。
例如，我堵住了審查中途停止卻被標記為通過的漏洞。當審查者未能啟動或回傳的報告損壞無法讀取時，不再標記為通過。
即使大型變更在多位審查者之間共享，只有當所有人都返回通過、且沒有未審查或失敗的審查時，整個項目才算通過。這些改進降低了審查時遺漏問題的風險。
推薦用法
這個 Skill 被設定為在規格設計或中大型實作後自動觸發，但建議讓它在使用者預期的時機自動啟動。
例如，在 Codex 總是先讀取的 AGENTS.md 檔案中，加入「當...時執行 Codex 審查」。或者，如果有實作計畫的格式，就在那裡將它作為強制步驟。
前一個版本的解說文章也說明了這部分。
https://note.com/makaneko_ai/n/n3cefcec49e2d
Skill「codex-review」完整文字
規模 | 標準 | 策略 |
|---|---|---|
小 | ≤3 個檔案, ≤100 行 | diff 1 次執行 |
中 | 4-10 個檔案, 100-500 行 | arch → diff 1 次執行 |
大 | >10 個檔案, >500 行 | arch → diff（多次平行執行）→ 交叉檢查 |
{
"ok": false,
"summary": "審查摘要",
"issues": [
{
"file": "src/auth.py",
"lines": "42-45",
"problem": "問題描述",
"recommendation": "修正計畫",
"verification": "修正後的驗證方法"
}
],
"notes_for_next_review": "備註"
}
``text
## 修正迴圈
若 ok=false，則迭代最多 max_iters 次。預設為 max_iters=5。
1. 分析 issues 並建立修正計畫。
2. 實作者以最小 diff 進行修正（將規格變更保留為未解決問題）。
3. 根據變更風險執行測試、linter 或其他替代驗證。若未執行，則留下原因；若在關鍵路徑上未經驗證，則視為阻擋。
4. 以相同模式重新審查。
停止條件：
- ok=true：閘門通過
- 達到 max_iters：閘門失敗
- 連續兩次測試失敗：閘門失敗
- 審查者失敗 / JSON 解析失敗 / 輸出格式缺陷 / 存在未審查範圍：閘門失敗
若因閘門失敗而停止，請在最終報告中將剩餘的阻擋、未審查及失敗的驗證輸出為未解決項目。
## /review 備援
僅在 JSON 閘門失敗時使用 /review。/review 是探索輔助工具，其輸出不應直接作為 ok=true 的依據。
## 錯誤規則
- 若審查者無法建立，請在最終報告中記錄失敗原因、嘗試的審查者路徑及未審查範圍。
- 不得放寬審查者的唯讀限制。
- 若輸入過多或逾時，可透過縮減範圍或分割來重試。
## 最終報告範例
這是一個存在未審查範圍的範例，並非完整模板。
``text
Codex 審查結果
- 模式：JSON 閘門或 /review
- 審查範圍：分支 diff
- 規模：大（12 個檔案, 620 行）
- 平行：3 個子 Agent
- 審查者路徑：先 spawn_agent
- 備援證據：無
- 迭代次數：2/5
- 審查閘門：ok=false
- 原因：unreviewed_scope 不為空
- 完成證據：push/merge/release/任務完成等已另行確認
修正歷史
- auth.py：新增授權檢查
未審查
- utils/legacy.py：Codex 逾時，需要重新審查
未解決
- main.py：內容、風險、建議動作
總結
codex-review Skill 的最新版本不僅僅是讓前一個版本在 Codex 內部運作。它為了符合當前的 Codex 與 GPT-5.5，去除了不必要的步驟，並明確了作為審查閘門必須遵循的規則。
自動審查與修正的機制非常方便，請務必嘗試導入。
如果你覺得這篇文章有幫助，我很高興你能追蹤與分享。我會繼續分享不只是使用 AI，而是讓 AI 自主運作的方法。
相關文章
https://x.com/makaneko_AI/status/2058739339606233492
