AI 寫的 Code 一堆 Bug？Claude 與 Codex 的 Cross-Model Review 互審機制¶

Vibe Coding 時代，單一模型產出的程式碼容易遺漏邊界條件。這套方法用 Claude 負責實作、Codex 負責審查，透過 Stop Hook + Skill + Marker 三大元件自動化 Cross-Model Review，解決「既當運動員又當裁判」的盲點問題。適合獨立開發者或小團隊建立不依賴人肉紀律的代碼品質防線。

目錄¶

#一、Vibe Coding 的核心痛點
#二、解決方案：Cross-Model Review 互審機制
#三、個人 Harness 的最小實踐架構
#四、自動化互審的關鍵細節與收斂策略
#五、Solo Developer 的系統化思維
#六、全文總結與行動建議

一、Vibe Coding 的核心痛點¶

邊界條件與盲點遺漏¶

Vibe Coding 讓任何人都能用一句話生成網頁或 App，但單一模型產出的程式碼往往缺乏周全思考，容易遺漏 Corner Cases（極端情況）與邊界處理。結果是「跑起來一堆 Bug，反覆修改反而大幅消耗開發時間」。

人肉搬運的生產力瓶頸與紀律失效¶

如果採取純手工方式——將 A 模型的代碼複製給 B 模型審查，再將建議複製回來——面對多功能並行開發（Worktree）時，人類會成為「複製貼上」的生產力瓶頸。更嚴重的是，人性的「不自律」會導致在面對小型實作計畫時偷懶跳過審查，而出包的往往就是這些被忽略的細節。

痛點	手動審查	後果
Worktree 並行開發	人肉複製貼上	生產力瓶頸
小型 PL（實作計畫）	偷懶跳過審查	細節出包
單一模型自審	盲點永遠存在	同源盲區

二、解決方案：Cross-Model Review 互審機制¶

模型選型與性格分工¶

影片用班級比喻兩個模型的定位：

角色	模型	比喻	特點
作者（實作）	Claude	「第二名學生」	細心、互動愉快、能理解複雜想法並給驚喜，偶爾粗心漏細節
審稿人（審查）	Codex	「永遠第一名的學生」	對話缺乏火花，但處理後端複雜邏輯與跳錯極其穩健可靠

為何模型無法自我審查¶

同一個模型用同樣的「腦袋和假設」檢查自己寫的東西，盲點依然會存在——如同人類檢查自己的文章很難看出錯字。更重要的是，不同模型的訓練側重點不同（Claude/GPT 的前端美感與理解力優於 Codex），必須引進第三方客觀視角。

單一模型自審：
  Claude 寫 → Claude 審 → ❌ 盲點重複（同源偏差）

Cross-Model Review：
  Claude 寫 → Codex 審 → Claude 修 → Codex 驗 → ✅ 交叉覆蓋盲點

選型決策樹¶

選 Claude 做實作 如果你需要：
  ✅ 前端 UI / 創意設計
  ✅ 複雜想法的理解與表達
  ✅ 互動式的開發體驗

選 Codex 做審查 如果你需要：
  ✅ 後端邏輯的嚴謹把關
  ✅ 邊界條件與 Corner Cases 檢查
  ✅ 穩定可靠的 Bug 捕捉

三、個人 Harness 的最小實踐架構¶

影片將自動化系統比喻為「出版社出書流程」，三大核心元件各司其職：

┌─────────────────────────────────────────────────┐
│                 出版會審流程                      │
│                                                 │
│  作者(Claude) ──寫──→ 神稿人(Codex) ──審──→ 作者 │
│       │                   │              │      │
│       └─ 被守衛攔截 ←── Marker ◄── 審核通過  │
│              │                                  │
│         Stop Hook（門口守衛）                     │
└─────────────────────────────────────────────────┘

三大核心元件¶

元件	角色	功能
Stop Hook	門口守衛	Claude Code 的攔截機制，在 Claude 想要結束對話前觸發，檢查檔案末端是否有核准標記
Skill	審稿方法論	引導 Claude 如何調用 Codex 工具進行 Review 的提示詞指南
Marker	審核通過章	寫在檔案結尾的特定文字暗號，作為審核通過的憑證

解耦設計的智慧¶

將系統拆分為 Stop Hook（只負責攔截） 與 Skill（負責審核方法論）。這種設計的好處是：

