炼丹炉笔记

Claude Code 省 token 的最后三招都攥在你手里：怎么读、派给谁、何时清场——回报最高的那招竟是「怎么提一句话」

2026-06-14

本文适合：① 每天用 Claude Code、想把那张越滚越吓人的账单压下来的工程师；② 做过后端 / 数据架构、好奇 token 优化和数仓那套有没有共通逻辑的人；③ 在用 Claude API、看到 usage 飘红就条件反射 /clear 的人。

我做数据架构，日常打交道的就是谓词下推、投影裁剪、分区裁剪这些「让数据少流动一点」的招。所以盯着 Claude Code 的 token 账单看，我第一反应不是「这工具怎么这么贵」，而是「这不就是一次没做谓词下推的全表扫描在反复重放吗」。这篇就用这视角，把你能亲手发力的三招讲清楚。

先把结论放最前面。Claude Code 的省 token，系统级杠杆 S03 已经讲完（缓存、压缩、隔离、按需加载，改个配置就躺省）；剩下三招的开关不在工具里，在你手上——怎么读（T5 输出收敛）、派给谁（T6 模型路由）、何时清场（T7 thread//clear）。而这三招里回报率最高的恰恰是最不像技术的那个：怎么提一句话。下面把这三招、加一张 usage 90% 决策树，一条条拆开。

最贵的提示词，往往是最短的那种。比如「把整个项目看一遍，告诉我哪里可以优化」，它看着人畜无害，实际是一张空白支票：几万行的项目，Claude 会一个文件一个文件 read 过去，把源码、测试、配置全吞进历史，单次 input 轻松冲到一百多 K。但真正肉疼的不是这一次，而是后面每次追问——「这函数怎么改」「测试怎么写」——Claude 都背着那几万行历史，每轮重新付费一遍。一句「看一遍」，写进了你后面 20 轮的账单。这就是 S01 讲过的 W2 在收利息：工具吐进历史的东西出不去，你这次的「随手」要后面每轮陪着还。下面三招，本质都在拆这条利息。

一、省 token 不在事后压缩，而在请求的 5 个环节、每一步都有省料口

一句话：一条请求从你脑子里冒出来到 Claude 吐出最后一个字，中间走五段流水线、每段都漏 token，先定位瓶颈在第几段，再选对应的招，比盲目 /clear 有用得多。这五步是：

S03 那四招分别落在不同环节：T1 Prompt Caching 在②（命中 cache），T4 Progressive Disclosure 在①（拼 prompt 时只塞 skill 目录、不塞全文），T2 Context Compaction 和 T3 Sub-agent 都在⑤（一个压成摘要，一个把过程挪到子 agent）。

S04 这三招补上剩下的环节：T5 输出收敛打③+④（选对工具、收敛返回），T6 Model Routing 打⑤（委派杂活），T7 Thread//clear 打②+⑤（隔离话题、清空重置）。

图 4.1 一次请求的 5 个环节，每步都有省料口

（图 4.1）一次请求的 5 段流水线与各自的省料口。这张图我不建议背，usage 告急时拿它对照着问一句就够：我这次的钱，主要烧在第几步？ 答案常出乎意料。多数人以为是「历史太长」（⑤），实际大头往往在「工具返回太肥」（④），就是某次 read 整文件埋下的雷。先定位瓶颈在哪一环，再选对应的招。

二、用户手里最大的杠杆是 T5：一句「先 grep 再针对性读」，省的是后面每一轮的复利

一句话：T5 完全由你「怎么提一句话」决定，零配置、今天就能用；它省的不是一次，是 W2 那条利息。七招里普通用户能即时拨动、回报又最高的，就是它。

2.1 grep 命中 5 行 ≈ 200 token，整文件 read 一吞就是 15K

举个典型的遗留系统场景：一个 Python 文件 1500 行，塞了数据清洗、特征工程、模型评估三个模块。你让 Claude「找到特征工程的代码」，不加约束它的默认动作就是 read_file 整文件，1500 行全塞进历史。

算笔账：1500 行 ≈ 15K token；grep 搜 def.*feature 或 # feature engineering，命中 5 行 ≈ 200 token。每看一个文件，省 ~12K。

为什么 12K 值得省？因为 W2 效应：这次塞进去的东西后续每轮都重发。你读了 15K 的文件，之后问 10 个问题，每个背后都背着这 15K，总账 15K × 10 = 150K，而不是 15K 加后续 10 轮的小增量。

