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

使用指标 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 审查过程拆成了三段：从准备审查到首次审查、从首次审查到最终审查、从最终审查到合并。每一段同时给出中位数和 P90，并按 PR 合并日归因。这不是单纯加一个图表，而是把 AI 编码工具的度量口径推进到交付流程内部，让团队从只看到 PR 合并慢，走向看到慢在哪一段。

新数组只统计人工发起、且至少被另一位人工审查过的 PR。Copilot 代码审查、其他机器人以及作者本人的审查不计入计时。这意味着它与现有 pull_requests.total_merged 口径不同，后者还包含无审查合并的 PR，因此两个 total_merged 不能直接等同比较。

为什么重要

过去团队能看到 PR 合并总时长，却无法区分等待首次审查、评审者之间往返、已批准但未合并这三种完全不同的瓶颈。三段拆分把模糊的审查慢变成可归因的流程信号：等待首次审查可能指向排班和响应机制，评审往返可能指向 PR 大小、变更说明或评审标准，批准后未合并可能指向发布窗口、合并队列或所有权问题。

中位数旁边放 P90 也很关键。中位数代表常态体验，P90 代表长尾。若 P90 远高于中位数，往往说明少数 PR 拖累了整体交付，治理对象应是长尾而不是平均值。

对谁有价值

• 工程效能和研发平台团队：可以把三阶段耗时纳入度量看板，定位流程瓶颈。
• 工程经理和技术负责人：可以用团队级或仓库级数据讨论审查响应和合并机制，而不是停留在主观感受。
• Copilot 管理员和 AI 工具负责人：可以把 AI 编码使用指标与 PR 交付指标连接，评估工具是否真正改变工程流程。
• 平台与 DevOps 团队：可以据此检查合并队列、审查分配、发布窗口等制度设计。

可以怎么行动

1. 在企业或组织 repos-1-day 报告中拉取 pull_request_review_times，先为关键仓库建立三阶段基线和趋势。
2. 同时看中位数和 P90，把 P90 异常高的仓库、审查者配对或时间窗口作为优先排查对象。
3. 按瓶颈阶段设计不同实验：等待首次审查可用轮值或提醒，评审往返可用更小 PR 和评审规范，批准后未合并可检查合并队列与发布节奏。
4. 对比 pull_request_review_times[].total_merged 与 pull_requests.total_merged，理解无审查合并 PR 的影响，避免口径误读。
5. 把该指标当作系统改进信号，不直接用于个人绩效排名，防止指标被游戏化。

风险或限制

• 只统计人工审查，Copilot 代码审查和其他机器人审查不计时，因此不能完整反映 AI 参与审查后的真实流程。
• 数据无回填，从发布日开始向前积累；2026 年 9 月 21 日之前变为准备审查的 PR 不进入该段，早期数据会偏薄。
• 耗时按 PR 合并日归因，跨天等待会被归到合并日，可能影响日维度解读。
• P90 在样本量小的仓库或团队中波动较大，不宜单独下结论。
• 该指标衡量流程耗时，不等于代码质量、审查质量或业务价值，需要与其他指标结合。

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

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

• Allison 原帖