Claude写代码太快，Anthropic连源码系统都重造了，7人只用5个月 - LOL赛事前瞻

一天内代码合并次数突破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天、不到一天。

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

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

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

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

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

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

将两次复盘结合来看，AI写代码的速度提升了，审查、测试和合并等后续环节的压力也随之增加。

7人5个月，Anthropic重造源码系统

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

其主要变化是将更多操作交由服务器处理，客户端按需获取数据。

通俗地说，任务需要哪部分资料，就只取那部分；能直接向服务器查询的问题，就不必为了一个答案而先搬运大量数据。

Scion通过分层缓存，按需向任务提供代码数据。

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

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