GitHub用量API新增PR评审阶段耗时：当前计时只覆盖符合条件的人工评审

10-01 4阅读

2026 年 9 月 25 日，GitHub 为企业和组织的仓库级 Copilot 用量报告增加 PR 评审阶段耗时。新数据可以帮助区分等待首次评审、评审往返和评审结束后等待合并。但它并不是一个覆盖所有 PR 的完整工时表，更不能直接用来评价某个开发者。

配图为 AI 生成的概念示意图，并非产品截图或真实活动照片。

三个阶段和统计口径

新增的 pull_request_review_times 位于 repos-1-day 报告中，分别提供就绪到首次评审、首次到最终评审、最终评审到合并的中位数与 P90，单位为分钟，归到 PR 合并当天。

当前只对人创建、且由至少另一人评审的 PR 计时；机器人及作者自己的评审被忽略。无符合条件的合并时，数组为空；仅一次评审时，中间阶段可以为零。数据不回填，9 月 21 日前已就绪的 PR 不在新增部分内。读取还取决于相应权限与用量指标策略。

以下是假设读数：某仓库一天的数组为空，第二天中间阶段是零，第三天 P90 很高。第一种情况不能自动填成“大家当天零等待”；第二种可能是一次评审完成；第三种需要进一步查看样本量和具体 PR，不能只凭图上的尖峰判断流程退步。

日期归到合并日，也意味着某天看到的时长可能来自此前开始的工作。若用每日曲线研究团队负荷，最好同时记下节假日、值班安排和版本冻结窗口。它们是解释背景，不应该偷偷改写原始口径。

本文建议先问一个小问题，例如首次评审排队是否变长，再选择一段可比时间，检查合并量和 PR 类型是否接近。把文档小改动与大型迁移直接混在一起比较，可能把任务构成变化误写成协作效率变化。

发现某阶段变慢后，再抽样阅读相关讨论，确认是缺少评审人、需要补充说明，还是等待发布窗口。先定位可改变的流程，再观察调整后的同口径数据。新字段增加了定位线索，因果判断仍需要真实工作记录支持。

主要来源：GitHub：Usage metrics API adds pull request review stages（2026-09-25）。本文于北京时间 2026 年 10 月 1 日核验；产品开放范围仍以官方后续更新为准。