使用指标 API 新增拉取请求审查阶段

企业和组织仓库级 Copilot 使用指标报告现在细分拉取请求在审查每个阶段花费的时间。每个 repos-1-day 行上的新 pull_request_review_times 数组报告从可供审查到首次审查、从首次审查到最终审查、从最终审查到合并的时间的中位数和第 90 百分位数。

pull_request_review_times 中的每个条目包括：

• authored_by 和 reviewed_by：谁打开了此条目中的拉取请求，以及谁审查了这些拉取请求。在此版本中，两者都是人类。
• total_merged：当天在仓库中合并的符合条件拉取请求数量。
• median_minutes_ready_to_first_review 和 p90_minutes_ready_to_first_review：从拉取请求变为可供审查到其首次审查的时间。
• median_minutes_first_to_final_review 和 p90_minutes_first_to_final_review：首次审查和最终审查之间的时间。
• median_minutes_final_review_to_merge 和 p90_minutes_final_review_to_merge：从最终审查到合并的时间。

时长以分钟为单位，并归属于拉取请求合并的日期。现有的 pull_requests 字段保持不变。

团队已经可以看到拉取请求何时需要很长时间才能合并，但看不到时间花在哪里。将等待时间拆分为三个阶段，可以显示拉取请求是在等待有人查看、在等待审查者之间来回沟通，还是已经批准但未合并。其中每一种都指向不同的修复方法，而中位数旁边的第 90 百分位数显示少数慢速拉取请求何时在推动延迟。

可用性：存在于企业和组织 repos-1-day 报告中。

计数内容：由一个人打开且至少另一个人审查过的拉取请求。仅人类审查被计时。来自 Copilot 代码审查、其他机器人和作者的审查被忽略，因此由一个人和 Copilot 代码审查共同审查的拉取请求仍会被包含。因此，pull_request_review_times[].total_merged 通常低于 pull_requests.total_merged，后者还计入没有任何审查就合并的拉取请求。

无回填：数据从发布日期开始向前构建，因此早期数据会很少。在 2026 年 9 月 21 日之前变为可供审查的拉取请求不在此部分中，但仍计入 pull_requests.total_merged。

GitHub 企业与组织级 Copilot 使用指标报告新增 pull_request_review_times，按 PR 从可审查到首次审查、首次到最终审查、最终审查到合并三阶段提供中位数和 P90 耗时，仅统计人类评审，且不做历史回填。

• GitHub 企业与组织级 Copilot 使用指标报告新增 pull_request_review_times，按 PR 从可审查到首次审查、首次到最终审查、最终审查到合并三阶段提供中位数和 P90 耗时，仅统计人类评审，且不做历史回填。
• 原贴提到：The enterprise and organization repository-level Copilot usage metrics r
• 来源：github.blog

这是什么信号：GitHub 在企业与组织级 Copilot 使用指标报告里，把 PR 合并前的审查等待拆成可观测的三段：从 ready for review 到首次审查、首次审查到最终审查、最终审查到合并；每个 repos-1-day 行新增 pull_request_review_times 数组，并给出中位数和 P90。统计口径也很关键：只统计人类发起的 PR 和至少一个其他人的人类审查，Copilot code review、其他机器人、作者本人的审查不计时；但一个 PR 同时被人和 Copilot code review 审过，仍然算数。这意味着指标试图度量人类协作瓶颈，而不是把机器审查混进去。

为什么重要：过去团队只能看到 PR 从创建到合并很慢，却不知道慢在等待首个 reviewer、评审往返，还是批准后没人合并。三阶段拆分后，每一段对应不同修复动作：首次审查慢可能需要 reviewer 轮值或 SLA；首次到最终审查慢可能说明 PR 太大、评审意见反复；最终审查到合并慢则可能是合并窗口、发布冻结或作者未跟进。P90 与中位数并列，能识别长尾：当少数 PR 拖慢整体时，平均值和中位数可能看不出来。对已经部署 Copilot 的企业来说，这提供了一个把 AI 生成代码与人类评审流程分开看的指标基础。

对谁有价值：企业 Copilot 管理员、平台工程团队、DevEx/研发效能团队、工程经理和负责代码审查流程的 TL。只要组织使用企业或组织级 repos-1-day 报告，就可以把 pull_request_review_times 纳入现有效能看板。对推广 AI 编程工具的组织，这个字段能帮助回答“Copilot 是否只加快了写代码，但没有改善端到端交付”。

可以怎么行动：第一，在 repos-1-day 报告中拉取 pull_request_review_times，按仓库、团队、authored_by/reviewed_by 组合建立中位数与 P90 基线。第二，针对三个阶段分别设阈值和告警：ready 到首次审查、首次到最终审查、最终审查到合并。第三，把异常 PR 作为复盘输入，而不是直接考核个人；重点看 PR 大小、reviewer 负载、跨时区、发布窗口等系统因素。第四，注意 total_merged 通常低于 pull_requests.total_merged，因为后者还包含无审查合并的 PR；做比率时不要混用分母。第五，由于没有回填，刚上线时早期数据很薄，P90 在小样本下波动大，建议积累几周后再做趋势判断。

风险或限制：该数据无历史回填，从发布日期向前构建；2026 年 9 月 21 日之前变为可供审查的 PR 不进入此部分，但仍计入 pull_requests.total_merged。仅人类审查被计时，因此不能直接衡量 Copilot code review 或机器人审查的效率。耗时按合并日归因，可能把等待时间集中到合并当天，受合并策略影响。按 authored_by/reviewed_by 分组可能产生很多稀疏组合，容易在样本不足时误读。最后，它度量的是审查阶段耗时，不直接等于代码质量或开发者体验，需要结合缺陷、返工和满意度数据一起看。

这条内容的真正价值，不只是“有人发布了一个新功能”，而是它揭示了 github.blog 背后的产品方向、工作流变化或竞争信号。对 OPC 来说，这种信息可以转化成持续追踪的栏目选题。

如果把《使用指标 API 新增拉取请求审查阶段》放到你的内容系统里，它最大的价值在于帮助读者更快看懂“为什么值得关注”，而不是只看到一条碎片化动态。

• Allison 原帖