听雨发自凹非寺
量子位 | 公众号 QbitAI
GitHub，你怎么又出故障了……
11 月 3 日，官方状态页一天就记下了两起故障，其中一起影响 Git 操作。
到了 4 日，合并请求等服务又出现异常，部分请求失败或延迟。
代码改好了，想让同事看看能不能并进主项目，偏偏卡在了这一步。
还有网友因此打趣：正好去喝杯咖啡。
就在 GitHub 忙着抢修的时候，Axios 发出一条独家消息：
OpenAI 拟收购做代码托管工具的 Pierre，交易仍待交割。
这两条消息撞在一起，时间有点赶巧啊。
而且不得不说，做 AI 编程工具的公司，还真有好几家开始自己管代码了。
马斯克旗下的 Cursor，已经允许开发者把整个项目直接存在 Cursor 里。
Anthropic 更进一步，把自家工程师天天用的主代码库搬进了自研系统。
几家公司为什么都开始折腾这件事？
因为 AI 写代码的速度越来越快，基础设施已经逐渐跟不上了……
OpenAI 自己造了一个，还准备再买一家
OpenAI 自己就尝过代码系统跟不上的滋味。
今年 3 月，The Information 就报道过，OpenAI 工程师多次遇到 GitHub 服务中断，公司正在开发内部替代工具。
到了 11 月 2 日——就在前几天，它公开了自己的 Git 后端Pando，负责承接内部代码的存取等操作。
据工程团队介绍，以前，一个工程师手里推进一份改动。有了 Codex，一个人可以同时准备好几份。
而每推送一次代码，又会触发多个自动化任务，去取代码、运行检查。
写代码的人没有突然多出好几倍，系统要处理的工作却增加了。
原来的系统渐渐吃力，拉取、推送变慢，合并也会失败。
Pando 从 4 月起就开始承接真实的开发流量。按 OpenAI 的统计，换上之后，一次推送的中位耗时降了近八成。
自家工程师的问题解决了，面向 Codex 用户，OpenAI 还准备通过收购Pierre，把代码存储等能力带进产品里。
说起来，Pierre 的东西，你可能已经用过了～
假设你让 Codex 修一个 bug，它一口气改了五个文件。
你点开文件列表，找到其中一个，再逐行对照它删了什么、加了什么。
前一个动作，用的是 Pierre 做的 Trees；后一个，用的是 Pierre 做的 Diffs。这两套工具早就接进了 Codex。
Pierre 还有一门生意叫Code Storage，它的客户里，就有 AI 应用开发平台 Lovable。
用户在 Lovable 里输入几句话，就能做出一个网站。在后台，每个项目都要用一个或多个 Git 仓库来保存代码和修改历史。
据 Pierre 今年 8 月披露的数据，当时 Lovable每周新建超过 800 万个仓库，峰值达到每秒 250 个。
OpenAI 打算等收购完成，再把 Code Storage 的能力带进 Codex。
以后，开发者让 AI 写代码、查看它改了哪里，再把这一版存下来，都有望在 Codex 里完成。
目前，这笔交易还要满足监管批准等交割条件。
Cursor 开放代码托管那天，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 上的版本为准。
那问题就来了：写代码、审代码、合并，都能在 Cursor 里办完了，那我还专门打开 GitHub 干啥？
哪怕是老项目，仓库还放在 GitHub，但审代码的人也已经可以不去那儿了。
Claude 写得太快，Anthropic 自己造了一套
OpenAI 和 Cursor 把更多开发操作接进了自己的产品，而到了 Anthropic 内部，工作量已经大到需要重做代码管理系统。
主要还是因为，Claude 写代码写得太快了……
据 Anthropic 披露，今年 5 月，公司平均每天合并约 2500 项代码改动。到了 9 月，一天已经超过 3 万项。
也就是每天有超过 3 万份修改，被合并进团队共同维护的代码版本。
光是用于自动化测试等工作的持续集成任务，每天就要取用约 2500 万次代码。
高峰期，公司维护着数百个 Git 镜像，用这些仓库副本分担负载。可主仓库更新得越快，这些副本就越难维护。
工程师发现，来取代码的大多是始终在线的 Agent 和自动化任务。
有的任务，只是想知道一个文件改了哪几行，何必先在本地备好一份仓库？让服务器算好，把结果发过去就行。
照着这个思路，Anthropic 造出了Scion。
客户端用到哪个文件，再去取哪个。查历史、建提交、合并改动，则交给服务器。
7 名工程师借助 Claude，花 5 个月做出了这套内部版本控制系统，以及配套的代码审查工具 Antique 等，还把公司的主代码库整个迁了过去。
不过，Scion 主要服务于 Anthropic 这种规模庞大、改动频繁的内部代码库。
Claude Code 的公开仓库等社区资源，仍然保留在 GitHub 上。
一天三万项改动，谁来检查？
代码取得更快、存得更顺之后，还有一个更棘手的问题：这些修改，怎么判断能不能用？
在最近一场对谈里，Anthropic 的Addy Osmani介绍了他们的做法：
先让 Claude 做一轮审查，还要给它条件，像真实用户一样把功能跑起来。
比如改的是网页，就让它打开浏览器，检查页面、操作功能，再运行必要的测试。
工程师接着查看它交来的验证证据，包括操作录像、页面截图和测试结果。每项改动仍然有人负责，出了问题，负责人要去处理。
△Claude Code 团队公布的代码改动检查与发布流程
Anthropic 的工程博客里，还提到一个更麻烦的场景：
一轮测试运行期间，代码库里可能又合进了成百上千项改动。
在这样的规模下，团队发现，用仓库全局锁来协调合并队列的方式很难有效运行，于是把精力投向合并后、部署前的自动测试。
公司也承认，并发修改仍然可能发生冲突。
他们称，Claude 通常能比人类发现冲突更快地完成修复，但没有披露相应的量化结果。
One More Thing
读到这你可能会觉得，那 GitHub 呢？
GitHub，其实也没闲着，自己也在重做底层。
10 月 28 日，它披露，今年已经新增 400 万个 CPU 核心和 160PB 高速存储，并继续把服务迁往 Azure。
增加资源之外，原来的排队方式也得变化。
过去，即使几个 Agent 各自在不同分支上提交修改，仍可能在同一个仓库的写入环节相互等待。GitHub 正在让这些更新能够并行处理，减少不必要的排队。
△左侧按整个仓库排队，右侧允许不同分支等引用的更新并行进行
代码存进去之后，还会有大量自动测试任务来取用。
GitHub 也在把读取和写入所用的资源分开。来取代码的任务多了，就给负责读取的服务单独扩容，减少两边争抢资源的情况。
这些改造仍在分步推进。
OpenAI、Cursor 开始自己提供代码托管，Anthropic 重做内部系统；GitHub 也在改造自己的基础设施。
所以说，大家都在应对 AI 带来的开发工作量。
至于咱们用的人嘛，要求倒也很简单：代码写好了，该检查的也检查完了，准备合进去的时候，可别又给我出岔子啊……
参考链接：
[1]https://x.com/FrenchBoulou/status/2117919227147640978
[2]https://x.com/pierrecomputer/status/2117999036175188183
[3]https://www.axios.com/2026/11/04/openai-pierre-computer-github
[4]https://www.anthropic.com/research/redesigning-source-control
[5]https://www.youtube.com/watch?v=AnsXWH2_EBU
