Claude写代码太快，Anthropic连源码系统都重造了！7人只用5个月

新智元报道

一天合并超过3万次代码，Anthropic原有的开发工具跟不上了！

10月13日，Anthropic在官方工程博客中披露：

今年5月，公司每天平均合并约2500次代码变更；到9月，这个数字已超过3万，达到原来的12倍以上。

Anthropic公布的2026年1月至9月每日代码合并量。（图源：Anthropic）

为了跟上这股爆炸式增长，一个7人团队仅用5个月就自建了全新的版本控制系统Scion，并将公司的单体代码库从Git完整迁移了过去。

有意思的是，这里形成了一个颇为魔幻的闭环：

Claude写代码太快，把原有工具推到了瓶颈；可等到团队重造工具、解决问题时，用的还是Claude。

Claude惹出的问题，还得Claude来解决。

一天3万次合并

代码写完之后还得排队

「一天3万次合并」，究竟意味着什么？

可以把软件想象成一本许多人共同修改的书，其中有人改第一章，有人补最后一章，还有人负责统一全书的术语。

各自的活儿干完，工作还没结束。

这些修改还要汇总起来，检查是否相互冲突；发现问题后，还要知道谁改过哪里，以及怎样退回之前的版本。

版本控制系统负责保存修改记录、协调变更。至于改完的软件能否正常运行，还要经过构建和测试。

而随着AI不断提交修改，后面的环节也要跟着提速。否则，代码生成得越快，等待处理的任务就越多。

Anthropic所遇到的，正是这样的压力。

三次补救

撑住的时间越来越短

这已经不是Anthropic第一次为代码增长重建工具了。

9月14日，公司在另一篇官方文章中披露：

持续集成（CI）任务量在六个月内达到原来的25倍。

持续集成，可以理解为代码修改后的自动构建和检查流程。

任务越来越多，负责判断「这次修改应该跑哪些测试」的服务，开始跟不上节奏。

团队先增加处理能力，再把任务拆给多个工作进程，后来还尝试每天重启服务。

三次临时补救维持的时间分别是：

70天、29天、不到一天。

很明显：修修补补能争取到的时间，越来越少。

最终，一名工程师用三周重构了这个服务。

新架构的运行成本更高，但更容易扩展，调优后保持了稳定。

测试选择服务重构并调优后，待处理事件积压趋于平稳。（图源：Anthropic）

这篇复盘还提到，Claude倾向于提交更小、更细的修改，也会在夜间和周末工作。

修改被拆得更细，工作时间也拉长了，后面的测试系统自然要接住更多任务。

把两次复盘放在一起看，AI写代码的速度上去了，审查、测试和合并等后续环节的压力也随之增加。

7人5个月

Anthropic重造源码系统

面对源码管理的瓶颈，Anthropic选择了自建Scion。

它的一个主要变化，是把更多操作交给服务器处理，客户端按需获取数据。

通俗地说，任务需要哪部分资料，就取哪部分；能直接向服务器查询的问题，就不必为了一个答案，先把大量资料搬到自己这里。

Scion通过分层缓存，按需向任务提供代码数据。（图源：Anthropic）

少搬数据，少做重复工作，更多任务才能同时推进。

据Anthropic披露，以CPU和内存需求衡量，Scion的基础设施规模约为此前Git镜像基础设施的1/200。

这一对比限定在源码管理所用的基础设施，不能直接换算成整个公司的开发成本。

而在重建过程中，Claude还给团队带来了一次意外的提速。

团队曾手写过第一版Git到Scion的数据导入管线原型。

后来，他们让Claude Mythos Preview的内部早期版本重新编写。官方称，重写后的版本，速度达到原来的4倍，内存占用约为原来的1/20。

AI带来的代码增长，要求工具跟着升级；AI的编程能力，又帮助团队加快了升级。

这也解释了为什么Anthropic的7人团队，能在5个月内完成这次系统建设和迁移。

当然，大公司为超大代码库自建工具，早有先例。

Meta在2022年介绍Sapling时，就说明过它如何应对代码库增长，并开放了兼容Git的客户端。

这条路线有长期的工程积累，不同项目的起点和范围也不同，不能只拿开发周期比较效率。

Anthropic同样明确表示，Scion面向极大规模的代码库，并非适合一般用途的Git替代品。

对多数团队来说，更值得思考的问题是：

当AI提交的修改越来越多，自己现有的流程会先堵在哪里？

工程师还要做什么

在这次项目复盘里，Anthropic特别强调了工程师的一项工作：

对Claude说「不」。

接到任务后，AI可以提出方案、写出实现。

但一个局部可行的办法，放进整个系统里，可能增加新的复杂性，也可能违背原有约束。

因此，工程师需要判断：为什么当初这样设计？哪些条件必须坚持？今天省下的时间，会不会变成明天的维护负担？

这些判断，很难只靠眼前几行代码得出。

你用AI做一个小工具时，也可能遇到类似问题。

功能越加越多，界面越改越复杂；一次修改解决了眼前的问题，又影响了此前正常的部分。

这时候，继续让AI添加代码，未必能让结果更好。

删掉不必要的需求，理清功能之间的关系，甚至否决一个已经写出来的方案，同样是开发工作。

对普通人来说，难点也在这里：发现一个功能不好用并不难，但问题出在哪里、该改哪一部分、改完会不会影响其他功能，仍然需要知识和经验来判断。

在Anthropic的这个7人团队里，工程师同样需要理解系统之间的关系、作出架构取舍，并审核AI提交的变更。

一天超过3万次合并，让「生成代码之后怎么办」这个问题变得无法回避。

判断AI编程是否好用，不仅要看代码写得有多快，更要看做出来的产品能不能正常使用、功能是否符合需求、出了问题能不能修好。

后续环节跟得上，靠AI写代码省下的时间，才不会又耗在等待和返工里。

参考资料：

https://x.com/AnthropicAI/status/2110047081414987957

编辑：元宇