Anthropic 在 9 月 14 日发了一篇工程博客，作者 Sachin Malhotra 讲的是自家一项内部服务被压垮又重写的过程。这项服务叫测试影响分析，职责很单一：一次代码改动进来，判断哪些测试必须跑、哪些可以跳过。听上去是个后台组件，但它撑不住的原因很有代表性。
先看几个倍数
博客给出的第一组数字是产出侧的：Anthropic 的工程师现在平均每季度提交的代码量，是 2021 到 2025 年那个区间的 8 倍，其中 80% 的代码由 Claude 写，Claude 同时还在评审和批准 PR 的环节里占了很重的分量。
第二组数字是压力侧的：代码库里的测试总数涨了 10 倍，六个月内 CI 任务数涨了 25 倍。
第三组数字最能说明事态节奏。团队为了顶住负载做过三轮临时缓解，每一轮买来的时间是 70 天、29 天、不到 1 天。第三轮方案上线当天就被吃掉了。
旧服务卡在哪
原来的架构里有一个单进程的 listener，它要把每一项测试的结果按顺序记进存储。单写入意味着没法横向扩容，PR 涌进来的速度一超过它的处理速度，队列就开始堆。博客里的原话是 listener “starts to increasingly fall behind the PR queue”。
延迟带来的后果是复合的。文章举的例子是，二十分钟的滞后对应着数以万计的测试结果更新还没落到存储里。而测试选择这件事恰恰靠历史结果做判断，历史不准，选出来的测试集就不可信。雪上加霜的是这个进程还有内存泄漏，每天跑到下午就顶到上限。
改成了什么
重写的思路是把状态从进程里挪出去。新架构引入了一个内存数据存储：任何一个 listener worker 都可以处理任何一条结果，它只负责往日志里追加，自身不保存状态，于是可以按需要加机器。另有一个独立的消费进程，每隔几秒把日志折叠成按单项测试组织的历史记录。选择器需要决策时，直接查这份历史。
代价是成本上去了。博客承认了这一点，理由是换来了可扩展性和可观测性——哪一段慢、慢在哪里，现在能单独量出来。整个重设计由一名工程师用三周完成。
25 倍这条曲线
六个月 25 倍，折算成月度复合增速大约是 1.71 倍（粗算：25 开六次方）。按这个斜率再往前推六个月，就是 625 倍。作者文末那句 “always plan for the exponential” 并不是修辞，它对应的是一条已经量出来的曲线。
这条曲线的外推当然不可靠——增速会因为内部政策、配额、工程习惯的变化而拐弯，Anthropic 也没有公布 CI 账单的绝对值，没说新服务把多少比例的测试筛掉了，更没有给出重写之后延迟降到了什么水平。省了多少钱这个问题，从公开信息里推不出来。
不过压力从哪一环传到哪一环，这条线索是清楚的。今年 4 月 GitHub 停掉 Copilot 三档个人订阅的新注册，给出的理由是智能体长任务的算力消耗超出了套餐设计；更早一些，AI 提交激增曾经把 GitHub 写到出故障，微软一度回借亚马逊云顶住。三件事的形态不同，指向的是同一件事：代码生成环节先提速，然后是评审，再往后每一个按”人写代码的速度”设计过容量的系统，都要被轮着撞一遍。测试影响分析只是这一轮里比较早报警的那个。
参考来源：CocoLoop、Anthropic 工程博客；代码量倍数、测试与 CI 任务增幅、三轮缓解方案有效期均取自该文公布口径。