8 月 20 日，GitHub 发了一份宕机复盘。里面有一句话被全网截图转发：
「自 4 月以来，月度提交量从 14 亿次涨到了 29 亿次。」
四个月，翻一倍。
然后有人顺手翻了下 GitHub 自己的年度报告，发现了另一件事——它 2025 年的全年提交量，是 9.86 亿次。
一个月 29 亿，一年 9.86 亿。
同一家公司，两份官方材料，差了 35 倍。
不是标题党，是真事。今天咱们把这两个数字拆开看看，顺便聊一个更值得琢磨的问题：我们用了几十年的那把衡量「软件增长」的尺子，可能已经不灵了。
一个月 29 亿次，它自己的年报说一年才 9.86 亿
先把数字摆清楚，来源都是公开的。
第一个数字出自 GitHub CTO Vlad Fedorov 的宕机复盘。8 月 17 日，GitHub 全站挂了 7 小时 47 分钟，认证、Actions、API、Pull Request、Issue、Copilot 一起躺平。复盘解释原因时，他给了一组数据：
- 月度提交量：4 月 14 亿次 → 8 月 29 亿次
- 每月合并的 PR：约 1.3 亿个
- 每月新建仓库：约 2400 万个
第二个数字出自 GitHub 的 Octoverse 年度报告，那份每年发布的「平台成绩单」。2025 年那份统计出来的是：全年 9.86 亿次提交。再往前一年，2024 年，约 7.8 亿次。
一个说月，一个说年。一个月 29 亿，一年 9.86 亿。
但两个数字都是真的
我知道你第一反应是什么。不过先别急着喊数据造假——技术社区扒完之后，结论恰恰相反：这两个数字都站得住，它们算的根本不是一回事。
Octoverse 数的是「内容」：公开仓库里、由人类作者产出的那些提交。它关心的是「这个平台上有多少人，写了多少新东西」。
而宕机复盘里的 29 亿，数的是「负载」：所有打进 GitHub 写入路径的东西。这里面包括私有仓库、fork、CI 流水线自动生成的提交、从别处镜像导入的完整历史，以及——关键词来了——AI agent 建起来又随手扔掉的临时分支。
打个不太严谨但好懂的比方：年报统计的是图书馆最终上架了多少本书；宕机复盘统计的是印刷厂的机器一共转了多少次。机器转的次数里，有印废的、有试印的、有打出来又销毁的。两个数字都是真话，只是一个在说藏书量，一个在说产能。
还有一件事值得注意：GitHub 从没公布过平台口径下「AI 到底写了多少」。它只公开了 Copilot 相关的数据——完成了 6000 万次代码审查，占平台全部审查量的五分之一以上。至于那 29 亿次提交里有多少是 agent 自己冒出来的，官方没给答案。
四个月翻一倍，这个速度不正常
数字对不上是一回事，但它四个月翻一倍，是真的。
而且曲线的形状变了。过去十几年，GitHub 的提交量增长基本跟开发者人数同步——多一个程序员，多一份提交，斜率平稳。但从今年 4 月到 8 月，它突然变成了一条竖线。
原因不难猜：提交量不再和人数挂钩了。
一个开发者同时开三个 AI agent 会话，产出的提交量，是任何一份招聘计划都预测不出来的。今年 GitHub 加了 300 万 CPU 核心、120 PB 高速存储，把 Azure 承载比例从 5 月的 12% 拉到 58%，自家数据中心能用上的电全用上了——然后 8 月连挂两次。8 月 6 日 Actions 停了 9 小时 9 分，8 月 17 日直接全站 7 小时 47 分。
顺便说，这类数字现在都只能当「下限」看。有第三方追踪器按提交签名统计，Claude Code 的签名提交占 2.19%，Cursor 0.2%，Copilot 0.01%。看着很小对吧？但只有主动签名的 agent 才会被数进去，企业私有仓库里的、被配置成用开发者身份提交的，全都统计不到。另有研究估算，每月可检测到的 agent 提交超过 32 万条，还有研究在 15%–19% 的项目里发现了 agent 的活动痕迹。
真实数字？没人知道。包括 GitHub 自己。
真正扛不住的，不是服务器
到这儿，多数报道的结论是「GitHub 扩容没跟上」。这没错，但对 GitHub 来说这是个有解的问题——机器不够就加机器，微软不缺钱。
真正没解的那个问题，藏在这组数据的背面：
这 29 亿次提交，每一条都在声称「我这次改动是对的」。而整条把它们生产出来、运送出去、合并进去的链路里，几乎没有任何一个环节，真的去验证过这句话。
生成和验证，是两条斜率完全不同的曲线。
代码生成已经是机器节奏了，指数上扬；而验证——确认一个改动真按它说的那样工作、并且没弄坏别的功能——还是人的节奏，曲线几乎是平的。
一条指数曲线，和一条平线，中间张开的那个口子，就是接下来几年最要命的基础设施问题。
有人干脆把装货的容器换了
面对这个口子，行业里出现了两种反应。
一种是在「验证」上加码：让 AI 工具先筛一遍改动，帮人省点力气。这也是最近一大批代码审查工具在干的事。
另一种更狠：承认老容器本身就不行了，换一个。
9 月 16 日，Zed 发布了 Delta 的公开测试版。主张很直接——Pull Request 这套流程，用了 15 年，该退场了。
Zed 的理由不是「PR 不好用」，而是「PR 的设计前提变了」。PR 是为人类工作流设计的：你埋头写一阵，攒成一批，停下来，等别人审。这套「攒批—审查」的节奏，天然带着延迟。
但 agent 不攒批，它连续产出、并行产出。把一股连续的流硬塞进一个「攒批再放行」的闸门，堵是必然的。
Delta 的做法是用「线程」取代 PR：把任务、和 agent 的对话、以及所有改动绑在一起，别人可以随时进来，直接追问 agent「你当时为什么用 Mutex 不用 RwLock」。改动不再需要被打包成一个孤零零的 diff 送出去审——因为你审的时候，上下文就在边上。
Zed 自己已经这么干了：他们关掉了自家仓库的 PR，33 个人直接往主分支提了 570 个变更。
当然别急着叫好。Delta 现在只替代了「代码审查」这一层，CI/CD、Issue、安全扫描、项目管理，全都还在外面撑着。它是不是终局，谁都说不准。
但它暴露的那个矛盾是真的：当产出速度涨了好几倍，第一个卡住的，是原来那个用来收货验货的环节。
这事儿跟你有什么关系
你可能不写代码，这套东西跟你的关系在哪？
一句话：别再用「产出量」当 AI 的绩效指标了。
这份数据最有价值的地方，不是告诉你 AI 有多能写，而是告诉你——写的量翻倍了，验的量没动。这意味着，任何只盯着「我们一周生成了多少代码」「AI 帮我们省了多少工时」的团队，都在拿一把偏了的尺子量自己。真正的瓶颈不在生成端，在验收端。
对做产品、做管理的人来说，道理一样：AI 让「做出来」变得便宜了，但「确认它没做错」这件事，还没变便宜。
生成越便宜，判断就越贵。
这是这轮变化里最容易被忽略、也最值钱的一句话。
我是老魏，一个专门把 AI 圈的新闻翻译成人话的程序员。这儿不讲参数，不讲架构图，只讲「这事儿到底意味着什么」。
觉得有用就点个关注，咱们下期见。