Two desk lamps facing each other over a sheet of paper marked in red pencil
Back to blog
EngineeringAI Automation

2,481 次交叉審查:Claude Code 與 Codex 互相檢查

兩個月來,我們讓 Claude Code 與 Codex 在發布前互相審查對方的工作。經過 2,481 次審查,數字說明了什麼?我們又不得不加上哪一條規則?

S
Sno AI Team
September 22, 2026
|
6 min read
|
139 views
Share:

Claude Code 完成工作後,由 Codex 在發布前檢查。Codex 寫的東西,則交給 Claude 檢查。

銀行也是這樣運作的。沒有人核准自己的貸款。一個人寫好資料,另一個人簽字,誰也不覺得受了冒犯。我們把自己的做法稱為 Dual Brain 雙腦:兩個 AI Agent 結對完成同一項工作,一個執行,另一個審查。它內建於 Sno Station;從 七月中旬起,我們就一直用這種方式工作。

每次審查都會在建置機器的日誌檔裡留下一行。前陣子我起了好奇心,把它們數了一遍。

數量

從 七月 19 日到 九月 21 日,這兩個 AI Agent 互相審查了 2,481 次。這段期間有 63 天在工作,平均每天約 39 次。他們檢查了 9,452 個檔案中的 3.2 百萬行內容。

一次審查大約需要兩分鐘。中位數是 141 秒,十次裡有九次不到六分鐘就完成。這個數字比乍看之下更重要。人工審查需要一天,大部分時間都在等人。審查只要兩分鐘時,你就不再問某件事值不值得審查。每件事都會審查。

我原本以為大部分工作都會通過。

在給出結論的審查中,431 次判定通過,1,953 次判定需要處理。也就是說,五次裡有四次,第二個 AI Agent 把工作退了回去。

五次裡有四次。這些不是疲憊實習生交來的潦草初稿。模型已經跑過測試,也說工作完成了。

程式碼與計畫

接著,我把程式碼審查和計畫審查分開統計。

程式碼的通過率是 27%。1,475 次審查中有 398 次通過。不算好,但還能接受。

計畫的通過率是 3.6%。907 次裡只有 33 次。

我看了兩遍才敢相信。計畫是一份文件,說明我們要做什麼、為什麼做。你可能以為文件比程式碼容易寫對,畢竟它不用編譯。事實恰好相反。每次執行程式碼,現實都會糾正它。計畫卻可以寫著資料庫有某個實際不存在的欄位;在有人照著它動手之前,這句話看起來完全合理。

所以現在,我們把事實和計畫一起交給審查者。在審查計畫之前,撰寫計畫的 AI Agent 先執行指令、統計資料列、匯出資料庫結構,並附上原始輸出。這樣審查者才有東西可以核對計畫中的說法。否則,這就像閉卷考試:審查者能找到文件內部的矛盾,卻看不出文件與現實不符。

最嚴重的發現,多半正來自這個落差。同一期間,審查者在 1,395 次審查中標出了 4,277 個嚴重問題。我沒有逐一核實,也不是每個問題都真的存在。但確實存在的問題往往屬於同一類:有人信心十足地寫下一件事,卻從來沒有人親自查證。

出問題的地方

如果文章寫到這裡,就是個好故事了。我也想相信,所有這些審查都讓工作變得更好。

事情沒這麼簡單。問題在於,審查者總能找到點什麼。

看看後續輪次。撰寫者修好指出的問題,再次送審後,工作有 21% 的機率通過。第一輪的通過率是 17%。修好每個問題,幾乎沒改變通過的機會。有一項工作審查了十五輪。

這不是撰寫者失敗了十五次。審查者只是在做審查者會做的事。你請一個能力很強的模型找問題,它就會找到問題。如果一般使用情況沒有問題,它便往角落裡找。兩筆請求在同一毫秒抵達。寫入進行到一半時取消。這些情況也許會發生,就像被隕石砸中也可能發生一樣。

而撰寫者很配合,每發現一個問題就加點東西來修。

這個月稍早,我們遇到一個小問題。修復經過六輪審查。每一輪,審查者都提出一個新顧慮;每一輪,撰寫者都加一道防線。替 token 數量設上限。為每個工作階段加鎖。另建一張表,記錄已經提供了什麼。再加一份別名對照。最後,修補程式成了一座小堡壘。

這些機制從未在正式環境中執行過。可是在它們底下,修復本身仍有一行身分識別程式碼寫錯了,沒人發現,因為它埋在層層防線之下。這就像為了聽清一件聲音很輕的樂器而調高增益,結果聽到的主要是嘶嘶聲。

我們加的規則

於是我們寫下一條規則。這是整個實驗最有用的收穫。

發現一個問題,不等於必須加程式碼。

現在,審查結果分成兩類。第一類是一般使用者在日常使用中會遇到的問題,而且最小的修復不需要新增東西。這類問題要修。第二類是其他所有問題:罕見情況,以及需要新鎖、新重試機制或新資料表才能處理的事。這些問題會被記錄並回報。除非有人決定要做,否則它們不會變成程式碼。

我們也要求審查者先找多餘的東西,再找缺少的東西。沒人需要的鎖。只有一個呼叫端的開關。只是把程式碼重述一遍的測試。現在,刪掉東西也算一項審查發現。

審查次數也有上限:程式碼三輪,測試一輪。超過之後,就交給人來判斷;說不定本來就該如此。

值不值得

我沒辦法給你一個準確的價值數字。我倒是想。但我沒有對照組,沒有另一家公司在不審查的情況下交付同樣的工作。

我有的事實是:五次裡有四次,一個模型宣稱完成的工作,另一個模型認為有東西需要改。其中有些是雜訊。但一個 AI Agent 審查自己的工作時,幾乎從不把它退回去,因為它已經相信自己寫的東西。第二種意見必須來自別處:一個由另一群人訓練的模型,而且它當時不在場,沒有參與第一個模型認定一切都沒問題的過程。

兩個腦袋比一個好。看來,即使兩個腦袋都不是人,這句話也成立。

Sno Station 是開源的,交叉審查也是其中的一部分。專案在 sno.ai。

S

Written by Sno AI Team

Contributing writer at Sno.ai, sharing insights about AI, productivity, and knowledge management.

Related Articles

Comments

Comments coming soon. Configure Giscus at giscus.app

2,481 次交叉審查:Claude Code 與 Codex 互相檢查,五次有四次找到問題,結果如何