GitHub 於美國時間十月五日在官方工程網誌發布 ReviewBench，一個公開、可重現的 AI 程式碼審查離線基準。基準以分析逾一億零三百九十萬個 GitHub 拉取請求（PR）的分佈為藍本，精選來自一百八十七個開源授權公開儲存庫、橫跨十九種程式語言的二百一十九個真實 PR，數據集、評分準則、LLM 評審設定及自助執行器全部公開，研究預覽版已開放任何團隊提交自家審查代理上排行榜。

GitHub 同時披露，基準的「標準答案」經未參與建置的資深工程師獨立重新標註，一致率達百分之九十六點六；而以 ReviewBench 預測的 Copilot 多模型集成審查，正式 A/B 測試結果與離線預測方向一致：關鍵級評論增加百分之二百六十二，每次審查成本下降百分之八。

GitHub 開源 AI 程式碼審查基準 ReviewBench：二百一十九個真實 PR 測代理「抓蟲」能力，Copilot 實測關鍵評論增百分之二百六十二

本文以 GitHub 官方網誌文章《ReviewBench: An open benchmark for AI code review》（作者 Michelle Zhou 與 Alejandro Carderera de Diego，二零二六年十月五日）為主要依據，並核對 ReviewBench 官方網站已上線，來源真實性已驗證。下文整理基準的構成、評分原理、GitHub 自身的實測數據，以及對開發團隊與香港企業的實際意義。

一、核心事件：AI 審查代理終於有一把公開的尺

近年 AI 程式碼審查工具愈來愈多，但各家公布的成績多數來自自建測試集，標註質素、覆蓋範圍及是否貼近真實審查工作都難以比較。GitHub 指出，業界一直缺少一套把標註質素、覆蓋度與真實代表性結合起來、而且可重現的評估方法，ReviewBench 正是為填補這個缺口而建。

技術細節

語料規模：GitHub 先分析一億零三百九十萬個 PR，按語言、儲存庫大小及變更形態建立分佈，再從一百八十七個公開開源儲存庫抽出二百一十九個 PR，涵蓋十九種語言，語言及儲存庫大小分佈與 GitHub 整體貼近。
刻意調整：PR 大小的分佈特意偏向「值得審查」的中段與長尾，減少單檔細改的比重，保留更多跨檔案、審查質素真正有影響的變更。
結構化發現：每項「發現」（finding）均標註嚴重程度（關鍵、中、低）與類別（正確性、安全、可靠性、可維護性、測試等），用戶可按需要切片比較。
開放程度：完整數據集（PR、發現、標籤、嚴重程度及類別註解）、評估方法、LLM 評審提示詞、評審模型設定及自助執行器全部公開。
團隊：GitHub 表示基準由 GitHub 與微軟研究及工程人員共同建置。

二、技術原理深度解析

1. 多來源「標準答案」，再統一裁決

GitHub 認為，無論人類還是模型，單一審查者都不可能找出 PR 內所有值得指出的問題。因此標準答案（golden set）以三步建立：

多來源收集：候選發現來自真實人類審查意見、從作者後續修正提交反推的問題、確定性靜態分析工具，以及多個不同模型家族的前沿 LLM。
語義去重：把指向同一根本問題的發現合併，既擴大覆蓋，又避免多個來源「同意」同一點而人為灌大答案集。
統一準則驗證：發現來自哪裏並不決定其對錯，只有「真實、相關且非瑣碎」才算真陽性。GitHub 採用 Claude Sonnet 5 作為 LLM 評審，以同一準則評核所有提交，並公開準則與評審設定。

2. 兩組六項指標：既計已知問題，也計新發現

Grounded（以答案集為準）精確率、召回率、F1：只用既有標籤，提供嚴格、可直接對比的成績，即「已知問題中找到多少」及「代理提出的意見有多少命中已知問題」。
Augmented（擴充）精確率、召回率、F1：對未能配對答案集的發現，由評審獨立判斷真偽，令代理找出答案集未有的真問題時仍可得分。

GitHub 解釋，審查代理愈來愈強，固定答案集必然愈來愈不完整，擴充指標可避免「找到新蟲反被扣分」。不過由於擴充召回率的分母會隨各代理的發現而變，跨系統比較以 grounded 召回率為主要指標，擴充指標只作個別系統診斷。

3. 可調權重，配合不同團隊口味

有團隊只想看關鍵問題，有團隊重視覆蓋面，亦有團隊最怕噪音。ReviewBench 允許按嚴重程度與類別切片，並可調整 Fβ 分數中的 β 值，偏重召回（覆蓋）或精確（低噪音），排行榜會按偏好重新排序。

4. 內部稽核與版本化

發布前，GitHub 邀請未參與建置數據集的資深工程師由零開始重新標註每一項標準答案，其真／假陽性判斷與 ReviewBench 一致率為百分之九十六點六。數據集、評審及配對器在每次評估均有版本記錄，基準更新時可重新驗證；GitHub 亦公開驗證方法、一致率數據及已知效度風險。

