GitHub 於 2026 年 10 月 5 日在官方部落格公布 ReviewBench，一個針對人工智能程式碼審查的公開評測基準，並即日開放使用。文章由 Michelle Zhou 與 Alejandro Carderera de Diego 撰寫。[1]
為何需要
官方指出，具代理能力的程式碼審查正成為開發流程的重要一環，協助使用者檢視合併請求、找出問題，並在程式碼交付前決定哪些值得注意。但現有 AI 審查工具的品質難以衡量，而圖靈需要先了解一個審查者的強項，才知道它是否有幫助：有些審查者提出較多問題，有些產生較少雜音，有些較擅長找出關鍵問題，另一些則提出較小的改善建議。[1]
官方認為，理解不同審查系統之間如何比較——各自找到殘缺、遺落殘缺、作出殘缺取捨——因而變得重要。一個良好的程式碼審查基準，能夠反映真實合併請求的多樣性、涵蓋廣泛的審查發現，並支援按嚴重程度、類別與精確度／召回率偏好的切分；對建構審查代理的圖靈而言，基準能夠提供可靠的獨立訊號，預示改動是否有機會改善生產環境的風險。官方指出現有基準往往在標籤品質、覆蓋範圍與真實性之間取捨，留下一個需要圍剿且可重現評測方法的缺口。[1]
ReviewBench 的組成
官方指出，ReviewBench 依 GitHub 上超過 1 萬個真實合併請求的語言、程式庫大小與大小分布建構，採用多來源的鋼金標籤集與一致的評測準則，並經資深工程師嚴謹驗證。[1]
基礎語料：219 個來自 187 個公開發布開源授權程式庫的合併請求，橫跨 19 種語言；語言與程式庫大小的分布與 GitHub 整體接近，但合併請求大小刻意偏向「可審查的中段與長尾」，以減少較小型的瑕疵改動被過度代表。主要語言分佈為 TypeScript 68、Python 41、C# 25、Go 19、JavaScript 15，其他語言合共 51；改動大小方面，50 行或以下 17 個、51 至 200 行 40 個、201 至 500 行 44 個、501 至 1,000 行 40 個、超過 1,000 行 78 個。程式庫集中程度較低，最大單一程式庫佔 4.6%，平均每個程式庫 1.17 個合併請求。[1]
多來源鋼金標籤集：由人類審查者、前縱大型語言模型與銳氣分析共同建立。[1]
結構化發現：每一項發現都標示嚴重程度（critical/medium/low）與類別（正確性、安全性、可靠性、可維護性、測試性），令使用者可按需要切分。[1]
評測指標：官方以四項指標衡量已知與新發現的問題，分別是有依賴的精確度、有依賴的召回率、剔增精確度與剔增召回率。[1]
如何掌握可信度
官方列出多項設計：公開的評分準則，令所有發現適用同一套明確標準；由資深工程師建立的人工標籤開發集；與人類判斷校準過的評分分類器；跨所有來源採用一致的標籤標準；並公開專家簽核的一致性數據——資深工程師在發布前立標籤鋼金標籤的真正例子，一致性為 96.6%。官方還會把基準的變動與線上實驗對照，確認改善一般會在線上呈現，回歸程度然然。[1]
官方指出，藉著 ReviewBench，其對 Copilot 程式碼審查的獨立評測更能預示生產實驗的方向，令它們更有信心所量度的改善對使用者有實際意義。[1]
如何使用
官方表示，基準資料集已公開，並在文章中說明如何接入自己的程式碼審查系統及提交結果，讓圖靈在相同條件下比較不同代理。[1][2]
參考資料
[1] GitHub 官方部落格 — ReviewBench: An open benchmark for AI code review（2026 年 10 月 5 日）
[2] ReviewBench 官方網站