GitHub 9 月 25 日给企业版 Copilot 报告加了一项新指标：把一个 PR（合并请求，即开发者提交的代码改动）从「可以审查」到「合并」的整个等待时间，拆成三段分别计时，每段都给出中位数（P50，一半 PR 比这快一半比这慢）和第 90 百分位（P90，最慢那 10% 的水平）。我们注意到，这件事的意义不在「多一个数据」，而在它把过去那句笼统的「我们开发慢」，分解成了三种可以分别下药的问题。

这是什么

三段的切法很直接：

  • 第一段「标 Ready 到第一次有人审查」—— 测的是团队响应能力，可能问题在没人点开。
  • 第二段「第一次到最后一次审查」—— 测的是协作复杂度，包含了来回修改、补充测试、需求变更。
  • 第三段「最后一次审查通过到真正合并」—— 测的是发布与权限流程，往往是机器或制度在等，不是代码讨论。

关键限制要记一下：当前只统计由人创建、且至少被另一名人类审查后合并的 PR；Copilot 和其他机器人审查不计入。没有历史回填，9 月 21 日之前的数据不在统计内。

行业怎么看

GitHub 自己的判断是：这些指标是排队系统的症状，不是开发者绩效分。如果拿 P90 直接给个人排名，会鼓励快速点「批准」、把 PR 拆得毫无意义、甚至绕过审查——这种用法显然违背工具的设计初衷。

我们更在意另一个方法论陷阱：把多个仓库的 P90 简单平均，得不到整个组织的 P90。小仓库一条慢 PR 会和大仓库数百条 PR 权重相同，意味着你可能为一个无关紧要的小项目开了整整一周会。拿不到原始时长时，至少要按合并量加权，或者保留仓库维度分别看。

还有一层风险被原文点出但容易被忽略：审查变快不等于质量提升。回滚率、线上缺陷、二次修复这些「质量信号」必须和速度并排，否则容易把 CI（持续集成，即自动跑测试和构建的流水线）队列把人类等待伪装成「协作慢」这类问题掩盖过去。

对普通人的影响

对企业 IT：开了企业版 Copilot 的团队可以直接拉这个数据，按仓库和变更类型定位瓶颈——响应慢就配轮值审查人，协作慢就拆 PR，合并慢就改自动合并规则。比一句「开发慢」管用得多。

对个人职场：开发者短期内不会被这个数据直接打分，但要知道管理层能看到——审查响应慢会作为团队层面的问题被识别，而不是个人 KPI。

对消费市场：消费者层面无直接影响，但反映了一个行业趋势：AI 工具厂商正在补「效果衡量」这块短板，从「卖工具」走向「卖结果」。