AI 写代码太快，GitHub 撑不住了：OpenAI 自研后端并收购 Pierre，Cursor 与 Anthropic 各建各地
GitHub 在 11 月初接连出现故障，同一时间 OpenAI 被曝拟收购代码托管工具 Pierre，并已上线自研 Git 后端 Pando。Cursor 和 Anthropic 也在把代码向自研系统迁移。直接原因只有一个：AI 编程让代码提交和自动化任务量激增，原有代码基础设施跟不上。
GitHub 一天两起故障，撞上 OpenAI 的收购消息
11 月 3 日，GitHub 官方状态页一天记录了两起故障，其中一起影响 Git 操作。到了 4 日，合并请求等服务又出现异常，部分请求失败或延迟。
代码改完了，想让同事看看能不能并进主项目，偏偏卡在这一步。有网友打趣说，那就正好去喝杯咖啡。
就在 GitHub 忙着抢修时，Axios 发出独家消息：OpenAI 拟收购代码托管工具 Pierre，交易仍待交割。
两条消息撞在一起，时间上颇为凑巧。更值得注意的是，做 AI 编程工具的公司里，已经有好几家开始自己管代码了。
Cursor 允许开发者把整个项目直接存在 Cursor 里；Anthropic 更是把自家工程师每天使用的主代码库搬进了自研系统。
之所以如此，是因为 AI 写代码的速度越来越快，支撑它的基础设施已经逐渐跟不上。
OpenAI：先自研 Pando，再买下 Pierre
OpenAI 自己就体验过代码系统跟不上的困境。今年 3 月，The Information 报道称，OpenAI 工程师多次遇到 GitHub 服务中断，公司正在开发内部替代工具。
11 月 2 日，它公开了自研 Git 后端 Pando，用于承接内部代码的存取等操作。按工程团队的说法，以前一个工程师手上通常只推进一份改动；有了 Codex，一个人可以同时准备好几份。
而每推送一次代码，又会触发多个自动化任务去拉取代码、运行检查。写代码的人并没有一下子多出好几倍，系统要处理的工作量却大幅增加。
原来的系统渐渐吃力：拉取、推送变慢，合并也会失败。Pando 从 4 月起就开始承接真实的开发流量。按 OpenAI 的统计，换上之后，一次推送的中位耗时降低了近八成。
内部问题解决之后，面向 Codex 用户，OpenAI 还打算通过收购 Pierre，把代码存储等能力直接带进产品。
Pierre 的三块拼图：Trees、Diffs 和 Code Storage
其实 Pierre 的东西，你可能早就用过了。假设你让 Codex 修一个 bug，它一口气改了五个文件：你点开文件列表，找到其中一个，再逐行对照它删了什么、加了什么。前一个动作用的是 Pierre 做的 Trees，后一个用的是 Pierre 做的 Diffs。这两套工具早已接入 Codex。
Pierre 的另一块业务叫 Code Storage。它的客户之一是 AI 应用开发平台 Lovable：用户在里面输入几句话就能做出一个网站，而在后台，每个项目都要用一个或多个 Git 仓库来保存代码和修改历史。
按 Pierre 今年 8 月披露的数据，当时 Lovable 每周新建超过 800 万个仓库，峰值达到每秒 250 个。
OpenAI 计划在收购完成后，把 Code Storage 的能力带进 Codex。以后开发者让 AI 写代码、查看它改了哪里、再把这一版存下来，都有望在 Codex 里完成。目前这笔交易还需满足监管批准等交割条件。
Cursor 的 Origin 上线，GitHub 又挂了
8 月 14 日，SpaceX 完成对 Cursor 的收购。三天后，Cursor 的代码托管服务 Origin 开放早期测试。偏偏就在 8 月 17 日，GitHub 发生了一场持续 7 小时 47 分钟的故障。
Cursor 员工 Matt Palmer 当时开了个玩笑，大意是：他们本来想更早发布，可 GitHub 它、它又挂了。
Origin 给了开发者两种选择。做新项目，可以直接在 Origin 建仓库，代码推到 Cursor，请同事审、接收修改意见、合并分支，这些操作都能绕开 GitHub。老项目如果已经放在 GitHub，也可以只同步一份到 Cursor：你在 Cursor 里留下的评论，队友回到 GitHub 也能看到，代码仍以 GitHub 上的版本为准。
换句话说，Origin 的思路是“绕开但不必撕破脸”：新项目完全自托管，老项目先做镜像同步。
Claude 写代码太快，Anthropic 只能重做代码系统
OpenAI 和 Cursor 把更多开发环节搬进了自家产品。Anthropic 那边的问题不在工具里，而在内部代码库本身：工作量已经大到原来的系统撑不住了。
原因不复杂——Claude 写代码太快。
按 Anthropic 披露的数据，今年 5 月公司日均合并约 2500 项代码改动；到了 9 月，每天超过 3 万项。这些改动都要合进团队共同维护的代码版本里。
持续集成这类自动化任务，每天要取用约 2500 万次代码。高峰期公司维护着数百个 Git 镜像，用仓库副本来分担压力。但问题是：主仓库更新越快，副本就越难保持同步。
工程师还发现，频繁来取代码的，多数是始终在线的 Agent 和自动化任务。很多任务只是想确认某个文件改了哪几行，根本没必要在本地准备一份完整仓库——让服务器算好、把结果发回来就行。
沿着这个思路，Anthropic 做出了 Scion：客户端需要哪个文件就取哪个，查历史、建提交、合并改动则交给服务端。
7 名工程师借助 Claude，用 5 个月完成了这套内部版本控制系统。配套的代码审查工具 Antique 也一并落地，公司主代码库已经整体迁了过去。
不过 Scion 主要面向 Anthropic 这种改动频繁的大规模内部代码库。Claude Code 的公开仓库等社区资源，仍然留在 GitHub 上。
一天三万项改动，谁来把关？
代码取用更快、存放更顺之后，更难的问题来了：这些修改怎么判断能不能用？
在近期一场对谈中，Anthropic 的 Addy Osmani 介绍了他们的做法——先让 Claude 做一轮审查，并且要给足条件，让它像真实用户一样把功能跑起来。
比如改的是网页，就让 Claude 打开浏览器检查页面、操作功能，再跑必要的测试。之后工程师查看它交回来的验证材料，包括操作录像、页面截图和测试结果。每项改动仍然有明确负责人，出了问题由负责人处理。
△Claude Code 团队公布的代码改动检查与发布流程
Anthropic 的工程博客里还提到一个更难处理的场景：一轮测试跑着跑着，代码库里可能又合进了成百上千项改动。
在这么大的规模下，团队发现用仓库全局锁来协调合并队列已经很难跑通，于是把重心转向合并之后、部署之前的自动测试。
他们也承认，并发修改仍可能冲突。Anthropic 表示 Claude 通常能比人类更快完成修复，但没有公布量化结果。
GitHub 其实也没闲着
看到这里可能会问：GitHub 自己在做什么？
实际上 GitHub 也在重做底层。10 月 28 日它披露，今年新增了 400 万个 CPU 核心和 160PB 高速存储，并继续把服务迁往 Azure。
资源之外，排队方式也得改。过去即使几个 Agent 分别在不同分支上提交修改，仍可能在同一个仓库的写入环节互相等待。GitHub 正在让这些更新并行处理，减少不必要的排队。
△左侧按整个仓库排队，右侧允许不同分支等引用的更新并行进行
代码写进去之后，还有大量自动测试任务来取用。GitHub 也在把读和写使用的资源分开：取代码的任务多了，就单独给读取服务扩容，减少两边争抢资源。
这些改造仍在分阶段推进。
OpenAI、Cursor 开始自己做代码托管，Anthropic 重做内部系统，GitHub 改造基础设施——各家都在应对 AI 带来的开发工作量。
- A 社三大内部模型曝光：领先 Opus 5.5 三个月，RSI 把实验时间缩短 80%（2026-11-06）