程式碼審查代理基準：如何評估審查者，並在你自己的程式碼上執行 c-CRAB

要判斷一個程式碼審查代理好不好，方法有許多。在這一領域短暫的歷史中，大多數時候答案是「看它的評論跟人類審查者有多接近」——聽起來合理，但實際做起來卻不然，因為兩位審查者可以用完全不同的措辭指出同一個問題。Code Review Agent Benchmark——論文為 arXiv:2603.23448，資料集為 c-CRAB——是第一份認真嘗試不依措辭、而依「依評論行動後產生的結果」來評分審查的基準。它把 234 則人類審查評論轉換成可執行的測試，讓四款廣為使用的審查工具——PR-Agent、Devin、Claude Code 與 Codex——去執行，結果發現四者合計僅通過其中 41.5% 的測試，用論文自己的話說是「只有大約 40%」。本頁是一份操作手冊：如何正確解讀這個結果而不至於曲解它、如何自行執行 c-CRAB，以及當你的程式碼庫根本不在這份基準中時該怎麼做。

標題數字是這個頁面上最沒用的東西。有用的是方法與失敗模式：為何每個先前的評分方案都在衡量錯誤的事物、改用可執行的測試來評分審查需要付出什麼代價，以及為何「審查代理只抓得到 40% 的錯誤」是對實際結果的三重誤讀。這裡的一切都是社群對已發布基準測試及從業人員執行經驗的解讀，而非相關工具廠商提供的官方指引。

為什麼顯而易見的指標不起作用

在 c-CRAB 之前，對程式碼審查代理的評估分屬少數幾個家族，而該論文自己的比較表（表 1）列出了這條脈絡。最古老的是文字重疊——BLEU、ROUGE、chrF 及其同類指標，被 CodeReviewer 和 ContextCRBench 等基準所採用。其概念是：當代理的評論其 n-gram 與人類的評論相符時，該評論就是好的。但這個概念在程式碼審查中無所不在的一種情況上失效了：同一缺陷用不同詞語描述。

論文的案例研究是最清晰的例子。在 python-telegram-bot 的一個 pull request（PR #3514）中，人類審查者和 Codex 都標記了相同的巢狀索引健壯性錯誤。Codex 的審查在行為上是正確的——一個依據該審查採取行動的編碼代理產生了通過可執行測試的修復。然而，文本指標對它的評分是 BLEU-4 0.00、ROUGE-L 7.02、chrF 20.74，以及嵌入相似度 54.59。n-gram 重疊為零，而該審查是對的。同樣的顧慮，只是措辭不同：字串指標無法識別它。嵌入相似度部分有所提升——相對於確認通過的結果，54.59 仍然遠未達到可用閾值——而它以較柔和的形式繼承了相同的問題。

LLM-as-judge，即由模型將代理的評論與人類的評論進行比較並投票，解決了詞彙問題，但引入了三個新問題，論文直接點名：偏見、不穩定性，以及對提示設計的敏感度。同樣的比較跑兩次，評審可能給你不同的裁決；換個措辭來寫評審提示，排名就會變動。當你在同一基準上，要在差距三分以內的兩位審稿人之間做選擇時，具有這種變異性的評審無法支持任何決定——而無法重現的分數，根本不算分數。

可執行的預言機能帶來什麼——又需付出什麼代價

c-CRAB 的核心想法既簡單又激進：與其問「這則評論聽起來像人類寫的嗎？」，不如問「如果你依照評論採取行動，程式碼是否會被修正？」。每一則被保留的人類評論註解，都會被轉換成一個可執行的測試，來捕捉其背後的根本問題。一則評論註解若能因為採取行動而產生行為上正確的修正、使該測試通過，就視為正確——而且每個實例都附帶一個可執行的 Docker 環境，所以「使測試通過」是事實，而非判斷。

該論文定義了兩種測試。行為測試「在執行時匯入並執行被測試的程式碼」，以「特定輸入」呼叫函式，並檢查「輸出或驗證例外」。結構測試「檢查原始碼文字、比對模式，並檢查 API 表面，以判斷是否已做出所需的程式碼變更。」最終的分佈是 42 個行為測試（17.9%）與 192 個結構測試（82.1%）——而這種偏差值得一句誠實的話：這個測試基準大部分是對原始碼文字的型態比對，而不是執行程式碼。黃金標準是行為測試；而資料集的大多數是它的務實版本。

建立 oracle 是一個四階段的漏斗，每個階段都會丟棄一些東西：

