Claude写代码太快，Anthropic连源码系统都重造了！7人只用5个月
新智元报道
今年5月，公司每天平均合并约2500次代码变更；到9月，这个数字已超过3万，达到原来的12倍以上。
Anthropic公布的2026年1月至9月每日代码合并量。（图源：Anthropic）
为了跟上这股爆炸式增长，一个7人团队仅用5个月就自建了全新的版本控制系统Scion，并将公司的单体代码库从Git完整迁移了过去。
Claude写代码太快，把原有工具推到了瓶颈；可等到团队重造工具、解决问题时，用的还是Claude。
可以把软件想象成一本许多人共同修改的书，其中有人改第一章，有人补最后一章，还有人负责统一全书的术语。
这些修改还要汇总起来，检查是否相互冲突；发现问题后，还要知道谁改过哪里，以及怎样退回之前的版本。
版本控制系统负责保存修改记录、协调变更。至于改完的软件能否正常运行，还要经过构建和测试。
而随着AI不断提交修改，后面的环节也要跟着提速。否则，代码生成得越快，等待处理的任务就越多。
把两次复盘放在一起看，AI写代码的速度上去了，审查、测试和合并等后续环节的压力也随之增加。
通俗地说，任务需要哪部分资料，就取哪部分；能直接向服务器查询的问题，就不必为了一个答案，先把大量资料搬到自己这里。
据Anthropic披露，以CPU和内存需求衡量，Scion的基础设施规模约为此前Git镜像基础设施的1/200。
后来，他们让Claude Mythos Preview的内部早期版本重新编写。官方称，重写后的版本，速度达到原来的4倍，内存占用约为原来的1/20。
这也解释了为什么Anthropic的7人团队，能在5个月内完成这次系统建设和迁移。
Meta在2022年介绍Sapling时，就说明过它如何应对代码库增长，并开放了兼容Git的客户端。
这条路线有长期的工程积累，不同项目的起点和范围也不同，不能只拿开发周期比较效率。
Anthropic同样明确表示，Scion面向极大规模的代码库，并非适合一般用途的Git替代品。
因此，工程师需要判断：为什么当初这样设计？哪些条件必须坚持？今天省下的时间，会不会变成明天的维护负担？
功能越加越多，界面越改越复杂；一次修改解决了眼前的问题，又影响了此前正常的部分。
删掉不必要的需求，理清功能之间的关系，甚至否决一个已经写出来的方案，同样是开发工作。
对普通人来说，难点也在这里：发现一个功能不好用并不难，但问题出在哪里、该改哪一部分、改完会不会影响其他功能，仍然需要知识和经验来判断。
在Anthropic的这个7人团队里，工程师同样需要理解系统之间的关系、作出架构取舍，并审核AI提交的变更。
判断AI编程是否好用，不仅要看代码写得有多快，更要看做出来的产品能不能正常使用、功能是否符合需求、出了问题能不能修好。