✅ 攔截異常 → 修 Stop Hook
✅ Review 品質不佳 → 優化 Skill
❌ 兩者耦合 → 牽一髮動全身

Stop Hook ──┐
            ├── 獨立維護，互不影響
Skill    ──┘

❌ 耦合設計：
  一個大腳本同時處理攔截 + 審核邏輯 → 改一處壞另一處

四、自動化互審的關鍵細節與收斂策略¶

單一對話 Session 的重要性¶

LLM 具有「順從性（Sycophancy）」傾向。若每一輪都重開新 Session，Codex 會為了找碴而找碴，導致過度設計（Overengineering）且無法收斂。堅持在同一個對話中進行，Codex 第一輪抓出大問題，第二輪便會專注於「驗收」而非無事生非。

❌ 每輪新 Session：
  Claude 提交 → 新 Codex Session（為找碴而找碴）→ 過度設計 → 不收斂

✅ 同一 Session 延續：
  Claude 提交 → Codex 第1輪（抓大問題）→ Claude 修
  → Codex 第2輪（驗收模式）→ 共識達成 → 收斂 ✓

共識機制的建立¶

審查通過的標準不是走形式。兩者必須真正達成共識：

❌ Codex 放水 → 低品質代碼通過
❌ Claude 假裝問題不存在 → 隱患遺留
✅ 有爭議就持續討論，直到一方被說服

影片中取消了「最多三輪」的上限，因為上限反而會逼出模型為了完工而假裝沒問題的惡劣結果。

收斂策略對比¶

策略	行為	結果
固定三輪上限	模型為了完工假裝沒問題	❌ 品質虛假
每輪新 Session	為找碴而找碴，過度設計	❌ 不收斂
同一 Session + 無上限	第一輪找大問題，第二輪驗收	✅ 真正收斂

五、Solo Developer 的系統化思維¶

Harness 的真正定義¶

Harness（安全帶/束帶）是指包在 AI 外面的那一整套工作環境，包含限制、流程與工具——如同老闆幫員工準備的舒適辦公室。它不是單一工具，而是一個讓 AI 發揮最大價值的安全框架。

從「人肉救火」到「系統防禦」¶

當 AI 產出不夠好的程式碼時，與其每次都肉身跳下去救火，不如從系統層面思考：

❌ 人肉救火模式：
  AI 寫出 Bug → 人類發現 → 手動修復 → 下次再犯 → 循環

✅ 系統防禦模式：
  AI 寫出 Bug → Harness 攔截 → 自動互審 → 修復 → 漏洞封殺
                                    │
                               「為什麼放行這種東西？」
                               → 修強 Harness

✅ 反思：我的 Harness 為什麼會放行這種東西？
✅ 行動：直接在系統上把漏洞封殺
❌ 反應：每次跳下去手動修

六、全文總結與行動建議¶

核心價值¶

這套「個人最小 Harness 實踐」的核心價值在於用系統的強制力克服人類的紀律盲點。將 Cross-Model Review 轉化為底層自動化的基礎設施，讓 Claude 的靈動創意與 Codex 的無聊穩健完美互補。對獨立開發者而言，等同於利用技術建構了一個「24 小時不嫌累、不偷懶且完全免費的 Code Review 團隊」。

四步行動建議¶

#	行動	為什麼
1	引進第三方審查	停止讓單一 AI「既當運動員又當裁判」
2	建立自動化攔截（Stop Hook）	不要仰賴人肉複製貼上，將 Review 固化為強制管道
3	保持對話上下文	同一 Session 中延續 Review，避免無限找碴
4	轉換管理思維	打造「允許 AI 出錯，但錯誤絕對被安全網接住」的環境

最佳實踐清單¶

✅ 開發與審查由不同訓練側重的模型分工
✅ Stop Hook 只負責攔截，Skill 只負責方法論（解耦）
✅ Review 在同一 Session 中延續，不設固定輪次上限
✅ 出錯時先反思 Harness 為什麼放行，再修強系統
❌ 讓同一模型自我審查（同源盲區）
❌ 設固定三輪審查上限（逼模型造假）
❌ 每輪重開 Session（Sycophancy 導致過度設計）
❌ 仰賴人肉紀律（必然偷懶）

参考资料¶

AI 寫的 code 一堆 bug？讓 Claude 跟 Codex 自動互審 — Gary Chen