• 初始資料集 — 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% 的初始 pull request 能存活下來。我們直說吧，因為這是以測試為基礎的驗證機制所付出的誠實代價：如果一條評論不夠具體可行、無法轉化成失敗的測試，或是環境無法建置，又或者一位稱職的程式編寫代理無法單憑評論修好程式碼，該實例就會被捨棄。這也是為什麼這個基準測試規模很小。184 個 PR 實例和 234 條通過驗證的評論，是一份你能讀完的資料集，而不是一座會讓你淹沒的語料庫——而對一個必須執行真實 Docker 環境的驗證機制來說，規模小反而是項優點。

作為規模參考：平均每個實例觸及418.1行修改，測試平均31.8行，每個實例有1.27個測試。在50個抽樣實例中，兩位標註者對生成的測試是否忠實捕捉人類審查者的關切，有84%的時間達成一致。

如果你自己去看那篇論文，會遇到一個參考文獻上的瑕疵：數據集表格（表4）列出了67個倉庫，而「有效性威脅」一節卻說「在56個倉庫中有184個拉取請求實例，並有234個可驗證的oracle」。論文在不同的地方給出了這兩個數字，卻沒有調和它們。不要偏袒任何一個，也不要取平均值——在各自出現的地方引用。這類差異正是讀者用來判斷某個基準是否值得他們花時間的細節。

就獨立性的盡職調查而言：該論文披露了一位作者隸屬於 SonarSource，並表示研究結果不應被詮釋為「對 SonarSource 產品品質的評估」。這是他們的免責聲明，且是直接引用而非改寫。

如何在 c-CRAB 上讀譜而不會誤引

主要指標是通過率：每個實例中，該 PR 的測試通過比例，並跨全部 184 個實例取平均。以下是論文中的完整結果表格，每個審閱者一行。人類那一行是標尺標記，而非競爭者——人類撰寫了 oracle，因此根據構造，他們的分數就是 100%：

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

• Devin — 1,344 條評論，每個 PR 7.3 條，總體 24.8%（行為 31.0%，結構 23.4%）。

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

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

• 人工 — 234 則評論，每個 PR 1.3 則，100% 依構造達成。

有三處需要更正，因為摘要中「僅約40%」是目前AI程式設計討論圈中最常被誤引的數字。首先，41.5%這個數字——234項測試中有97項至少被一個工具通過——是所有四位審查者的聯集：只要任何代理通過某項測試，該測試就計為一次。沒有任何單一代理得到41.5%；最佳單一成績是Claude Code的32.1%。其次，人類那一列是基準答案（oracle），而非參賽者；把它複述成「人類擊敗機器人」是範疇錯誤。第三點，也是最重要的一點：c-CRAB不會對人類審查者從未提出的有效問題給予任何分數。基準答案就是人類的審查意圖。若某個代理發現了沒人提過的真實錯誤，它為此得零分。所以，「AI審查代理僅能抓出40%的錯誤」在三個層面上都是錯的——它是聯集、它不是錯誤抓取率、而且它衡量的是與人類審查者的一致程度，而非整體正確性。

評論量就是陷阱

結果中最有趣的數字並非贏家。Claude Code 和 Devin 各自發布了超過 1,300 則評論——每個 PR 約 7.3 則——分別達到 32.1% 和 24.8%。Codex 發布了 324 則評論，每個 PR 約 1.8 則，達到 20.1%。人類基準是每個 PR 1.3 則評論。數量不等於覆蓋率：約五倍的評論量，換來的卻是遠低於兩倍的通過率。若你在挑選審查者，這些額外評論的真正成本在於人類審查疲勞——代理每發布一則評論，都是一個需要人類篩選判斷的決定。

有用性的發現則指向另一個方向，而正是這一部分讓此事不至於淪為廉價的「機器人很吵」的故事。作者人工檢查了6個PR中的92則評論，判定其中84%（77/92）為有用——PR-Agent 94%、Codex 88%、Devin 85%、Claude Code 78%。因此，大多數未通過測試的評論並非噪音；它們涉及的是人類評論者未曾提出的問題。樣本規模很小——92則評論、6個PR——這點應與那些百分比一同提及。

雙方實際談論的內容，說明了結果的樣貌。人類審查者傾向關注可維護性、設計與文件；工具則傾向關注穩健性、測試與錯誤處理。論文將此解讀為支持人類與代理協作而非取代的論點——而這也是對分數為何偏低的最佳現有解釋。一個對邊緣情況敏銳但對設計沉默的審查者，會系統性地遺漏人類所標記的類別，而評分基準完全建立在人類的標記之上。

走過這個過程的實務工作者最終都會到達同一個結論。丹尼爾·沃恩（Daniel Vaughan）在一篇詳細文章中將這項工作稱為 CR-bench，得出了相同的結論，並將其轉化為一套工作流程：讓代理（agent）負責穩健性與正確性的全面掃查，把設計、慣例與架構留給人類——這些正是代理得分最差的類別——並以指名這些弱項類別的審查指示來引導代理。他對任何閱讀排行榜的人最有用的告誡是：「有用性不等於通過率」，因為測試套件要求的是與人類預期的修正相匹配，而一個有效的替代修正方案反而會無法通過測試。依他的解讀，從 20% 到顯著更高分數的路徑，不是升級模型——而是配置工作。

