GitHub 上四成 PR 由智能体起草，半年前是 17%

在 GitHub 上，一次代码改动的第一稿越来越多出自智能体。据 GitHub 10 月 28 日发布的 Octoverse 年度报告，到 9 月，平台上超过 40% 的拉取请求由智能体起草，3 月时是 17%。拉取请求简称 PR，是开发者提交改动、请人审查后合并的基本单位。

读者最想问的是：智能体写得这么多，代码靠得住吗，人审得过来吗？暂时的答案是，GitHub 给出的数字只能证明智能体写得多、合得快；质量要看回滚和缺陷，报告没有给。GitHub 同一天推出的，是更多用 AI 做审查的工具，和按用量付费的企业套餐。

9 月约 1.1 亿个 PR 先由智能体起草

报告把「智能体起草的 PR」定义为第一稿来自 GitHub 能检测到的编程智能体的 PR，并说明这类信号是下限，因为有的智能体用法检测不到。按这个定义，报告给了几组数：

• 9 月由智能体起草的 PR 约 1.1 亿个，约为 3 月的 6 倍。
• 约 87% 的这类 PR 改动不止一个文件，未检测到智能体参与的 PR 是 79%。
• Copilot 月活用户里 55% 用上了智能体功能，一年前是 35%。
• 布置任务后由智能体独立完成的云端智能体，用量同比增长 230%，智能体对话增长 85%。

报告称，全平台活动在 6 月前后明显加速，那时智能体开始跨多天追踪进度，并大量在云端运行。GitHub 没有把增长归到单一原因上。

两周内合并率升到 90%，回滚数没有公布

报告用来说明质量的，是合并速度。2 月，有智能体参与的 PR 有 83% 在两周内合并，未检测到智能体参与的约为 86%；到 9 月，前者升到 90%，后者仍约 86%。

这组数有两处要读细。一是报告前面统计份额用的是「智能体起草」，这里用的是「智能体参与」，两个范围不一定相同。二是报告没写分母：是全部打开的 PR，还是最终合并的那部分。

两周内合并，衡量的是改动多快被接受。合并之后有没有被撤回、有没有引出新缺陷，报告没有给出智能体与对照组的对比。

有人会说，合并率高于对照组，说明审查者认可了这些代码。对此我们只接受一半：合并要经过人的批准，这一点成立；但下一节会看到，审查本身也越来越多交给 AI，人批准时看了多少，现有数字说明不了。

审查也在交给 AI，用量一年涨了九成

报告自己写道，审查是开发者塑造智能体产出的环节。它列出的审查工具数据是：

• 把一组相关改动拆成几个小 PR 依次审查的「堆叠 PR」，7 月 30 日开放预览，到 9 月已有超过 26.4 万名开发者用过。
• AI 辅助代码审查与 GitHub 高级安全功能的用量，同比都增长超过 90%。

在 Universe 大会上，Microsoft CoreAI 执行副总裁 Jay Parikh 在发布文章里写道，代码多了，PR 就多，审查需求也随之变大。

GitHub 为此推出 Copilot 代码审查的 Max 档，称它在 ReviewBench 的高危问题上取得了最高 F1 分数，这是 GitHub 的自述。Copilot 自动化还可以在云端做 issue 分拣和代码审查，并根据结果提出改进，交给人批准。

智能体写的 PR 越多，GitHub 给出的解法越是让另一个模型先审一遍。这是分析推断，依据是同一天发布的审查新档、自动化功能和报告里的审查用量数据。

企业不再单买 Copilot，按 AI 额度付费

同一篇文章宣布，GitHub Enterprise 客户即日起不必另买 Copilot 订阅，就能用 Copilot 应用、代码审查、自动化等全部功能，按实际用掉的 AI 额度付费。目前通过销售团队开通，自助开通稍后上线；现有 Copilot Business 和 Enterprise 客户可保留原套餐。

计费按用量走，选模型也交给平台。新推出的 Copilot Fusion 按推理、写代码、调试、调用工具等环节，替任务选一个或多个模型。成本说法有两个版本：

说法来源	对比对象	成本	耗时
Parikh 的发布文章	Claude Opus 5.5 Max	约一半	少 40%
Nadella 的领英帖	未点名，称达到前沿水平	最多低 77%	快 40%

后一条出自 The Next Web 的报道对 Microsoft CEO Satya Nadella 领英帖子的转述。两个数都是 Microsoft 自己的说法，比较对象不同，不能互相印证。

GitHub 今年还为平台加了 400 万个 CPU 核心、160 PB 高速存储和 50 Tb/s 网络带宽。对改用新方式的企业，智能体带来的 PR、审查和自动化任务会按额度计量，而不再藏在固定的席位费里。这是分析推断，依据是上述计费变化，GitHub 没有公布额度单价与典型用量。

能让这个判断改口的数字

我们的判断是：GitHub 证明了智能体已经是平台上的主要起草者之一，还没有证明它写的代码不比人差。

能让我们改口的，是三类目前没有公开的数据。一是智能体起草的 PR 合并后被回滚或引出缺陷的比例；二是四成这个比例的分母，是否包含私有仓库和机器人账户；三是企业改按额度付费后，平均每合并一个 PR 用掉多少额度。

如果 GitHub 在后续报告里公布了回滚率，且智能体起草的 PR 不高于对照组，那么「合得快」就能升级成「合得稳」。在那之前，企业更需要盯的，是审查环节里人还实际看了多少。