c-CRAB，程式碼審查代理基準：它衡量了什麼、發現了什麼，以及 41.5% 的真正含義

一個程式碼審查代理與一位人類審查員看了同一個 pull request，並提出了相同的顧慮。依照代理的評論進行修正即可修復 bug，測試也通過了。然而，作者計算的所有文字相似度指標，都將代理的審查評為與人類的審查基本上毫不相關：BLEU-4 0.00、ROUGE-L 7.02、chrF 20.74、embedding 相似度 54.59。相同的顧慮、不同的措辭，而標準的審查評分方式卻看不出兩者意見一致。這一個例子正是 c-CRAB（讀作「see-crab」）——即 Code Review Agent Benchmark——背後的論證，發表於arXiv:2603.23448。

c-CRAB 評估的是程式碼審查代理，而非程式碼編寫代理。給定一個 pull request——可能來自人類或編碼代理——審查代理會產生一份審查意見，而 c-CRAB 會根據該意見付諸實行後是否能產生行為正確的修復來評分。此基準測試由軟體工程研究人員 Yuntong Zhang、Zhiyuan Pan、Imam Nur Bani Yusuf、Haifeng Ruan、Ridwan Shariffdeen 和 Abhik Roychoudhury 建構，並評估四個工具：PR-Agent、Devin、Claude Code 和 Codex。其中一位作者隸屬於 SonarSource，而論文本身明確說明了這種關聯代表什麼、不代表什麼，原文如下：“本論文所表達的觀點和結論僅代表作者本人，並不代表 SonarSource 的官方政策或認可。此外，本文所述的研究結果是獨立的，不應被解讀為對 SonarSource 產品品質的評估。”

在細節之前有兩點說明。一些第三方文章將同一項工作稱為「CR-bench」；它是同一個基準，而本頁面全程使用 c-CRAB。下方的每個數據都是論文自行報告的結果，是今天從論文和複製套件中讀取的——並非獨立重跑——而詮釋是我們自己的，加上該論文已引發的實務工作者討論。這些都不是來自受評測工具供應商的指導。如果你仍在猶豫是否要運行程式碼審查代理，我們關於程式碼審查代理的買家指南是更好的起點；本頁面講述的是這些代理是如何被衡量的。

為什麼 c-CRAB 使用測試來評分評論，而不是 LLM 評判

評估程式碼審查代理的常見方式，是將其審查結果與人類的審查進行比較，使用 LLM-as-judge 或文字相似度指標。c-CRAB 的作者對這兩種方式都不認同。他們認為，LLM-as-judge 存在偏見、不穩定性及對提示詞的敏感性，使得可重現且一致的評分變得困難。而上述案例研究顯示了字串指標實際衡量的內容：措辭，而非有效性。在那個 python-telegram-bot 的 pull request 中，Codex 的審查意見與人類審查者相同，但 BLEU-4 和 ROUGE-L 卻無法辨識出這一點。

所以，c-CRAB 的做法正相反。每一條人工審查評論都會被轉換成一個可執行的測試，以捕捉其背後的問題。若根據某條評論採取行動後，能產生行為上正確的修正——也就是讓測試通過——那麼這條評論就算正確。每個實例都附帶一個可執行的 Docker 環境，因此通過／失敗的判定是藉由執行程式碼來決定，而不是詢問另一個模型兩段文字有多相似。這正是它重要的原因：審查評論的職責是改變開發者的行為，而測試是唯一能直接衡量這種改變的評分訊號。

論文以它自己的話定義了兩種測試：“行為測試會在執行階段匯入並執行受測程式碼。它們以特定輸入呼叫受測函式，並檢查輸出或驗證例外。另一方面，結構測試會檢查原始碼文字、比對模式，並檢查 API 表面，以判斷是否已做出所需的程式碼變更。”最終的分佈是 42 個行為測試（17.9%）與 192 個結構測試（82.1%）。誠實地說一句：這個測試基準大多是在對原始碼文字做模式比對，而不是實際執行程式碼。這種偏斜是真實存在的限制，值得銘記在心。

基準是如何建立的，以及漏斗的成本

c-CRAB 建立在現有的 inclusionAI/SWE-CARE 資料集之上，該資料集提供帶有 commit 元資料的 pull-request 實例；c-CRAB 自身的貢獻在於 oracle，而非 PR 語料庫。篩選管線會執行四個過濾器，每個過濾器都會耗損實例。論文報告的漏斗如下：

• 初始資料集 — 671 個 PR、1,313 則留言。

• 審查過濾 — 410 個 PR、595 則評論。一個 LLM 分類器，根據 100 則人工標註評論的黃金標準集進行校準，只保留可客觀驗證的問題，並剔除對話式或主觀的回饋。

