四个练习帮你测量Token消耗浪费

在《Nothing Broke. It Just Wasn't There.》中，一份针对个人 AI 编码环境的审计发现 token 浪费问题早已被解决——不是靠主观推断哪些习惯看起来开销大，而是通过测量真实的 60 天语料库，发现四个初始假设中有三个是错的。

本工作坊是那次测量的实践部分。如果你已经完成了配套的 /doctor 工作坊，那这里覆盖的是另一个时钟：不是外部的约束机制，而是每次你与模型对话时内部积累的东西。

开始之前有一个关键认知值得先理清楚：agent API 是无状态的。每次工具调用都会重新发送你到目前为止的整个对话历史。一句话说过一次并不等于免费——在一个长会话中靠前的 token，在后续每个回合都要再次付费——这就是为什么会话长度，而不是某个看起来很贵的操作，才是真正的成本驱动因素。

练习 1：装上机械部分

这里四个杠杆中有两个一旦装好就完全不需要你再操心——一个自动拦截特定浪费的钩子，一个无需你主动询问就能显示上下文使用量的状态栏。先把这两个装上；它们一旦就位就开始见效，甚至在你还没开始测量之前就已经在回报你了。

两者都存在于与 /doctor 相同的公开仓库中：github.com/nino-chavez/agentic-ways-of-working。

hooks/read-guard.py — 一个针对文件读取的 PreToolUse 钩子。它会一次性拦截两种特定模式，并在同一次响应中给出修复方案：超大图片读取（长边超过 1400px 会生成一份 1000px 的副本替代），以及重新读取一个在过去 10 分钟内没有变化过的文件（你会收到一个提醒，要求你引用上下文中已有的内容）。立即重试总是会成功——这是针对反射性操作的摩擦，不是堵死的墙。

statusline.py — 在你的终端中显示 model | context tokens（50%/80% 颜色编码）| cwd，所以会话膨胀到不合理的程度是你实时看到的，而不是在三次工具调用之后才发现的。

如果你之前已经为 /doctor 工作坊克隆过这个仓库，那你已经拥有所有需要的东西——只需要运行安装程序来接入剩余部分：

cd ~/agentic-ways-of-working   # 或者你克隆到的其他位置
./install.sh

全新开始：

git clone https://github.com/nino-chavez/agentic-ways-of-working.git ~/agentic-ways-of-working
cd ~/agentic-ways-of-working
./install.sh

安装程序是幂等的——它会先备份你的 settings.json，只添加尚未存在的钩子注册，绝不会覆盖你已经配置过的状态栏。

重启你的 Claude Code 会话。你应该能在终端底部看到状态栏，显示你的模型、当前上下文使用量和工作目录。重新读取一个你最近几分钟内没有改动过的文件，然后立即再次读取同一个文件——第二次读取应该会被弹回一次并附带一个提醒，随后立即重试应该就能正常通过。这就是钩子在按设计的方式工作。

练习 2：测量，而不是猜测

关于哪个工具调用是贵的直觉通常都是错的——这不是保守说法，而是在一个真实的 2335 文件、529 会话语料库上运行后得到的实际发现。四个初始假设中有三个是错的。你的环境与那一个不同。想知道你的环境里实际发生了什么，唯一的办法是运行测量，而不是从感觉重的部分去推理。

tools/token-audit.py 读取 ~/.claude/projects/**/*.jsonl 下的每个会话日志，对其进行流式处理（多 GB 的语料库在一两分钟内就能完成），然后报告你的 token 实际花在了哪里——而不是你猜的哪里。

python3 tools/token-audit.py [--days 60] [--projects-dir ~/.claude/projects] [--top 20]

--days 控制回溯窗口（默认 60——如果你是刚上手不久，用更小的值），--projects-dir 允许你指定其他位置（如果你的 Claude Code 数据不在默认位置），--top 控制每个类别列出多少个主要的"肇事者"。

用你自己的历史运行它：

cd ~/agentic-ways-of-working
python3 tools/token-audit.py --days 60

