GitHub ReviewBench 發布：AI 程式審查怎麼比，才能找到問題又不淹沒工程師？

AI 程式審查最容易製造的錯覺，是留言很多就代表檢查很仔細。開發者打開一次程式變更，看到滿滿建議，可能真的發現重要錯誤，也可能花半小時才知道多數提醒並不適用。當團隊開始選擇審查代理，真正要比較的是它替工程師找出多少值得處理的問題，以及帶來多少額外查證工作。

GitHub 在二〇二六年十月五日發布 ReviewBench，用共同的程式變更與評分方式比較 AI 審查系統。它的重點不只是列出一個總分，而是讓使用者調整問題嚴重程度、類型，以及漏報和誤報的偏好。這使排行榜更接近工作選擇，也讓評分如何形成變成必須理解的部分。

本文的判斷是，ReviewBench 提供了有用的篩選與改進工具，尤其適合需要比較不同審查代理的團隊。它仍不能替每個專案保證安全，也不代表分數最高的工具適合所有工作流程。先理解題目從哪裡來、答案如何判定，再決定排名是否符合自己的審查目的，才不會讓測試代替工程判斷。

一億次變更提供背景，實際題目是二百一十九筆

程式團隊通常透過 pull request 提出變更，交由其他人檢查後再合併。它可簡稱 PR，內容可能是修錯、新增功能或更新文件。AI 審查代理的任務，是閱讀這些改動與相關專案脈絡，提出值得作者處理的發現。它必須針對本次變更，指出有根據且能採取行動的問題。

GitHub 為建立資料集，分析了一億零三百九十萬筆 PR 的分佈。這個大數字用來理解語言、儲存庫規模與變更形態，並不表示每次評測都執行一億個題目。ReviewBench 實際包含二百一十九個公開 PR，來自一百八十七個有開源授權的儲存庫，涵蓋十九種語言。

這個區別會影響讀者對證據的判斷。分析大規模背景，有助於選題更接近真實工作。最後評測的樣本數，才決定工具實際面對哪些題目。若把兩者混為一談，就可能高估測試覆蓋範圍，誤以為某個排名已經代表整個 GitHub 平台所有變更的審查表現。

官方也說明，語言與儲存庫規模盡量接近平台分佈，但刻意提高中型與大型變更的比例，避免大量微小、單檔案變更佔滿題目。這是合理的設計取捨，因為實質審查常需要跨檔案理解。不過，日常多是小型更新的團隊，不能假設它與自己的工作比例完全相同。

因此，看資料集不是為了挑一個漂亮的語言數字，而是確認它與團隊任務的關係。若自己的程式語言、變更規模或產品架構很少出現在題目中，排名仍可作參考，卻應增加本地案例。共同測試解決比較基準的問題，專案自己的案例則補上實際使用的差異。

參考答案來自多個來源，仍要逐項驗證

程式審查很難只有一份完整答案。原作者後來修正的錯誤，可能沒有出現在當時的留言中。靜態分析工具找到的問題，也可能被人工忽略。靜態分析是不用執行程式就檢查結構或規則的方式。ReviewBench 結合不同來源，目的是降低單一審查者的盲點。

官方收集人類審查、作者後續提交、確定性的分析工具，以及多種前沿模型的候選發現。它們會先合併指向同一個根本問題的留言，再以共同規則判定。這樣就不會因三個模型用不同措辭重複指出同一件事，就把參考答案中的問題數膨脹成三個。

合併並不代表只保留多數意見。有些重要錯誤可能只有一個來源發現，也應依內容判斷。官方要求有效發現必須是真的、與變更相關，而且不是瑣碎提醒。這三項條件很重要，因爲審查成本不只來自錯誤答案，也來自正確卻與本次工作無關的留言。

假設某個工具指出專案裡存在一種低效率寫法，但這次 PR 並未新增或改變它，作者就可能無法合理地在這次變更修正。這是用來說明相關性的假設案例。若評測把這種留言全部算成有效發現，就會獎勵廣泛評論專案，卻未必改善這次合併決策。