• 可執行環境建置 — 410 個 PR、595 則評論。每個 PR 對應一個 Docker 映像檔，依賴解析在自動化失敗時會改由編碼代理接手。

• 將自然語言註解轉換為測試 — 339 個 PR、481 則評論。測試由 GPT-5.2 在執行引導的改良迴圈中生成，最多嘗試三次；只有當測試在原始程式碼上失敗、並在修復後通過時，才會保留該測試。

• 以編碼代理進行驗證 — 184 個 PR、234 則評論。Claude Code 在 Sonnet-4.6 後端上，僅根據人類審查評論來嘗試修正程式碼；無法讓測試通過的實例會被丟棄。這是最終的資料集。

大約 27% 的初始拉取請求存活下來。這是基於測試的判斷基準所付出的誠實代價，也是該基準測試規模小巧而非龐大的原因。存活下來的集合：184 個 PR 實例、234 則通過驗證的審查評論、每個實例 1.27 個測試、每個 PR 平均修改 418.1 行、每個測試 31.8 行。兩位標註者分別獨立評判生成的測試是否忠實反映了人類審查者所關切的事項，共取 50 個抽樣實例，兩人的一致率為 84%。

若你仔細閱讀，會注意到一處不一致：資料集表格列出 67 個儲存庫，而威脅有效性（threats-to-validity）一節則稱「184 個 pull request 實例，涵蓋 56 個儲存庫中的 234 個可驗證 oracle」。論文中在不同位置給出了這兩組數字，我們不會將它們平均，也不會默默選取方便的那個。讀者正是藉由這類細節來判斷一個基準測試是否值得投入時間，因此此處照實重現兩組數據，如同原文所載。

結果，以及如何解讀它們

通過率是整體測試通過率：就每個實例而言，它是該 PR 的測試中通過的比例，而主要數字是所有實例的平均值。該論文按工具分別報告：

• Claude Code — 1,336 則評論，平均每個 PR 7.3 則 — 行為 38.1%、結構 30.7%、整體 32.1%

• Devin — 1,344 則評論，每個 PR 7.3 則 — 行為 31.0%、結構 23.4%、整體 24.8%

• PR-Agent — 524 則評論，每 PR 2.8 則 — 行為 38.1%，結構 19.8%，整體 23.1%

• Codex — 324 則評論，每個 PR 1.8 則 — 行為性 38.1%，結構性 16.1%，整體 20.1%

• 人類 — 234 則評論，每 PR 1.3 則 — 100% 建構而成。人類撰寫了 oracle，因此此行是標尺，而非競爭者。

在引用任何這些行之前，請仔細閱讀。摘要中的「僅約40%」是一個聯集：234 個測試中有 41.5% 至少被四個工具中的一個通過。這不是任何單一代理的分數——最佳單一分數是 Claude Code 的 32.1%——也不代表這四個工具合計抓到了 40% 的真實缺陷。以下章節說明原因。

最有趣的數字不是贏家。Claude Code 和 Devin 各自發布了超過 1,300 則評論——每個 PR 約 7.3 則——分別達到 32.1% 和 24.8%。Codex 發布了 324 則，每個 PR 約 1.8 則，達到 20.1%。人類基準是每個 PR 1.3 則評論。算算看：大約四倍的評論量，換來的通過率卻遠不到兩倍。數量不等於覆蓋率。話多的審查者並不等於有用的審查者，而 c-CRAB 是第一個為證明這點而設立的基準。

實用性也可能適得其反。

低通過率讀起來像是譴責，直到你檢視作者還測量了什麼。他們手動檢查了 6 個 PR 中的 92 則評論，並判定其中 84% 是有用的（92 則中的 77 則）— PR-Agent 94%、Codex 88%、Devin 85%、Claude Code 78%。因此，大多數未通過 c-CRAB 測試的評論並非雜訊；它們涉及的是人類審查者未提出的內容。樣本很小 — 92 則評論、6 個 PR — 而論文也如此表述，我們也應該如此。

同樣的模式也出現在審稿人的評論中。人類審稿人偏向可維護性、設計與文件；工具則偏向穩健性、測試與錯誤處理。論文將此解讀為支持人類與代理協作、而非取代的論證。這也是目前對分數為何偏低的最佳解釋：代理與人類往往關注的面向不同，而 oracle 只獎勵人類所列出的項目。

c-CRAB 所無法看到的

該基準對其盲點直言不諱，我們也是如此。c-CRAB 不會為人工審查者從未提出的有效問題給予任何分數。其神諭是人工審查意圖：一個代理即使找出一項沒人提及的真實錯誤，在這項上也得零分。論文直接指出 — 自動化審查工具可能產生其他人工審查者未能識別的有價值評論，但「與其他現有基準一樣，c-CRAB 並不直接評估這些額外評論。」

