AI狂写代码！Anthropic的CI系统被直接砸瘫

当大语言模型接管了绝大多数代码编写工作，你以为程序员终于能松口气？某头部AI公司的真实内部案例给出了相反的答案：最先被压垮的，竟是公司的持续集成系统。

据披露的数据，这家公司80%的代码直接由AI辅助工具生成，工程师平均每季度交付的代码量，达到过往五年平均水平的整整8倍。更值得注意的是，AI不仅负责疯狂产出代码，还在代码合并请求的审查、批准环节承担了大量主力工作。

写代码不再是瓶颈，代码审查也不再卡脖子，但整个持续集成系统，却在半年之内被汹涌而来的代码直接“砸瘫”了。团队统计显示，测试用例狂飙10倍，CI运行任务量在短短6个月内爆炸式飙涨25倍。

面对随时宕机的危险，团队连续三次尝试紧急打补丁：增加核心算力、分片处理、每日强制重启，但结果一次比一次糟糕，最后一个补丁连一天都没撑住。

为什么代码写得快，CI会直接暴毙？最根本的原因在于，AI写代码的“行为模式”，与人类有着本质区别。

在传统软件研发流程中，人类工程师需要构思、敲键盘、本地调试，一天能提交的合并请求数量有限，且往往倾向于把一堆相关改动打包成一个中大型请求。再加上人类每天总归要休息，CI集群因此有充分的低谷期来消化任务。

但换成AI作为主力研发工具后，整个研发节奏彻底变天：

• 更小、更碎、更密集的请求：AI极其偏爱提交粒度极细、体量更小的合并请求，一个小修改就是一个单独请求，导致全系统在单位时间内需要触发的流水线频次呈几何级增长。
• 24×7永动机，全天候高频轰炸：最要命的是，AI代理根本不需要睡觉。除了白天配合人类的高并发突发提交，AI还在深夜和周末不间断地跑任务、提代码、做重构，原本的系统“低谷期”被彻底抹平。
• 伴生测试用例爆炸：AI写完逻辑后，会顺手写出密密麻麻的单元测试和集成测试，整个代码库的测试规模激增10倍。如果换作传统做法，让每个合并请求都跑全量测试，CI流水线早就彻底超时卡死。

为此，团队打造了一套确定性测试影响分析服务，核心依赖两个组件：记录每次CI运行测试结果的监听器，以及根据历史结果决定每个请求该跑哪些测试的选择器。

然而，这套在“人类研发时代”运作良好的架构，埋下了一个致命隐患：单点写入。为了保证所有测试历史严格按时序记录，系统最初设计为单进程写入模式。但面对AI每秒持续倾泻而来的数千上万个并发任务，监听器开始严重滞后。

在AI原生开发生命周期中，哪怕监听器仅仅落后20分钟，就会导致数万次测试状态无法同步给选择器。结果，错误代码被合并，其他工程师开始排查与自己无关的报错；偶发失败的测试开始阻塞合流；新增或修复的测试无法及时生效，回归风险飙升。

接下来的三次经典“快速止血”尝试如下：

第一次补丁：更换算力更强的机器，把核心数翻倍。谁都知道这是临时的，但没人想到它只撑了70天。

第二次补丁：采用分片架构，不再需要全局单一写入者，改为每个代码包一个独立的分片工作节点。这个方案撑了29天。

第三次补丁：每日自动重启。到了2026年3月，这台不断打补丁的单体服务彻底崩溃。每个工作日刚过午后，进程就会直接触发内存上限。团队排查了半天只找到4个微小Bug，尝试替换内存分配器以优化垃圾回收，全部无济于事。

由于单点服务承受着超高负载，团队根本不敢冒着全线停摆的风险给它做生产环境内存分析。无奈之下，工程师启用了每日定时自动重启的绝招，然而在AI每秒几十倍的并发倾泻下，这套古老的“重启大法”连一天都撑不过去。每日重启造成了严重的任务数据丢包，监听器经常连续落后1小时以上，测试选择器只能拿着陈旧数据瞎猜，导致全公司CI全线亮起大红灯，大面积瘫痪。

被逼到绝境的工程师，最终选择彻底推倒原有架构重来。

新架构的核心思路极为干脆，彻底剥离单体内存状态，转向分布式无状态设计，引入内存数据存储——异步轻量汇聚——选择器秒级只读解耦。效果也是立竿见影，在上线切换并完成调优后，此前每周都在疯狂攀升、动辄堆积数十万的未处理事件队列，瞬间被拉成了一条贴地的水平直线。

这次事故的意义，在于它验证了一个更根本的判断：AI编程真正带来的冲击，已经从“程序员会不会失业”，进入“整套软件工程体系会不会过载”。一个过去不起眼的单实例服务，完全可能成为整个团队等待的瓶颈。

AI编程的竞争，正在从代码生成能力，延伸到整套工程体系的承载能力。谁能让测试及时反馈、让结果可靠流转，谁才更有机会把新增代码变成真正可交付的软件。代码可以一夜暴增，交付能力得跟上。