实操就一句话：在 prompt 里明确告诉 Claude「先 grep 找位置，再针对性 read」。模板长这样：

任务：找到 XXX 模块的 YYY 函数并分析其性能瓶颈。
方法：先用 grep 搜索相关代码位置，确认后再用 read_file 读取具体函数或片段。不要读整个文件。

反例就是开头那句「把整个项目看一遍」。你以为 Claude 会智能地只读关键部分？它不会，它老实巴交地一个一个文件读、一个一个塞回去。

更精确的用法是 read_file 带 offset/limit 参数指定行号范围。知道目标函数在 300–400 行，直接 read_file path/to/file.py --offset 300 --limit 100，只读 100 行，而不是 1500 行。

2.2 提问方式这件最不像技术的事，回报率却最高

为什么把 T5 放在「用户手里最大的杠杆」？S03 那几招要么自动生效（T1）、要么得改架构（T3/T4），普通用户能即时拨动的不多。T5 不一样，它完全由你「怎么提一句话」决定，省的还是复利：一次省 12K、后面跟着聊 15 轮，等于省了近 180K，比你后面所有招加起来动的量都大。提问方式这件最不像技术的事，恰恰是回报率最高的技术。

用数据工程的话说，T5 的本质就是投影裁剪 + 谓词下推，只取需要的行和列。grep 一个关键词，相当于在数据进入管道之前就把不需要的行过滤掉。做数仓的都知道，谓词下推是性能优化第一原则：越早过滤，越少数据流进后续环节。

三、T6 模型路由能省七成，但用错场景反而贵 290%——它是七招里最容易「看着在省、其实在赔」的一招

一句话：把「长 output + 不在乎质量」的杂活派给小模型，output 能省七成；但场景判断错、或委派结果回流主上下文，省的全得赔回去。

3.1 杂活给小模型，output 省 60–90%

Claude 的 output token 比 input 贵。Haiku 级模型比旗舰模型便宜好几倍（按官方定价，Haiku 的单价大约是 Opus 的五分之一）。于是有个自然的省法：把「不需要深度推理、但 output 很长」的杂活委派给小模型。典型场景：

这些任务不需要 Claude 的推理能力，让 Haiku 级模型做，output 省 60–90%。生成 50 个接口的 OpenAPI 文档，大模型 output 约 12K token；换 Haiku 级模型，output 量级相当、质量够用，但单价便宜好几倍，output 成本能省七成以上。

3.2 让小模型写「50 字介绍」，它能写出 2300 字——反贵 290%

但是。有一个坑，我踩了两次才敢写出来。

抽象任务——比如「用 50 字介绍这个模块」——小模型会膨胀。 一个反直觉的实测：让 Haiku 级模型写「50 字的模块介绍」，它能写出 2300 字——output 膨胀 46 倍，总账不降反升，反贵了 290%。

原因很简单：小模型没有「克制」的推理能力。你让它「50 字」，它理解不了为什么只写 50 字，只会尽力「完整」地答。所以T6 只适用于「长 output + 不在乎质量」：

3.3 委派的省，全省在「结果落盘、主模型只引一行摘要」这最后半步上

还有一条更硬的铁律：委派出去的结果，必须让小模型 -o 落盘，不要回流主上下文。 你让 Haiku 级模型做了格式化，结果又塞回 Claude 历史里，等于没省。正确做法是小模型写文件、主模型只读摘要或直接引用。

这条铁律的本质，是别让委派「绕一圈又回来」。小模型干完又把那 2000 字原样塞回主对话，它在子侧省下的全在主侧赔回去，还白白多付一次调用钱。委派的省，全省在最后这半步上。这也是 T6 为什么是七招里最容易「看着在省、其实在赔」的一招。

用数仓的话说，T6 就是把 ETL 重活调度到独立作业。 你不会把清洗、转换、加载塞进一个 SQL 跑完，而是拆成多作业各跑各的、结果落表。T6 一样：杂活派出去，结果落盘，主流程只读摘要。

四、T7 会话隔离能省，但频繁 /clear 反而更贵——所以要按 usage 决策树走，而不是看到飘红就清

一句话：任务隔离到独立 thread、必要时 /clear 归零确实省；但 /clear 后下一次请求是 100% cache miss，乱清比不清更贵，该不该清得按决策树走。

4.1 一个 thread 里塞三件无关的事，是浪费重灾区

