实测 24 个省 token 工具：先告诉你结论——按任务挑 1-2 个，用对省 60%、用错贵 15 倍

2026-06-14

本文适合：① 每天用 Claude Code、想把 token 账单压下来的工程师；② 装了一堆「省 token」工具却不知道哪个真有用的人；③ 想知道一个工具到底该信不该信、怎么自己测出数字的人。

我做数据架构，日常就是给数仓选索引、调 SQL、做查询优化。我们这行有条铁律：没有普适最优的索引，只有匹配某种查询模式的索引。给一张只做全表扫描的表硬建 B-tree，查询不会变快，写入反而变慢。这套工具横评，我用的就是这个眼光，最后结论也长得几乎一样。

把选型结论先拍出来：市面上的「省 token 工具」，没有一个是装上就普适受益的。它们各有一个明确主场，出了主场就反向收费。所以正确做法不是「装最多」，是按你日常八成的活落在哪一类，精挑 1-2 个。具体分三档——短 bash 任务装命令收敛类（如 rtk），中长代码任务装代码索引类（如 tree-sitter-mcp / serena），剩下还有一件零成本、永久受益的事，就是把 CLAUDE.md 瘦身。这篇就讲清楚三件事：工具到底分几类、怎么测才不被平均值骗、以及我那两次多花十几倍的翻车是怎么来的。

我以前真以为这类工具的名字是诚实的。有个叫 cache-fix 的代理工具，听着像缓存救星，GitHub 上一堆 star，README 写着「自动管理 context window，减少重复 token」。我装上，挂到一个新开的 session 跑了个简单重构。同样的活，不挂它是 base，挂上之后反贵了 1534%——一个零头小任务，硬生生烧成十几倍。不是工具不好，是我把它用在了最不该出现的场景。这笔账，是用多花十几倍的真金白银买来的。下面这套结论，就是我把工具拉来挨个跑了 194 次调用、12.77M token 之后磨出来的。

一、24 个工具拆开看只有三类：真省的、看场景的、别装的

一句话：24 个公开省 token 工具，194 次调用、12.77M token 实测后，按「在你的场景里到底省不省」分，干净利落只有三类。 你不用背全表，找到日常八成的活落在哪一类，直接抄对应那一档就行。

第一类：真省的，装上就省，不用动脑子

这一类的特点是：只要场景对，闭着眼装都不会亏。

• 短 bash 任务装命令收敛类，比如 rtk。 单行命令、文件查找、git 日志查询这类活，rtk 把高频命令的输出在塞回历史前先压一遍，git status 两百行变五行摘要那种。短 bash 上实测平均省 68%，代价是首次调用多花一点缓存建立时间，第二次起就是纯赚。但它只在短 bash 上灵，复杂任务上基本没用，甚至因为多挂一层 MCP schema 而倒贴。
• 中长代码任务装代码索引类，如 tree-sitter-mcp 或 serena。 跨文件重构、API 适配、类型定义联调这类活，它们先把项目的 AST 索引建好，Claude 不再每次重新解析整个目录去找符号。中长代码任务上实测 tree-sitter-mcp 能省 67%，代价是初始要建一次索引，建好之后同类任务稳定吃六七成。反过来拿它跑短 bash，又因为多挂一层 MCP schema 而贵 126%——又一个「看场景」的活例子。
• 零成本永久受益：CLAUDE.md 瘦身。 去掉「你是一个 AI 助手」这种废话，去掉重复的代码风格说明，去掉已经写在 ESLint 配置里的规则，把它从几百行压到一百多行。瘦完每个 session 能永久省下约 9,000 token。严格说它不算工具，是配置卫生。它省的是 system 那块每轮都重发的固定开销（S02 拆过，那是账单大头），所以一次瘦身、全程受益，是唯一一个装了就再也不用管的。

第二类：看场景的，用对省 60%、用错贵 15 倍

这一类全是「双向阀门」：同一个工具，主场里是救星，出了主场就反向收费。用之前先确认自己在不在主场。

• 长 session 强制模式：适合 200+ 轮次的持续对话，实测能省到一半左右；但短 session（30 轮以内）开它，反而因为频繁重建 context 倒贴。
• sub-agent 委派：把任务拆给子 agent 跑，cold start（第一次启动）比直接跑贵 108%，但 warm start（5 分钟内复用）省 45%。问题在于大多数人的 sub-agent 都是 cold 的，每次新建、每次重建上下文。你要是不分冷热桶去算平均，它会被平成一个「贵 31%」的假数字，让你白白错过一个好工具。
• cache 稳态：连续做同类任务，cache hit 会一路爬升。ccusage 的记录里，同一个项目 127 天下来稳定在 96.6%；可一换新项目，头几天又掉回很低。稳态是熬出来的，不是开箱即得。换项目的第一周别急着评判工具，那时候 base 本身就高。
• 小模型路由：把简单任务（变量重命名、排序、格式化）路由到 Haiku 级小模型，省 70% 以上；但抽象任务（设计接口、写文档、做架构决策）丢给小模型反而贵 290%——输出质量低，得 3-4 轮修正对话，总 token 比直接上大模型还多。

