四成 PR 先由 agent 起草：Octoverse 2026 的数字说明了什么、没说明什么

一句话：写代码的起点变了，审代码的活变重了

GitHub 在 2026 年 10 月 28 日发布的 Octoverse 2026 年度报告里，给出了一个值得所有写代码的人停下来想一想的数字：到了 2026 年 9 月，GitHub 上超过四成的拉取请求（Pull Request，简称 PR）是由 agent 起草第一版的，而 3 月时这个比例还是 17%。短短半年，agent 从“偶尔帮忙写一段”变成了“很多活儿的起草人”。

这份报告统计的是 2025 年 10 月 1 日到 2026 年 9 月 30 日这一整年的平台数据，覆盖公开和私有仓库。它的分量不在于某一个数字有多大，而在于一整套数字指向同一个方向：开发者的工作正在从“自己一行行写”转向“给 agent 定方向、再审它交回来的东西”。这篇文章先把报告里最关键的数字讲清楚，再讲这些数字对普通开发者和 vibe coding 的人到底意味着什么，以及哪些结论不能乱下。

核心数字：四成、1.1 亿、六倍

先说最核心的三个数字。第一，2026 年 9 月，超过 40% 的 PR 由 agent 起草第一版，3 月是 17%。第二，只算 9 月这一个月，agent 起草的 PR 就有 1.1 亿个，差不多是 3 月的六倍。第三，agent 起草的 PR 更常改多个文件：约 87% 会动到多个文件，而没有检测到 agent 参与的 PR 里这个比例是 79%。

这三个数字要连起来读才有意思。四成说的是比例，1.1 亿说的是体量，六倍说的是速度。半年时间里，agent 起草的量翻了六倍，这不是某个团队的个别现象，而是整个平台一起拐弯。GitHub 在报告里还提到，平台活动的加速大约从 6 月开始：更好的模型、更成熟的 agent 工具、云端执行铺开，几件事撞在了一起。

还有一个容易被忽略的细节：GitHub 统计的是“能检测到的 agent 参与”。也就是说，这个四成是按“第一版草稿来自能被检测到的 agent”来算的。检测不到的 agent 不在里面，所以 GitHub 自己也把这个数字说成是一个下限，而不是精确值。真实的比例只会更高，不会更低。读报告的时候记住这一点，后面很多判断都要打这个折扣。

合并不等于写得好：先看合并速度，再看质量缺口

报告里另一组数字经常被拿来当“agent 写得更好”的证据，但其实它证明的只是“合得更快”。2026 年 2 月，agent 参与的 PR 里有 83% 能在两周内合并，略低于没有 agent 参与的约 86%；到了 9 月，agent 参与的 PR 两周内合并率升到了 90%，而另一组还停在约 86% 附近。

合并快说明流程顺，不说明代码对。合并率衡量的是“多久能进主分支”，不是“上线之后出不出 bug”。报告里没有公布 agent 代码的回滚率、缺陷率或者线上故障率，所以任何人拿“合得更快”来论证“写得更好”，都是在数字之外加了自己的想象。审 PR 的人应该把这两件事分开：流程变快了是好事，但质量还得用测试、评审和线上表现来验证。

与此同时，agent 起草的 PR 更常改多个文件，这对评审来说是个负担。改动的文件越多，评审要看的上下文就越多，漏掉问题的概率也越大。报告里也提到了应对这个趋势的工具：把相关改动拆成一串小 PR 的 Stacked PR 在 7 月 30 日推出预览，到 9 月已经有超过 26.4 万名开发者用过；AI 辅助代码评审和 GitHub 高级安全功能的使用量同比都增长了 90% 以上。平台在补评审的工具，说明平台自己也知道，瓶颈已经从“写不出来”移到了“审不过来”。

平台全年的体量：不只是 PR 在涨

只盯着 PR 会低估这场变化的规模。报告统计的这一年里，开发者向 GitHub 推送了 179 亿次，比 2024 年和 2025 年两年加起来还多；提交总数达到 343 亿次，是两年前的三倍多；合并的 PR 达到 13 亿个，平均每天 350 万个；GitHub Actions 一年跑了 454 亿个任务，平均每秒 1440 个。

这些数字放在一起，画出的是一张“量变”的图：代码的产出速度在全面加快，而 agent 只是其中一个加速器。报告里还有一个对照很有意思：在今年新建的仓库里，带有 agent 配置文件的仓库，平均提交量是没有 agent 配置文件的仓库的八倍。这个对照不能直接证明“配置文件导致了高产出”，因为愿意配 agent 的团队本来就可能更活跃，但它至少说明了一点：从第一天就按 agent 协作来搭架子的团队，跑出来的节奏完全不一样。

人的规模也在涨。GitHub 现在服务的开发者超过 2.25 亿，美国 3830 万、印度 3200 万，仍然是最大的两个开发者社区，今年各自都增加了超过 1000 万人。公开贡献在 2026 年达到 25 亿次，是去年的两倍多。这些数字提醒我们：agent 的故事不是“机器取代人”，而是“更多人在用机器干活”。

