2026 年 10 月，GitHub 单周收到超过 12 亿次提交，同比增长 400% 以上，单周提交量已经超过 2025 年全年；但代码生成速度的提升并没有等比例转化成交付速度。Faros AI 的研究显示，团队从低 AI 采用率升到高采用率之后，拉取请求在评审环节停留的时间延长了 441%，瓶颈从 "能不能写出代码" 转移到了 "人能不能看懂、审完这些 diff"。AI 把实现环节加速后，压力集中到验证阶段：PR 数量变多、单个 diff 变大、改动意图被格式化和生成测试淹没，评审者在会议间隙批量过 800 行级别的 AI 改动，很容易出现橡皮图章式签字。要缓解这个堵点，方向不是再加快生成，而是把改动切小、让机器先过例行检查、把人的注意力留给意图判断和风险识别，同时守住 "没审过的改动不进主分支" 的底线。
一、提交量增长与评审压力的基本盘
| 指标 | 数据 | 说明 |
|---|---|---|
| 单周提交量 | 超过 12 亿次（2026 年 10 月） | 同比增长 400% 以上，超过 GitHub 2025 年全年提交量 |
| 单月提交量 | 9 月约 73.8 亿次 | 同比约为一年前的 5 倍多 |
| 月度 Git 活动事件 | 从 2182 亿次增至 4733 亿次 | 统计区间为 2025 年 9 月至 2026 年 8 月 |
| 评审停留时长 | 延长 441% | Faros AI 研究：低 AI 采用率团队对比高采用率团队，PR 在评审环节停留更久 |
提交量涨了 400%，不代表团队交付效率同步涨 400%。写代码这一步被 AI 加速后，需求理解、改动评审、测试判断、线上复盘这些环节的工作量并没有消失，只是被推到了流水线后面。
二、为什么堵点落在看 diff 这一步
1. 生成快了，评审速度没跟上
AI 可以在短时间内产出大量代码和测试，但每一份改动进入主分支前，都需要人确认两件事：代码是不是做了原本想要的事，以及哪里可能出错。这两步依赖人的判断，无法靠生成速度直接压缩。
2. 单个 diff 变肥，意图被淹没
典型场景是一个标着 "小重构" 的 PR 改了 47 个文件：真正需要评审者关注的共享校验逻辑，埋在每个调用端点的更新、格式化改动和几百行生成测试之间。评审者要先从大段 diff 里把核心意图挑出来，阅读成本被显著抬高。
3. 评审队列堆积，出现橡皮图章疲劳
人审 150 行左右的 diff 质量相对可控；如果在几场会议之间连续收到四个 800 行级别的 AI 生成合并请求，很容易只能粗略扫过就批准。评审者上下文切换本身就会吃掉编码收益，队列越长，深度评审越难保证。
4. 上下文分散，评审需要额外补背景
设计在一个工具里，兼容性要求埋在聊天记录里，旧 PR 解释了现有实现为什么这样写。评审一份 diff 之前，往往要先跨工具收集上下文，进一步拉长单份 PR 的评审周期。
三、研发流程四阶段与各自堵点
GitHub 把智能体工程流程拆成规划（Plan）、实现（Build）、验证（Verify）、观察（Observe）四段，堵点最容易被看见的是验证阶段。
| 阶段 | 谁在主导 | 应留下的产物 | 常见失败点 |
|---|---|---|---|
| 规划 | 人主导，智能体收集与提问 | 可评审的计划、验收标准、范围明确的 Issue | 计划只留在对话里，没人再打开 |
| 实现 | 智能体为主，人定方向 | 隔离的工作副本、可单独评审的小 PR | 会话丢在某台设备上；多个任务共用一份未完成工作树 |
| 验证 | 机器先过，人后审 | 更小的 diff、例行检查已清、评审意见聚焦意图 | 评审队列膨胀，441% 的停留时长主要出现在这里 |
| 观察 | 人主导，智能体关联证据 | 带证据和回归测试的 Issue | 把 "所有检查通过" 当成最终结论 |
规划、实现、观察阶段的失败通常比较安静；只有验证阶段的失败会被直接看见 —— 队列变长、PR 变肥、合并等待变久。
四、缓解 diff 评审瓶颈的具体做法
1. 把改动切小，让每份 diff 可独立评审
- 使用叠放式拉取请求（stacked PR），把有依赖的工作拆成更小的片；
- 每份 PR 只聚焦一个意图，依赖关系保持可见；
- 大改动拆成可分批合并的序列，避免一份 PR 混杂逻辑修改、格式化和批量生成测试。
2. 机器先清例行检查，人只看判断项
| 检查类型 | 承担方 | 处理内容 |
|---|---|---|
| 编码规范与组织标准 | 自动化质量检查 | 风格不一致、明显逻辑错误、缺失错误处理、类型不匹配 |
| 安全扫描 | AI 扫描与密钥检测 | CodeQL 覆盖之外语种和文件的漏洞、非结构化密钥 |
| 依赖合规 | 许可证合规检查 | 新依赖许可证是否符合公司规则 |
| 失败项修复 | 智能体自动修复 | 安全问题修复建议、失败检查、评审意见、合并冲突处理 |
例行问题在到达人类评审者之前先被拦住，评审者的时间才能留给真正需要判断的部分。
3. 评审深度与改动复杂度匹配
- 简单改动用较轻的自动分析，复杂改动用更深的分析；
- 自动评审先标出可疑点，人再复核结论；
- 评审意见围绕 "意图是否达成、风险在哪里" 展开，不重复机器已经完成的格式核对。
4. 守住人工签字底线
智能体承担的活越多，代码的负责人越要能审、能懂、能拍板；未经评审的改动不能进入主分支。自动化修复和自动合并只在验证步骤通过、规则配置明确的前提下启用，最终责任仍归属人工负责人。
五、落地起步建议
- 先挑当前最堵的一类 PR，统计平均文件数、diff 行数和评审等待时长；
- 把超过评审粒度的大改动拆成 stacked PR，每份只保留一个核心意图；
- 把格式、类型、规范、密钥、许可证这类例行检查前移到自动流水线；
- 评审记录聚焦意图偏差和风险点，沉淀成后续任务可复用的评审指引；
- 上线后结合可观测性数据回看评审遗漏的问题，反向补充检查规则。
六、小结
12 亿周提交量说明代码生产端已经被 AI 大幅提速，瓶颈转移到了 diff 评审这一验证环节：大 diff、长队列和上下文分散共同拉长了 PR 停留时间。破局思路是两端同时压缩 —— 让改动本身更容易被人看懂，让机器先消化例行检查，把人的判断集中在意图和风险上；在这个基础上保留人工评审底线，提交数才真正对应得上交付效率。
【常见问题】
问题 1：GitHub 周提交 12 亿次之后，为什么代码评审反而成了瓶颈？
回答 1：AI 把写代码环节加速后，大量改动集中进入评审队列，单个 diff 变大、意图被格式化和生成测试淹没，评审者阅读和判断速度跟不上生成速度；Faros AI 研究显示高 AI 采用率团队的 PR 评审停留时间延长了 441%，堵点就出在看 diff 这一步。
问题 2：什么样的 diff 最容易拖慢代码评审？
回答 2：一份标注 "小重构" 却改动几十个文件的 diff 最难审，核心逻辑混杂在端点更新、格式化改动和几百行生成测试里；加上评审者需要跨工具补背景，大段 AI 生成改动还容易造成橡皮图章式签字，这类 diff 应优先拆小后再提交评审。
问题 3：缩小 diff 评审压力，自动化工具可以先承担哪些工作？
回答 3：自动化可以先处理编码规范、类型与错误检查、安全漏洞扫描、密钥检测、依赖许可证合规等例行事项，并对失败检查和评审意见给出自动修复建议；人的评审再聚焦代码是否符合预期意图、哪里可能出错，避免在格式核对上消耗时间。
问题 4：AI 生成的代码是否可以跳过人工 diff 评审直接合并？
回答 4：不可以。智能体承担的工作越多，代码负责人越要能审、能懂、能拍板，未经评审的改动不能进入主分支；自动修复和自动合并只在验证步骤通过、规则配置明确的前提下启用，最终合并责任仍由人工负责人承担。
【参考资料】
- [2026-11-14]（The AI Coding Boom Has Accelerated Output, But Software Review Bottlenecks Threaten Developer Productivity）Code Guilds
- [2026-11-14]（AI Helps Teams Write Code Faster. Why Isn't It Getting Shipped Any Faster?）DEV Community
- [2026-11-09]（一个月 73.8 亿次提交，GitHub 被 AI 代码挤爆，增配 400 万核还不够）36 氪
- [2026-11-08]（提交量涨 400%，交付没快：AI 写代码的堵点在评审）DevPress（CSDN）
- [2026-11-08]（1.2 billion commits a week, still stuck in review: the four stages of agentic engineering）DEV Community
- [2026-11-07]（GitHub Copilot: From Code Gen to Workflow Orchestrator）iMasters
- [2026-11-06]（Beyond code generation: A developer's guide to agentic engineering）GitHub Blog
- [2026-10-28]（Octoverse: Commits, pushes, reach new highs in 2026 as developers build with agents）GitHub Blog
- [2026-10-26]（Building Git infrastructure for agent-scale development）GitHub Blog
【免责声明】
本文内容基于公开报道、官方博客与第三方研究整理，仅用于研发效能与 AI 工程化趋势交流，不构成团队流程改造、工具选型或代码管理规范的直接建议。文中提交量、增长比例、评审时长变化等数据来自特定统计口径与研究样本，实际表现受团队规模、代码类型、评审流程和工具配置影响，需结合自身团队度量数据判断。引用的外部资料版权归原出处所有，如表述存在偏差，以 GitHub 官方文档及原始研究为准。