作者：The Pragmatic Engineer
編譯：深潮 TechFlow
深潮導讀：AI 寫代碼越來越快，但審查代碼的還是人。這個矛盾正演變成一場危機：工程師被 AI 生成的 PR 淹沒，要麼疲於應付審查不仔細，要麼乾脆看 AI 沒報錯就點通過。大廠紛紛自建工具應對，但目前沒人有標準答案。
嗨，我是 Gergely，這是 Pragmatic Engineer Newsletter 的一期免費增刊。每期我都從資深工程師和工程領導者的視角報導大型科技公司和初創公司。今天我們討論過往 The Pulse 期刊四個話題中的一個。完整訂閱用戶一週前就收到了這篇文章。如果這封郵件是轉發給你的，你可以在這裡訂閱。
我聽到許多工程領導者最關心的一件事是如何應對持續增長的程式碼審查負載。這個話題已經存在一段時間了，現在這類對話似乎越來越多。
對我來說，這始於今年 1 月，當時 Opus 4.5 和 GPT 5.4 開始在大多數公司寫出更多更好的代碼。大約從那時起，總監級別的人開始討論軟體開發的瓶頸正從編碼階段轉向審查階段。
AI 代碼審查工具的爆發
自2月以來，為應對負載增加，AI程式碼審查工具出現了爆發式增長，專門的AI程式碼審查工具如 CodeRabbit、Greptile、Qodo、SonarQube（現已加入 Gitar）的實驗與採用呈爆炸式增長。此外，編碼工具本身提供的功能，例如 Claude Code review、Cursor review、GitHub Copilot review，也廣泛應用。同時，此前未涉及程式碼審查但對程式碼庫具有上下文資訊的工具也開始加入這一領域，例如 Sentry 的 Seer AI reviews 和 Linear code reviews。
大廠自建內部工具：Uber 的 Code Inbox
大型企業正在開發內部工具以改善程式碼審查體驗。Uber 的 Code Inbox 就是一個例子：
智能分配是 Code Inbox 的一項功能，用於推進審查進程：
圖：Code Inbox 的智能分配（Smart assignment）設定，用於推進審查流程。來源：The Pragmatic Engineer
此外，還提供風險檔案功能，用於評估變更的影響，並鼓勵開發者對高風險變更格外注意：
圖：Code Inbox 的風險檔案（Risk Profiles）功能，估算程式碼變更風險並提示重點關注。來源：The Pragmatic Engineer
我們曾報導過 Uber 如何使用 AI 進行軟體開發，而且不僅僅是 Uber：Cloudflare（AI Code Reviewer）、Faire（Fairey）、HubSpot（Sidekick）以及許多其他公司都已開發出工具，以使他們的程式碼審查流程更順暢，因為他們發現內部實現的效果優於整合供應商的方案。
從「審查」轉向「驗證」
另一種方法是思考如何驗證程式碼，而不是審查程式碼。說起來容易做起來難；理論上，徹底的測試應該能夠驗證程式碼按預期運作。但多少測試才算是「徹底」？我們指的是什麼類型的測試？集成測試和端到端測試也包括在內嗎？模糊測試呢？形式化方法呢？如何驗證新測試按預期覆蓋了功能？我們如何將所有這些與可觀測性連接起來？
過度審查正在拖垮工程師
過度徹底的代碼審查正在讓工程師筋疲力盡，並導致審查質量下降。我聽到很多傳聞說，開發者看到其他人不再能用心審查代碼，如果 AI 代碼審查沒有實質性意見，他們就直接通過了。與此同時，那些像以前一樣投入同等精力和時間進行代碼審查的開發者，感到被 AI 發來的垃圾 PR 淹沒了。
問題存在，方案仍為實驗
問題存在，但解決方案感覺更像是實驗。