一个由Claude Code从零写出的约15万行Rust应用里，数据访问层写着写着长成了一个17155行的单体文件。每一次读写Firestore，都在重复同样的HTTP请求、同样的JSON编解码。作者做了个对照实验：按标准重构手法把这个文件拆成19个文件后，让全新的子agent去完成同一个功能变更，需要读入的输入token从159564个降到27360个，降幅达到83%。
这不是道听途说的行业趋势，而是一次可复现的实验——每次重构后都用全新的子agent执行完全相同的prompt，避免agent"学到"上一次的经验。作者的判断很克制：省钱的关键不是代码变少了，而是agent能更准确地定位到该读哪一小块代码，这套结论建立在边界清晰的重构基础上。
从17155行到19个文件，Token账单降了八成
代表性变更是给数据层加一个ItemWatchStore trait，每次重构后都拿这个变更去跑分。整个过程分15步，从提取重复函数、封装HTTP客户端，到把store逻辑拆进子目录，最终数据访问层的总行数几乎没变（始终维持在1.65万行左右），只是被重新组织进19个文件。输出token几乎没动（1705到2113之间波动），因为写代码的工作量没变，变的只是读代码的范围。
省下的不是代码量，是智能体要翻的那堆文件
- 结论.按Sonnet5每百万输入token 3美元算，132204个token的节省相当于每次变更省0.397美元，钱不多，但每一次触碰这个模块的后续变更都能吃到这笔折扣。
最大单文件行数才是真正的开关
数据摆在一起能看出因果：输入token在最大单文件从17155行降到13845行、9269行时降得并不明显，直到最大文件缩到3695行，才出现作者所说的"断崖式下跌"。这说明真正起作用的不是"文件数量变多"，而是"检索范围变准"——随机把一个大文件切成十几个小文件，如果边界不清晰，agent照样要挨个翻找，未必能省下同样的token。
省钱账没算完：人工规划、耗时波动、上限500万
这次实验的token数字是靠字符数除以4估算出来的，作者明确提到Claude当时没有可靠的实时计数方式。重构本身花了多少token也没被精确记录，作者只能给出一个上限——约500万，这还包含了两次重构规划、实验设计等其他工作。执行时间也不是单向变好：从基线342秒，中间某一步涨到1353秒，最终降到454秒，整个过程耗时约8小时，中途还需要一次人工纠偏。
- 风险.这只是单个开发者维护的绿地项目、只有一个代表性变更的单次实验，不能直接套用到复杂遗留系统的重构预算上。
更关键的是，Claude本身并不擅长判断该重构什么。重构方案是作者按《重构》一书的规范手写出来的，机械改写靠Python脚本调用grep和sed完成，还经常被缩进搞乱。想靠agent自主发现并执行高质量重构，目前还做不到。
对采用Claude Code这类工具的工程团队来说，更现实的做法是先盯住高频改动的模块，算一算这些模块的变更回收周期值不值得投入重构，而重构方案本身，仍然需要工程师亲自设计、亲自盯着执行。