2026 年 10 月 28 日，GitHub 发布年度 Octoverse 报告。今年最值得软件工程团队关注的不是开发者总数，而是一个流程指标：2026 年 9 月，超过 40% 的拉取请求由智能体起草，而 3 月这个比例还是 17%。当“第一笔”越来越多由智能体写下，评审与代码质量就成了新的瓶颈。
核心数字
过去 12 个月，开发者向 GitHub 推送代码 179 亿次，超过 2024 与 2025 两年之和；所有仓库类型的提交达到 343 亿次，是两年前的三倍多；合并的拉取请求超过 13 亿个，平均每天 350 万个。GitHub Actions 每秒运行 1440 个作业，折合每天 1.24 亿次，是去年的三倍多；合并的 Dependabot PR 超过 3000 万个，约为 2025 年的两倍。公共贡献达到 25 亿次，是去年 11.2 亿次的两倍多。
智能体起草的 PR
报告给出的智能体信号很明确：9 月由智能体起草的 PR 超过 40%，单月约 1.1 亿个，是 3 月数量的约 6 倍；在 2026 年新建仓库中，带智能体配置文件的仓库平均提交量是不带配置文件的 8 倍。智能体 PR 也更“重”：约 87% 改动多个文件，而没有检测到智能体参与的 PR 为 79%。
合并速度同样值得注意。2 月，智能体参与的 PR 在两周内合并的比例为 83%，略低于无智能体参与 PR 的约 86%；到 9 月，智能体 PR 升至 90%，对照组仍约 86%。这说明智能体不仅写得更多，也在更快通过评审。但“更快合并”不等于“更少缺陷”；报告没有给出缺陷率对照，团队不能把合并速度当作质量证明。
评审成为瓶颈
当生成速度提升，评审容量不会自动同步。报告提到，开发者开始用智能体完成第一稿，然后通过评审塑造结果；9 月有 61% 的 Copilot 用户使用不止一个模型，请求分布在通用、深度推理与规划、轻量快速三类。模型选择变多，意味着同一团队产出的代码风格与推理路径更分散，评审者需要更强的上下文来判断“为什么这样改”。
对软件工程实践，这意味着三件事需要重新设计。第一，PR 粒度：智能体倾向于一次改多个文件，团队应要求更小的可回滚变更，或在评审前自动拆分。第二，评审清单：把“是否引入新依赖”“是否覆盖异常路径”“是否有可复现测试”变成模板化检查，而不是依赖评审者记忆。第三，自动化测试：生成量上升会放大脆弱测试集的噪音，必须先修好测试稳定性，再扩大智能体使用范围。
开发者地理分布
GitHub 现在服务超过 2.25 亿开发者。美国 3830 万、印度 3200 万、中国 1240 万、巴西 1020 万、日本 715 万。美国与印度今年各新增超过 1000 万开发者。报告用 40 多个预测模型推算 2031 年：约一半认为开发者数量会增长三倍以上，略少于一半认为会翻倍到三倍，只有三个模型认为低于两倍。预测分歧本身说明 2026 年的增长斜率超出了历史模式。
自动化与依赖治理
Actions 作业量与 Dependabot 合并量的增长，说明自动化已经从“可选优化”变成默认流程。依赖更新自动化降低了已知漏洞的使用，但也带来评审疲劳：大量机械 PR 会挤占人类评审注意力。团队应把依赖更新按风险分级，低风险补丁走自动合并与灰度验证，高风险升级保留人工评审，避免把“自动化”变成“无人看”。
对团队的建议
第一，把评审容量当作产能指标来管理，像跟踪部署频率一样跟踪评审等待时间与返工率。第二，为智能体产出的 PR 增加机器可验证的门槛：类型检查、单元与集成测试、静态分析、依赖许可检查，先过机器再过人。第三，记录智能体参与情况，便于事后分析缺陷来源与回滚成本。第四，别用“PR 数量”衡量团队产出；报告已经显示数量可以快速增长，真正稀缺的是判断与责任。
小结
GitHub Octoverse 2026 于 2026 年 10 月 28 日发布，以 179 亿次推送、13 亿个合并 PR、四成 PR 由智能体起草、90% 两周内合并与 2.25 亿开发者为看点，把软件工程的焦点从“写得多快”推向“评审与代码质量能否跟上”。