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 从试用推向稳定工程能力。