模型选择也在变：没人只用一个模型了

报告里关于模型选择的部分，对每天挑模型的人很有参考价值。2026 年 9 月，在自己选模型的 Copilot 用户里，61% 在一个月里用了不止一个模型，比四个月前多了不少；付费用户在 9 月一共用了 47 个不同的模型，5 月还是 29 个；没有任何一个模型能占到当月请求的四分之一以上。

这说明“选一个最好用的模型然后一直用它”的时代已经过去了。开发者在按任务分模型：有的任务要深度推理和规划，有的任务要通用能力，有的任务要快而轻。报告把请求按模型用途分成三类：通用型占 38%，深度推理和规划型占 37%，快速轻量型占 25%，三类都有人用，而且很少有人长期只守着一类。

对 vibe coding 的人来说，这个趋势的实际意义是：别再纠结“哪个模型最强”这种笼统的问题，改问“这个任务适合哪类模型”。写个小工具和重构一座老系统，根本不是同一种任务，用同一个模型硬扛，等于拿一把刀切所有的菜。报告里还提到，63% 的付费 Copilot 用户在 9 月至少用过一次自动选模型。这和本站 10 月 28 日报道的 Copilot Fusion 是同一条线：系统帮你按步骤挑模型，你只定努力程度。只不过那篇讲的是功能上线，这篇讲的是全平台的数据，两者互为印证。

语言版图：TypeScript、Python、Rust 领跑

报告还给出了语言方面的变化。按贡献者数量算，TypeScript 仍然排第一，Python 第二，JavaScript 第三。从 2025 年 9 月到 2026 年 9 月，TypeScript 每月新增贡献者 362 万，Python 323 万，JavaScript 182 万，是前十名里增长最多的三个。按百分比算，Rust 增长最快，过去一年翻了一倍。

更有意思的是语言和 AI 参与度的关系。在增长最快的几个语言社区里，合并 PR 中检测到 AI 参与的比例也最高：TypeScript 约 44%，Python 约 41%，Rust 约 40%。而 Java、 C#、C++ 这类语言虽然低一些，也都在两成以上。报告还提到一个耐人寻味的现象：在今年新建的仓库里，TypeScript 是 35% 带有 agent 信号的仓库的主要语言，而在没有 agent 信号的仓库里只有 24%。

这个现象有两种读法。一种是“用 agent 的人更爱用 TypeScript”，另一种是“agent 自己更爱写 TypeScript”，因为类型信息让 agent 的输出更容易检查。报告倾向于后一种解释：当开发者不指定语言时，agent 似乎会偏向那些输出更容易检查的语言。这对 vibe coding 的人是个实用提醒：如果你让 agent 自由发挥，它大概率会给你 TypeScript；如果你有别的语言偏好，最好在开始就明确说出来，而不是等它写完再改。

对普通开发者的四个实际影响

第一，评审能力成了新的核心能力。以前一个人一天能写多少代码，决定了他一天能干多少活；现在 agent 一天能起草的量远远超过一个人能审的量，瓶颈卡在了评审上。会拆 PR、会写清楚的评审意见、会用测试卡住质量的人，会比只会写代码的人更值钱。这不是说写代码不重要了，而是说“写”的部分被分摊了，“审”的部分被放大了。

第二，PR 要越拆越小。agent 天生爱一次改很多文件，87% 这个数字就是证据。如果放任它一次交几十个文件的改动，评审只能走马观花，最后等于没审。实用的做法是：让 agent 按功能拆成一串小 PR，或者用 Stacked PR 这类工具把相关改动排成顺序；每个 PR 只讲一件事，标题和描述写清楚改了什么、为什么改、怎么测。

第三，测试和验收标准要先于代码定下来。agent 起草的第一版常常“看起来能跑”，但边角情况、异常路径、数据迁移这些地方最容易藏问题。让 agent 动手之前，先把验收标准写清楚：哪些情况必须通过测试、哪些接口不能改、回滚怎么做。这比事后逐行挑毛病省事得多，也符合本站之前多篇指南反复讲的道理：给 agent 的指令越具体，返工越少。

第四，别被“四成”这个数字吓到，也别被它忽悠到。吓到的人会觉得“再不学 agent 就要被淘汰”，其实报告说的是“起草”，不是“独立完成并负责”。忽悠到的人会觉得“以后都不用自己写了”，其实合并、负责、上线兜底的还是人。GitHub 在报告结尾也写了同样的话：决定代码该做什么、能不能用、好不好的人，仍然是开发者。工具变了，责任没变。

对 vibe coding 的人的特别提醒

vibe coding 的人比传统开发者更依赖 agent 起草，所以这份报告对他们的影响也更直接。有三点值得单独说。