經過驗證的發現形成 golden set，可以理解為這批題目的參考問題清單。它是重要的比較基準，但不應被當成所有錯誤都已找齊。代理若能提出原清單沒有的新問題，需要另一套判定方式才能公平處理。這也是 ReviewBench 同時提供兩組指標的原因。

精確率與召回率，分別回答噪音和漏報

精確率衡量代理提出的問題中，有多少符合有效標準。比例高，通常意味着工程師較少花時間處理無效提醒。召回率則衡量參考清單中已知的有效問題，有多少被代理找到。比例高，代表在這批題目裡漏掉較少已知問題。兩者分別對應審查負擔與覆蓋範圍。

假設題目有十個已知問題，代理指出五個，其中四個符合參考清單，便得到八成精確率與四成召回率。這是為了說明指標的簡化算例，不是任何參賽系統的成績。它讓我們看見，一個工具可以大部分留言正確，卻仍漏掉很多問題，不能只看其中一個數字。

另一個代理可能提出十五個提醒，找到九個已知問題，但讓工程師多讀六個未符合既有答案的發現。這些額外留言未必全部是錯誤，也可能是真的新問題。因此，只用既有答案計分時，雖然比較基準一致，卻可能對發現新問題的工具過於嚴格。

ReviewBench 的 Grounded 指標只使用既有參考標註，比較共同的已知問題。Augmented 指標則進一步請評分者判斷未匹配的發現是否有效，使真正的新問題也能獲得肯定。前一組方便在相同基準上比較，後一組有助於瞭解某個系統超出原答案的能力。

官方特別說明，Augmented 召回率的分母會依各代理發現的問題擴充，因此不同代理未必面對相同分母。平台使用 Grounded 召回率作跨系統的主要比較，Augmented 作補充診斷。若直接把兩種召回率混在一張排行榜中，就容易比較不同問題集合而得出錯誤結論。

同一套排名，也可能因審查目的而改變

F1 分數把精確率與召回率等量結合，方便呈現單一概括結果。但企業的使用情境未必等量看待兩者。資深工程師面對大量簡單更新時，可能更在意提醒少而準。接近正式上線的關鍵變更，則可能願意接受更多查證，只要能少漏掉重要問題。

ReviewBench 提供 Fβ，讓使用者調整精確率與召回率的重視程度。β 是控制權重的參數，不是新的模型能力。調整偏好會重新排序，因此排名改變不代表工具突然變好或變差，而是使用者選擇不同審查目標。這種設計比只展示一個固定冠軍，更有助於採用判斷。

問題的嚴重程度也需要分開看。抓到很多低風險維護建議，不能直接抵銷漏掉一個嚴重的資料錯誤。官方把發現標註嚴重程度與類型，讓使用者依正確性、安全、可靠性、維護或測試等面向看結果。團隊應先說清楚審查目的，再看對應切片，而非反過來為高分找用途。

若希望降低日常留言負擔，可以看精確率及低價值提醒。若要在特定類型變更中補足人工盲點，就看相應問題的覆蓋。這是使用指標的建議，不是官方替每個團隊選好的政策。最終是否有效，仍要確認工程師能否理解發現、重現問題，並做出正確修正。

即使一個工具真的發現重要錯誤，留言表達也會影響效益。它應指出涉及哪段程式、在什麼條件下出問題，以及為何值得處理。團隊試用時可以記錄重現與判斷所需時間，分辨「模型找到了」和「工程師能用這個發現」之間的距離，避免總分掩蓋工作上的阻力。

九成六的一致性，是標註品質而非模型準確率

ReviewBench 使用 Claude Sonnet 5 作評分模型，套用共同規則判斷候選發現。讓模型評模型，自然會引起對偏好與錯判的疑問。官方公佈評分規則與使用的模型配置，並安排沒有參與資料集建置的資深工程師，重新逐項標註參考問題的真假。

這份內部獨立複覈與 ReviewBench 的標註有百分之九十六點六一致。它說明人工判斷與評測標註在這些問題上高度相符。這是資料標註的內部複核結果，應與特定代理的準確率、外部認證分開理解。這個數字應用來判斷標註品質，而非工具實際成績。

