你還應該審查你的AI代理的程式碼嗎？

爭論在每個團隊中以相同的方式開始。一方說，代理現在交付的程式碼比我們以前簽字的許多拉取請求要乾淨得多，那我們為什麼還要逐行閱讀呢？另一方則說，因為我們是簽字的人。

雙方都是對的。這正是爭論永無止境的原因。爭論不會結束，因為問題本身是錯誤的，一旦你修正了問題，答案几乎變得無聊。

不逐行閱讀程式碼的理由

從最強的樂觀論點開始，因為它比大多數審查者承認的要強。

在一個有明確規範和測試套件的有界任務上，現代編碼代理產生的程式碼比在截止日期下工作的中等人類更一致。它不會在錯誤路徑上感到厭倦。它在週五下午六點寫下空檢查。它每次都遵循給定的專案約定，而沒有疲憊的開發者允許的小小叛逆。

在人類審查之前，審查也已經破裂。任何在真實團隊中工作過的人都知道 LGTM 反射：審查者的注意力在幾百行後崩潰，隨之而來的批准是社交的，而不是技術的。我們並沒有失去嚴格審查的黃金時代。我們失去了一個已經大部分是戲劇的儀式。

然後是數量。一個開發者同時執行五個代理，每小時生成的diff比任何人類能仔細閱讀的都要多。如果你的規則是「閱讀所有內容」，那麼你就悄悄地重新安裝了自己作為你剛剛自動化掉的瓶頸。一個人快速瀏覽 900 行diff，產生簽名而沒有產生知識，這比根本不審查更糟，因為它製造了沒有的保證。

保持人類在diff上的理由

現在是另一方，這一方的論點也比熱衷者承認的要強。

問責制無法轉移。 模型不會在凌晨三點被叫醒。它不在事件審查中，不與資料洩露的客戶交談，也不會將變更的後果帶入下個季度。合併的人擁有結果，審查是行使所有權的方式，而不僅僅是宣告。

代理審查者在與代理作者相同的方向上失敗。 這是實際上解決「讓另一個代理審查它」提案的論點。來自同一模型家族的兩個代理，在相同的上下文中，分享先驗，分享訓練資料和盲點。它們的錯誤是相關的。第二個代理會樂於捕捉缺失的測試或未處理的錯誤，並樂於批准導致錯誤的領域的微妙誤解，因為它也產生了相同的誤解。兩個方向錯誤的審查者並不等於一次有效的審查。

測量結果也不樂觀。 行業資料表明，審查者在 AI 生成的更改上進行的回合比人類編寫的更改多得多：程式碼到達得更快，但變得值得信賴的時間更長。一項 2026 年 1 月的研究進一步發現，代理生成的更改每次攜帶更多冗餘和累積的技術債務，而審查者報告對批准它們的感覺更「好」。這種感覺與程式碼品質之間的差距，就是整個風險的一句話。

爭論的框架是錯誤的

這裡是結束會議的重新框架。

你審查程式碼不是因為你不信任作者。你審查它是因為你是簽字的人。這是完全不同的活動，而整個爭論源於混淆了它們。

一旦你看到這一點，「代理是否比人類更好」就不再是決定性的問題。決定性的問題是：如果這個更改是錯誤的，發現它的代價有多高，撤銷它的代價又有多高？ 營銷標題中的一個錯別字在幾秒鐘內被發現並在幾秒鐘內撤回。授權中介軟體中反轉的許可權檢查由客戶或監管者發現，並且它從未真正撤回，因為到那時資料已經被讀取。

所以答案既不是「審查所有內容」，也不是「信任代理」。而是：

你停止逐行審查。你開始審查風險。

具體而言，審查從工作的中間轉移到它的兩個邊界。之前：閱讀計劃，因為錯誤執行的錯誤計劃是最昂貴的失敗模式，而一個計劃只有十五行，而不是九百行。之後：根據爆炸半徑閱讀diff。在此之間，行屬於機器。

「代理搞砸了」實際上是什麼樣子

你可以帶回團隊的最有用的東西不是意見，而是一個客觀訊號的列表。不是「程式碼感覺不對」，而是你可以在不到一分鐘的diff中檢查的訊號。這些是已經贏得其位置的訊號。

