当GitHub的老朋友说再见
4月28日，Mitchell Hashimoto发布了一篇简短的博文，标题只有几个字：Ghostty Leaving GitHub。
如果你对他的名字感到陌生——他是HashiCorp的联合创始人，Vagrant、Terraform、Consul这些享誉业界的工具均出自他手。在离开HashiCorp日常管理后，他全心投入了新项目Ghostty，一个使用Zig语言开发的跨平台终端模拟器，以原生UI和GPU加速为特色。该项目在GitHub上已获得5.2万颗星，成为近年来最亮眼的开源新星之一。许多人试用过，我也曾短暂体验过一段时间。
Mitchell的GitHub用户编号是#1299，注册于2008年2月。某种程度上，他是GitHub的“元老级”用户。
在那之后的18年里，他几乎每天都在使用GitHub。大学时期室友已入睡，凌晨4点他仍在提交commit；蜜月旅行时妻子尚未醒来，他已经打开GitHub；分手后，他将所有情绪都埋入开源项目中。
他甚至坦言，当初开发Vagrant，最初的目标就是希望这个项目足够出色，能让GitHub愿意雇佣他。
因此，这绝不是一个普通开发者的抱怨。这是一个维护着5万星开源项目、把大半辈子都倾注在GitHub上的人，在做最后的告别。
一个月的宕机日志：几乎每天都有X
Mitchell透露，过去一个月他进行了一项实验：拿出日历，每当GitHub宕机影响了他的工作，就在当天画个X。结果呢？几乎每天都有X。
写那篇文章的当天，他因为GitHub Actions宕机已超过两个小时无法进行PR review。请注意，这不是4月27日那次广为人知的大规模故障——那是一周后的事。这是另一次，一次普通的、日常的、又一次宕机。
这段话读起来像分手信。因为它确实是。
GitHub官方承认：两起重大事故
Mitchell并非唯一受影响的人。同一天，GitHub工程副总裁Vlad Fedorov发布了一篇官方博客，标题为《关于GitHub可用性的最新进展》。
文中承认了两起重大事故：
- 4月23日——合并队列bug，导致代码被回退。使用squash merge通过合并队列合并PR时，如果合并组包含多个PR，会产生错误的合并提交，导致已合并的更改被意外回退。涉及658个仓库、2,092个PR。
- 4月27日——Elasticsearch集群过载，搜索功能瘫痪。PR、Issues、Projects的部分功能大面积失效。原因可能是僵尸网络攻击导致的集群过载。
而这两起事故，只是冰山一角。
罪魁祸首：AI正在生成海量的代码流量
GitHub在文章中给出了几组令人震惊的数据：
- 合并PR峰值：9000万
- 提交数峰值：14亿
- 每月新建仓库：2000万
这些数字从何而来？不是人类开发者，而是AI Agent。
GitHub自己说得也很直接：自2025年12月以来，agentic开发工作流急剧加速。仓库创建、PR活动、API使用、自动化以及大型仓库的工作负载，都在快速增长。这不是线性增长，是指数级的。
一个PR可能涉及Git存储、可合并性检查、分支保护、GitHub Actions、搜索、通知、权限、Webhooks、API、后台任务、缓存和数据库。在大规模并发下，再小的效率问题也会被不断放大：队列加深、缓存未命中转化为数据库负载、索引滞后、重试放大流量——一个缓慢的依赖就可能拖垮多个产品体验。
GitHub正在执行一个30倍扩容计划，从自建数据中心迁移到公有云，并规划多云路径。但基建改造的速度，远远跟不上AI写代码的速度。
AI Agent不休息、不睡觉、不喝咖啡。它们24小时不停歇地创建仓库、提交代码、发起PR。GitHub的基础设施，正在被AI生成的流量海啸淹没。
被AI压垮的不只是GitHub。讽刺的是，AI公司自己的服务也在经历同样的困境。
就在4月28日——Mitchell宣布离开GitHub、GitHub承认两起事故的同一天——Anthropic的Claude状态页上记录了一连串故障：Claude.ai无法访问、API鉴权错误激增、Claude Opus 4.7和Sonnet 4.5相继出现错误率飙升。Claude Code过去90天的可用率只有99.2%——对开发者日常依赖的编程工具来说，这意味着平均每个月有将近6小时无法正常使用。
AI工具催生了海量的代码流量，压垮了代码托管平台；而AI工具自身的服务稳定性，同样经不起考验。开发者的工具链正在被这场AI潮汐从两端挤压。
一条git push，就能拿下GitHub后端
就在GitHub基建承压的同时，一个更危险的信号出现了。
安全研究团队Wiz发现了一个漏洞，编号CVE-2026-3854，CVSS评分8.7。
利用方式简单到有些离谱：一条git push命令。任何经过认证的用户，只要使用标准的git客户端，就能在GitHub的后端服务器上执行任意命令。
漏洞的根因是GitHub内部组件babeld在处理git push options时，没有过滤分号。而分号恰好是内部协议X-Stat头的字段分隔符。攻击者可以通过push option注入任意字段，覆盖安全配置，绕过沙箱，最终实现远程代码执行。
在GitHub.com上，这个漏洞允许在共享存储节点上执行代码。Wiz团队确认，受影响节点上可以访问属于其他用户和组织的数百万个仓库。而在GitHub Enterprise Server上，这个漏洞意味着服务器被完全控制——所有仓库、所有内部密钥，全部暴露。
这是最早一批用AI发现的关键漏洞
这个漏洞背后的故事还有另一层含义。
Wiz团队过去就研究过GitHub Enterprise Server，但面对大量编译后的黑盒二进制文件，传统的逆向工程需要投入不切实际的时间和人力。这一次，他们用了IDA MCP——一个AI增强的逆向工程工具。
通过AI，他们快速分析了GitHub的编译二进制文件，重建了内部协议，系统性地定位了用户输入可能影响服务器行为的位置。以前需要数月的工作，现在被大幅压缩。
Wiz在报告中明确指出：这是首批使用AI在闭源二进制中发现的关键漏洞之一，标志着漏洞发现方式的根本性转变。
从发现到GitHub在GitHub.com上部署修复，只用了6个小时。但截至文章发布时，88%的GitHub Enterprise Server实例仍然存在漏洞，尚未升级。
矛与盾的悖论
把这几件事放在一起看，一个清晰的矛盾图景浮现出来：
AI是压垮GitHub基建的力量。 Agentic coding推动了指数级的流量增长，GitHub的基础设施在拼命追赶，30倍扩容计划还在路上，但每天都有新的宕机。一个18年的老用户因此选择离开。
AI也是发现GitHub致命漏洞的武器。 IDA MCP让安全研究员可以以前所未有的速度分析闭源二进制，发现跨组件的协议级漏洞。安全研究的游戏规则就此改变。
GitHub面对的不是一个问题，而是一个结构性矛盾：AI写的代码越来越多，AI发现的漏洞越来越快，平台自身的基建还在追赶扩容——在这个三角张力中，开发者该把代码放在哪里？
Mitchell在文章最后说得直白：
这句话不止是对GitHub说的，也是对整个依赖单一平台的行业说的。当AI同时成为基础设施的矛与盾，信任就不能只建立在承诺上了。
更深一层：我们正在亲手建造自己无法承受的世界
上面这些事，表面上讲的是GitHub的宕机、漏洞和用户出走。但把它们叠在一起看，一个更深层的叙事浮出水面。
软件工业正在经历一场“规模不匹配”。
过去二十年，软件开发的核心约束是人的生产力。一个程序员一天写几百行代码，一个团队一个季度交付一个版本。整个工具链——版本控制、CI/CD、代码审查、包管理——都是围绕这个节奏设计的。GitHub 2008年上线时，全球注册开发者不到100万。它的架构从第一天起就根植于“人类规模”的假设。
AI Agent打破了这个假设。一个Agent一天可以提交上千次，发起上百个PR，创建几十个仓库。这不再是人类生产力10%的提升，而是数量级的跃迁。GitHub那套“一个PR走一遍合并队列”的架构，在每分钟9000万次合并请求面前，就像一条乡间小路突然要承担高速公路的车流。
这不是GitHub一家的问题。npm、PyPI、Docker Hub，甚至云厂商的API限流策略——所有围绕“人类开发者”设计的基建，都在面对同一个问题。
更值得警惕的是反馈回路的形成。AI生成代码的速度压垮了基础设施，基础设施宕机导致部署延迟和安全响应滞后，而AI同时又在以更快的速度发现这些基础设施中的漏洞。攻击面在扩大，防御线在变薄，驱动这一切的引擎——AI自身——也在变得越来越不稳定。
这不是一个“加机器”就能解决的问题。30倍扩容追得上今天的流量，追不上明天。因为AI的能力增长是指数的，而基础设施的物理扩张永远受限于资本、电力、芯片和时间的线性约束。
Mitchell的离开指向了一个被忽视的问题：代码的去处。我们把代码放在GitHub，是因为信任——信任它不会丢，信任它随时可用，信任它足够安全。但当平台在可用性和安全性上同时出现裂痕，信任就开始动摇。
开源社区从来不缺替代方案——GitLab、Gitea、Codeberg、SourceHut、Radicle（基于P2P的去中心化Git网络）。过去大家不迁移，是因为GitHub“够用”。现在，“够用”这个前提正在被动摇。
真正的解法可能不是换一个平台，而是重新思考：当代码的生产方式发生了根本性的变化，代码的托管方式是否也需要根本性的变化？基于P2P的分布式版本控制、基于内容寻址的代码存储（类似IPFS）、去中心化的CI/CD网络——这些过去被认为是“极客玩具”的概念，可能会因为AI时代的规模压力，变成必要的基础设施。
最后，回到人本身。Mitchell在凌晨4点的宿舍里写代码，在蜜月旅行的清晨打开GitHub，在分手后把自己沉浸在开源项目里。这些描述之所以动人，是因为它们指向一个AI永远无法替代的东西——代码背后的人。
AI可以24小时不间断地生成PR，但它不会在凌晨4点因为兴奋而睡不着，不会在蜜月旅行的清晨迫不及待地想打开电脑，不会在人生低谷时把写代码当作救赎。当一个18年的老用户因为平台而离开，失去的不只是一个账号，而是十八年的习惯、情感和信任的锚点。
AI正在重塑软件工业的一切——代码怎么写、漏洞怎么找、基建怎么承受压力。但在这场重构中，最不应该被牺牲的，是那些让代码有意义的人。