第三类：别装的，短任务下装了就是反向优化

这一类不是工具差，是它的主场极窄，你大概率不在那个主场里。

• 某些沙箱方案（如基于 Docker 的每次重建环境）在短任务下反贵 497%——每次重建容器消耗的 token 比任务本身还多。它适合安全敏感场景，但别为了省 token 装它。
• 某些代理工具（如 cache-fix 的新 session 场景）反贵 1534%。它适合长 session resumed，新 session 下就是灾难。

（图 5.1）24 工具实测结论矩阵：分三类（真省 / 看场景 / 别装），每个工具标出 hero 数字。一句话带走：用对省 60%、用错贵 15 倍。（建议发布时把这张 ASCII/截图换成 D2 决策矩阵图，绿/灰/红三色分档更直观。）

这张图别背，要对号入座：找到你日常八成的活落在哪一类，直接抄对应的绿格，灰格红格连看都不用看。天天 git / ls / find，就装命令收敛类；天天在大仓库里翻符号、做重构，就上代码索引类；两类都沾，先把零成本的 CLAUDE.md 瘦身做了。省 token 工具的第一原则，从来不是「装得多」，是「别用错」。

二、横评能不能信，全看测得公不公平：五条纪律缺一不可

一句话：一个工具被吹成「省 70%」，往往是它在主场的成绩，换个场景可能直接反贵；要测出能指导自己决策的数字，光看百分比不够，方法得站得住。 我这 194 次调用磨出的方法，核心就一句——别让平均值骗了你。下面五条纪律是它的拆解。

• 控制变量：每次只挂 1 个工具跟 base 比。 不叠加、不混装。挂 2 个工具测出来的结果，你分不清哪个有效、哪个拖后腿。
• 同一任务 ×3 取中位数，不取平均。 有一次 rtk 第一次省 71%、第二次省 68%、第三次因为网络抖动只省 12%。平均值是 50.3%，中位数是 68%——后者更接近真实表现。
• cwd 切到 sandbox 或真实大仓库。 我用一个十来个文件、几千行、混了 React / Express / CLI 三种结构的 sandbox 当主测场，再挑表现最好的几个去真实大仓库复验。两边偏差在个位数百分点以内，说明 sandbox 够代表性，又比每次搬真仓库快得多。
• cold/warm 分桶：每个工具测 5 次，前 2 次 cold、后 3 次 warm，单独报告。 不分冷热桶，sub-agent 的「贵 108%」和「省 45%」就会被平均成一个「贵 31%」的假数字，你可能因此放弃一个好工具。
• Control Z（控制组漂移监控）。 固定一个任务（比如「把 3 个文件里的 console.log 改成 logger.info」），每次测试前跑 5 遍，看 base 有没有变。有一次 Claude Code 更新后，同样任务从 412 token 涨到 439 token，漂移 6.6%；不做 control Z，你会以为新工具效果差了，其实是 baseline 变了。我这 194 次调用里 control Z 漂移最大 1.6%，说明测试环境稳定。

这五条不是学术洁癖，跟我在数仓里「选索引前先看执行计划」是同一套纪律：单变量隔离、重复取中位、控制组防漂移。少一条，你拿到的数字就可能是个会骗你的平均值。

三、我两次翻车都栽在同一件事上：信了名字，没信自己的基准

一句话：这两次多花十几倍的账单，根子都是同一个错——拿别人主场的数字当自己的场景用。 横评做完，我最想留给你的不是那张矩阵图，是这一条：装任何工具前，先花 5 分钟跑一个自己的基准任务，跑出自己的数字。

坑①：被名字骗，从「省 20×」到「贵 1534%」

cache-fix proxy，README 写「reduce token waste by 40-70% in long sessions」。我在 resumed session（长会话重连）上测，是真神，省到 20×，那几天我以为捡到宝了。然后一个新项目进来，顺手把它装上开跑，一个几轮就能完的简单 API 适配任务，挂上之后反贵 1534%。

它的核心是「复用已经建好的 context 索引」，长 session 重连是它的主场；新 session 下它得先把索引从头建一遍，这笔开销比省的还多。教训：工具的名字描述的是它最好的场景，不是你的场景。README 写的是作者在他主场测出来的上限，而你的日常，大概率不是他的主场。

坑②：盲堆叠加，「4 个全开」比 base 只省了不到 1%

我一度以为「4 个工具全开 = 省最多」，逻辑很朴素：rtk 省 68%、tree-sitter-mcp 省 67%、CLAUDE.md 瘦身省 9K、cache-fix 省 20×，加起来还不省上天？实际一测——四个全开、同一个任务，比 base 只省了不到 1%。

原因是工具之间开销互相抵消。rtk 缓存了 bash，可 cache-fix 的 proxy 把 rtk 的缓存又包了一层，每次多跑一次 proxy 的 token 计数；tree-sitter-mcp 的 AST 索引和 cache-fix 的 context 索引又重复了大部分工作。叠加不是加法，是嵌套函数——每层多一次调用开销。教训：精挑 2 个看任务。短 bash，rtk 就够了；中长代码，tree-sitter-mcp 或 serena 选一个；长 session，cache-fix 单独用。别堆。

