Gary Talks Stuff：AI 寫的 Code 一堆 Bug？讓 Claude 跟 Codex 自動互審

寫軟體的成本在過去兩年因為 AI 被不斷壓低，不用懂程式，一句話就能讓 AI 生出一個網頁甚至一個 App。

這就是所謂的 vibe coding。

但只要真的動手做過，就會發現一個共通痛點：不管用哪個模型，產出的東西總有角落沒想清楚、邊界沒處理，跑起來就是一堆 bug。

來回修改的過程中，vibe coding 的時間全部都卡在 debug 循環上。

為了解決這個問題，Gary 分享了一套自己長期使用的工作流 —— cross model review，讓 Claude 跟 Codex 彼此自動審查，找出各自的盲點。

Claude 與 Codex 的分工哲學

Gary 原本是 Claude 的死忠用戶，但後來感覺 Claude 明顯降智，於是轉去使用 Codex。

用久了又發現 Codex 也有缺點，於是他想通一件事：何必二選一？

兩個模型各有脾氣、各有強項，那就兩個都要，各取所長。

在他的設定中，多數時候主力是 Claude，負責大部分的討論和實作計劃。

Codex 的角色是 reviewer，專門負責挑錯。

當然也可以反過來，畢竟 Codex 比 Claude 便宜不少。

Gary 用一個生動比喻來形容兩者的差異：Claude 很像班上那個第二名，跟他合作愉快、討論細心，偶爾還會給驚喜，但就是會粗心，有些細節沒顧到。

Codex 很無聊，跟他對話沒什麼火花，但他就是穩，尤其在處理後端複雜邏輯時特別可靠，該想到的都幫你想到了，考試總是考第一名。

為什麼不讓 Claude 自己檢查就好？

一個常見的疑問是：既然要省，為什麼不乾脆叫 Claude 自己再檢查一遍？

原因在於模型訓練時的側重點不同。

Codex 做前端的設計有時讓人吐血，但 Gemini 或 Claude 在這方面就做得比較好。

更重要的是，自己寫的東西自己讀三遍還是有錯字，拿給別人卻一眼就看到。

AI 也是一樣的道理，一個模型用自己的腦袋和假設檢查自己，一定存在盲點。

從手動到自動：人肉橋樑的瓶頸

Gary 最早的做法完全純手工：Claude 寫完 plan，複製貼到 Codex 請他 review，再把 feedback 複製回 Claude 修改，改完再貼回去複查。

來回跑好幾輪，直到兩邊達成共識。

雖然沒有嚴謹的 AB test，但體感上程式碼架構確實變乾淨，技術債變少，後續修 bug 的頻率也大幅降低。

但問題也來了：Gary 本人成為了生產力的瓶頸。

當需要多功能並行開發，同時跑三、四條開發線時，每一條線的 plan 都得手動跑好幾輪 review，所有東西都卡在複製貼上的速度上。

更糟的是，人有偷懶的本性。

有些 plan 看起來很簡單，瞄一眼就想跳過 review，結果出包的就是那些覺得應該沒事的東西。

跳過 review 省下的五分鐘，後面要花一兩個小時擦屁股。

出版社比喻：三層架構的理解

Gary 用一個出版社的比喻來解釋整套系統的設計邏輯。

想像出版社出書前的流程：作者寫稿、門口守衛檢查稿件上有沒有審核通過的章、審稿人負責與作者討論修改。

如果沒有章，稿子就不准送出這道門。

作者和審稿人來回討論，審稿人提出問題，作者要嘛改掉、要嘛拿出理由說服審稿人，直到兩個人都同意，審稿人才蓋上章。

老闆從頭到尾只會看到最後那份定稿。

把這個比喻套回系統：作者是 Claude，審稿人是 Codex，門口守衛是 StopHook，審核通過的章是 Marker（寫在檔案結尾的一段文字）。

StopHook：強制攔截的守衛

StopHook 是 Claude Code 裡的一個機制，每次 Claude 想收工、要把控制權交還給使用者之前就會被觸發。

觸發時有兩個選擇：放行（正常結束）或擋下並塞一段提示詞回去讓 Claude 繼續做事。

這個能擋下結束、還能塞提示詞回去的能力，是整套系統能成立的關鍵。

StopHook 在系統中做三件事：掃這一輪有沒有寫出 implementation plan、有的話翻到檔案結尾看有沒有審核通過的 marker、如果沒有 marker 就擋下並叫 Claude 去跑 Codex review skill。

StopHook 只負責攔，不負責審。

Codex Review Skill：審稿方法論

第二塊是 Skill，提供 Claude 一套審稿的方法論。

Claude 被 StopHook 攔下來後會閱讀這份 Skill，指示 Claude 調用 Codex CLI tool 請 Codex 幫忙 review。

直到 Codex 放行後，再回頭在檔案結尾蓋上審核通過的 marker。

兩塊平常互不相干，中間就靠 Marker 這個暗號接起來。

拆成兩塊的好處是解耦：攔截有問題就修 StopHook，審核品質不佳就改 Skill 裡的方法論，各司其職。

完整循環：五步流程

一個完整的審查循環有五個步驟。

第一步，Claude 寫完 plan，想結束對話。

第二步觸發 StopHook，發現檔案尾巴沒有 marker 就擋下。

第三步，Claude 收到 StopHook 的指令啟動 Codex review skill，呼叫 Codex 請他 review。

