為何在 LLM 代理時代，人工程式碼審查依然重要

TL;DR

人工程式碼審查依然不可或缺，因為它能揭露真實的不理解、質疑變更的必要性、發現遺漏的功能、運用組織背景知識、強化責任制，並促進雙向學習——這些能力是目前基於 LLM 的代理無法可靠提供的。

1. 人類的困惑是寶貴的缺陷信號

結論： 當審查者說 「我無法理解這段程式碼」 時，這種困惑本身便標示出一個 LLM 無法複製的問題。

  • 人類無法理解差異（diff）表示程式碼過於複雜、抽象不佳或意圖不明。
  • LLM 始終「理解」程式碼（指能解析），但從不會產生 困惑 的信號。
  • 被審查的文章將可讀性視為風格問題；dimbletimbers 的評論強調，「至少有兩個人理解功能如何運作」這種重複的可讀性是核心的安全網。

"我希望能看到更多這樣的對人工程式碼審查的辯護……至少有兩個人理解功能如何運作（即使這個數字正趨近於一到零之間）。" – dimbletimbers

2. 對變更必要性的懷疑性提問

結論： 人工審查者能質疑某項變更是否本應存在，這一步驟先於缺陷檢測。

  • 例如 「這應該拆成兩個 PR 嗎？」 或 「這解決的是症狀還是根本問題？」 這些問題探討意圖、範圍與合適性。
  • 文章假設每項變更都是必要的，忽略了審查者作為阻止無謂或範圍錯誤工作的守門人角色。
  • n4r9 指出，對 LLM 來說最難的清單項目是驗證變更是否 實際達成其聲稱的目標。

"……我們首先檢查的是：‘測試是否通過？’ 然後才看……範圍與潛在影響……部署與回滾計畫……" – metalspot

3. 檢測什麼是 遺漏的（缺失盲點）

結論： 人類能察覺遺漏的錯誤處理、缺失的 API 合約或遺漏的測試——這正是 LLM 已知的弱點。

  • 缺失盲點（參見連結的基準測試）的概念顯示，LLM 常常忽略遺漏的元素。
  • 人工審查者依賴領域知識所建立的預期來發現缺口。
  • metalspot 強調：「具專業知識的工程師能輕易發現遺漏之處」，與僅審查現有內容的代理形成對比。

4. 針對作者的校準關注

結論： 對作者的先前經驗會影響審查的深度與焦點，這是 LLM 無法模擬的細節。

  • 老手的例行重構會受到較輕的審查，而新手對關鍵模組的首次提交則會受到更嚴格的審查。
  • 文章將所有差異視為等價輸入，忽略了這種校準過的風險評估。

5. 程式碼審查是一種 共同參與 的學習活動

結論： 審查是一場雙向對話，能重塑作者與審查者的認知模型，而不僅僅是單向資訊傳遞。

  • 知識傳遞涉及共同理解，而不僅是生成解釋。
  • dguest 觀察到，每次合併請求（MR）都在教導審查者貢獻者是如何產生困惑的，強化了雙向性。

"每次 MR 都在教導你，你的貢獻者是如何產生困惑的。" – dguest

6. 運營背景存在於程式碼庫之外

結論： 人工審查者會將近期事件、下游棄用、法律限制與非正式協議帶入審查過程。

  • 例如：「我們上週二剛在這個服務發生了一起事件」，或「法律部門告訴我們不要記錄這個欄位」。
  • 文章假設程式碼庫是完整的背景，這是錯誤的。
  • metalspot 指出，程式碼審查歷來扮演協調、治理與責任保護的角色——這些功能需要外部背景。

7. 責任制與「投入其中」

結論： 個人責任感促使審查更徹底；自主代理則缺乏後果與動機。

  • 人工審查者是具名的個人，可被法律或職業上追責。
  • 文章將責任歸為官僚形式，忽略了責任制的動機影響。
  • metalspot：「程式碼審查從來不只是關於程式碼。它讓律師滿意，並提供了一個執行真正讓系統運作之事的載體。」

8. 超越檢測：協調、理解與治理

結論： 程式碼審查是一項多目的流程，包含協調、理解與治理，而不僅僅是缺陷檢測。

  • 文章的「替代謬誤」將人類貢獻簡化為可量化的功能，然後聲稱代理能複製每一項。
  • 這種分解忽略了人類在各功能間的整合角色。
  • metalspot 主張，隨著 AI 生成程式碼的擴張，傳統審查將成為一種責任保護，而非品質門檻。

9. 對審查未來的社群觀點

  • clintonb 擔憂 AI 驅動的反饋會削弱工程師的學習機會。
  • ChicagoDave 認為，設計審查將取代程式碼審查，成為主要的人類門檻。
  • bhouston 預測，超過 90% 的非關鍵 AI 生成程式碼將不再需要人工審查。
  • looperhacks 報告指出，GitHub Copilot 內建的審查遠未達到「機器將很快審查所有程式碼」敘事中的「足夠好」標準。

10. 人工增強審查的實用檢查清單

根據 n4r9 的非完整清單，一項穩健的審查應問以下問題：

  1. 變更是否達成其聲稱的功能目標？
  2. 是否有額外的雜項（除錯列印、密鑰）？
  3. 是否沒有明顯的缺陷（記憶體洩漏、安全漏洞）？
  4. 程式碼是否易於理解且抽象良好？
  5. 是否遵循風格指南？
  6. 是否有性能提升？
  7. 變更是否已充分測試？

LLM 在第 2 至 6 項表現良好，但在第 1 項（功能意圖）與檢測遺漏元素（第 3 至 4 項）上表現吃力。

最終結論

雖然 LLM 代理能自動化許多低階檢測任務，但無法取代人工審查者揭露困惑、質疑必要性、檢測遺漏功能、根據作者歷程進行校準風險評估、參與共同學習、注入外部運營背景以及承擔責任的能力。因此，即使 AI 生成程式碼日益普及，程式碼審查依然是關鍵的協調與治理機制。

Sources

相關