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


![image.png](https://developer.qcloudimg.com/http-save/yehe-9678105/5af37a3525934e8adc6b3aac1398c8dc.png)



## 摘要

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，质量周报里哪些指标会先失真，以及替代它们的是什么。

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

![image.png](https://developer.qcloudimg.com/http-save/yehe-9678105/c001ce63d2fb97aa4c21899ce7819903.png)




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

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

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

![image.png](https://developer.qcloudimg.com/http-save/yehe-9678105/491a2ab9f14922ecf92e6359783ceb5d.png)

### 指标二：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 大规模接入，这个数字会先跌后升，然后所有人都不知道它在说什么。

![image.png](https://developer.qcloudimg.com/http-save/yehe-9678105/58371cddd2fcf2a5dd16ccdd6a7e2196.png)


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

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

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

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

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

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

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

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

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

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

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

### 该换成什么指标

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

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

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


![image.png](https://developer.qcloudimg.com/http-save/yehe-9678105/3ef4fe431313642bf1d5bdd767eb3d46.png)


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

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

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

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


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

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

GitHub 一个月 73.8 亿次提交：质量周报里哪个指标先失真

测试

开发工具

人工智能

GitHub 2026年9月提交量激增5倍至73.8亿次，其中Agent主导超40% PR，传统质量指标严重失真。本文解析提交数、PR量、CI通过率、覆盖率四大失真指标，提供替代方案：有效变更率、回滚率、门禁型通过率、变更隔离度，帮助团队在AI驱动开发下重建真实效能度量。

软件测试

服务器

GitHub

Agent

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

GitHub 一个月 73.8 亿次提交：质量周报里哪个指标先失真-腾讯云开发者社区-腾讯云

GitHub 一个月 73.8 亿次提交：质量周报里哪个指标先失真

GitHub 一个月 73.8 亿次提交：质量周报里哪个指标先失真

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