一句话定位：这不是"提交多了好不好"，而是"这些数字统计的还是不是原来那件事"——被测对象是指标的口径与分母，不是数量本身。同样的口径检查可迁移到缺陷率统计、自动化覆盖率、告警有效率、工单结案率等任何"量涨了但含义变了"的场景。

摘要

GitHub 在 Octoverse 2026 与配套工程博客中公布了一组数字：9 月单月提交 73.8 亿次，同比增长五倍多；推送增长 4.9 倍；9 月超过 40% 的 PR 由 Agent 起稿，其中约 87% 一次改动多个文件。这些数字落到质量报告里，会立刻遇到口径问题。这篇讲清四个最容易失真的指标，以及在该换什么指标上去。

2026 年 9 月，GitHub 上出现了 73.8 亿次提交，比一年前多五倍以上。同一个月，推送次数是 33.5 亿次，同比增长 4.9 倍。

这两个数字放在一起，第一个反应应该是"口径问题"。提交在本地就能产生，推送才真正到达服务端。提交涨得快于推送，说明每次推送里装的提交变多了。GitHub 工程师在官方工程博客里的解释是：Agent 在紧凑循环里几乎每做一个动作就提交或打一次检查点，它的速度受限于单次推送完成的速度。

这句话对做质量度量的人是一记提醒：提交数不再是一个人的产出信号，它是一个运行次数信号。

这篇要处理的问题是：当生产代码的主体从人换成 Agent，质量周报里哪些指标会先失真，以及替代它们的是什么。

指标一：提交数。它已经不能代表进展

官方给了一个很能说明性质的对照：今年新建的仓库里，有 Agent 配置文件的仓库，平均提交数是同批次没有配置文件仓库的八倍。

八倍这个数字在传播中很容易被读成"用了 Agent 效率高八倍"。但原文的表述是"移动速度明显不同"，说的是节奏，不是产出价值。一个每步都提交的运行，天然会产生八倍于人工提交的记录，这跟这些提交里有多少被合并、被保留、被证明正确，是两件事。

所以提交数作为效能指标已经失效，但它作为运行频次指标反而有价值。它能告诉你团队里有多少工作是由 Agent 驱动的、CI 的压力来自哪里。用错了地方是失真，用对了地方是信号。

指标二：PR 数量。增长最快，但含义变了

官方数据：到 9 月，超过 40% 的 PR 由 Agent 起稿，3 月是 17%；9 月单月 1.1 亿个，约为 3 月的六倍。其中约 87% 的 Agent 起稿 PR 一次改动多个文件，而无 Agent 参与的 PR 是 79%。

这组数字的关键在最后一项。多文件改动意味着审查者要跨文件重建上下文，审查成本不是线性增加的。而 PR 总量涨了六倍，审查能力不可能涨六倍。

于是瓶颈位置发生了转移。以前 PR 数量少、审查能力富余，问题在"写得对不对"；现在 PR 数量涨、审查能力不变，问题变成"哪些 PR 值得审"。原文对这个转变有一句概括性的表述：审查是开发者塑造产出形态的地方，围绕它的工具正在增多。

对质量报告的含义是：PR 数量和合并速度不能同时作为正向指标。 当 40% 以上的 PR 由 Agent 起稿，合并速度快很可能意味着审查被压缩，而不是效率提升。这时候该看的指标是"合并后被回滚或事后修补的比例"，而不是"从提交到合并的时长"。

指标三：CI 通过率。分母已经被污染

官方工程博客提到，这一年内 Actions 的运行量增长到 45.4B（2024 年为 8.0B，2025 年为 14.0B）；Octoverse 的表述是每秒运行 1440 次作业，相当于每天 1.24 亿次，超过去年总量的三倍。

CI 通过率作为质量指标，前提是"跑的都是值得跑的检查"。当 Agent 每步都提交、每次都触发流水线，分母里就混进了大量"只是为了记一个检查点"的运行。这些运行失败率高、意义低，会把整体通过率拉下来，让团队误以为质量在恶化。

正确的做法是把 CI 指标拆成两类：门禁型运行（合并前必须通过的那次）和探索型运行（Agent 迭代过程中的中间运行）。前者的通过率才反映质量，后者的通过率更接近"Agent 一次做对的比例"，是另一个维度的事。