剩下的不一致同樣值得看。如果差異集中在某種安全問題、特定語言或低嚴重度提醒，可能對特定團隊比總比例更重要。官方也公佈驗證方法與效度限制，使用者可藉此理解測試能支持到哪裡。高一致性使基準更可信，卻不會消除所有邊界與爭議。

評測還把資料集、評分者和問題匹配機製版本化。匹配機制用來判斷代理留言是否指向同一個參考問題。若這些設定變了，分數變化可能部分來自評分規則，而不是代理改善。因此，查看成績時應一併看版本與配置，才能把新舊結果放在同一把尺上。

對開發審查代理的團隊來說，這也提醒了改善方法。只改模型提示、發現分數上升，仍需檢查是否只是迎合評分器的措辭。真正有價值的進步，應在人工閱讀、問題重現與後續修正上也看得見，讓測試成為反饋工具，而不只是優化排行榜的目標。

離線分數有用，最終仍要回到工程師工作

離線評測是讓系統對已準備好的題目運行，再計算成績。它能較快比較不同配置，不需要每次都讓真實團隊承擔實驗。GitHub 表示 ReviewBench 已用於 Copilot 程式審查的迭代，並將離線變化與線上實驗方向對照。這是平台說明其使用價值的證據，不能直接當成所有代理的營運保證。

線上實驗中的「已處理率」，由模型參考程式變更、討論串、反應與後續狀態，判斷留言是否促成相應修改。它不是簡單的人工獨立正確率，也不表示開發者照做就一定改善程式。因此，即使離線與線上方向一致，也要看兩邊指標實際衡量什麼，避免把代理留言採納當成最終產品品質。

團隊可以先用 ReviewBench 縮小候選範圍，再用自己的歷史變更測試。選擇已知問題、可重現結果和必要脈絡，觀察代理有沒有找到關鍵錯誤，是否提出過多無關意見。最後在限定範圍的新變更中使用，記錄工程師實際閱讀與處理結果，這樣就能連接共同基準與本地工作。

評測工具也不能成爲自動合併的唯一理由。測試中的高覆蓋，不代表遇到新的架構、內部規範與資料流仍然同樣可靠。若變更涉及重要業務條件，仍需有能負責驗收的人理解結果。AI 的價值是補充檢視與加快發現，不是把責任交給排行榜上的一個數字。

官方研究預覽提供公開資料與自行評測流程。註冊自己的代理需要容器、配置與模型金鑰，先用二十五個 PR 的測試集調整，再執行完整二百一十九個 PR 的三輪最終評測。成績在維護者審查批准前保持私人狀態，首次或優於既有公開成績才進入排行榜，因此公開榜單也不是所有嘗試的完整紀錄。

這使 ReviewBench 同時具有研究與產品比較的價值。對一般團隊，先理解問題覆蓋與噪音偏好。對代理開發者，保留版本與配置並覈對具體發現。只有當評分能指出該補哪種錯誤、該減少哪類無效提醒，它才真正幫助程式審查，而不僅是增加另一張需要追逐的成績單。

常見問題

一億筆 PR 都是實際測試題嗎？

不是。GitHub 分析大規模 PR 來建立分佈背景，實際基準有二百一十九筆公開 PR。語言與儲存庫規模儘量貼近平台，中大型變更則有意提高比例。判斷結果是否適用自己的團隊，應看實際資料集與任務形態，不能只看背景統計數量。

找到參考答案沒有的問題，會被算錯嗎？

既有答案的 Grounded 指標與擴充判斷的 Augmented 指標分開處理。後者會判斷未匹配的發現是否真實有效，讓新問題獲得肯定。跨系統比較仍要留意兩種指標分母不同，避免把各自擴充後的召回率當成完全相同的共同測試。

排名最高就可以直接採用嗎？

先確認排名使用的嚴重度、類型和精確率與召回率偏好，再看是否符合團隊需求。之後用本地案例檢查問題重現、人工負擔與真實完成結果。排行榜能幫助篩選，但採用決定還需要回答這套工具能否改善自己每天處理的程式變更。

資料來源

• GitHub：ReviewBench 發佈與評測方法
• ReviewBench：官方研究預覽、資料與排行榜