第四步，兩邊一輪一輪過招，該修的修、該反駁的反駁，直到雙方有共識且 Codex 回覆通過。

第五步，Claude 在檔案尾端蓋上審核通過的 marker。

從頭到尾 Gary 只需要掛在那邊等他們討論完畢。

共識為本：不是跑完輪數就算通過

這套流程最重要的設計是通過標準。

標準不是你們來回討論滿三輪就算過，而是兩個 model 真的達成了共識。

審稿人 Codex 不能為了趕快結束就隨便點個投放水，作者 Claude 也不能為了趕快過關就假裝問題不存在。

每一個爭議，Codex 都要明確表態：要嘛被說服了承認你說得對，要嘛堅持並講清楚到底在堅持什麼。

有爭議就繼續吵，沒有達成共識，不准收工。

Gary 一開始的版本有設最多三輪的上限，後來發現這會逼出很糟的結果：到了第三輪，不管問題解決了沒，它都會為了結束而假裝沒問題。

於是他把上限拿掉，只認一個標準：共識。

同一個對話的魔力：避免過度設計

如果每一輪都重開一個新的 Codex，它每次都是冷啟動，什麼都不記得。

結果就是每一輪都可能挑出一堆新的、不重要的小毛病，永遠挑不完，變成沒完沒了的過度設計。

但如果是同一個對話，Codex 記得自己上一輪講過什麼。

第一輪就把主要的問題一次抓出來，修掉就好。

下一輪它是來驗收的，看改對了沒，然後往共識收斂，而不是重新發明一堆新問題。

當然缺點在於第一次如果漏看，可能會漏掉一些關鍵 bug，但這樣已經可以解決 80% 的問題。

具體案例：電商超賣問題

Gary 舉了一個具體例子來說明這套系統的價值。

假設 Claude 規劃一個電商網站的下單功能，plan 寫得漂漂亮亮，其中一條寫著「這個功能必須保證不會超賣，同一件商品不會賣給兩個人」。

聽起來很完整，但仔細看整份 plan 從頭到尾沒有寫具體的處理方法。

只剩最後一件的時候，兩個人同時按下下單，那一瞬間到底要怎麼處理？誰先搶到？另一個怎麼被擋下來？

Claude 可能因為 context 過長導致遺漏細節，或者模型在處理這種 corner cases 時本來就容易粗心。

這時換 Codex 用第三方的角度客觀審核，就有更高的機率發現盲點，這就是整套系統真正的價值。

Harness：為自己打造的開發環境

Gary 把這件事往上拉一層來看待：他不只是找第二個 AI 來審稿。

他是根據自己的使用習慣替自己建立一套 harness。

Harness 可以理解成包在 AI 外面的整套工作環境，包含給它的限制、流程和工具。

就像老闆幫員工準備舒服的辦公室來提高工作效率，harness 就是你幫 AI agent 準備的辦公室。

回頭看這套流程：StopHook 扮演強制約束，逼著流程一定要走完，不給偷懶的空間。

Skill 扮演工作方法，定義了審核的流程跟方法。

Marker 是他們之間的握手暗號。

同樣的思路可以拿去包任何一件本來就會做、但常常會偷懶跳過的事。

Harness 不用複雜，就像一個好的產品不用太花俏。

只要它能解決生活中不起眼的小摩擦，就能大幅提高工作效率。

QA 精選

Q1：為什麼不只讓 Claude 自檢查，而要引入 Codex？

因為模型訓練時的側重點不同，同一個模型用自己的腦袋和假設檢查自己一定有盲點。

就像自己寫的文章讀三遍還有錯字，拿給別人一眼就看到。

不同的模型用不同的思維框架審查同一份 plan，能更有效地找出實作上的遺漏。

Q2：如何避免 AI review 變成沒完沒了的過度設計？

關鍵在於從頭到尾使用同一個 Codex 對話，而不是每輪重開新 session。

同一對話中 Codex 記得上一輪講過什麼，第一輪抓出主要問題，下一輪是來驗收而不是重新發明新問題。

這樣能往共識收斂，而不是無限循環。

Q3：為什麼不設 review 輪數上限？

Gary 最初設了三輪上限，但發現到了第三輪，不管問題解決了沒，AI 都會為了結束而假裝沒問題。

這完全違背了審核的初衷，因此最終拿掉上限，只認一個標準：真正的共識。

Q4：Harness 的概念可以應用到其他場景嗎？

可以，同樣的思路能拿去包任何一件本來會做、但常常偷懶跳過的事。

Harness 不用複雜，只要能解決生活中不起眼的小摩擦，就能大幅提高效率。

核心精神是從系統層面解決問題，而不是靠人的紀律。

Q5：這套系統對 solo developer 的意義是什麼？

Solo developer 沒有同事可以 code review，所有洞都得自己扛。

透過這套系統，可以建立一個永遠不會累、永遠不會偷懶的同事，24 小時在後面幫忙把關。

一個人也可以有一整個團隊的把關品質。

結語

當 AI 一直產出不夠好的東西，與其每次都自己跳下去手動救，不如回頭問一個問題：系統為什麼會讓這種東西過關？

然後從系統的層面直接把漏洞封殺掉，讓它下次不再發生。

對於 solo developer 來說，這件事尤其重要。

與其祈禱 AI 不要出錯，不如動手建一個讓它可以出錯、但錯誤會被 harness 接住的環境。

這就是一個現代開發者為自己打造的最佳工作流程。