GitHub 在 2026 年 6 月 26 日更新 Copilot usage metrics，讓 enterprise 和 organization reports 可以按 AI adoption phase 顯示 pull request merges 的總量。這看似是報表欄位更新，但對企業衡量 AI coding 成效很關鍵。
之前 totals_by_ai_adoption_phase breakdown 主要提供每位使用者平均值。今次新增 total_pull_requests_merged，讓管理員可以看到某個 adoption phase 的使用者在一天內合共 merge 了多少 pull request，並可配合既有 avg_pull_requests_merged 在 1-day 和 28-day reports 中分析。
這個改動的價值，在於把 AI 使用度量由「人均行為」推向「團隊交付量」。平均值可以看到某類使用者是否活躍，但總量才更容易回答管理問題：哪一個 adoption phase 對整體 merge throughput 貢獻最多？AI 採用更成熟的群組，是否真的推動更多已完成 PR？
對工程管理而言，這比單純統計 Copilot chat、completion 或 seat activation 更貼近結果。AI coding 工具的目的不是製造更多互動，而是令工程流程更穩、更快、更少阻塞。當報表能把 adoption phase 與 merged PR 數量連起來，企業就可以開始評估 AI 使用是否有轉化成 delivery impact。
不過這類指標也需要小心解讀。更多 merge 不一定代表更好品質，亦可能受到團隊規模、PR 粒度、repo 類型、release 節奏和審核規則影響。所以 total_pull_requests_merged 最有用的方式，是配合 defect rate、review latency、change failure、cycle time 和 code review 質量一同看。
GitHub 在公告中強調 total 和 average 使用相同 attribution，因此兩者可以一致比較。這一點重要，因為企業採用 AI 的過程很容易被各種分散工具割裂。若度量口徑不一致，管理層會很難判斷 Copilot 到底是在提升效率，還是只是在改變工作方式。
更大的訊號是，AI coding 正在由個人 productivity 工具進入管理報表層。當 Copilot adoption 可以按 phase、throughput 和時間窗口追蹤，企業就可以更有系統地做 enablement：哪些團隊需要培訓，哪些流程適合 agent task，哪些地方需要治理或 code review 加強。
這次更新不是一個華麗功能，但它很實用。企業 AI 的下一階段，會越來越重視可觀測性。只有知道 AI 怎樣影響 pull request、review、merge 和 release，團隊才有辦法把 AI coding 從試用推向穩定工程能力。