1. 測試在與其覆蓋的程式碼相同的提交中發生了變化。 綠色是構造的，而不是觀察到的。這是列表中訊號最強的訊號，也是首先要檢查的訊號。
2. 一個斷言被削弱或一個測試被禁用。 一個 skip，一個 only，一個斷言被擴大以接受新程式碼返回的內容，一個 try/catch 吞下了測試本應暴露的錯誤。
3. diff大於任務。 沒有人要求的檔案被觸及。代理中的範圍蔓延不是熱情，而是代理在某個地方重新解釋了目標的跡象。
4. 一個虛構的表面。 一個 API 方法，一個配置選項或一個不存在的路徑。它在代理的腦海中編譯，而在其他地方則不存在。
5. 環境被修復而不是程式碼。 一個硬編碼的絕對路徑，一個特定於機器的值，一個個人令牌，一個使用者名稱。症狀在代理的機器上消失，轉移到其他人的機器上。
6. 一個未被請求的依賴出現。 新的供應鏈，新的授權，新的維護表面，由某個不會維護它的東西決定。
7. 重複而不是重用。 它重新實現了已經存在二十行之外的一個幫助器。這是測量債務的機制：每個更改在區域性看起來合理，而程式碼庫悄悄地獲得了第三種方式來做同樣的事情。
8. 摘要與diff不匹配。 「修復並測試」時沒有測試執行。敘述以相同的信心生成，無論工作是否發生，因此將其視為需要驗證的宣告，而不是報告。
9. 指令停止被遵循。 小約定的默默丟棄是會話在開始之前降級到完全幻覺的方式。如果你在你的上下文檔案中使用了 金絲雀，這正是它存在的目的。
10. 敏感領域在經過時被觸及。 一個 .env 讀取，一個新的出站網路呼叫，一個攜帶使用者資料的新日誌行，一個捆綁到功能提交中的遷移。

注意列表中沒有的內容：風格、命名、格式、「我會以不同的方式做」。這些一直是人類審查中最薄弱的部分，現在確實是浪費人力。將它們從你的審查中刪除，你就能重新獲得你需要的注意力來關注上述十個專案。

一個更改值得多少審查？

決定的是爆炸半徑，而不是diff大小。你的團隊今天下午可以採用的表格：

diff的大小告訴你審查需要多長時間。爆炸半徑告訴你這是否是可選的。

這些行不是關於信任級別的。它們是關於錯誤成本的，這是程式碼的屬性，而不是誰寫的。這使得表格可用：沒有人需要就代理的好壞達成一致才能就表格達成一致。如果你的團隊在哲學問題上僵持不下，跳過它，協商行而已。你會驚訝於這有多快收斂。

如果你的產品在歐洲處理個人資料，法律而非品味為你寫了一行： AI 建置的功能在 GDPR 下必須遵守的內容 不是判斷，而「代理寫的」從來不是辯護。

當五個代理同時執行時會發生什麼變化

以上所有假設你可以看到更改。隨著並行代理，這一假設首先破裂，並且以特定的方式破裂：diff不再有單一作者。自上次提交以來，三個代理已經觸及了工作樹，而「誰更改了這個檔案，作為哪個任務的一部分」這個問題不再有明顯的答案。沒有歸屬的審查不是審查，而是考古。

這是一個工具問題，這也是 AgentsRoom 將審查放在代理所在位置而不是拉取請求末尾的原因：

• Review Mode 顯示你的代理所做的每一個更改，作為可讀的diff，在任何內容被提交之前。這是「根據爆炸半徑閱讀diff」的步驟，變得足夠便宜，以至於人們實際上會去做。
• 每個代理審查 按代理過濾diff，並讓你分別提交每個代理的工作。五個並行代理變成五個可審查的單元，而不是一個不可讀的工作樹，壞更改仍然歸屬於產生它的任務。
• 提交訊息是從 真實diff 生成的，使用提交欄位上的閃光按鈕，因此歷史描述了發生了什麼變化，而不是代理所說的它在做什麼。這個區別在凌晨三點、六個月後是重要的。

這些都不替代判斷。它消除了不行使判斷的藉口。

讓機器擁有這些行