你自己的命中率，一行命令就能查

不用猜自己在哪一档。Claude Code 每条 assistant message 的 usage 字段里都有这些数字：

{
  "input_tokens": 1247,
  "cache_creation_input_tokens": 0,
  "cache_read_input_tokens": 892,
  "output_tokens": 355
}

文件在 ~/.claude/projects/<proj>/<session-id>.jsonl，每行是一个 message 的完整 JSON，usage 字段在 assistant 角色的 message 里。懒得翻 jsonl，一行命令 npx ccusage@latest 看最近会话的 cache 统计。判断标准：

• cache_read 占比 >90%：健康，context 利用率高、重复 token 少。
• 60%-90%：正常，大部分工作有缓存，有些场景没命中。
• 30%-60%：不及格，session 结构可能有问题（频繁换任务、不延续 context）。
• <30%：你几乎每次都在重建 context，去查 CLAUDE.md 是不是太长，或 prompt 是不是每次重写所有指令。

我自己的 cache hit 是慢慢养上来的：头一两周还在五成上下晃，一个月后上到八九成，长期稳定在 96.6%。最大的一次跳变，来自把 CLAUDE.md 狠狠瘦了一轮——前缀一稳，命中率立刻上一个台阶。这反过来印证了 S02 的结论：账单的命脉是前缀稳定性，CLAUDE.md 正是前缀里你最能动手的那一块。

要是你一查发现命中率长期在不及格线，别急着装工具，先做三件零成本的事。一是给 CLAUDE.md 瘦身，它每轮都进前缀，太长就是每轮都在交税。二是改掉「一个会话里跳着做无关任务」的习惯，一个 thread 只做一类相关的事，让前缀有机会连续命中。三是别频繁手痒改 system 或中途切话题，每改一次前缀就等于主动清空缓存重来。这三件都不花钱、不装任何东西，却往往比装任何工具都更能拉高命中率，因为它们直接作用在「前缀稳定性」这个最底层的变量上。工具是锦上添花，习惯才是地基。

收口 + 行业预判

把工具横评翻译成我做数据架构的语言，这套东西就一点不神秘：上 tree-sitter 索引像建物化视图（把重复解析固化下来，免得每轮重算），CLAUDE.md 瘦身像给宽表做列裁剪（只留每轮真正要扫的列），thread 隔离像分区裁剪（一个分区只扫一个话题的历史），sub-agent 委派像把重 ETL 调度到独立作业进程。OLAP 调优那套「先定位被全表扫描的大表，再针对性建索引/分区/物化视图」的思维，平移到 token 优化上几乎一一对应。

从 S01 的 Loop 原理，到 S02 的账单拆解，到 S03、S04 的 7 招省 token，再到这篇的实测，一条因果链闭环了：因为 LLM 无状态（S01），所以每轮要重发整本历史，账单 99% 烧在重复运输上（S02）；要压这笔账只有两个旋钮——命中率和增量大小，七招都是在拧这两个旋钮（S03、S04）；而到底哪把扳手在你手里好使，得用控制变量的方法实测，不能信名字（S05）。理解了这条链，你就不用记七招，遇到任何新工具都能自己推：它拧的是哪个旋钮、在什么场景拧得动。

再撂一个可以打脸、有时间窗的判断：未来 12–18 个月，「省 token 工具」这个品类会大面积洗牌——靠 README 数字博 star、却不标主场边界的工具会被淘汰一批，活下来的会被逼着公开自己的冷热桶基准和反贵场景。这事我赌得挺死，逻辑跟数据库选型一样：早年也是一堆「通用加速」插件满天飞，最后能留下的，都是肯告诉你「我只在这种 workload 下快」的那些。一个工具敢标自己的反贵区间，才是它可信的开始。

这五篇连载到这里就收尾了。如果你只带走一句话，那就是：省 token 不是抠输入框、不是堆工具，是理解那个无状态的循环，然后在对的环节、用对的扳手、拧对的旋钮。读懂这条链的那一刻，你就从 prompt 的用户，变成了 token 经济的设计者——这套能力，不会因为某个工具下架、某个版本更新而过期。

互动题：去翻你 ccusage@latest 最近 5 个 session 的 cache_read 占比。要是有哪个掉到 30% 以下，先别怪工具，回想一下那个会话是不是跳着做了好几件无关的事、或者中途改了 CLAUDE.md。评论区留一个你自己测出来「反贵」的工具名字和场景，我看看谁的翻车比我这次的 1534% 还狠。

本系列每周两更到这里收官。五篇拆下来，你对每一次回车背后的 token 开销，应该都心里有数了。后面想看哪个方向接着拆，评论区告诉我。

我是做数据架构的,在公众号「炼丹炉手记」用工程师的较真劲儿实测 AI 工具的真实 ROI——真省钱、真赚钱,还是智商税。工程拆解之外的,都在那边。

本文为 AI 辅助创作。