代码多写八倍，你的 CI 半年涨 25 倍
Hello，我是飞飞。
先问你件事：你每个月为 AI 花的钱，能报出几个数？
我猜大多数人只报得出一个，模型账单。上个月我也是这么想的。那阵子我写了篇 Uber 怎么把 AI 的账拆成六项相乘，一项一项往下压，写完还挺得意，觉得自己这笔账总算算明白了。Uber 那套拆法是：用户数、每人会话数、每会话轮次、每轮请求数、每请求 token 数、每 token 单价。能下手的就中间三项，说的都是同一件事，agent 为了帮你干活，自己多烧掉的那些。
我当时以为成本是省出来的，Uber 告诉我它是压出来的。
可这个月刷到一条东西，我才发现我盯的那本账，只是其中一本。
这账不在 token 上
这个月我刷到一篇 Anthropic 的官方博客，作者是他们的工程师 Sachin Malhotra，标题翻过来是《agentic coding 正在给 CI 施加压力》。
CI 这东西，说人话就是每次你改完代码，自动帮你跑一遍测试、检查有没有把别处弄坏的那套流水线。它跑在服务器上，你平时看不见它。
Anthropic 说的是，他们真正被撑爆的不是模型账单，是这套东西。
Uber 那六项乘数里，一项都不包含它。
AI 省下的时间不会凭空消失，它只是把账单挪了个地方记。像你把客厅的电费省下来，回头发现车库里多了台一直开着的冰柜。不打开那扇门，你永远不知道它在转。
半年涨了二十五倍
先把数摆出来。这些全是 Anthropic 自己报的，没有第三方审计，当参考不当铁证。
他们每季度交付的代码量，是 2021 到 2025 那几年的八倍。其中八成由 Claude 写。代码库里的测试数量涨了十倍，工程师呢，基本没多招人。这几件事凑一起，六个月内 CI 任务涨了二十五倍。
但这个二十五倍，容易读歪。
它不能直接翻译成「AI 让 CI 涨了二十五倍」。测试数自己就涨了十倍，人也得算一份。AI 带来的变化是它提交的改动切得更碎、也更多。作者还特意补了一句：并不是每个测试都在每一次改动上跑。
那他们靠什么撑？靠一套叫测试影响分析的机制。它的办法很朴素：只跑这次改动真正碰到的那几个测试。
这套东西的死穴也在这儿。它得一直读历史，而历史得一直保鲜。落后一步，它的判断就开始失真。
补丁的寿命在变短
全文最刺我的是这一段。
那套服务顶不住，他们打了三次补丁。每一次都知道是权宜之计。
第一次是十月，加机器，把核数翻倍，撑了七十天。第二次是二月，改成按模块分片，撑了二十九天。第三次是三月，每天重启一次进程，撑了不到一天。
七十天，二十九天，一天。像止痛药，第一片管得久，后面越吃越短。
他们也不是没试别的。查内存问题只翻出四个 bug，换内存分配器没用，又不敢在重负载下做内存剖析。最后只能每天重启。
而每日重启带来一个新麻烦：服务会慢慢落后。落后超过一个小时的时候，大量测试结果根本没被记下来。于是决定跑哪些测试的那个部件，是在用过期数据做判断。
作者澄清得很老实。这不代表 CI 没跑，也不代表没测过的代码上了生产。真实后果是他们在跑那些本来就时好时坏、或者本来就大面积失败的测试。测试假红这东西，费的钱跟真红差不多。
重做完，账反而更贵
最后他们还是重写了。他们把结果从那个进程的内存里搬进了一个独立的内存数据库，然后就能一台一台往上加机器了。
我喜欢这篇的一个地方，是它没把重写写成一劳永逸。原文直说，这个新架构跑起来更贵。
他们没把成本压下去。做的是把一笔压不住的成本，换成了一笔更贵、但看得住也扩得动的成本。
还有个数字值得单独看。这个重写项目，一个工程师三周做完。一年前，同样的活要接近一个季度。
两件事一起看就有意思了。打补丁买到的时间在缩水，重做的成本也在缩水。作者给的结论是，既然如此，不如一开始就把架构按十倍二十倍的规模去设计，别怕过度设计。他还说了一句，「过度工程这个概念正在开始淡出」。
它一直在催，人一直在撑
这篇里我最想拿出来说的是一个细节。
作者在内部一个 Claude 工具上开了个长期会话，专门盯着这个服务。只要积压超过五万个任务，Claude 就弹条消息提醒他，接着上次的上下文继续聊。这个会话挂了好几个月。
然后原文写了这么一句：Claude 经常主张干脆彻底重写，但我们通常还是又选了一个补丁。
我看到这句的时候笑了，笑完有点不是滋味。AI 在那儿一遍遍说这个得重做，人在那儿说再撑撑。
把这半年的很多事串起来看，好像都是这个形状。最新的模型在催你做长期正确的事，你手上那份急着要交的活，一次次把它推后。
我又想了一遍那笔账怎么涨到二十五倍的。AI 把「重写一遍」这件事的成本打下来了，三周能干完一年前一个季度的活。可人做决定的那一下，成本一点没降。
交付真的变快了吗
写到这里得泼一盆冷水，不然这篇就成了「大厂好厉害」。
DORA 那份年度报告盯了四项指标：交付速度、部署频率、变更失败率、故障恢复时间。四项都没有随着 AI 工具用得更多而变好。更扎心的是，变更失败率最低的那批团队，恰恰是最不常用 AI 辅助的。
还有 METR 做的一个随机对照试验。他们找了十六个有经验的开源开发者，在各自真实的复杂代码库上干活。结论是用 AI 工具那组完成任务慢了百分之十九。而这些人自己预测的，是会快百分之二十四。
不过这几份数据的分量不一样。METR 那个是十六个人的小样本，不能当普适结论用。DORA 是问卷加行业数据，也只能看趋势。还有份 CloudBees 的调查说，七成受访者认为测试维护比写代码更累。不过这家公司自己就卖测试优化产品，利益是相关的。
这几份数据指向同一件事：写代码确实快了，交付没跟着快。那省下来的时间去哪儿了？一部分吃在返工里，一部分沉在这套没人盯着的流水线上。这两本账，一本都不在 AI 的账单上。
我也有笔账没数过
说回我自己。
我没有 CI，只有一条跑了快一年的内容流水线。按 Anthropic 这个思路对照，我那条流水线的车库里，也停着一台从来没打开看过的冰柜。
去年冬天那次我一直记着。
那天流水线的构建全绿，一路绿灯。真正出事的是最后一步，推代码的认证悄悄红了。整条链路就那么挂了一整天，没人知道。第二天我才发现。
我当时的结论是，自动化最贵的成本，藏在没人盯着的时候。
现在看，Anthropic 说的那个监听部件落后，就是同一件事的另一种长相。你没在看的那段时间里，它不会停下来等你，只会拿着错的数据继续往前跑。
当然我也不是全在打补丁。
有件事我改对过一次。那份 CLAUDE.md，每一行每一轮都要被原样重发一遍。用不上的旧规矩，也照发照付。
我把它从 12K 砍到 4K。砍掉的全是早就用不上的部分。
改完之后，缓存命中率从三成跳到七成三。那个月的账单，106 美元变成 33 美元。
那一次我动的，是我每轮喂进去的东西。
我打算怎么开始
这周我准备干一件很土的事：把流水线跑一整轮的输入输出全打出来，看看每一轮到底带了多少用不上的东西进去。
这笔账不查则已，查了心里才有数。不然下次有人问我「你这条流水线一个月烧多少钱」，我只能报出模型那一项。就像 Uber 那六项，我原本只盯着最后一格。
你那边的账呢。你手上有没有哪一笔开销，是你从来没在任何账单上找过、但确实每个月都在发生的？
我猜那笔账多半也是这个形状：它一直在催你处理，你一直在说再撑撑。