第一，你的项目从第一天起就该有 agent 配置文件。报告里带 agent 配置文件的仓库提交量是八倍，这个数字不能当因果关系来读，但它至少说明了一个习惯：把 agent 的工作方式、规范和边界写进仓库，比每次现想现说要高效得多。配置文件就是给 agent 的长期记忆，别只依赖聊天框里的临时指令。

第二，小项目也要有评审环节，哪怕评审的人就是你自己。一个人加一个 agent 的项目最容易跳过评审：反正代码是 agent 写的，看起来能跑就合并了。但 agent 一次改多个文件的倾向，在小项目里同样存在。给自己定一条规矩：每个 PR 至少跑一遍测试、至少看一遍改动文件列表、至少确认一次没有动到不该动的地方。这三条花不了五分钟，能拦住大部分低级问题。

第三，模型别只用一个，也别追着每一个新模型跑。报告里 47 个模型、61% 的人混用的数据说明，成熟的做法是按任务分模型：快活交给轻量模型，难活交给推理强的模型，日常活交给通用模型。同时也别被新模型的首周热度带跑：报告指出，新模型在头几周的请求份额往往高于尝试过它的人数比例，也就是说少数早期重度用户撑起了热度，等热度过去再看它是不是真的适合你，也不迟。

不能从这份报告里得出的三个结论

第一个不能得出的结论是“40% 的代码是 AI 写的”。报告统计的是 PR 的起草来源，不是代码行数。agent 起草的 PR 里有多少行最终留下来、有多少是人改过的，报告没有说。把“四成 PR 由 agent 起草”说成“四成代码是 AI 写的”，是偷换了统计口径。

第二个不能得出的结论是“agent 代码质量更高”。报告没有质量数据，只有合并速度和多文件比例。合并快可能是因为流程工具变好了，也可能是因为评审变松了，单看合并率分不出来。质量问题要看测试覆盖、回滚率和线上故障，这些都不在这份报告里。

第三个不能得出的结论是“开发者要变少了”。报告恰恰相反：开发者总数超过 2.25 亿，还在快速增长；公开贡献翻倍；更多行业、更多国家的人在加入。agent 让更多人能动手做东西，而不是让动手的人变少。真正变少的是“从零手写每一行”的工作量，变多的是“定方向、审结果、负责任”的工作量。

和本站已发的 Copilot 新闻怎么区分

10 月 28 日前后本站发了好几篇 GitHub 的消息，容易混淆，这里划一下界。Copilot Fusion 那篇讲的是模型路由功能上线，Copilot Projects 那篇讲的是跨仓库协作功能，代码评审 Max 那篇讲的是评审功能升级，企业版含 Copilot 那篇讲的是计费模式变化。而本篇讲的不是某个功能，而是一份年度数据报告：它用全平台一年的数据回答“开发者实际在怎么用 agent”这个问题。功能新闻告诉你“能用什么”，数据报告告诉你“大家实际在怎么用”，两者角度不同，互不重复。

如果你是想挑工具的人，先看功能新闻；如果你是想判断趋势、决定团队工作方式的人，本篇的数据更有参考价值。把两者分开读，就不会把“某个功能上线了”和“某种用法已经普及了”混为一谈。

明年再看这份报告时，该盯哪几个数字

年度报告的价值不只在今年的数字，还在它给了明年一个对照的起点。如果明年再读 Octoverse，有四个数字最值得对比着看。第一，agent 起草的比例还会不会继续往上走，还是会在某个位置稳住；第二，两周内合并率和多文件比例有没有跟着变，这能看出评审是跟上了还是被拖垮了；第三，混用多个模型的人是不是越来越多，这能看出模型选择会不会彻底变成平台的事；第四，带 agent 配置文件的新仓库占比有没有继续扩大，这能看出“从第一天就按 agent 协作搭架子”是不是已经成了默认做法。把今年的数字记下来，明年对照着看，比今年空谈趋势要实在得多。

结尾的判断：起草权交出去了，决定权还在人手里

这份报告最值得记住的，其实不是四成这个数字，而是它背后的分工变化：起草的活越来越多地交给 agent，判断的活越来越多地留给人。起草可以批量做，判断不能批量做；起草错了可以重写，判断错了可能上线才发现。这个不对称，就是未来几年开发者工作的真实形状。

对个人来说，值得投资的能力正在从“写得快”转向“看得准”：看得准 agent 交回来的东西对不对、够不够、全不全。对团队来说，值得投资的流程正在从“怎么写代码”转向“怎么评审、怎么拆 PR、怎么定验收标准”。这些能力不像新模型那样每个月换代，但它们决定了你用 agent 是省时间还是返工。

最后回到报告里那句最朴素的话：工具会一直变，新行业会一直冒出来，但“做什么、为谁做、做得好不好”仍然是开发者自己的决定。agent 可以起草四成的 PR，但它不能替你决定这四成 PR 该不该存在。这个决定权，就是开发者这个职业在 agent 时代剩下的、也是最重要的部分。