Nick Saraev · 15:01 · 发布 2026-07-04 · 2.7万次观看(截至抓取) · 观看原视频
主旨
在 Fable 高强度实测中总结出七类可落地的 Claude Code token 削减技巧,多数场景能省 30%-50% 甚至更多 token 消耗且不损失输出质量。
核心论点
- 多数工具调用输出充斥重复冗余信息,压缩格式而非削减信息量能省下 30%-99% token。(→ 详解1)
- 系统提示词/记忆文件里的礼貌性铺垫对模型语义零增益,语义压缩后信息密度不变而体积骤降。(→ 详解2)
- 面对超大文件(日志、数据转储),让 agent 用查询/采样代替逐行通读,能省下 99% 级别的读取 token。(→ 详解3)
- 英语是信息密度最高的提示语言之一,同一诉求切换语言可能带来 20%-80% 的 token 差异。(→ 详解4)
- 把”只读明确指定资源”写进系统提示能显著省 token,但代价是牺牲模型自主查找的灵活性。(→ 详解5)
- 上下文膨胀常在无声无息中发生(如多个 MCP 实例同时加载),需要定期主动体检才能发现。(→ 详解6)
- 自适应思考(adaptive thinking)默认倾向于用更多而非更少的思考预算,手动封顶到低档能省 30%-40% 而结果不变。(→ 详解7)
知识点详解
1. RTK(Rust Token Killer):工具调用瘦身 00:42
Claude Code 内部每次工具调用(读写文件、跑测试等)都会产生大量标准输出,很多是重复的样板信息(如反复出现的”standard out""setting up fixtures”)。模型和计费系统都不区分这些信息是否有效,照单全收还要照单计费。
RTK 的做法是把工具调用的输入输出重新格式化,只保留模型完成任务真正需要的信息,把无关重复项压掉。视频演示中一次工具调用从 612 行、36,700 字符压到 4 行、177 字符,达到 99% 的削减(02:15)。作者强调不是所有调用都这么夸张,更现实的整体预期是节省 30%-50%。
2. 语义压缩:系统提示与记忆文件瘦身 02:27
语义压缩指把一句话在不改变含义的前提下用尽可能少的词重写。很多 CLAUDE.md、system prompt 是口述转写或团队协作攒出来的,充满”非常感谢大家的辛苦付出”之类对模型语义价值为零的客套铺垫。
演示里用 Sonnet 5 通读一份 CLAUDE.md 并按最大信息密度重写,前后词数从 865 降到 211,token 估算从 1125 降到 274,同时提升了可读性与输出质量。这一手法可套用到项目里所有的 system prompt 与 memory 文件。
3. 日志转 SQLite:用查询代替通读 04:22
当 Claude 需要在一个几千行的日志文件里定位问题(例如”今早结账失败,在 app.log 里找根因”),传统做法是把整个文件当纯文本从头读到尾,极度浪费 token。
改进做法是把日志预先导入 SQLite 之类的数据库,再让 Claude 调用一个封装好的查询脚本(如 scripts/logq.py)去检索,而不是直接读原始文件。这个思路不限于日志,任何结构化数据源(Google Sheet、CSV 等)都可以套用:核心原则是用数据库/查询函数做过滤,而不是用纯文本搜索。
4. 阻断大文件全读:采样+定位代替逐行读取 05:54
不是所有资源都需要被从头读到尾。对超大文件(演示中是 618KB、约 20,000 行的数据转储),更高效的做法是先只读开头和结尾采样理解结构,再依靠模型智能匹配模式、用类似 sed 的定位工具只读取需要的具体行区间。
这样原本要读 20,000 行的任务可能只需读 20-30 行,对长资源的工具调用能省下接近 99% 的 token。这不是每次工具调用都要用的策略,但只要涉及大资源读取,收益就非常显著。
5. 用英语提示:语言本身的 token 效率差异 07:24
英语相对法语、德语、日语等语言信息密度更高,同一句简单查询,英语只消耗 51 token,意大利语 87(约 1.7x)、德语 118(约 2.31x)、日语约 74(约 1.45x)。多数模型的训练语料也以英语为主。
值得一提的例外是中文:虽然本视频未展开测算,但作者提到中文类模型用英语提示同样表现良好,而汉语本身因为高度符号化,其实是 token 效率很高的语言。这条建议对已经用英语提示的用户没有新增行动,但提醒了跨语言项目的额外成本。
6. 上下文管理:frugality 规则 + 定期体检 08:24
在系统提示里加入Context Frugality规则——“只读明确指定的文件,超出三个文件前先询问,优先用 glob/grep 定位后只读目标区域,读更多文件前先总结已有发现”——能让模型在检索前就自我约束范围,减少无谓的全目录扫描。作者坦言这类规则会牺牲模型内建的自主检索灵活性,属于”用更明确的指令换更省 token”的取舍。
即便如此,上下文膨胀仍常在不知不觉中发生——作者提到自己曾同时挂着十几个 Chrome MCP 实例,每个都带着完整 context,导致 Claude 变得臃肿且困惑该用哪一个,这种情况即使是资深用户也会中招(10:16)。对策是定期用 /context 检查上下文构成(system prompt、工具、memory 文件、skills、消息各占多少),或者用 /loop 让另一个 Claude 实例每天巡检一次、发现上下文里出现了 24 小时前没有的新东西就报警。
7. 封顶思考预算(thinking effort) 11:55
Claude 的自适应思考(adaptive thinking)会自行决定Thinking Effort预算,但演示对比同一个简单 bug 定位任务发现:低思考档(low)用 7 轮、1028 output token、18 秒、约 16 美分完成;而最高档(extra high)用了 9 轮、1363 output token、21 秒,多花约 3 美分——结果完全相同,只是 extra high 更”啰嗦”。
作者的建议是默认设为低思考(12:32),只有明确需要复杂推理的具体业务场景才手动切到高档。这个改动据称能带来 30%-40% 的整体节省。文中也提出一个动机层面的观察:Anthropic 的收入与总 token 用量挂钩,adaptive thinking 越倾向多想,厂商越受益,用户需要自己主动管理而非依赖默认档位。
可执行步骤
- 审视项目里所有 system prompt / CLAUDE.md / memory 文件,做一次语义压缩:同一意思用最少词重写,去掉客套铺垫。
- 涉及大日志/大数据文件的工作流,改为预先导入 SQLite(或类似结构化存储)+ 封装查询脚本,禁止 agent 直接整文件读取。
- 在 CLAUDE.md 里加一条 frugality 规则:只读明确指定文件,超范围前先询问,优先用 glob/grep 定位后读区域而非整目录。
- 定期(如每天)跑一次 /context 检查上下文构成,或用 /loop 设置每日巡检,及时发现意外膨胀(如遗留的 MCP 实例)。
- 把默认 thinking 档位从自适应/高改为低,只在明确需要复杂推理的具体任务上手动调高。
关联
- 印证:Context Rot——本片七条技巧本质都是在对抗上下文/token 膨胀对模型表现和成本的双重侵蚀,是 Context Rot 问题的具体工程对策。
- 印证:CLAUDE.md——本片的语义压缩与 frugality 规则都直接作用于 CLAUDE.md/system prompt,呼应此前笔记提到的”滥用 CLAUDE.md 收益微弱还推高推理成本”,本片给出的是”压缩瘦身”而非”增补”的反向操作路径。
术语
- RTK(Rust Token Killer,把工具调用输入输出压缩成精简格式的 token 削减手法)
- semantic compression(语义压缩,同义改写压缩系统提示/记忆文件体积)
- context frugality(在系统提示里显式约束模型只读必要资源的规则)
- thinking effort(思考努力档位,如 low/high/extra high,决定模型推理时消耗的 token 量)
金句
“the difference pre and post RTK is literally a 99% reduction in token usage for the same thing” → 同一件事,格式化输出就能省下 99% token,浪费的从来不是信息本身而是冗余的表达方式。
“that’s what Anthropic makes money off of, right? They make money off of the total number of tokens you use.” → 默认档位不天然对用户利益最大化,厂商与用户在 token 消耗上存在结构性的利益不一致。
立场与利益
视频结尾引流至作者自己的付费项目 Maker School(承诺 90 天内拿到第一个客户,否则全额退款),本片提到的所有脚本/文件(RTK、语义压缩提示词、frugal-claw.md 等)则声明免费在描述区提供。技巧演示本身未见明显王婆卖瓜倾向,但对比数据(低思考 vs 高思考、RTK 前后)均来自作者自己的演示环境,未见第三方复现或统计意义上的多次重复验证。
价值定位
面向已经在用 Claude Code 或类似 agent 编码工具、且对 token/账单成本敏感的实践者,提供了一套具体可落地的工程习惯(压缩提示词、日志转数据库、封顶思考档位、定期上下文体检),多数不依赖特定模型,可直接迁移。缺点是部分数据(如 99% 削减)是单次演示的极端案例,没有交代统计意义上的平均收益,采纳前建议在自己的项目里先小范围验证再全面推广。
自检问题
- RTK 主要针对的是什么类型的 token 浪费? 答案:工具调用(tool call)输入输出里的重复样板信息,如反复出现的 standard out、fixture 设置等;RTK 重新格式化这些内容,只保留模型完成任务真正需要的部分。00:42
- 为什么面对几千行的大日志文件不应该直接用 Claude 逐行读? 答案:逐行读会把整份日志当纯文本消耗掉,token 成本随文件行数线性增长;更优做法是预先导入 SQLite 之类数据库,让 agent 调用封装好的查询脚本去检索需要的具体记录。04:22
- 视频里对比低思考(low)与最高思考(extra high)档位,在同一个简单 bug 定位任务上分别耗费了多少轮次和成本? 答案:低档 7 轮、1028 output token、18 秒、约 16 美分;extra high 档 9 轮、1363 output token、21 秒,多花约 3 美分——结果完全相同。11:55
- context frugality 规则的主要代价是什么? 答案:牺牲模型内建的自主检索灵活性——加了”只读明确指定资源”之类的规则后,模型如果没有被明确告知具体位置就更难自己找到该看哪里,需要用户更主动、更具体地指明范围。08:24
- 作者提到自己是如何在不知情的情况下造成了上下文膨胀的? 答案:同时开着约十几个 Chrome MCP 实例,每一个都加载了完整的 context,导致 Claude 变得臃肿、困惑该用哪个实例,进而花掉远超预期的成本。10:16
💬 热门评论 top-10 主 + 10 回(抓取 2026-07-07)
[2] @stagius:嘿，谢谢你的视频！我觉得值得一提，还有个叫headroom的工具，基本上是rtk的扩展，但能压缩更多类型的东西（日志、文件、历史记录等）。 👍 19 ↪ @nicksaraev(UP):很棒的扩展。谢谢。 👍 6 [5] @rakly347:为了在自定义文件（比如技能、记忆）上节省token，我用了一个双层系统。顶层是自动包含的内容，每个主题和内容的一般索引。第二层是更深入的索引，限定在该主题内，如果有关系的话还会交叉引用其他主题。然后是实际的内容文档。用markdown很容易实现。它绝对需要知道的东西，你可以放在顶层（默认包含，不会被压缩），或者指向它必须阅读的显式规则（由代理手动读取，是正常聊天上下文的一部分，所以会被压缩）。如果文本太多，我可能还会加一些指向SQLite知识库的指针。 👍 3 [6] @johnathancagle:RTK和语义压缩进入工作流了。谢谢Nick。能加上资源文档吗？ 👍 12 ↪ @nicksaraev(UP):当然，很高兴你喜欢。更新了描述！ 👍 4 ↪ @fonzing:所以资源都在他的skool付费墙后面。好吧，又一个AI创作者推他的skool付费墙。你提供刚好够的价值，看起来真诚，但其实都是为了让我们付钱。 👍 2 [8] @harryp-90:有趣的视频，来得正是时候。我在Fable上多花了32美元，本来至少能省10美元的。 👍 3 ↪ @nicksaraev(UP):是的，完全理解。 👍 2 ——其他 6 条:感谢/夸赞([1]@KumR、[3]@elvis3354、[4]@ANNA_family_explains、[7]@americanrewardsclub、[9]@MaximilianLesek、[10]@Leto2ndAtreides)
英文原文
[1] @KumR:Missed u bro…. There was so much of slop around… Only some creators like you give us something valuable😊 👍 13
↪ @nicksaraev(UP):Appreciate you so much 🙏 👍 1
↪ @flaviusapop:This is soo true.
[2] @stagius:Hey, thanks for the vid! Thought it is worth mentioning, there's also a tool called headroom, which is basically an extension of rtk but that allows compression on a wider range of items (logs, files, history etc.). 👍 19
↪ @nicksaraev(UP):Great extension. Thanks for this. 👍 6
[3] @elvis3354:Thanks for taking the hit for us. Damn the API is f’kx expensive! 0:26 👍 10
↪ @nicksaraev(UP):Agree 100%, hurts. 👍 3
[4] @ANNA_family_explains:Thank You for getting this video out so soon! Talk about taking one for the team...lol The learning curve for Fable just wouldn't be possible for those of us who don't have the money to " learn as we go". THANKS AGAIN! 👍 4
↪ @nicksaraev(UP):Thank you! 👍 1
[5] @rakly347:To save tokens on custom files like skills, memory, I use a two tiered system. Top level, what get's included automatically, general index per topic and content. 2nd tier, more in depth index scoped to that topic, with cross references to other topics if it's relational. Then the actual content docs. It's pretty easy to do using markdown. Stuff it absolutely needs to know, you can put at top tier (includes it by default, doesn't get compacted), or a pointer to explicit rules it has to read (read manually by the agent, is part of the normal chat context, so this does get compacted.) Here I then also might add some pointers to an SQLite kb if it's too much text). 👍 3
[6] @johnathancagle:RTK & Semantic compression going in the workflow. Thanks Nick. Can you add the resource docs? 👍 12
↪ @nicksaraev(UP):Hell ya, glad you enjoyed. Updated the description! 👍 4
↪ @fonzing:So the resources are all gated behind his skool paywall. Cool just another ai creator push their skool paywall. You offer just enough value to seem genuine but it's really all about getting us to pay. 👍 2
[7] @americanrewardsclub:I've never been this early. I don't know what to do with my hands. 👍 16
↪ @kazsaysyoukan:shake 'em a little, tiddle your thumbs for 4 seconds, then do the nae nae. Usually works for me. Hope this helps Also, here's your gold star ⭐ 👍 1
[8] @harryp-90:Interesting video came out at a good time. I literally blew $32 in extra usage on Fable, when I could have saved at least $10 on that amount 👍 3
↪ @nicksaraev(UP):Yep, completely get that. 👍 2
[9] @MaximilianLesek:I needed this. 👍 4
↪ @nicksaraev(UP):Thx Maxi! 👍 1
[10] @Leto2ndAtreides:Good stuff.