一句话看懂：GitHub 在 Copilot 用量指标 API 的企业级和组织级仓库报告中新增了 pull request 审查阶段拆解，把 PR 从“可审查”到合并的等待时间切成三段，并同时给出中位数和第 90 百分位。这让团队第一次能看出延迟卡在哪一步，而不是只知道合并慢。
事件核心：发生了什么
2026 年 9 月 25 日，GitHub 在 Changelog 中宣布，企业级和组织级的仓库 Copilot 用量指标报告新增 pull_request_review_times 数组，挂在每条 repos-1-day 记录下。它按天统计三类时间：PR 从 ready for review 到第一次审查、从第一次审查到最终审查、从最终审查到合并，每段都给出中位数和 p90 分钟数，并附带 authored_by、reviewed_by 和当日合并数 total_merged。本次发布中，作者和审查者均限定为人类；Copilot code review 和其他机器人的审查不计入时长。数据从发布日起向前累积，不回溯 2026 年 9 月 21 日之前进入待审查状态的 PR。
为什么重要
此前团队只能看到 PR 合并总耗时，却看不到时间花在哪。拆成三段后，问题指向变得具体：如果卡在 ready 到首次审查，说明缺少审查人力或分派机制失灵；卡在首次到最终审查，说明评审往返过多或意见分歧大；卡在最终审查到合并，则更像审批流程、CI 流水线或发布窗口的问题。p90 与中位数并列，还能判断延迟是普遍现象，还是少数长尾 PR 拉高了平均值。对正在把 Copilot 引入研发流程的企业来说，这也是把 AI 编码工具与工程效能指标挂钩的一步——AI 写代码变快之后，瓶颈是否转移到了人工审查环节，这套数据给出了可量化的观察口径。
对用户/开发者/创作者的影响
对开发者个人，这些指标不会直接改变写代码的方式，但会间接影响团队对审查节奏的管理，例如是否引入更明确的分派规则或限制 PR 体积。对企业管理者和平台团队，API 层面的结构化字段意味着可以把 PR 审查时长接入内部 BI 或研发效能看板，与 Copilot 用量、代码产出等数据做关联分析。需要注意的是，统计口径只覆盖“由人创建且至少被另一人审查”的 PR，因此 pull_request_review_times 里的 total_merged 通常低于 pull_requests.total_merged；没有审查直接合并的 PR 不计入这一新板块。访问权限限于企业所有者、账单管理员、组织所有者，以及被授予 View Copilot Metrics 权限的自定义角色，且需启用 Copilot 用量指标策略。
AI 工具推荐
想把多个 AI 模型放在一个入口？
GamsGo AI 集成 ChatGPT、DeepSeek、Gemini、Claude、Midjourney、Veo 等常用模型，适合写作、绘图、视频和日常 AI 工作流。
推广链接：通过此链接购买，我可能获得佣金，不影响你的价格。
值得关注的后续
三点可以观察：一是 GitHub 是否会把机器人审查、Copilot code review 纳入统计或单独拆列，目前公开信息显示仅计时人类审查；二是数据积累一段时间后，是否会出现公开的行业基准值，供企业横向比较；三是竞品 GitLab、Bitbucket 等是否跟进类似的审查阶段指标，把 PR 流程可观测性变成代码托管平台的标配能力。
