新智元报道
新智元报道
一天合并超过3万次代码，Anthropic原有的开发工具跟不上了！
10月13日，Anthropic在官方工程博客中披露：
今年5月，公司每天平均合并约2500次代码变更；到9月，这个数字已超过3万，达到原来的12倍以上。
Anthropic公布的2026年1月至9月每日代码合并量。（图源：Anthropic）
为了跟上这股爆炸式增长，一个7人团队仅用5个月就自建了全新的版本控制系统Scion，并将公司的单体代码库从Git完整迁移了过去。
有意思的是，这里形成了一个颇为魔幻的闭环：
Claude写代码太快，把原有工具推到了瓶颈；可等到团队重造工具、解决问题时，用的还是Claude。
Claude惹出的问题，还得Claude来解决。
「一天3万次合并」，究竟意味着什么？
可以把软件想象成一本许多人共同修改的书，其中有人改第一章，有人补最后一章，还有人负责统一全书的术语。
各自的活儿干完，工作还没结束。
这些修改还要汇总起来，检查是否相互冲突；发现问题后，还要知道谁改过哪里，以及怎样退回之前的版本。
版本控制系统负责保存修改记录、协调变更。至于改完的软件能否正常运行，还要经过构建和测试。
而随着AI不断提交修改，后面的环节也要跟着提速。否则，代码生成得越快，等待处理的任务就越多。
Anthropic所遇到的，正是这样的压力。
这已经不是Anthropic第一次为代码增长重建工具了。
9月14日，公司在另一篇官方文章中披露：
持续集成（CI）任务量在六个月内达到原来的25倍。
持续集成，可以理解为代码修改后的自动构建和检查流程。
任务越来越多，负责判断「这次修改应该跑哪些测试」的服务，开始跟不上节奏。
团队先增加处理能力，再把任务拆给多个工作进程，后来还尝试每天重启服务。
三次临时补救维持的时间分别是：
70天、29天、不到一天。
很明显：修修补补能争取到的时间，越来越少。
最终，一名工程师用三周重构了这个服务。
新架构的运行成本更高，但更容易扩展，调优后保持了稳定。
测试选择服务重构并调优后，待处理事件积压趋于平稳。（图源：Anthropic）
这篇复盘还提到，Claude倾向于提交更小、更细的修改，也会在夜间和周末工作。
修改被拆得更细，工作时间也拉长了，后面的测试系统自然要接住更多任务。
把两次复盘放在一起看，AI写代码的速度上去了，审查、测试和合并等后续环节的压力也随之增加。
面对源码管理的瓶颈，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写代码省下的时间，才不会又耗在等待和返工里。
参考资料：
编辑：元宇
