AI程式碼審查需要異議，而不是共識

adamsreview描述了一套由6個命令組成的程式碼審查流程，包含平行審查視角、驗證關口、人類導覽、Codex同儕審查，以及在提交前重新審查變更的修正迴圈。¹

這套設計指出了AI程式碼審查真正的前沿。更好的審查，不是再多一串機器人留言。更好的審查來自彼此獨立的審查者：它們會提出不同意見、保留分歧、驗證主張，並在專案把某項發現視為阻擋因素之前，把判斷交回人類審查者。

重點摘要

AI程式碼審查應該優化的是有紀律的異議，而不是共識。一套有用的審查系統會分派獨立視角、合併重複發現、驗證每一項主張、區分已確認的錯誤與需要人工判斷的事項，並讓人類審查者維持正式審查者身分。共識可能掩蓋罕見但重要的發現。審查資料包應該保留少數主張，直到證據推翻它們，再追蹤修正與重新審查結果。

關鍵收穫

給工程主管： - 將AI審查視為證據流程，而不是投票系統。 - 即使代理找到真實錯誤，合併權限仍應留在人類手上。

給代理建置者： - 指派具備不同任務的獨立審查視角：正確性、安全性、測試、使用者影響、可維護性、執行環境行為與發布風險。 - 在驗證推翻之前，將少數發現保留為結構化主張。

給程式碼審查者： - 要求證據、重現步驟、受影響檔案、驗證結果、人類決策狀態與修正驗證。 - 拒絕那些把「一致同意」當成信心、卻沒有證明底層主張的審查系統。

為什麼AI程式碼審查需要異議？

當每位審查者都在尋找同一類缺陷時，程式碼審查會悄悄失效。

單一代理審查會形成單一失敗模式。模型掃描差異、產生看似合理的留言，然後漏掉注意力範圍之外的問題。多代理審查只有在代理保持獨立時，才能改善這種模式。如果5個代理讀同一個提示、繼承同一套優先順序，最後收斂成同一份摘要，系統得到的只是重複。

異議會改變審查涵蓋面。安全性審查者可能反對一段正確性審查者接受的請求流程。測試審查者可能在產品審查者認可行為後，指出缺少回歸測試覆蓋。執行環境審查者可能拒絕一個程式碼看起來乾淨、但在部署限制下會失敗的實作。

少數發現很重要，因為嚴重錯誤往往一開始只是孤立的反對意見。共識分數可能埋掉這個反對。一套好的審查流程會讓反對意見存活夠久，直到主張被證明或推翻。

獨立審查者應該檢查什麼？

獨立審查者需要分開的任務，而不是不同的名稱。

視角清單應依儲存庫調整。付款系統需要詐欺與對帳視角。編譯器需要健全性、診斷與效能視角。出版系統需要引用、SEO、翻譯與快取視角。

機制保持穩定：每個視角產生的是主張，不是裁決。

為什麼共識不是好的審查訊號？

共識回答的是錯誤問題。

多數決問的是許多審查者是否同意。程式碼審查需要知道的是，一項主張能否經得起程式碼、測試、執行環境與專案政策檢驗。

一致同意可能代表發現很明顯。也可能代表每位審查者都共享同一個盲點。分歧可能是雜訊。也可能代表某位審查者找到了真正的錯誤。

更好的指標是主張狀態：

這個狀態機勝過共識，因為它把分歧視為證據庫存。流程可以關閉嘈雜的發現而不抹除它們，也能在驗證證明缺陷時，把孤立發現升級。

強健的AI審查流程會做什麼？

強健的AI程式碼審查流程會分階段執行。

1. 獨立偵測。審查視角在看不到彼此結論的情況下檢查差異。
2. 合併重複主張。系統會群組等價發現，但不會把不同證據壓平。
3. 低成本驗證。快速檢查會抓出站不住腳的主張：檔案是否存在、變更行是否可到達、測試是否存在、型別錯誤與明顯過期的脈絡。
4. 深度驗證。高影響主張會接受較慢的審查：重現、讀取追蹤、聚焦測試、安全推理或第二模型批判。
5. 分類狀態。流程會將每項發現標記為已確認、已推翻、人工判斷、僅報告或低於門檻。
6. 帶人類走過不確定性。審查者決定需要判斷的事項、升級重要主張，並拒絕低價值工作。
7. 按群組修正。相關發現一起移動，避免系統套用互相衝突的修補。
8. 重新審查修正。流程再次審查已變更的程式碼，並在提交前還原回歸。
9. 寫出資料包。最終產物會記錄發現、證據、決策、測試、提交與未解缺口。

adamsreview提供了這種形態的具體範例。它的README描述最多7個平行子代理視角、重複項合併、先低成本後深度的驗證、選用的整體審查、Codex審查同儕、外部發現注入、不確定發現的導覽，以及會在提交存活修正前重新審查並還原回歸的修正迴圈。¹ README也把效能主張標為軼事證據，這點很重要。應把這個專案視為有用的設計證據，而不是基準測試。

AI程式碼審查發現應該長什麼樣子？

有用的發現需要足夠的結構，讓另一位審查者、代理或CI工作稍後檢查。

id: SEC-003
lens: security
claim: "The new webhook endpoint accepts unsigned retry requests."
severity: high
affected_files:
  - app/routes/webhooks.py
evidence:
  - "Handler reads JSON before signature validation."
  - "Test suite covers valid signatures but not missing signatures."
validator:
  cheap_check: pass
  deep_check: manual
  reason: "Reachable path confirmed; exploit impact needs owner judgment."
human_decision:
  status: promoted
  reviewer: "reviewer of record"
fix_group: webhook-auth
post_fix_review:
  status: pending