三、GitHub 自己的實測：離線分數能否預測上線效果

GitHub 表示已用 ReviewBench 評估 Copilot code review（CCR）的多次迭代，在 A/B 測試前先取得離線訊號；至今離線評估的改動方向，與其後正式環境結果一致。

官方舉出一個近期「lite 級」實驗：把多次獨立模型運行合併為單一審查的多模型集成方案。ReviewBench 事前預測精確率、召回率及評論數量上升，同時每次審查成本下降。正式 A/B 測試相對對照組的結果為：

「被採納率」（addressed rate，GitHub 以 LLM 判斷評論是否促使開發者作出相應修改，作為精確率的線上對應指標）上升百分之八點零
召回率（以仍需多少額外人手審查衡量）上升百分之十三點六
評論數量上升百分之六十一
每次審查成本下降百分之八點零

GitHub 強調評論數量本身不代表質素，ReviewBench 的嚴重程度分析亦捕捉到結構變化：離線預測關鍵級評論增加百分之二百二十七，線上實測為百分之二百六十二，同時中等級評論增加、瑣碎意見減少。

四、日常應用場景

1. 開發者與技術團隊

自建或微調審查代理的團隊，可先在官方提供的二十五個 PR 測試集上反覆調參，再以完整二百一十九個 PR、跑三輪作正式評分。提交流程為：以 GitHub 帳戶登入、登記代理（提供容器映像、設定及自備模型金鑰，評審由官方提供）、測試、正式運行，再申請上榜。成績在維護者審核前保持私密，且只有首次上榜或勝過該代理現有成績時才會公開。

2. 企業與採購決策

企業選購 AI 審查工具時，可要求供應商提供 ReviewBench 成績，並按自身重視的類別（例如安全或可靠性）及 Fβ 偏好比較，而不是只看宣傳頁的單一分數。對受規管行業而言，「關鍵級問題召回率」比評論總數更具參考價值。

3. 一般開發者與開源維護者

開源維護者可透過公開的發現及標籤，了解 AI 審查常見的漏判與誤判類型，從而決定在合併流程中讓 AI 擔任第一輪篩查，還是只作輔助。

4. 香港與亞洲市場視角

香港不少企業以小型內部團隊配合外判開發，程式碼審查往往是最容易被壓縮的環節。一套公開、可重現的基準，讓本地團隊可以用數據而非感覺，判斷某款 AI 審查工具是否值得接入 CI 流程；對金融、醫療等重視合規的機構，亦可按安全類別切片，檢視工具在安全相關問題上的表現，再決定內部審批流程如何配合。

五、專業評價與潛在考量

優勢

語料按 GitHub 真實 PR 分佈抽樣，並刻意保留較有審查價值的多檔變更，比示範式測試集更貼近日常工作。
標準答案結合人類、靜態分析、提交歷史與多家模型，並以資深工程師百分之九十六點六的一致率作稽核。
數據集、評審提示詞及執行器全公開，第三方可重現及挑戰結果。
GitHub 公開了離線預測與線上 A/B 結果的對照，增加基準的可信度。

需要留意的地方

基準由 GitHub 建置，並以自家 Copilot code review 作主要案例，第三方仍需時間檢驗其中立性。
二百一十九個 PR 屬精選樣本，對特定語言、框架或私有程式碼庫的代表性有限。
真偽裁決依賴 LLM 評審（Claude Sonnet 5），評審本身的偏差及日後更換模型對分數的影響仍需留意。
目前屬研究預覽版，指標與流程或會再調整；文中線上數據來自 GitHub 單一實驗，並非跨產品通則。

結語

ReviewBench 把「AI 審查代理到底找到多少真問題、製造多少噪音」變成可公開比較的數字，亦顯示離線基準若設計得當，可以有效預測上線效果。隨着編碼代理產生的程式碼愈來愈多，審查環節的品質把關只會更加重要。如團隊需要遠端開發人手配合 AI 工具完成開發與審查流程，可參考 YSK Limited 的遠端開發者外判服務（HK$2,000/月起，https://ysk.hk/services/outsourcing）；若企業希望把程式碼審查等 AI 工作流放在自家私有模型上、數據不出境，亦可參考企業私有 LLM 全託管（年費 HK$88,000 起，https://ysk.hk/services/ai-automation）。

參考來源

GitHub 官方網誌：ReviewBench: An open benchmark for AI code review（Michelle Zhou、Alejandro Carderera de Diego，2026 年 10 月 5 日）https://github.blog/ai-and-ml/github-copilot/reviewbench-an-open-benchmark-for-ai-code-review/
ReviewBench 官方網站（研究預覽版、排行榜及提交入口）https://review-bench.ai/
GitHub Docs：Using GitHub Copilot code review https://docs.github.com/en/copilot/how-tos/use-copilot-agents/request-a-code-review/use-code-review
發現來源：GitHub 官方網誌 RSS