GitHub 给 Copilot 用量 API 补上评审耗时与轮次，AI 价值开始更容易落到代码评审环节

GitHub 在 2026-07-07 更新了 Copilot usage metrics API，新增两项和代码评审速度直接相关的指标: avg_pull_requests_minutes_to_review 与 avg_pull_requests_review_cycles。前者表示拉取请求从创建到首次被评审的中位耗时，后者表示一个拉取请求在合并前经历的评审提交轮次中位数。NZAO 认为，这条更新的重要性在于 GitHub 正把 Copilot 的价值证明，从“多少人打开了 AI”继续推进到“AI 是否真的缩短了团队交付链条”。

官方说明里有两个细节值得特别留意。第一，这两项指标都放进了 totals_by_ai_adoption_phase 这组按 AI adoption phase 拆分的 cohort 字段里，也就是说，企业现在可以把不同采用深度的团队放在同一框架里比较。第二，这些数据 只统计已合并的 pull request，并按合并日归因，未合并的评审记录不会混入其中。这个口径相对克制，但也因此更适合管理层和效能团队拿来做阶段性复盘，因为它避开了“草稿 PR 太多导致噪音偏大”的常见问题。

从运营视角看，很多企业这两年已经不缺 AI 使用率数据，真正缺的是能和业务流程衔接的结果型指标。补上“首评耗时”和“评审轮次”之后，Copilot 的采用情况终于更容易和代码审查、协作摩擦、交付节奏这些核心工程信号连起来。尤其对已经建立 PR 审查制度的团队，这比单纯看提示调用量更有解释力: 如果一个团队的 AI 采用更深，但评审依旧慢、来回轮次依旧多，那么问题大概率不在模型可用性，而在规约、上下游接口或审查方式本身。

这也意味着，AI 效能分析正在进入更细颗粒度阶段。过去企业常把“上线 Copilot”当成一次工具部署，现在更现实的做法，是围绕 采用深度、评审效率与最终合并结果 建立连续观察。GitHub 这次不是给出结论，而是把更关键的数据接口补齐了。谁能真正从中拿到价值，取决于团队是否愿意把 AI 采用分析从采购层、活跃层，继续推进到工程流程层。