你问了个 SQL 优化问题，又问「顺便看看这个 Python 脚本的 bug」，再问第三个「帮我写个 Dockerfile」。Claude 的上下文里塞了 SQL、Python、Docker 三个不相干的东西，每轮跟着重发。

解法：不相关的任务隔离到独立 thread。 thread A 做 SQL 优化、thread B 做 Python 调试，互不干扰。每个 thread 的 cache 只缓存本 thread 的 key，cache miss 概率更低。

/clear 是更暴力的做法：把当前会话历史全部清空，适用于「完全切换话题、旧上下文毫无价值」的场景。

4.2 /clear 不是免费的：下一次请求 100% cache miss

代价是什么？/clear 之后，下一次请求是 100% cache miss。 服务端要重建 cache key、走完整推理。频繁 /clear 每次都在付这个代价，短时间（比如 5 分钟内）频繁切 thread 或 /clear，反而更贵。我自己摸出来的几条用法：

用数仓的话说，T7 就是分区裁剪。 查一张大表不会全表扫描，而是指定分区条件只扫相关分区。Thread 就是给上下文做分区，只扫本 topic 的历史；/clear 相当于 drop partition，整个分区不要了。

4.3 usage 90% 决策树：按「破坏性递增」的顺序走

看到 usage 报警，大部分人第一反应是 /clear。但它不是唯一选项，甚至不是最优。给一个 4 步决策，按顺序走。

  1. 任务能收尾吗？ 能 → 收尾、提交结果、关闭会话，收尾后自然归零。不能 → 下一步。
  2. 任务还在进行、上下文已经快满？ 用 /compact。S03 讲过，它压缩历史但不丢上下文，代价是一次 cache miss，但后续还能接着聊。还满 → 下一步。
  3. 完全切换话题了吗？ 是 → /clear，旧上下文全部作废，不要留恋。不是 → 下一步。
  4. 当前 thread 里有大杂活（格式化 / 翻译 / 批量处理）？ 是 → 委派给小模型、结果 -o 落盘，释放主上下文。不是 → 你真的该 /clear 了。

这个顺序为什么这么排？因为四个动作的「破坏性」是递增的：收尾零代价、/compact 付一次 cache miss 但历史还在、/clear 整段历史作废且 cache 全重建、委派有 cold start 开销。按代价从低到高走，你才不会在「其实收个尾就好」时上来就 /clear，把还有用的上下文连根拔掉。

核心逻辑就一句：能不 /clear 就不 /clear，但该 /clear 时不要犹豫。 很多人一看到 usage 飘红就条件反射 /clear，把本来再聊两轮就能收尾的任务拦腰斩断，下一轮还得把刚清掉的上下文重新喂一遍，省了一次的钱，赔了三次。

收口 + 下集钩子

回到主线：省 token 不只在事后压缩，请求的 5 个环节每一步都能下手，S04 这三招都是你能主动发力的环节，你控制「怎么提问」「派给谁」「什么时候清场」。我做数据架构，看 token 优化本质就是资源调度：哪段是瓶颈就在哪段动手；先诊断，再开药。

到这里七招齐了：S02 拆清楚账单结构（钱烧在重复运输的历史上），S03 给了四个系统级杠杆（缓存、压缩、隔离、按需加载），S04 给了三个手动发力的环节（怎么读、派给谁、何时清场）。七招背后只有一句话：盯住每轮被重复扫描的那块热数据，用对的招把它缓存住、压小、挪走或延迟加载。

再撂一个可以打脸、有时间窗的判断：未来 12 个月，会冒出一批专门做「省 token」的第三方工具，但相当一部分是「看着在省、其实在赔」，就像 T6 那个反贵 290% 的坑换层包装。我赌：拉来做控制变量实测，经得起「结果落盘、不回流主上下文」铁律的不会过半。下篇见真章。

下集预告：招都会了，到底哪个工具真省？S05 我把市面上的省 token 工具拉来做了一轮控制变量实测——24 个工具、194 次调用，上真数据，外加两次自己的翻车，包括一个名字听着像救星、实测却反贵 15 倍的坑。

互动题：你最近一次 usage 报警，是硬 /clear 还是先 /compact？再翻翻那个会话，吃掉额度的是你打进去的字，还是某次 read 整文件埋的雷？

本系列每周两更，跟着拆完，你会对每一次回车背后的开销心里有数。卡在哪个点，评论区告诉我，我挑高频的写进后面。

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

本文为 AI 辅助创作。

本文首发于知乎:阅读知乎原文 →