remaining_gap: "Need replay test against malformed retry payload."

確切欄位可以改變。紀律不應改變。發現要命名主張、證據、驗證結果、人類決策、修正群組、修正後狀態與剩餘缺口。只寫「檢查webhook auth」的留言，無法支撐負責任的合併決策。結構化發現可以。

為什麼人類必須維持正式審查者身分？

GitHub的審查模型在合併前給審查者3種高階結果：留言、核准或要求變更。² AI審查可以支援這些結果。不應悄悄取代它們。

Rust草案LLM政策清楚劃出這條界線。截至2026年5月18日，該政策仍是開放中的pull request，尚未成為已採納的Rust政策。³ 草案允許私人LLM審查，但禁止把LLM審查視為足以合併或拒絕變更。它也說審查機器人必須維持諮詢性質，機器人留言本身不得阻擋合併，而人類審查者必須明確背書他們希望處理的留言。⁴

這條邊界保護問責。一個機器人可以發現真實錯誤。機器人也可能產生過期留言、膚淺的風格反對，或充滿自信的誤判。正式審查者擁有阻擋、合併、要求變更或忽略主張的決策責任。

人類角色應該出現在產物中：

AI審查在讓人類審查更銳利時贏得信任。當它把權限藏在機器人裁決裡時，就會失去信任。

審查資料包應包含什麼？

審查資料包會把一次審查執行轉化為可持久保存的決策物件。

最低欄位：

資料包不應讀起來像逐字紀錄。逐字紀錄顯示發生過的一切。審查資料包顯示負責任的審查者做決策時需要知道的事。

資料包也保留組織記憶。當同一個誤判下週再度出現，團隊可以看到它為什麼不成立。當少數發現變成正式環境錯誤時，團隊可以檢視該主張如何通過系統。

研究如何看待代理式PR失敗？

這種失敗模式不只發生在審查機器人身上。

一篇MSR 2026論文分析了GitHub上33,000個由代理撰寫的pull request，發現文件、CI與建置更新任務的合併成功率最高，而效能與錯誤修正任務表現最差。⁵ 作者也發現，未合併的PR通常觸及更多檔案、變更更大，而且CI失敗。他們的質性分析指出了多種拒絕模式，例如審查者參與不足、重複PR、不需要的實作，以及代理與需求不一致。⁵

這些發現支持一條務實規則：AI程式碼審查不應只問差異是否有錯誤。它也應該問代理工作流程是否交給維護者一個可審查的物件。大型、錯位、審查薄弱的PR需要更好的審查資料包、更窄的提交邊界，以及更強的人類決策點。

團隊應如何開始？

從一套小型審查系統開始。它要產生更好的決策，而不是更多留言。

1. 為風險最高的程式碼路徑挑選2到3個視角。
2. 要求每項發現都包含主張、證據、受影響檔案與驗證結果。
3. 保留少數發現，直到驗證器推翻它們。
4. 把需要人工判斷的主張交給人類審查者，而不是藏在分數底下。
5. 追蹤誤判，讓系統學會團隊會拒絕什麼。
6. 在提交前重新審查修正。
7. 將資料包附到PR。

不要從自動修補開始。先從可信的審查產物開始。當發現流程取得信任後，才能接著開放狹窄的自動修正通道：機械式測試、明顯的null檢查、錯字等級修正，或人類在導覽中升級的修正。

目標不是讓程式碼審查感覺自主。目標是讓人類審查更難被騙過。

快速總結

AI程式碼審查需要獨立異議，因為光靠一致同意無法證明一項發現。強健的系統會依任務分隔審查者、保留少數主張、驗證證據、將不確定性轉交給人類，並在提交前重新審查修正。GitHub的審查契約仍以人類審查狀態作結。² Rust草案政策讓LLM審查維持諮詢性質，直到人類背書該主張。⁴ adamsreview展示了一種目前的流程形態，包含視角、關口、導覽與修正重新審查。¹

勝出的產物不是機器人留言。勝出的產物是讓人類能負責任決策的審查資料包。

FAQ

什麼是AI程式碼審查？

AI程式碼審查使用語言模型或代理檢查程式碼變更、識別可能缺陷、說明風險、建議修正，或為人類準備審查產物。嚴謹的系統應為每項發現提供證據與狀態，而不只是張貼留言。

AI程式碼審查應該使用多個代理嗎？

當每個代理都有獨立任務，而且流程會保留分歧時，多個代理有幫助。若每個代理看到相同提示、產生相同摘要，最後收斂成共識分數，多代理的價值就很有限。

為什麼在AI程式碼審查中，異議比共識更好？

異議會讓罕見發現保持可見，直到證據證明或推翻它們。當多數審查者都漏掉同一個邊界案例時，共識可能掩蓋嚴重的少數發現。程式碼審查需要已驗證的主張，而不只是同意。

AI審查者可以阻擋pull request嗎？

團隊應讓阻擋權限留在人類手上。Rust草案LLM政策說，LLM審查必須維持諮詢性質，而且審查者必須在阻擋PR之前明確背書LLM留言。⁴ 這項規則符合更廣泛的問責原則：人類審查者擁有合併決策。

AI審查資料包應包含什麼？

AI審查資料包應包含範圍、視角、發現、證據、驗證結果、人類決策、修正群組、重新審查結果、相關發布證明與未解缺口。資料包應讓審查決策可以稽核，而不必強迫讀者讀完整份逐字紀錄。

團隊何時應允許自動修正？

團隊應該只在發現流程取得信任後，才允許自動修正。先從機械式、低風險修正開始，或從人類在審查中升級的發現開始。每個自動修正都需要修正後審查與回復路徑。

參考資料