摘要： GitHub 在 2026 年 11 月 5 日為企業與組織層級的 Copilot usage metrics reports 加入一個 copilot_code_review 物件，放在每筆 repos-1-day 資料上，讓你能按 repository 計算「addressed rate」——開發者實際處理 Copilot code review 意見的比率。這解決了一個量測上的老問題：舊欄位只看 Copilot 跑了幾次 review、有幾個建議被點擊套用，但大多數回應其實發生在其他動作裡。
addressed rate 是怎麼算出來的
機制本身不複雜。Copilot 的每則 code review 意見會在對應的 pull request 合併時被「評估」，檢查開發者有沒有處理它。每筆資料回報兩個核心數字：total_comments_evaluated 是被檢查的意見總數，total_comments_addressed 是開發者有採取行動的數量。所謂「處理」的定義相當寬鬆——套用建議、叫 Copilot 自己修、直接改程式碼，或者回覆說之後的 PR 再處理，都算。兩者相除就是該 repository 當天的 addressed rate。
另外有一個獨立指標 total_merged_no_human_change_request_after_review：在 Copilot 完成第一次 review 之後，沒有人再提出 change request 就直接合併的 pull request 數量。這等於是從審查流程的另一端問：人類 reviewer 還會不會推翻 Copilot 的結論？
細分欄位才是真正的用處
總數之外，GitHub 也提供四組拆解：review_comments_by_severity（high、medium、low）、review_comments_by_review_tier（lite、balanced、max）、review_comments_by_comment_type（bug、security，或代表你自訂 coding guidelines 的 custom），以及 review_comments_by_customization——這一組按 custom instructions、skills、MCP servers 或 none 來分。
最後這組對做產品的人特別有價值。你為某個 repo 投入了客製化審查規則，過去很難驗證效果；現在可以直接比較有掛自訂設定的意見，addressed rate 是否真的比較高。如果手上有多個 repo，這也是一套現成的實驗框架。我先前在 Copilot usage metrics API 納入用戶端工具用量的那篇 裡提過，這個 API 一直在往「按切面拆解用量」的方向走，這次等於把同樣的思路套在 code review 的成果上。
三個容易誤讀的限制
第一，計數歸屬在合併日。意見是 Copilot 週一留的、PR 週五才合併，這則意見就算在週五。做時間序列時別把曲線解讀成「Copilot 當天的審查品質」。
第二，bot 開的 pull request（例如 Copilot cloud agent 自己開的）通常不會被評估意見，但 total_merged_no_human_change_request_after_review 仍然把這些 PR 算進去。兩個指標的分母不同，不能直接互比。
第三，新數字跟舊的 pull_requests.total_copilot_applied_suggestions 不可混用：後者只計「可直接套用且真的被套用」的建議，前者涵蓋每一則被評估的意見、而且以更寬的動作定義計入。如果儀表板同時拉兩組數字，圖例要標清楚。
同一天補上的另一塊拼圖
同一份 changelog 當天（2026 年 11 月 5 日）還有第二條更新：企業與組織的使用者報告新增 client_telemetry_present 和 usage_metrics_requirements 兩個 per-user 欄位，並在 1-day 報告裡加入 missing_client_telemetry_user_count 和 below_usage_metrics_minimum_user_count 兩個每日計數。前者標出當天收不到用戶端遙測的人——這些人照樣計為活躍，但他們的資料會缺 lines of code、feature 和 model 細分；後者標出 IDE 或 extension 版本低於最低門檻的人。常見原因是編輯器或 extension 太舊、IDE 遙測被關掉，或是 proxy、防火牆擋掉了事件。
要注意的是，這兩個每日計數不能相加——同一個用戶可能同時出現在兩邊——也不能跨天加總來推算不重複人數。null 或缺欄位代表資料不可得，不是零。
你接下來該查什麼
如果團隊已經在消費這個 API，先確認三件事：Copilot usage metrics policy 已啟用，而且你的帳號具備權限（enterprise owner、enterprise billing manager、organization owner，或被授予 View Copilot Metrics 權限的自訂角色）；解析器能處理「無活動的 repo 回傳 0 與空陣列」；以及 11 月 5 日之前的歷史資料不會有這些欄位。
接著挑一兩個你投入過自訂審查設定的 repo，跑幾週的 addressed rate，按 customization 維度對照。資料會告訴你那些 custom instructions 和 MCP servers 到底有沒有讓意見更容易被採納。至於多高的 addressed rate 算健康，這次的公告與文件都沒有給基準值，這部分只能靠你自己建立內部基線。
參考來源
- Usage metrics API adds code review details and addressed rate - GitHub Changelog
- Usage metrics API flags telemetry and version gaps - GitHub Changelog
- GitHub.com Help Documentation
在 X 上查看原貼文