OpenAI 官方博客发了篇长文，字里行间透着一股无奈：AI 写代码实在太猛，把公司内部的代码管理系统直接干崩了，逼得他们连夜魔改 Git。
- 发生了什么：Codex 让并行开发暴增，原有 Git 系统可靠性跌破 90%。
- 真相是什么：OpenAI 没换工具，而是魔改了 Git 后端 Pando，兼容原有工作流。
- 影响是什么：推送延迟降低近 5 倍，每天吞吐近 1 PB 数据，基础设施被 AI 倒逼升级。
AI 狂飙突进的时代，最先崩溃的往往不是代码逻辑，而是承载代码的基础设施。OpenAI 这次被迫重写 Git 后端，给所有试图用 AI 搞人海战术的团队敲了警钟：产出速度翻倍，后端的吞吐量不跟着翻，系统早晚得宕机。
过去这一年，OpenAI 的单仓库规模和需求涨得离谱。原因很简单，Codex 让工程师能同时干更多的活。一个人手里捏着好几个改动等着跑 CI，每次推送又触发一堆任务去拉同一个提交。去年底，老系统终于扛不住了。拉取和推送慢得令人发指，合并经常失败，可靠性一度掉到 90% 以下。面对这种情况，他们没选择抛弃 Git。毕竟 Git 是靠着邮件发补丁起家的，大家用了二十多年。如果直接换个新系统，工程师和 AI 智能体的工作流全得推翻重来。于是他们搞出了 Pando。这玩意儿是个全新的 Git 后端，最绝的是，它完全兼容 Git 协议。工程师和 AI 智能体根本感觉不到底层换了，照样用原来的命令敲代码。
很多人以为扩容就是加机器，但 Git 的痛点在于写和读的冲突。传统方案要么用三阶段提交让所有节点排队，要么用预写日志在存储里排序。这些方法在超大规模并发下都会互相等待。Pando 的解法很粗暴但有效：把分支更新彻底解耦。不相关的分支更新直接并行处理，各走各的。代价是，如果你同时看多个分支，可能会看到它们处于不同的时间点。但这对于疯狂开分支的 AI 辅助开发来说，根本不算事。读取方面，Pando 不再给每个客户端单独生成压缩包，而是直接复用缓存里的字节。客户端可能会多下点已经有的对象，但服务器端省下了海量的计算资源。结果就是，中位推送延迟直接砍掉近 5 倍，每天能往外吐近 1 PB 的 Git 数据。
Pando 的架构思路虽然好，但不适合小团队。如果你的团队只有十几个人，每天提交不到一百次，去魔改 Git 后端纯属给自己找不痛快。这种重量级改造只适合几百人规模、重度依赖 AI 智能体并发写代码的超大单仓库。小团队老老实实买个好点的商业 Git 托管服务更省钱，别为了用 AI 把运维成本搞上天。强行套用大厂架构，最后只会让运维天天半夜起来修数据库，研发照样因为拉代码慢而骂街，典型的花钱买罪受。
如何判断你的团队是否需要升级代码管理基础设施？看三个硬指标。第一，每天合并请求数量是否超过 50 个且还在持续增加。第二，CI 流水线排队时间是否经常超过 15 分钟，导致研发只能干等。第三，研发群里抱怨拉取代码慢、推送超时的频率是否每周都有。如果中了两个以上，说明你的代码托管服务器已经成了 AI 提效的致命瓶颈，该考虑优化底层架构或者换更贵的商业套餐了，别在烂泥上建高楼。
别光盯着 AI 帮你写了多少行代码，看看你公司的 CI 流水线能不能扛住。当 AI 智能体开始自动开分支、自动提 PR，你的代码托管服务器如果还是单线程排队，等待你的就是无休止的合并冲突和拉取超时。OpenAI 把改进开源到了他们的 Git 分支里（代码仓库： ，安全披露： ，内部站点： ）。如果你公司的运维天天抱怨代码库太卡，不妨把 Pando 的架构思路甩给他们看看。想复现这套思路，先评估下你们单仓库的体积，如果超过 50GB，普通的 Git 客户端在 Windows 上跑起来会非常吃力，建议直接上 Linux 环境或者升级内存。
看完想聊两句？
代码库卡吗？AI提效后，CI流水线扛得住吗？
往期推荐
- ·查阅招股书，Anthropic单季亏损233亿美元
- ·
- ·5 个月写百万行代码，OpenAI 团队让 AI 自己踩油门
点击公众号头像 → 历史消息，可翻阅以上文章
