PR合并慢，别再只看平均时长：GitHub把等待拆成了三段
内容提要
GitHub 新增 PR 审查分段指标，将 PR 生命周期拆分为首次审查、反复修改、批准到合并三段，各提供中位数和 P90。该指标用于诊断流程瓶颈而非考核个人，应结合仓库维度、样本量和质量数据，一次只改一项流程并观察效果。
延伸解读
分段指标的口径限制
该指标只统计由人创建、且至少被另一名人类审查后合并的 PR，Copilot、机器人及作者自己的审查不计入。数据按合并日归属，9 月 21 日前进入 ready 状态的 PR 不纳入，且无历史回填。安静的一天返回空数组而非零。这些口径意味着早期样本可能很薄，解读时需注意覆盖范围。
P50 与 P90 的配合解读
中位数 P50 代表典型 PR，P90 代表最慢的一成。若 P50 短而 P90 长，说明多数流程正常，但某些仓库、时区或高风险改动缺少兜底；若两者都长，则更像系统性产能不足。同时观察两者，才能区分局部异常与整体瓶颈，避免被单一平均值误导。
避免误用为个人绩效
文章强调这些指标是排队系统的症状，不是开发者绩效分。用 P90 给个人排名，会鼓励快速点批准、拆无意义小 PR 甚至绕过审查。正确用法是按仓库和变更类型找瓶颈，再验证干预是否降低尾部等待。指标应服务于流程诊断，而非考核个人。
汇总与质量并重的注意事项
把多个仓库的 P90 简单平均得不到组织级 P90，小仓库的一条慢 PR 会获得与大仓库数百条 PR 相同权重。若拿不到原始时长，至少按 total_merged 加权并说明是近似值。同时应并排观察速度与质量，如回滚率、线上缺陷，避免审查变快但质量下降的无效改进。
Q&A
GitHub 新增的 PR 审查分段指标具体把 PR 生命周期拆成了哪三段？
拆成三段：从 ready for review 到第一次审查、第一次到最后一次审查、最后一次审查到合并。每段提供中位数和 P90，单位为分钟。
为什么不能只看 PR 合并的平均时长？
只看总时长会把三种不同问题混成一个数：可能是没人点开审查、修改来回拉扯，或批准后一直搁置。分段指标才能区分瓶颈所在。
PR 审查分段指标中，P50 和 P90 分别代表什么？为什么要同时看？
P50 是中位数，代表典型 PR；P90 是第 90 百分位，代表最慢的那一成。若 P50 短、P90 长，说明大多数流程没问题但某些仓库、时区或高风险改动缺少兜底；若两者都长，才更像系统性产能不足。
这些分段指标适合用来考核开发者个人绩效吗？
不适合。这些指标是排队系统的症状，不是开发者绩效分。拿 P90 给个人排名，会鼓励快速点“批准”、拆成没有意义的小 PR，甚至绕过审查。正确用法是按仓库和变更类型找瓶颈，再验证干预是否降低尾部等待。
针对三段指标分别可以采取哪些改进动作？
首次审查慢：设置代码所有者和轮值审查人，给高风险目录明确响应时限。首次到最终审查慢：查看 PR 尺寸、测试反馈速度和需求是否频繁变化。最终审查到合并慢：检查分支保护、部署窗口、必需检查和自动合并。
汇总多个仓库的 P90 时，为什么不能简单取平均？
把多个仓库的 P90 简单取平均，得不到整个组织的 P90：小仓库的一条慢 PR 会获得与大仓库数百条 PR 相同的权重。若拿不到原始时长，至少按 total_merged 做加权展示，并明确它仍是近似值；更稳妥的是保留仓库维度，分别观察趋势。
使用这套分段指标时有哪些风险或适用边界？
数据刚开始积累且没有回填，早期样本很薄；单次审查的 PR，“首次到最终”会是 0；total_merged 通常低于仓库全部合并数。小团队每日只有一两个 PR 时，按天的 P90 会剧烈跳动，至少应看四周滚动窗口，并同时保留样本数。这套指标适合诊断人类参与的审查流程，不适合衡量纯机器人 PR、未合并 PR 的积压，也不能直接证明 Copilot 提升了研发效率。
