程式碼審查：在AI作者之上疊加AI審查者是不夠的

隨著AI編碼工具的普及，工程團隊面臨的並非簡單的效率提升，而是風險格局的轉變。AI生成的程式碼往往格式規整、文件齊全，並附有清晰的變更說明，但這些表象無法掩蓋其潛在的安全隱患。一篇程式碼變更可能看起來生產就緒，透過了單元測試，但其中可能隱藏著逃脫使用者輸入轉義的渲染路徑，或是一個帶有已知漏洞的新依賴項。

近期獨立基準測試表明，大型語言模型（LLM）在生成功能正確程式碼方面表現優異，但在安全程式碼生成上仍然困難重重。提高功能正確性的技術並未能可靠地改善安全結果。這意味著，一個變更可能看起來滴水不漏，卻仍需確定性安全檢查才能合併。

Faros AI的遙測研究基於22,000名開發者和4,000多個團隊的資料，發現隨著組織從低AI採用向高AI採用過渡，事件與拉取請求（PR）的比率飆升了242.7%。同時，無任何審查（包括AI或人工）就合併的PR增加了31.3%。這明確表明，審查實踐未能跟上程式碼吞吐量的增長。

以一個具體場景為例：開發者請求AI輔助新增使用者更新個人簡介的端點。AI返回了新的路由、資料庫遷移、React元件以及一些透過了測試的單元測試。然而，這些程式碼中可能包含：未經轉義直接渲染使用者輸入的XSS漏洞、帶有已知安全建議的新Markdown解析庫、測試夾具中的真實憑證（本應為佔位符）、以及僅驗證了樂觀路徑而未測試授權邊界的單元測試。這些問題在傳統的快速瀏覽式審查中極易被忽略。

那麼，在AI作者之上再疊加一個AI審查者是否就能解決問題？研究表明，這遠遠不夠。GitHub上超過五分之一的程式碼審查現由AI代理參與，但Faros AI的資料顯示，僅約1%的PR完全由AI自主開啟，其餘風險仍透過人類名義上負責的程式碼流轉。更深層的問題是感知差距：METR的隨機對照試驗發現，使用AI工具的資深開發者完成實際任務所需時間顯著更長，但他們自以為效率更高。這種自信與基於驗證的自信截然不同，卻常被混淆。

AI審查的價值在於作為生產力助手：生成變更摘要、建議測試用例、輔導初級工程師。但它絕不能成為合併決策的權威。對於安全相關的門控，應依賴獨立的確定性檢查和有責任感的審查者。

構建實用的審查工作流需遵循以下原則：識別AI輔助的PR（如新增標籤）；對每個PR應用基線門控（如秘密掃描、依賴掃描、靜態分析、測試覆蓋）；對高風險的變更（認證、支付、客戶資料、基礎設施）設定更高門檻和強制人工審查；保持AI審查的諮詢性質，合併許可權僅授予必需的檢查和指定審查者；限制覆蓋必需檢查的許可權，並記錄所有例外。

AI編碼工具確實提高了吞吐量，但吞吐量改變了工程風險的形式，而非消除了風險。最成功的組織是將AI輔助開發與變更點的一致性執行門控相結合，而非僅依賴AI的自我驗證。