自行運行 c-CRAB

以上內容都是在閱讀別人的成果。複製套件讓基準測試得以執行——它就位於 c-CRAB-Benchmark/dataset（GitHub 上）——而 README 如實說明了所需條件。

要求：code>uv sync/code>；Docker，以及任一 code>OPENAI_API_KEY/code> 或 code>ANTHROPIC_API_KEY/code>（Claude Code 另外會從 code>~/.claude/.credentials.json/code> 讀取憑據，這個檔案預設會掛載到容器中）。佈局包含五個目錄： code>pipeline//code>（pipeline 邏輯和提示詞），code>execution//code>（Docker 鏡像構建器與運行時輔助工具），code>results_preprocessed//code>（已發布的基準測試子集），code>results_pipeline_funnel//code>（stage0–stage4 的 JSONL 檔案與 funnel 摘要），以及 code>raw_results_compressed//code>（原始實驗輸出）。五個步驟依序為：

1. 建置 Docker 環境 — code>uv run python -m execution.build_swe_care --split test --instance results_preprocessed/instance-ids.txt --max-workers 4/code>. 預先建置的映像檔也發布在 c-CRAB-Benchmark 的 GitHub packages org 下，如果您想略過建置步驟。

2. 生成測試 — code>./run_testgen_full.sh --instances-file results_preprocessed/instance-ids.txt --workers 4 --output-dir results_testgen/code>.

3. 收集基線評測 — code>uv run python run_batch_baselines.py --split test --instances-file results_preprocessed/instance-ids.txt --tools pr-agent devin claude-code codex --output-dir baselines_output --workers 4/code>。在執行此步驟之前，請先設定相應的外部工具憑證。

4. 執行代理程式解析 — code>uv run python run_batch_agent_resolution.py --stage3-file results_pipeline_funnel/stage3_testgen_verified.jsonl --testgen-dir results_testgen --output-dir results_agent_resolution --workers 4/code>.

5. 評估 — 每個工具重複一次： code>uv run python run_batch_tool_eval.py --tool pr-agent --stage3-file results_pipeline_funnel/stage3_testgen_verified.jsonl --testgen-dir results_testgen --tool-results-dir baselines_output --output-dir results_eval_pr-agent --workers 4/code>.

README 沒有提到的兩件事。要新增第五位審查者，就得編輯 code>run_batch_baselines.py/code>——那就是各工具基線審查提示詞所在的位置，而且沒有外掛介面；README 也未說明更簡潔的擴充點。此外，儲存庫沒有明確的授權檔，因此不要假設程式碼是 MIT 或 Apache 授權——論文以 CC BY 4.0 釋出，程式碼本身的授權條款則未標明。

成本是另一個未公開的項目。論文並未公布執行管線所需的代幣或美元數字，所以你在網路上看到的任何成本數字，都應視為未經證實。結構所暗示的已經夠清楚了：每個 PR 一個 Docker 映像，橫跨 184 個實例，加上每個工具各一次編碼代理解析回合與評估回合。這不是筆電等級、一個下午就能完成的事——請為真正的運算資源編列預算。

當你無法負擔可執行的預言機

大多數團隊誠實的立場是：基準是正確的，LLM 評審無法為審查評分，但要為自己的 PR 建立基於測試的 oracle 是一項重大的工程。值得劃分的區別在於 LLM 評審作為評分者與作為過濾者。c-CRAB 拒絕將評審當作 oracle，並不會使評審在審查器內失去作用——一個能聚類重複發現並丟棄弱點的評審仍然可以提高精確度。設計時需要防範的失敗模式是獨立性。

在審查者自身模型上運行的評判者會自我認同：它讀取評論，認為其可信，然後在未更改任何東西的情況下回報成功。來自不同供應商的評判者能降低這種自我認同——它不會把評判者變成測試，但能阻止橡皮圖章式的放行。由於我們自己的測試平台是開源的，我們可以展示一個具體且可驗證的實例來說明這道防護機制：Orca-Code-Review在 GitHub 上以 MIT 授權釋出，其路由配方以 repo 自己的話語說明了這條規則——評判者「不得指明預設的模型」，因為「在審查者自身的模型上它會自我認同，因此該評審動作會失效，卻仍然回報成功。」這個 Action 從不指名模型；由配方來決定。依目前的配置，審查者的預設值是 deepseek/deepseek-v4-flash-0731，而一條比對 code>x-cr-lens: judge/code> 標頭的規則，會將評判者的評審送往 z-ai/glm-5.3——一個不同的供應商。這是與 c-CRAB 論點相平行的設計，而不是一項結果：我們並不在該基準測試中，我們的審查者也沒有 c-CRAB 分數。但這是任何無法建立可執行測試預言機（oracle）的人都能取得的務實緩解措施，而且當評判者與審查者能位於不同提供者、共用同一把金鑰時，成本很低——這正是路由器的用途。在 OrcaRouter 上，審查者與其評判者只是路由 DSL 中的兩行，而你以提供者的列表價格付費，零加價。