如果你刚接触 Claude Code，还没有 60 天的历史，就缩小窗口：--days 14 或者你实际拥有的天数。一个窄窗口仍然能告诉你一些东西；只是不会像完整数据那样稳定。

你应该看到一份报告，包含几个命名指标和专属于你自己会话的数字——而不是工具自带文档中的参考数字。如果报告回来基本是空的，检查一下 --projects-dir 是否指向了你 Claude Code 会话日志实际存放的位置（默认是 ~/.claude/projects）。

练习 3：读懂这五个数字

直到你知道每个数字在告诉你该怎么做时，报告才有用。五个指标承载了整个故事的要点。

Replay multiplier（重放倍数）— cache reads ÷ tokens written。这是最大的那个数字：因为 API 是无状态的，一个载荷的真实成本是它的大小乘以会话中后续每个 API 调用，这使得会话成本在大致上是回合数的二次方。在参考语料库上这个数字测出来是 41×。如果你的这个数字很高，解决方案几乎从来不是精简你发送的内容——而是更短的会话，以及把探索工作委托给子 agent，它们的上下文随它们一起消亡，而不是积累在你的会话里。

Redundant re-read rate（冗余重读率）— 同一文件、同一会话、内容未变、被读取超过一次。高重读率通常是长会话的症状：压缩会丢弃工具结果，agent 重新读取它丢失的内容，上下文膨胀，再次触发压缩。你在练习 1 中安装的 read-guard 钩子是防线；缩短会话才是真正的解决方案。

Image reads（图片读取）— 按像素尺寸计费，而不是文件大小。一张全分辨率截图的费用可以是一份裁剪过、缩放过的同内容副本的好几倍。在参考语料库中，图片占所有读取字节的 78%，大多来自设计循环会话中被反复读取数十次的全页面截图。

Cache-write ratio（缓存写入比）— cache writes ÷ fresh input。写入费用大约是输入价格的 1.25 倍，且发生在缓存 TTL 过期（约 5 分钟空闲后）以及每次子 agent 派生时。高写入比通常意味着一个肥胖的会话在空闲放置后被恢复——每次随意恢复都会以溢价费率重写整个上下文。

Per-model spread（各模型分布）— 缓存是按模型分的。在会话中间切换模型会为切换到的那个模型启动一个冷缓存。

回到你自己的报告。先找到你的 replay multiplier——它通常是最大的单个数字，也是最好的切入点。然后检查 redundant-read rate 和 image reads；这两个是钩子能部分拦截的，所以在练习 1 之后看到它们仍然居高不下能告诉你一些具体的东西（是在钩子安装之前的旧历史，还是一个仍在持续发生的模式）。

说出你自己的 replay multiplier 和你自己的 redundant-read rate，具体数字——而不是这篇文章里的参考数字。如果这两个数字中任何一个与你在运行工具之前的预期相比令你惊讶，那这才是测量而不是猜测的真正意义所在。

练习 4：把一个数字变成一个改变

一个没有改变任何习惯的测量是研究练习，不是审计。重点不是报告——而是你在下一个会话中做得有什么不同。

把你发现的与真正能修复它的方法对应起来：

从练习 3 中挑出匹配你最大那个数字的那一行。不是全部五个——就一个。用一句话写下你从下一个会话开始要改变的具体习惯。

把你的这一个改变大声说出来或者写下来：从什么时候开始你会做得不同。过几周再跑一次审计，检查那个具体的数字是否有变动。如果没有，说明这个修复方案没有对得上真正的原因——回到练习 3，重新更仔细地读一遍那个数字。

四次练习，每次覆盖同一个机制的不同半边：

Where This Is Heading

状态栏是这里唯一实时的部分——它告诉你的是你当前所在的这个会话。其他一切都是回顾：token-audit.py 告诉你的是已经发生了什么，而不是这一分钟正在发生什么。

几周后再跑一次，与 /doctor 工作坊建议重新运行那个命令的方式相同。单次测量是一张快照。真正改变你的 token 账单的是，练习 4 中的那个习惯在你第二次检查时是否仍然成立。