Claude 開始收“代碼審核稅”：一條 PR 25 美元，大廠一年或花百萬，還得上交整個代碼庫

編譯 | Tina

3 月 9 日，Anthropic 推出了一款新的代碼審查產品 Code Review，主打在人工介入之前，先用 AI 自動檢查 Pull Request 中的問題。 這項服務面向團隊和企業用戶，瞄準的是軟件開發生命周期（SDLC）中一個越來越突出的新環節：代碼寫得越來越快，但代碼審查正逐漸成為瓶頸。

和傳統 IDE 內置的審查插件不同，Code Review 主要運行在 GitHub 和 CI 流程中，而不是開發者本地的 IDE 里。也就是說，它更像是被放在代碼提交之后、人工審查之前的一道自動檢查關卡。乍一看，這確實像是個很有吸引力的新功能——畢竟在 AI 持續抬高代碼產能之后，代碼審查已經成了越來越多團隊不得不面對的新問題。

1 更貴，也更慢：Claude 開始收“審代碼稅”

實際上，Anthropic 的 Claude 模型本身已經具備按需進行代碼審查的能力——甚至可以通過讓 Claude 審查自己寫的代碼，來評估 AI 生成代碼的質量。此外，公司還提供了 Claude Code GitHub Action，可以在 CI/CD 流水線中自動觸發代碼審查。而新的 Code Review 服務，則把這種能力做得更深入——當然，成本也更高。

“代碼審查按 token 使用量計費，通常平均每次在 15 到 25 美元之間，具體費用取決于 Pull Request 的規模和復雜度。”

注意，Claude Code 創始人 Boris 強調了這是每個 Pull Request 的價格。

從開發者實際測試來看，這個價格并不只是紙面數字。開發者 Sinai Gross 表示，他測試了 Claude Code 的代碼審查功能，一次共審查了 3 個 Pull Request：其中兩個 PR 各修改了約 750 行代碼，另一個修改了約 100 行，系統給出的平均費用是 18.39 美元。

問題在于，這樣的價格一旦放到真實的工程規模里，成本會迅速放大。網友 DanT（@uyintans） 就直接指出，如果一家中大型公司每天都會產生大量 Pull Request，而每個 PR 都要花 15 到 25 美元來審查，那么規模化之后，這筆費用很容易滾到每年數百萬美元。

換句話說，假設一個團隊一天產生 100 個 PR——這在大型工程團隊里并不算夸張。按“每位工程師每天提交 1 到 2 個 PR”估算，一個 50 人的工程團隊，一天就可能接近這個數量。若按平均 20 美元一次審查計算，一天就是 2000 美元，一年大約就是 70 多萬美元。如果是更大的工程組織，PR 數量再翻幾倍，整體成本很快就會邁入百萬美元級別。

對比之下，做 AI 代碼審查的 CodeRabbit，月費也不過 24 美元。也就是說，Claude 這套多跑兩次 PR，花的錢可能就已經超過別人一個月。

Q：每次 PR 審查要 15–20 美元，對于一個個人項目來說實在太貴了。有沒有更便宜甚至免費的替代方案，同時還能在測試階段防止新的功能把生產環境搞崩？ A：CodeRabbit 對開源項目是免費的。

而且，Code Review 的速度也不算快。Anthropic 表示，具體耗時取決于 Pull Request 的規模，但平均一次審查需要約 20 分鐘。

原因在于，這些 Agent 并不只分析 PR 的改動部分，而是會把整個代碼庫作為上下文來分析。

Anthropic Claude Code 產品負責人 Cat Wu 認為，這樣可以避免某個文件的改動在其他文件中引入新的 bug——例如不同模塊之間存在一些意想不到的交互關系。

她解釋說，他們希望這個系統“非常智能、非常徹底，而目前實現這一點的方式，就是讓它運行得更久一些?！?/p>

“不過換來的結果是更可靠的輸出。而且每個 Agent 不只是查看你修改的代碼，它們可以靈活地遍歷整個代碼庫。”

目前，這個工具只會在 Pull Request 創建時自動運行。對于簡單的 PR，系統只會進行一次“輕量級掃描”；而對于復雜的 PR，則會調用更多 Agent，進行更深入的分析。

2 并行 Agent，效果還不差