當你的程式碼不在基準測試中

184 個 PR，橫跨 56 到 67 個公開儲存庫，那不是你的程式碼庫，也從來不會是。可轉移的部分是方法，你可以在自己的歷史紀錄上以更小的規模執行它。挑選那些有人工審查意見的已合併 PR。針對這些意見的樣本，寫一個測試：在審查意見被處理之前失敗，處理之後通過——這種「先失敗後通過」的特性就是整個遊戲的核心。用你的候選審查者在審查前的 diff 上執行。然後檢查根據它的評論採取行動是否能使測試通過。你得到的是一個在你實際發布的程式碼上計算出的數字，比排行榜名次更有價值。而它的代價正是那篇論文撞上的那堵牆：你需要每個 PR 可重現的環境，因為一個只在你的筆記型電腦上通過的測試，不是一個可靠的判準。

你並不需要 234 個測試。在你們團隊真正爭論過的 PR 上，十來個精挑細選的測試，會比任何基準分數更能讓你了解你的審查者。而針對這個基準系列的平行從業者分析，關於這道關卡說得很直白：LLM 分類器在判斷一則評論是否為有效且可驗證的問題時，其精確度介於 66% 到 85% 之間，因此請把機器篩選視為一份候選名單，並在任何內容變成測試之前，保留人工裁決的步驟。同一篇分析也指出，LangChain 的 ReviewBench——獨立基於相同的「評論轉測試」概念建置——最多只能還原其基準問題的約 30%，與 c-CRAB 的 20–32% 大致在同一水準，這也提醒我們，工具之間個位數的排行榜差距，往往比你自身環境中的雜訊還要小。

如果您正在考慮要購買哪種審查工具，那是另一個問題——我們的 code-review-agent 採購指南涵蓋了 bot 與 agent 的比較、按席位（per-seat）與按 token（per-token）的計價方式，以及何時自架（self-hosting）更勝出——而一旦您擁有工具，每次推送時執行審查框架（review harness）的運行成本，則在我們的自動化程式碼審查解說中有詳細說明。本頁僅專注於衡量，而與本篇搭配的姊妹篇會逐步解說基準測試的結構：建構漏斗、資料集統計，以及完整的結果表格。

常見問題

41.5% 是最佳智能體的分數嗎？ 不是。41.5% 是四個工具的聯集——只要任何一個工具通過某項測試，該測試就計入一次。最佳單一分數是 Claude Code 的 32.1%。

c-CRAB 是否衡量審查者找出多少錯誤？ 不是。它衡量的是審查與人類審查者提出的問題——轉化為可執行測試——之間的匹配程度。人類從未提及的真實缺陷，無論多麼有效，得分皆為零。

人類審查員是否「擊敗」了機器人？ 100% 人類的那一行本身就是基準——這些測試是由人類撰寫的——因此它是衡量標尺，而不是競爭對手。

c-CRAB 和 CR-bench 是同一件事嗎？ 是的。資料集是 c-CRAB；有些第三方報導稱之為 CR-bench，但這裡只有一個基準。

運行它的成本是多少？該論文未公布任何成本數字。每個 PR 構建一個 Docker 映像，涵蓋 184 個實例，再加上一次 agent 解析過程，這代表實際的運算量——不是筆電等級的一個下午就能辦到。

底線

c-CRAB 的貢獻不在於排行榜——而在於它展示了評論可以透過執行其建議來評分，也說明了先前的文字相似度與 LLM 評審機制評錯了對象。如果你只能記住一件事，那就是這個三部分修正：41.5% 是聯集，人類那一列是 oracle，而基準對人類從未提出的缺陷不給予任何分數。而如果你想要一個可以據以行動的數字，這個方法是可以轉移的——在你自己的合併 PR 上進行「先失敗後通過」測試、加入人工裁決步驟，以及，如果你無法建立可執行的 oracle，至少要用一個與審查者模型相互獨立的評審模型。

如果你比較想實際評量一個審查工具，而不是爭論哪個比較好，那就從一個你能讀懂的測試框架開始。OrcaCode Review會執行一次審查流程，外加一個獨立的驗證裁判；它按 token 計費，而不是按席位計費，而且其中的每個提示詞都是公開的——所以你可以讓它針對像這樣的基準測試進行評測，取得你自己的分數，而不是我們的分數。