Anthropic 的工程师现在每个季度交付的代码量，是 2021 到 2025 五年均值的 8 倍。其中 80% 由 Claude 写成。代价来得也快：六个月内，CI 任务量涨了 25 倍。这不是一个关于模型有多强的故事，而是一个基础设施被自己的成功压垮的故事。
代码产量翻八倍，先塌的是流水线
写代码快了，验证没跟着快
过去一年，几乎所有工程团队都在算 agent 能替自己写多少代码。很少有人把后半句算清楚：这些代码要通过多少道验证才能进主干。产出端 8 倍，流水线端 25 倍，两条曲线根本不在一个量级上。原因不复杂——写代码是并行的，一个人开着几个 agent 同时推进；而验证是串行的，测试要跑、构建要过、合并队列要排队。瓶颈从人手里那支笔，转移到了机房里那排机器。
旧版测试选择为什么失灵
在 agent 大规模涌入代码库之前，多数单仓团队靠一套叫测试影响分析的机制压住 CI 成本：改动落在哪些文件，就只跑跟这些文件相关的测试。这个思路在小步提交、改动集中的年代很管用。问题出在 agent 的改法上。它改一个函数签名，顺手把三十个调用点一起修了；它重构一个模块，波及范围横跨好几个包。改动面一宽，静态推导出来的"相关测试"集合迅速膨胀，最后跟全量跑没差多少——你付出了复杂度的代价，却没换来时间。
把跑测试当成系统问题，而不是脚本问题
Anthropic 团队的复盘里有一个很关键的转身：他们没有去优化某个 CI 脚本，而是重新定义了问题。哪些测试必须跑、哪些可以跳过、跳过的依据是什么、判断错了谁兜底——这四个问题一旦当成系统来设计，后面的架构选择几乎是自动浮现的。工程团队最容易犯的错，是在一个已经选错的问题上做得越来越精细。
静态依赖图不够用了
真实执行记录比声明式依赖更诚实
构建系统给的依赖图是声明式的：模块 A 声称自己依赖模块 B。这类图有两个毛病。一是偏保守，声明了依赖不等于运行时真的碰到；二是偏乐观，测试通过动态导入、配置、反射碰到的东西，图里根本看不出来。Anthropic 的做法是把真实运行记录叠上来——每次测试跑完，记下它实际接触过哪些源文件；历史跑得越多，这张经验映射就越准。静态图回答"理论上可能相关"，执行数据回答"实际上真的相关"，后者才是决定该跑哪些测试的依据。
不是跑或不跑，而是给一个概率
把测试选择做成二值判断，是另一处常见的思维陷阱。要么跑、要么不跑，中间没有缓冲区，那么阈值定在哪里都会有人骂。更合理的做法是给每条"改动—测试"关系打一个分数，再按分数和风险偏好切片。核心路径上的改动，门槛放低；边缘工具的改动，门槛抬高。这样一来，CI 成本变成一个可以调节的旋钮，而不是一个非黑即白的开关。团队讨论的也不再是"要不要跳过测试"，而是"这个改动我们能承受多大的漏测概率"。
拿不准就多跑，这不是浪费
效率系统必须内置刹车。对那些历史数据稀薄、或者处在关键路径上的文件，正确反应是扩大测试范围，而不是赌一把。这不是保守，是成本核算：多跑几分钟测试的代价，远小于主干断掉之后十几个工程师停下来排查。真正浪费算力的，是那种"看起来很聪明"的激进裁剪——它在平时替你省 3%，在关键时刻让你赔掉一整天。系统的可靠性，取决于它如何对待自己不确定的部分。
省时间的系统，前提是不闯祸
合并队列是最后一道闸
测试选择做得再聪明，也只是概率上的取舍。所以必须有一层机制，在多个改动叠加之后重新验证——这就是合并队列存在的意义。单个 PR 各自通过，合到一起未必通过。当 agent 让提交频率成倍上升，队列本身也会变成瓶颈，需要按优先级调度、按相似性批量验证。换句话说，你不能只优化"跑哪些测试"，还得优化"什么时候跑、跟谁一起跑"。
别只看省下多少，要看漏掉多少
衡量这类系统，最容易用错的指标是时间节省率。它好看，也危险。真正该盯的是漏检率：有多少本该被拦下的失败，被测试选择放过去了。Anthropic 的复盘把评估重点放在这上面——用历史数据反复回放，看新策略在真实改动上的召回表现。这个指标不好看，也不适合放进季度汇报的封面页，但它决定了这套系统是帮你提速，还是帮你埋雷。
省下来的算力，花在刀刃上
测试时间降下来之后，多出来的机器不是让你提前下班的。它可以拿来跑更狠的检查：更长的模糊测试、更严格的静态分析、真实环境下的端到端验证。agent 生成代码的速度上去了，就意味着进入主干的候选代码变多，验证的深度理应同步加深。如果省下来的资源只换来更多的闲置产能，那这次优化就只完成了一半。
这套东西，别的团队能抄走多少
先量清楚，再动手
绝大多数团队连自己的 CI 里哪些测试在浪费时间都不知道，就开始讨论要不要上智能测试选择。顺序反了。先做统计：哪些测试几乎从不失败、哪些测试的失败从没指向过真实缺陷、哪些包每次改动都会触发全量测试。这张账单一摆出来，往往有一半的优化空间根本不需要新系统，删掉冗余用例就够了。
别急着把 LLM 塞进每个环节
这类问题有一个诱人的错误答案：让模型来判断哪些测试相关。听起来很自然，实际上你只是把一个概率问题又套了一层不确定性。Anthropic 的做法更像是把确定性工具用在确定性任务上——构建图、执行记录、评分阈值，都是可解释、可调试、可回滚的。模型适合写代码，不一定适合当调度器。把 LLM 放进关键路径之前，先问一句：它出错了，你怎么知道？
Agent 写得越多，工程判断越值钱
这份复盘最值得琢磨的地方，不是某个具体架构，而是它暴露出的一个趋势。当代码的边际成本趋近于零，工程团队的稀缺资源就从"写"转向了"判断"——判断哪些测试值得留、哪些风险可以承担、哪条路径必须保守。八倍的代码量没有让工程师变得多余，反而把他们的品味和取舍放大了八倍。工具会继续进化，这个比例只会更极端。
