AI 替你寫完了代碼，卻沒人願意再認真看一眼

作者： 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 淹沒了。

問題存在，方案仍是實驗

問題存在，但解決方案感覺更像是實驗。