@addyosmani：Agentic 程式開發的程式碼審查 (Code Review) 現在的 Coding Agent 能力極強，且進步神速。這帶來了一個有趣的後果：軟體工程…

Agentic 程式開發的程式碼審查 (Code Review) 現在的 Coding Agent 能力極強，且進步神速。這帶來了一個有趣的後果：軟體工程中最困難的部分，已從「撰寫程式碼」轉變為「決定是否信任這些程式碼」。這使得「程式碼審查」成為當前軟體開發中槓桿效益最高的 skill。你該如何應對，取決於你的身分：一個沒有使用者的獨立開發者，與一個維護十年歷史應用程式的團隊，他們面臨的問題截然不同。 我對 Agentic 程式開發的樂觀程度前所未有。這些 Agent 確實好用，每個月都在進步，現在我每週都能交付一些在一年前同樣時間內我根本不敢嘗試的功能。這篇文章是一份地圖，標示出那些有趣的工作轉移到了哪裡，因為它們確實轉移了，而大多數團隊還沒完全跟上這個變化。 過去，程式碼審查之所以有效，是因為一種「相對速度」的幸運巧合。資深工程師閱讀程式碼的速度比初階工程師撰寫的速度快，因此審查過程自然能跟上進度，團隊成員也在閱讀彼此的 diff 時，順帶理解了系統的架構。這其中很多並非刻意為之，而是源於一個事實：撰寫程式碼是緩慢且昂貴的環節，而閱讀程式碼則是廉價且快速的。 這個事實已不復存在。Agent 產生一千行結構良好、格式整齊的程式碼所需的時間，比我讀完這一段文字的時間還短，而人類的閱讀速度自從我們開始靠盯著螢幕維生以來，幾乎沒有改變。因此，瓶頸轉移到了下游，轉移到了唯一沒有變快的那一步：人類必須確認變更內容是正確的。我不認為這是一種損失。這反而是目前軟體開發中，投入心力回報最高的地方，也是我今年投入最多關注的領域。 這裡有一個令人開心的轉折，它塑造了這篇文章的其餘部分。那些產生大量程式碼的工具，同時也是我用來跟上這些程式碼的最佳利器。在我自己的專案（包括熱門的開源專案）中，我現在會讓 Claude Code 或 Codex 處理一批進來的 PR，並讓它們為我進行佇列分流，這確實改變了我分配時間的方式。所以，這不是一篇反對 AI 的文章，我稍後會回到我具體如何使用它的細節。 這也不是一篇資料堆砌文，也不是關於「讓模型撰寫程式碼是好事還是軟體工藝的終結」的陳腔濫調，因為那種框架毫無意義。唯一能在真實程式庫中存活下來的答案是：這完全取決於你是誰。一個正在「vibe-coding」開發一個只有十幾個人會用的副專案的開發者，與一個為了再撐一季而維護十年歷史企業系統的團隊，他們幾乎沒有任何共同的限制條件，而市面上大多數的建議，其實都只是其中一方在教另一方該怎麼過日子。 2026 年的數據實際顯示了什麼 AI 帶來的生產力提升是真實存在的，但原始產出誇大了這些效益：大約是四倍的程式碼量，卻只帶來了多出一成的交付價值。這兩個數字之間的差距就是審查工作，這正是為什麼審查現在成為槓桿效益所在的原因。 幾年來，這一直停留在軼事和爭論階段。現在，透過一些沒有共同議程、甚至在某些情況下存在商業競爭關係的組織進行大規模測量，結果始終指向同一個方向：AI 大幅推升了產出，卻同時拉低了品質與可審查性。 Faros AI 對 4,000 個團隊中的 22,000 名開發者進行了監測，追蹤團隊從低 AI 採用率轉向高 AI 採用率後的變化。這是 2026 年 3 月的數據，與本文內容相當同步。其正面效益是真實的，且值得明確指出：開發者合併了更多的 PR，完成了更多工作，每位工程師的吞吐量也隨之攀升。但報告的其餘部分如下： 程式碼變動率 (code churn) 上升 861% 事件與 PR 的比例上升 242.7% 每位開發者的缺陷率從 9% 上升至 54% 中位數審查時間上升 441.5%，首次審查時間與平均審查時間大約都翻了一倍 零審查直接合併的 PR 上升 31.3% 最後一個數據是我覺得最難以忽視的，因為沒人選擇這麼做。沒有人決定要停止審查。審查者只是無法跟上數量，所以程式碼開始在未經閱讀的情況下被合併，這變成了一種常態。我反覆思考的細節是，那些擁有成熟、嚴謹工程實踐的團隊，受到的衝擊與其他團隊一樣大。良好的流程並沒有保護他們，因為產出的數量增加速度，遠超任何流程設計所能負荷的程度。 這裡有一個需要全程銘記的警示：CodeRabbit 和 Faros 都在銷售相關產品，因此他們的觀點並非完全中立。這並不代表數據是錯的，這些效應在不相關的來源中規模巨大且一致，但閱讀廠商的研究報告時，仍應將此納入考量。 CodeRabbit 在 2025 年 12 月研究了 470 個開源 PR，其中 320 個由 AI 共同撰寫，150 個僅由人類撰寫，發現 AI 變更帶來的問題大約多出 1.7 倍：邏輯與正確性問題增加了約 75%，安全性問題常見程度增加 1.5 到 2 倍，可讀性問題則增加了兩倍以上。他們的 AI 總監 David Loker 將這些描述為「組織必須主動緩解的、可預測且可衡量的弱點」。關鍵字是「可預測」。這些是已知且可定位的弱點，這是一個好消息：這意味著無論是人類還是自動化的審查流程，都可以直接針對這些弱點進行優化。 GitClear 在這裡也有有趣的數據。在他們 2025 年的生產力數據中，AI 的日常使用者產出的原始程式碼量約為非使用者的 4 倍，但與他們一年前的產出相比，實際的生產力提升僅約 12%。你產生了約四倍的程式碼，卻只帶來了約一成的交付價值，而人類仍然必須審查這四倍的程式碼。GitClear 的 Bill Harding 明確表示，這 12% 的提升中，部分源於選擇偏差，因為更強的開發者更集中在 AI 使用者群體中。四倍程式碼與一成價值之間的差距，就是程式碼審查問題的精確寫照。 GitHub 報告稱，Copilot 審查功能目前已執行超過 6,000 萬次審查，在不到一年內成長了 10 倍，平台上超過五分之一的審查涉及 Agent。這已不再是小眾做法，而是程式碼產出的方式。 四個資料集、四種方法，得出同一個結論。我們將機器速度的產出傾倒進一個為人類速度工作而建構的系統中。瓶頸並沒有消失；它轉移到了驗證階段，而審查就是這筆帳單到期的地方。 每個人都在解決不同的問題 一個變更需要多少審查，幾乎完全取決於它的「爆炸半徑」(blast radius)，而你讀到的大多數建議，都是由處於完全不同環境的人所寫的。 上述幾乎所有令人震驚的數據，都來自企業遙測資料以及不堪重負的開源維護者。如果你的情況正是如此，這些數據完全真實。如果你是一個人在開發某個只有少數人會用的東西，其中大部分內容根本不適用於你，你不應該因此感到焦慮。 三個變數決定了你的處境： 爆炸半徑：出錯時會發生什麼？沒事，還是會導致使用者憤怒、金錢損失以及個人身分資訊 (PII) 外洩。 程式碼壽命：是一個下週可能就會重寫的拋棄式原型，還是一個你將維護多年的程式庫。 需要理解的人數：只有你一個人能掌握全貌，還是一個需要長期共同維護的團隊。 將同一個 diff 套入這三個變數中，「良好的審查」意味著完全不同的事情。 如果你是在一個沒有使用者的綠地專案 (greenfield project) 上獨自工作，審查的第二項工作——在團隊間傳遞知識——對你來說就不存在。你就是團隊。 合理的做法是大力依賴測試與自動化，審查真正重要的部分，並對其餘部分採取較寬鬆的態度。當程式碼可能一個月後就不存在，且出錯時不會有人在凌晨三點被叫醒時，重複與變動的成本要低得多。陷阱在於（人們通常會痛苦地學到這一點），這只有在測試是真實有效的情況下才行得通。在沒有安全網的情況下跳過審查並不會消除工作，它只是以更高的代價延後了工作，且當沒有人把關時，標準就會下滑。沒有使用者是你可以延後審查的許可，但不是你可以跳過驗證的許可。 接著，專案有了使用者。這是一個危險的中間地帶，且轉折點通常在當時很難被察覺。審查的「抓蟲」角色突然變得重要，因為 Bug 現在會傷害到人；而它的「知識共享」角色也隨之啟用，因為現在不再只有你一個人。團隊往往在 solo 時代的習慣上多停留了幾個月，然後就會發生一次事後檢討 (postmortem)，Faros 的數字就不再只是圖表，而成了他們自己的儀表板。 另一端是擁有舊程式庫和大量使用者的龐大組織。在這裡，每一個令人震驚的數字都會產生全面影響。一個沒人理解的變更，就是一種理解債務，最終會變成某人的值班事件。審查同時在執行多項任務，而 Agent 的產出量悄悄地破壞了所有這些任務。Faros 關於成熟團隊的發現，正是針對此處。 所以重點不是「企業應該謹慎，獨立開發者可以放鬆」。重點是審查的目的會隨著你的位置而改變，因此規則也必須隨之改變。將企業那種鎖定、多 Agent、要求證據的管線套用在一個兩人的原型上，只會增加摩擦力而毫無益處。在支付系統上執行「測試通過就發布」，等於是製造了一個頭頂綠色勾勾的事件產生器。這個領域中大多數糟糕的建議，都是光譜上某個位置的人在對另一個位置的人指手畫腳。 審查現在真正的用途是什麼 審查原本是為了檢查作者的推理並抓出…