Anthropic的CI系统为何撑不住AI代码量激增

　　Anthropic内部Claude已编写约80%的代码，但这项“AI写代码”的壮举却让自家CI系统在半年内作业量暴涨25倍，三次紧急打补丁均告失效，最终只能推倒重来。

　　一、代码激增让CI成为新的流水线瓶颈

　　产量剧增：Anthropic工程师每季度交付的代码量是2021—2025年平均水平的8倍，其中80%由Claude编写，Claude在PR审查和批准环节同样承担大量工作。

　　压力转移：当写代码不再是瓶颈，PR审查又被加速后，压力集中转移到CI系统。整个代码库的测试数量增长了10倍，而工程师人数仅略有增加，CI作业量在6个月内暴涨25倍。

　　系统告急：为控制每次变更运行的测试范围，Anthropic使用一个确定性的“测试影响分析服务”来选择应运行的测试，这一服务率先承受不住压力。

　　二、三次补丁为何节节败退

　　补丁1（换大机器）：将服务CPU核数翻倍，仅支撑了70天便再度告急。

　　补丁2（分片）：将每个package的状态拆成独立分片并配置独立worker，但只多撑了29天。

　　补丁3（每日重启）：进程在大多数工作日中午后达到内存上限，每天重启只能换来不到一天的稳定，且重启会让服务逐渐落后，漏掉大量作业结果。

　　三、根本症结与最终重构

　　基因缺陷：旧架构依赖单进程维护每项测试的持续历史记录，必须由单一写入者按顺序处理结果，无法通过横向分片扩展。

　　行为差异：AI生成的PR更小、更碎、更密集，且24小时持续提交，这抬高了系统的最低活动水位，也加剧了负载的突发性。

　　推倒重来：团队最终采纳Claude的建议，引入内存数据存储（journal），使listener worker变为无状态服务，可横向扩展；整个重构由一名工程师在3周内完成，若在一年前大约需要接近一个季度。