兩個模型互審：合併前必須有第二意見

AI 寫代碼越來越快，人的 review 帶寬卻是一個常數。一天下來，十幾個提交、幾個 PR，我不可能每一行都看。

我現在的規則是：合併前必須有第二意見——由另一個模型，或者至少是一個獨立的新會話，把改動審一遍。這條規則已經寫進了我提 PR 前的檢查流程裏，不靠記得。

但這件事比「讓另一個 AI 看看」複雜。下面是我踩出來的做法。

一、評審會以兩種方式失效

失效	表現	代價
假陽性（幻覺）	報了一個不存在的問題	浪費一輪；更糟的是把正確的代碼「修」壞
假陰性（漏報）	真問題沒報出來	缺陷直接進主幹

直覺只會防前者，因為它顯眼。但後者更貴。我遇到過一次整頁崩潰上線：類型檢查、單元測試、構建三道門禁全綠，沒有一道檢查文案有沒有對應的譯文。

所以協議要兩頭都堵。 只防幻覺，等於只防了便宜的那一半。

二、評審方選誰：參與不等於評審

組合	獨立性
跨模型交叉：A 寫 B 審，B 寫 A 審	強，兩套先驗
同模型新會話	弱，會一起漏同一類問題
同會話自評	無，不算評審

只有一個模型可用時，退到同模型新會話，但絕不喂實現時的上下文，只給 diff 和要檢查的清單。餵了上下文，它會順着實現者的思路複述一遍。

有一條看起來是廢話、實際栽過的規則：本輪的執行方不能當本輪的評審方。 有一批任務，另一個模型全程在當執行方寫代碼，收活時「這批有它參與」被順手讀成了「獨立評審跑過了」。寫代碼的模型對自己的實現有立場，它複查自己就是自評。

獨立性來自兩套先驗，不來自換個進程、換個會話、換個提示詞。

三、不是每個改動都要審

全量評審在數學上就是失效的：AI 產出的速度在漲，人的驗證帶寬不漲。預算要投向失敗不可逆的那一小部分。我的觸發條件是滿足任意一條：

• 改動文件多或行數多；
• 碰了錢、權限、數據完整性，或者對外不可撤回的動作；
• 改了公共契約：對外路由、共享組件、類型定義、文案目錄；
• 跨兩個以上模塊。

小改動直接走正常門禁。

四、提示詞怎麼寫：給補集，不要問「有沒有問題」

開放式地問「這段代碼有沒有問題」，會得到一堆風格意見。有用的提示詞有五個部分：

1. 範圍。 哪些文件在範圍內、哪些不在；明確寫「只評審，不許改任何文件」——評審模型有寫工具，不説它就會用。
2. 改動想做什麼。 寫意圖，不復述 diff。它能讀 diff，讀不到你的思路。
3. 必須驗證的硬規則。 項目裏的不變量，比如「某類數據只能從後端來，前端不許寫死」。這是第二個模型最能發揮價值的地方。
4. 我刻意沒做的事，以及原因。 請它攻擊這些決定。評審者默認誇已有的東西，不會主動質疑缺失的東西。
5. 具體問題。 編號，每條都能用「文件:行號」回答。

再加兩條：

• 主門禁已經跑過的，告訴它不用再查。 讓它只看門禁抓不到的東西：用户可見文案的全語種覆蓋、跨刷新的狀態保持、併發下的一致性。
• 結尾強制一問：「你沒檢查哪些方面？哪些地方你看了但沒把握？」 這一問專治假陰性。它的回答就是下一輪的工作項，往往比它報出來的問題更值錢。

一個工具層面的坑：命令行工具自帶的 review 子命令通常只審未提交的改動。如果這批改動已經全部提交，工作樹是乾淨的，它會回答「沒有可評審的變更」並且正常退出——又一種看起來像成功的失敗。 我改成普通的一次性執行，在提示詞裏把比較範圍寫死，比如 origin/main...HEAD。

五、拿到結論後：逐條驗證，不讀論證

評審報告也是自述。我的處理方式：

不讀它的論證，直接讀它指的代碼。 它説「某文件某行有某問題」，我就打開那幾行自己判斷。讀論證會被它的敍述帶着走——一段自洽的錯誤推理，讀起來比一段正確但枯燥的事實更有説服力。這正是幻覺傳染的路徑。

硬判據：能不能寫成一條會失敗的測試。 能寫成紅測的，是真問題，寫下來它還順便成了迴歸護欄；寫不成紅測的，多半是幻覺，或者只是風格意見。

每條三態裁定：

裁定	要求
確認	有復現步驟或紅測，進待辦
駁回	必須附反證：代碼行、測試輸出、契約原文。「我覺得不對」不算
存疑	進待辦，不當場改。存疑的東西改下去就是在賭

駁回要留痕。 不留痕，下一輪評審會報同一條，你會以為是新發現，再驗一遍。

確認的問題不在當輪順手改。 它們是新的工作項，走正常的流程。在收尾時順手改，等於繞過了所有門禁。

六、兩個紅旗

• 「評審説沒問題，那就過了」——評審報告也是自述。
• 「它報了三條，我都改了」——改之前逐條驗了嗎？改錯的代價比不改高。

收束

第二意見的價值，不在於另一個模型更聰明，而在於它帶着另一套先驗。

用好它要三件事：選一個真正獨立的評審方；給它補集而不是開放問題；拿到結論後讀代碼而不是讀論證。 合併按鈕仍然在人手裏——第二意見是幫人把有限的注意力放到對的地方。