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氪经授权发布。