在實際運行中，Code Review 會派出一組并行工作的 Agent，每個 Agent 負責尋找不同類型的錯誤。任務完成后，它們會在 Pull Request 中留下評論，總結發現的問題，并在必要時給出修復建議。

不過，這些 Agent 不會自動批準 Pull Request——最終是否通過，仍然由人類工程師決定。

這些 Agent 的重點是發現邏輯錯誤（logic errors），而不是代碼風格問題。這是一個刻意的設計選擇。 Cat Wu 表示，這樣做可以減少誤報。

她解釋說：“很多時候人類在做代碼審查時，不僅會發現邏輯錯誤，還會提出大量代碼風格上的問題。我們發現，在 AI 生成的代碼審查中，開發者最關心的其實是邏輯錯誤，所以這也是系統的核心關注點?！?/p>

“大家對誤報非常敏感。如果我們只專注于邏輯錯誤和真正的 bug，那么誤報率就會很低。因為一旦發現 bug，幾乎肯定就應該修復?！?/p>

Anthropic 表示，他們已經在內部使用 Code Review 數月，并取得了相當不錯的成果。公司稱：

• 對于超過 1000 行變更的大型 Pull Request，84% 的自動審查會發現值得關注的問題，平均 7.5 個問題。

• 對于少于 50 行的小型 Pull Request，31% 會收到評論，平均 0.5 個問題。

而在人類開發者的反饋中，被 Claude 標記的問題里，不到 1% 會被工程師否決。

一些參與測試的客戶也獲得了實際收益。例如，當 TrueNAS 在其開源中間件中進行 ZFS 加密模塊重構時，這個 AI 審查服務在相鄰代碼中發現了一個 bug：一個類型不匹配的問題，可能在同步操作時導致加密密鑰緩存被清空。

Anthropic 還舉了一個內部案例：Code Review 曾發現一處看似無害的一行代碼修改，但如果合入生產環境，實際上會破壞服務的認證機制。該公司表示：“這個問題在代碼合并之前就被修復了。事后這位工程師也表示，如果沒有 AI 審查，他很可能自己發現不了。”

3 既當運動員，又當裁判

Anthropic 還強調說，過去一年，自家工程師的代碼產量增長了 200%，代碼審查反而成了新的瓶頸。公司還表示，很多客戶也在遇到同樣的問題：開發者已經忙不過來，很多 PR 最后只能草草看一眼，很難做深入審查。

這其實也是行業普遍現象：AI 讓代碼寫得越來越快，但審代碼的人并沒有變多，PR 越來越多，審查自然就跟不上了。

不過網友的質疑也很直接：既然 Claude 能審代碼，為什么不一開始就把代碼寫對？有人吐槽，現在看起來像是 Claude 先寫代碼，再讓 Claude 自己審代碼，最后還抓出一堆 Claude 自己寫出來的 bug。還有人說得更犀利：這會不會違背了“裁判不能同時當劊子手（既當運動員，又當裁判）”的基本原則？萬一 Claude Code 先制造出問題，再靠修復這些問題繼續收費呢？

說白了，這看上去更像是在給模型自己的不穩定再加一層補丁——而且這層補丁，還要再收一筆錢。

https://x.com/bcherny/status/2031089411820228645

https://claude.com/blog/code-review

https://www.theregister.com/2026/03/09/anthropic_debuts_code_review/

聲明：本文為 InfoQ 翻譯整理，不代表平臺觀點，未經許可禁止轉載。

會議推薦

OpenClaw 出圈，“養蝦”潮狂熱，開年 Agentic AI 這把火燒得不可謂不旺。在這一熱潮下，自托管 Agent 形態迅速普及：多入口對話、持久記憶、Skills 工具鏈帶來強大生產力。但這背后也暴露了工程化落地的真實難題——權限邊界與隔離運行、Skills 供應鏈安全、可觀測與可追溯、記憶分層與跨場景污染、以及如何把 Agent 納入團隊研發 / 運維流程并形成穩定收益。

針對這一系列挑戰，在 4 月 16-18 日即將舉辦的 QCon 北京站上，我們特別策劃了「OpenClaw 生態實踐」專題，將聚焦一線實踐與踩坑復盤，分享企業如何構建私有 Skills、制定安全護欄、搭建審計與回放機制、建立質量 / 效率指標體系，最終把自托管 Agent 從可用的 Demo 升級為可靠的生產系統。