如果你想停止逐行閱讀，那麼其他東西必須閱讀它們。在實踐中，有四件事承擔這個負擔：

代理沒有在同一時間寫的測試。 首先編寫，或由不同的代理編寫，或至少作為他們自己的更改進行審查。程式碼及其測試來自同一代的那一刻，它們就不再是獨立的證據。

使用不同模型的審查者。 這是解決相關失敗問題的實際答案。如果第二個代理進行審查，請在與作者不同的提供者或模型家族上執行它。你不會完全去相關錯誤，但 Codex 家族的審查者在 Claude 編寫的程式碼上捕獲的問題類別與同模型審查者明顯不同，正因為它不共享作者的先驗。

不會感到疲倦的門。 型別、lint、秘密掃描、覆蓋率底線，一個拒絕與功能捆綁的遷移的 CI。你可以表達為門的每一條規則都是你不必再注意的規則。

一個自我閉合的迴圈。 一個建置、執行其工作與計劃並在交付任何內容之前迭代的代理，消除了你審查中「甚至沒有執行」的整個類別。這就是 自我修正代理迴圈，它是產生diff的代理與產生結果的代理之間的區別。它並沒有回答人類是否應該簽字的問題。它只是意味著人類正在簽署已經有效的東西。

那麼，你還審查嗎？

是的，但比你今天做的要少。

停止逐行閱讀以感到負責。在之前閱讀計劃，因為那是發生昂貴錯誤的地方。之後根據它可能造成的破壞比例閱讀diff，使用階梯而不是你的情緒。保持一個人類在身份驗證、支付、許可權、個人資料和任何不可逆轉的內容上，因為模型無法承擔問責制，而第二個代理共享第一個的盲點。將其他所有內容交給測試、型別、門和不共享作者模型的審查者。

那些搞錯這一點的團隊會在兩個方向上失敗，而這兩者都是可以避免的。一個審查所有內容，成為瓶頸，悄悄開始在沒有閱讀的情況下批准，這是兩全其美的最糟糕情況。另一個什麼都不審查，快速交付兩個月，然後花一個季度償還它從未看到的債務。

你在站會上爭論的並不是真正關於代理是否優秀。它是關於誰願意簽字。回答這個問題，審查政策就自然而然地寫出來了。

常見問題

你還應該審查 AI 生成的程式碼嗎？

是的，但不是逐行審查所有內容。在代理開始之前審查計劃，然後根據更改可能造成的破壞比例審查diff。文案和 CSS 只需快速瀏覽。身份驗證、支付、許可權、個人資料和遷移每次都由人類逐行審查。

AI 代理能審查另一個 AI 代理的程式碼嗎？

這有幫助，但不能替代在風險程式碼上的人類。來自同一模型家族的兩個代理，在相同的上下文中，往往在相同的方向上失敗。它們的錯誤是相關的，因此第二個代理捕捉到錯別字和缺失的測試，但共享導致錯誤的盲點。如果你確實使用代理審查者，請在與作者不同的模型上執行它。

你怎麼知道 AI 代理是否犯了錯誤？

尋找diff中的客觀訊號，而不是閱讀風格。最強的訊號是：測試在與其覆蓋的程式碼相同的提交中發生了變化，這意味著綠色是構造的，而不是觀察到的。其他訊號包括範圍蔓延、禁用或削弱的斷言、虛構的 API、硬編碼的本地路徑和摘要與diff不匹配。

AI 代理會取代人類程式碼審查者嗎？

它們已經取代了大部分逐行閱讀。它們無法取代簽名。問責制無法轉移到模型上，因此人類仍然擁有在任何難以逆轉的事情上合併的決定權。

你需要逐行審查 AI 程式碼嗎？

僅在爆炸半徑合理的情況下。逐行審查在幾個代理並行執行時無法擴充套件，而一個人在下午六點快速瀏覽 900 行diff會產生簽名而沒有產生知識。將注意力放在那些撤銷成本高的更改上。

什麼內容絕不能在沒有人類審查的情況下合併？

任何涉及身份驗證、支付、許可權、個人資料、資料庫遷移、刪除路徑和基礎設施的內容。這些共享一個屬性：錯誤的代價與 diff 的大小不成比例。