这个拆分在实际操作里不难：看触发来源和分支类型就能区分。难的是承认它们不该合并成一个数字。很多团队的周报里只有一个"CI 通过率"，一旦 Agent 大规模接入，这个数字会先跌后升，然后所有人都不知道它在说什么。

指标四：代码覆盖率。它测的是被执行，不是被理解

覆盖率在这套结构下有一个更隐蔽的失真方式。Agent 写代码时也会写测试，测试和实现出自同一个上下文，很容易出现"为了让它通过而写的测试"。覆盖率上升，但断言的强度没有上升。

原文在基础设施部分提到的一条原则可以作为判断依据：代码的所有者仍然要能审查、理解并批准它。这句原则的落点是"理解"，而覆盖率从来不测理解。

我在实际项目里用的替代指标是"变更隔离度"：一次改动如果失败，能不能在 10 分钟内定位到具体哪一处逻辑。这个指标可以直接从回滚和修复的实际耗时里统计，比覆盖率诚实得多。

平台侧的压力，会以"不稳定"的形式转嫁给测试团队

原文还有一层跟测试团队直接相关：基础设施已经成为瓶颈。

官方工程博客的描述是：每个仓库默认在多个文件服务器上保留五份完整副本，用于冗余和分摊读压力；但每份副本都参与每一次写入，所以一次推送的速度取决于这一组里最慢的那一份。结论很直接——增加副本以分摊读负载，会让写入变慢。

合并侧的压力更集中：主干开发、发布列车和合并队列把所有工作汇聚到同一个引用上，需要吸收每一次合并；成千上万个 Agent 在各自分支上工作，产生的持续写入速率会收敛到架构上的同一个点。

这两段话解释了为什么"平台偶发不稳定"会变成测试团队的日常。当写入变慢、合并排队变长，测试任务会超时、合并队列会积压、无人值守的流水线会在半夜挂掉。这些在测试报告里表现为"环境不稳定"“偶发失败”，但根因不在测试代码。

原文给出的架构方向是将计算与存储分离，内部基准显示最高可带来 35 倍的写入吞吐提升。这是官方基准，不是线上成绩。

对测试团队的实际动作是两条：第一，把"环境原因导致的失败"单独归类，不要混进 flaky 统计，否则你会花大量时间去修不存在的测试问题；第二，给自己的 CI 加预算意识，每次提交都触发全量构建，在 Agent 高频提交的节奏下会迅速吃满配额。

该换成什么指标

把上面四条合起来，我建议的质量报告结构如下。

原指标	失真原因	建议替代	取数方式
提交数	每个动作都提交，反映运行频次而非产出	有效变更率（合并进主干的比例）	周窗口内合并提交/全部提交
PR 数量	Agent 批量起稿，量增不代表价值增	合并后回滚率、事后修补率	回滚记录关联 PR
CI 通过率	探索型运行混入分母	门禁型通过率 + Agent 一次通过率	按触发来源拆分
代码覆盖率	测试与实现同源生成	变更隔离度（失败定位耗时）	回滚与修复计时

这张表不完美，但它有一个优点：每个指标都能在一周窗口内自己算出来，不需要等平台给数据。原文提到的"四个数字可横向比较"的口径意识，在这里同样适用——同一张表里的数字必须同窗口、同口径，否则比较毫无意义。

最后提醒一句容易被忽略的事。原文在讲架构压力时，落点不在吞吐，而在人：代码的所有者仍然要能审查、理解并批准。这句话的意思是，当所有可自动化的部分都被自动化之后，剩下的人工环节会变得更稀缺，也更贵。

还有一个判断层面的问题值得提前想清楚。当提交、PR、CI 运行的绝对数量都在成倍增长时，质量报告最容易犯的错是把"量"的增长当成"质"的变化。两个团队用同一套指标，一个团队的 Agent 覆盖率高、一个低，周报上的数字差异可能全部来自工作方式的差异，而不是质量差异。

所以我在写报告时会给每个指标加一行"本数字的解释边界"。比如"PR 数量：反映工作尝试次数，不反映交付价值"“CI 通过率：仅统计合并前的门禁运行”。这一行不增加任何工作量，但它能挡住大部分误读——包括你自己在三个月后回看时的误读。

质量报告最终要回答的不是"我们产出了多少"，而是"我们对产出的东西理解多少"。

本文部分内容参考了霍格沃兹测试开发学社整理的相关技术资料，主要涉及软件测试、自动化测试、测试开发及 AI 测试等内容，侧重测试实践、工具应用与工程经验整理。