GitHub 每月 73.8 亿次提交带来的治理压力

每月 73.8 亿次提交不等于 73.8 亿次有效开发。这组数字提出了一个治理问题：AI 智能体正把 GitHub 的瓶颈从“写代码”推向“托管、审核与治理”。

核对统计口径后，更准确的结论是：AI 正在降低代码生成成本，却没有同步降低托管、审查、验证和责任承担的成本。开发团队需要限制智能体权限，开源维护者要过滤机器贡献，平台方则要同时处理容量、CI 成本与滥用问题；衡量效率的指标，也必须从提交数量转向可验证的有效变更。

数据口径决定数字含义

本文统一采用 36 氪标题中的“一个月 73.8 亿次提交”口径。资料 的摘要出现“一天 73.8 亿次”的表述，与 的标题存在冲突，不能把两种说法拼成同一组趋势数据。

“提交”也不是一个可以脱离上下文理解的指标。GitHub 生态中几个常见概念记录的是不同事件：

资料 另列出一组年度报告数据：过去 12 个月有 179 亿次推送，所有类型仓库合计 343 亿次提交，合并的 PR 达到 13 亿次。这些数字与“一个月 73.8 亿次提交”并非同一统计口径，不能直接换算，也不能据此拼接增长率。

因此，73.8 亿次提交更适合作为协作活动规模的信号，而不是有效代码量、用户增长或开发效率的替代指标。一个仓库可以产生大量空提交、格式调整、自动生成文件和重试记录；反过来，一次经过充分设计、业务验证和长期维护的提交，其价值也可能远高于几十次机器提交。

AI 编程并非近期才进入 GitHub

GitHub 2023 年开源状态报告显示，92% 的开发者已经在使用或尝试 AI 工具，生成式 AI 项目总数同比增长 248%。

后续年度报告的相关数据又显示，与生成式 AI 相关的项目贡献量增长 59%，公共 AI 项目的贡献量接近翻番；Python 也首次超过 JavaScript，成为 GitHub 上最受欢迎的编程语言，Jupyter Notebooks 使用率增长 92%。这些数据表明，AI 的应用已从编辑器内的代码补全，扩展到项目创建、依赖选择、数据处理和持续贡献环节。

但 AI 辅助编码并不会自动等比例增加提交量。开发者使用 Copilot 补全函数，可能只是缩短了输入时间；智能体执行一个完整任务，则可能自动创建分支、拆分步骤、反复运行测试、生成提交记录并提交 PR；定时任务、依赖更新机器人还可能持续产生机械变更。在这三类活动中，只有后两类更容易放大仓库事件数量。

机器提交也不能直接视为 AI 贡献。自动化脚本可以与模型无关，AI 生成的代码也可能经过人工重构后才进入仓库。讨论规模与责任之前，需要先区分生成方式、执行方式和提交身份。

智能体活动与机器流量增长

资料 转述的报告称，到 9 月，GitHub 上已有超过 40% 的 PR 由 AI 智能体起草，而 3 月这一比例只有 17%；从第一天起配置智能体的仓库，平均提交量是未配置仓库的 8 倍。在 Copilot 月活跃用户中，55% 使用智能体功能，增长最快的则是把任务交给智能体独立执行的云端模式，其使用量同比增长 230%。

这些数据说明，智能体正在把开发流程从“人编写代码”改造成“系统编排多个执行步骤”。但提交量达到未配置仓库的 8 倍，只能说明相关性，不能直接证明智能体带来了同等比例的有效产出。任务拆分更细、自动重试更多、测试和格式检查频繁运行，都可能机械性放大提交数字。

更需要关注的是 PR 的来源结构和维护负荷。智能体起草的 PR 不等于完全无人参与，也不等于已经自动合并。仓库需要回答的是：机器贡献占用了多少审查资源、产生了多少重复修改、带来了多少返工，以及最终由谁批准这些变更进入主分支。

算力压力沿着协作链路扩散

36 氪标题用“增配 400 万核还不够”概括 GitHub 的容量压力，另一材料则把面向智能体重建 Git 地基后的吞吐量提升概括为 35 倍。核数与吞吐量并不是同一指标，这两组表述也不宜直接比较，但它们共同指向协作基础设施的扩容需求。

压力首先出现在 Git 对象与分支管理。一次任务可能创建大量 commit 和临时分支，涉及对象生成、增量压缩、引用更新、树遍历以及打包与传输。PR 渲染需要计算和展示差异，代码搜索需要持续更新索引，事件处理还要经过队列处理、去重与缓存。

其次是 CI 和安全检查。随着机器提交增多，构建、测试、制品上传和依赖分析任务也会增加；当多个智能体并发修改同一仓库时，队列可能快速堆积，扫描和运行环境也会同步扩张。GitHub 已将代码扫描、依赖关系监控等能力作为 AI 编程体系的一部分，但这些能力本身同样需要计算资源。

需要区分两类成本：模型推理成本通常发生在 AI 服务提供方或企业账户一侧，GitHub 更多承担的是代码托管、差异处理、搜索、CI 编排和安全扫描成本。判断扩容是否充足，不能只看平台总核数，而要结合活跃仓库数量、分支变动率、变更大小、并发检查量以及任务持续时间。

代码产量跑在验证之前

