4 月 28 日，Mitchell Hashimoto 写了一篇文章。标题很短：Ghostty Is Leaving GitHub。
如果你不知道他是谁------Mitchell 是 HashiCorp 联合创始人，Vagrant、Terraform、Consul 背后的那个人。离开 HashiCorp 日常运营后，他投入了新项目 Ghostty------一个用 Zig 语言编写的跨平台终端模拟器，主打平台原生 UI 和 GPU 加速。这个项目在 GitHub 上积累了 5.2 万 Star，是近年来最热门的开源项目之一，相比很多人用过，我也用过一段时间。Mitchell 是这个仓库的主要维护者。
他的 GitHub 用户编号是 #1299，2008 年 2 月注册，可以说是 Github 元老级别用户之一了。
mitchell hashimoto github overview
从那以后的 18 年里，他每天都在使用 GitHub。大学时凌晨 4 点室友都睡了，他再提交一个 commit。蜜月旅行时妻子还在熟睡，他打开 GitHub。经历分手的时候，他把自己沉浸在开源项目里。
"GitHub 是让我最快乐的地方。我总是能为此挤出时间。"
他甚至创建 Vagrant，最初就是希望这个项目够好，能让 GitHub 愿意雇他。
这不是一个普通开发者的抱怨。这是一个维护着 5 万 Star 级开源项目、把大半个职业生涯放在 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 集群过载，搜索瘫痪。 GitHub 上依赖搜索的功能大面积失效------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 正在重塑软件工业的一切------代码怎么写、漏洞怎么找、基建怎么承受压力。但在这场重构中，最不应该被牺牲的，是那些让代码有意义的人。