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——例如不同模塊之間存在一些意想不到的交互關系。

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

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

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

2 并行 Agent，效果還不差

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

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

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

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

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

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 升級為可靠的生產系統。