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

本文来自微信公众号“新智元”（ID：AI_era），作者：元宇，36氪经授权发布。