一天合并3万次代码，Anthropic被自己的AI逼到重造了源码系统

先说结论：Claude写代码已经快到把自己的公司挤爆了。10月13日Anthropic在官方工程博客里披露，今年5月他们每天平均合并约2500次代码变更，到9月这个数字超过3万，翻了12倍以上。原有开发工具扛不住，一个7人团队用5个月自建了全新的版本控制系统Scion，把单体代码库从Git整体迁了过去。

这里有个挺魔幻的闭环：Claude写代码太快，把原有工具推到瓶颈；可团队重造工具、解决问题的时候，用的还是Claude。Claude惹出的问题，最后还得Claude来解决。

一天3万次合并意味着什么，得把软件想象成一本好多人共同改的书。有人改第一章，有人补最后一章，还有人统一术语。各自的活儿干完，工作没结束——这些修改要汇总、检查有没有相互冲突、出了问题要知道谁改过哪块、怎么退回去。版本控制系统负责记变更、调冲突，改完的软件能不能跑，还要走构建和测试。AI不断提交修改，后面的环节就得跟着提速，否则代码生成得越快，排队等处理的任务越多。Anthropic遇到的正是这个压力。

这也不是他们第一次为代码增长重建工具了。9月14日的另一篇官方文章披露，持续集成任务量在六个月内涨到原来的25倍。任务越来越多，负责判断「这次修改该跑哪些测试」的服务开始跟不上了。团队先加处理能力，再把任务拆给多个工作进程，后来还试过每天重启服务。三次临时补救分别撑了70天、29天、不到一天。很明显，修修补补能争取的时间越来越少。最后一名工程师用三周重构了这个服务，新架构运行成本更高，但更容易扩展，调优后保持了稳定。

这篇复盘还提到，Claude倾向于提交更小、更细的修改，也会在夜间和周末干活。修改拆得更碎，工作时间拉长，后面的测试系统自然接住更多任务。两次复盘放一块儿看，AI写代码速度上去了，审查、测试、合并这些后续环节的压力跟着全上来了。

面对源码管理的瓶颈，Anthropic选择了自建Scion。一个主要变化是，把更多操作交给服务器处理，客户端按需取数。通俗说就是，任务需要哪部分资料就取哪部分，能直接向服务器查答案的，不必为了一个结果先把大量数据搬到自己这边。少搬数据，少做重复活，更多任务才能同时推进。按官方披露，以CPU和内存衡量，Scion的基础设施规模约为此前Git镜像基础设施的1/200。这个对比限定在源码管理用的基础设施，不能直接换算成整个公司的开发成本。

重建过程中，Claude还给团队带来一次意外的提速。第一版Git到Scion的数据导入管线原型是手写的，后来他们让内部早期版本Claude Mythos Preview重写了它。官方称重写后的版本速度是原来的4倍，内存占用约为原来的1/20。AI带来的代码增长逼工具升级，AI的编程能力又帮忙加快升级——这大概也是7人团队能在5个月内完成系统建设和迁移的原因。

当然，超大代码库自建工具不是Anthropic先干的。Meta在2022年介绍Sapling时就讲过它怎么应对代码库增长，还开放了兼容Git的客户端。这条路有长期工程积累，不同项目起点和范围都不同，不能光拿开发周期比效率。Anthropic也明确说，Scion面向极大规模代码库，并非适合一般用途的Git替代品。

对多数团队来说，更值得想的问题是：当AI提交的修改越来越多，自己现有流程会先堵在哪。可能是测试，可能是合并，可能是人工审查。

这次复盘里，Anthropic特别强调工程师有项工作：对Claude说「不」。AI能提方案、写实现，但一个局部可行的办法放进整个系统里，可能增加新的复杂性，也可能违背原有约束。工程师得判断当初为什么这么设计、哪些条件必须坚持、今天省下的时间会不会变成明天的维护负担。这些判断很难只靠眼前几行代码得出。你用AI做小工具也可能碰到类似情况：功能越加越多、界面越改越复杂，一次修改解决眼前问题，又影响了之前正常的部分。这时候继续让AI加码，未必能让结果更好。删掉不必要的需求、理清功能间的关系、甚至否决一个已写出来的方案，同样是开发工作。

一天超过3万次合并，让「生成代码之后怎么办」这个问题绕不过去了。判断AI编程好不好用，不能只看生成的代码有多快，更要看产品能不能正常跑、功能符不符合需求、出了问题能不能修好。后续环节跟得上，靠AI写代码省下的时间，才不会又耗回等待和返工里。