代码生成速度提高后，最先承压的是验证环节。机器可以快速产出功能代码，也可能同时带来边界条件遗漏、潜在漏洞、测试不足、重复实现和低价值变更。提交数量增长并不代表缺陷发现能力同步增长。

资料 借 PHP 社区近期高危漏洞提醒开发者：当生成速度远超人工逐行审查能力时，传统审核机制容易失效；这并不能证明该漏洞由 AI 直接造成，但说明了生产与验证之间的结构性风险。Copilot Chat 可以解释代码、协助检测安全漏洞并查找和修复错误，GitHub 也在持续提供代码扫描与依赖监控能力，但 AI 辅助检查仍不能替代测试、静态分析、依赖检查和明确的人类责任。

更稳妥的质量门禁需要组合多种措施：小步变更、自动化测试、静态检查、安全扫描和人工批准相互补充，而不是让同一个模型同时生成代码、解释代码并宣布代码安全。对于依赖升级、权限调整、加密实现和外部接口变更等高风险路径，还需要更严格的独立审查。

审核能力成为瓶颈

当 PR 增长速度超过专业审阅者的处理能力时，压力会先表现为排队时间、返工和注意力竞争。开源场景中又很难确认代码究竟由人还是 AI 起草、审阅者是否也使用了 AI 辅助工具，这会进一步降低审核过程的可解释性。

因此，团队需要观察的指标不应只有合并量。一次通过率下降，通常意味着提交前的需求澄清、设计和自检不足；返工率上升，说明生成速度已经超过验证能力；缺陷逃逸率则检验现有门禁是否仍然有效。专家注意力不足还可能造成维护延迟、规则执行不一致，甚至导致维护者流失。

衡量 AI 编程效果时，可以增加一组更贴近协作质量的指标：

• PR 从提交到首次有效审查的等待时间
• 首次提交即被接受的通过率
• 因需求、测试、格式或安全问题产生的返工率
• 缺陷越过当前检查环节进入后续环境的逃逸率
• 维护者为机器贡献投入的人工时间
• AI 使用披露和机器人身份标记的合规率

这些指标不会因为仓库看起来更活跃而自动变好，却能揭示代码生产是否真正转化成了可维护的软件。

责任链必须落到具体的人

开源治理不应停留在“允许还是禁止 AI”的二元选择上。全面禁止可能把使用行为推向不可见状态，也解决不了生成代码的质量与许可证问题。更可行的做法，是让“谁生成”与“谁负责”能够被分别追踪。

治理规则至少应覆盖几个方面：

• 披露仓库或 PR 是否使用 AI 辅助，以及使用范围。
• 为机器人账户设置可识别身份，避免伪装成个人贡献者。
• 在高风险场景保留必要的生成来源、提示或变更记录。
• 明确生成代码的许可证、安全漏洞和第三方依赖责任。
• 将可接受行为、重复提交、垃圾内容与自动绕过规则写入行为准则。
• 提供维护者拒绝、申诉和人工复核渠道。
• 无论代码由谁生成，最终合并责任都应由明确的人类或组织承担。

这些规则的目的不是给 AI 贴标签，而是防止责任在自动化链条中消失。

开发团队要缩小智能体权限

使用智能体的团队应优先把权限限制在可逆、可验证的环节，例如从 issue 生成任务说明、创建工作分支、起草 PR、补写测试或整理日志，而不是让智能体直接向主分支合并。

小步变更能够降低单次审查负担；将测试、静态检查和安全扫描设为强制门禁，关键路径再由人工批准。团队还需要记录智能体运行范围和失败重试情况，持续比较返工率、审查等待时间与缺陷逃逸率。如果提交量快速增加，而这些指标没有改善，就说明自动化正在放大流程缺陷，而不是消除它们。

维护者要为机器贡献设门槛

接收机器贡献的开源维护者可以先公开 AI 使用政策，提供机器人标签和贡献披露字段，再用自动初审过滤重复 PR、无关变更、格式噪声和明显不符合项目规范的内容。剩余 PR 再按风险分级，把有限专家注意力留给架构、安全和复杂业务判断。

自动筛选不能直接替代审查，但它可以避免维护者把时间消耗在明显无效的机器变更上。规则还应说明机器提交是否必须附有可复现的测试结果、变更说明和生成方式，尤其不能因为“由 AI 生成”而降低提交标准。

平台方要同时管容量与成本

平台方需要根据活跃仓库数量、分支变动、变更规模、CI 并发和安全扫描负载预测容量，并结合弹性计算、队列、缓存与可观测性，而不是依据提交总量做线性估算。成本分摊也应考虑任务占用的实际资源，避免高频机器人把公共基础设施成本转嫁给少数维护者。

限流、批量提交检测和滥用治理需要与扩容同步推进。否则，平台可能获得更高吞吐量，却同时承受更长的队列、更严重的垃圾 PR 和更高的安全扫描负担。更合理的做法是，用自动化处理低风险、高重复的协作事务，把人工审核和高成本计算资源留给需要判断的部分。

可信协作比提交数量更重要

我的判断是，GitHub 下一阶段更稀缺的是可验证、可追责且能够被维护者承受的协作带宽，而不是被机器批量生成的代码；评价平台价值的关键指标，也将从提交总量转向经人工确认的有效变更。