那單一句話正是對這項結果大多數報導的修正。任何引用「審查代理僅能解決40%」、彷彿那是在衡量代理抓到了多少真實缺陷的人，都誤讀了這個數字。它衡量的是這些代理共同設法解決了多少由人類提出的疑慮——一個更狹窄且更誠實的主張。

自行運行

如果你想重現這些數字，或加入你自己的審查者，複現套件已公開於c-CRAB-Benchmark/dataset。README 才是真正的文件，它如實描述了這個專案的樣貌。設定方式是code>uv sync/code>；你需要 Docker 和一個 code>OPENAI_API_KEY/code> 或 code>ANTHROPIC_API_KEY/code>，而 Claude Code 還會從 code>~/.claude/.credentials.json/code>。該組織也為這些環境發布了預先建置的 Docker 映像。

佈局：code>pipeline//code> 存放管線邏輯與提示詞，code>execution//code> 包含 Docker 映像建置器與執行期輔助程式，code>results_preprocessed//code> 包含已釋出的基準子集（410 個前處理執行個體），code>results_pipeline_funnel//code> 存放 stage0–stage4 的 JSONL 檔案與漏斗摘要，以及code>raw_results_compressed//code> 存放原始實驗輸出。

重現完整的執行流程需要五個步驟：建置 Docker 環境（code>execution.build_swe_care/code>）、產生測試（code>run_testgen_full.sh/code>）、收集基線審查（code>run_batch_baselines.py --tools pr-agent devin claude-code codex/code>）、執行代理程式解析（code>run_batch_agent_resolution.py/code>），然後進行評估（code>run_batch_tool_eval.py --tool <name>/code>）。如果你想新增第五個審查者，請注意擴充點並非外掛介面：每個工具的基線審查提示都存在於code>run_batch_baselines.py/code>，而 README 沒有記載更乾淨的做法——你只能直接編輯該腳本。

在你克隆它之前，還有兩個事實。該論文採用 CC BY 4.0 授權；但儲存庫頁面並未說明程式碼的授權，因此請勿自行假定。此外，論文並未公布執行該基準測試所需的成本或 token 使用量數據——這些並未公開，所以我們不會憑空捏造。但此流程確實暗示：在 184 個實例中，每個 PR 建立一個 Docker 映像檔，再加上代理程式解析過程，這不是一台筆電在一個下午就能完成的事。

這對任何部署審查管線的人來說意味著什麼

c-CRAB 的核心論點是，LLM 評審是一個不可靠的預言機。如果你無法建立可執行的預言機——而大多數團隊都無法——最好的可行緩解措施是永遠不要讓評審在產生評論的模型上運行。與評論者共享模型的評審會同意自己，驗證流程就變成了一個橡皮圖章，仍然回傳一個數字。

這正是我們隨附的審查器背後的路由配方所防禦的失敗——而且這與 c-CRAB 的批評是設計上的平行對應，而非基準測試結果。評測框架仍會執行一個 LLM 評判員，作為第二遍處理：它會將發現分群，每個群集就其是否為此變更中的具體缺陷評分 0–1，並丟棄所有低於門檻的內容。管理它的配方，code>recipes/orcacode-review.dsl.yaml/code>，是一個公開檔案。Action 從不指定模型：它呼叫路由器別名，而由配方決定。就預設配置而言，配方只有四行——審查器的預設是code>deepseek/deepseek-v4-flash-0731/code>，而有一條規則比對標頭code>x-cr-lens: judge/code>，會將評判遍次送往code>z-ai/glm-5.3/code>，這是不同的供應商。配方自身的文字要求評判員「MUST NOT NAME THE DEFAULT’S MODEL」，因為在審查器自己的模型上，它「同意自己，所以該遍次會失效，卻仍回報成功」。

不同廠商的評判模型會降低自我一致性，但這並不會讓 LLM 評判模型變成測試。c-CRAB 並未測試我們的評審者，我們也不會暗示相反的情況。OrcaCode Review會執行一輪審閱，再加上一個獨立的驗證評判模型；它按 token 計費，而非按席位計費，而且其中的每個提示詞都是公開的 — 所以你可以讓它去跑像這樣的基準測試，得到你自己的數字，而不是我們給出的數字。

底線

c-CRAB 是第一個程式碼審查基準，其評分大多名副其實、值得信賴：只有當採納審查意見能修復程式碼時，該審查才算通過。標題數字確實偏低——最佳單一工具 32.1%，聯集 41.5%——但這些數字衡量的是與人工提出的關注點的重疊程度，而非審查意見的品質，而實用性數據顯示大多數意見都是真正的訊號。真正能留下來的結論正是論文本身所主張的：數量不等於覆蓋率，代理與人類關注的面向不同，正確的部署方式是人類與代理協作。而且這個基準是開放的，所以誠實的下一步是在上面執行你自己的審查工具，並取得你自己的數字。