先说结论：省 Token，不是一门“省字学”，而是一门“上下文管理学”。
因为 Token 花销，本质上就是 AI 读了多少内容，加上它写了多少内容。
大家都知道 Claude opus 贵，但因为 Anthropic 对于国内过严的封禁策略，很多人还没体验到过或者用的中转站。前两天看到L站有人发了一个帖子：本来在电脑前木然且疲惫地打电脑的我忍不住笑出声。
日常为了测试和 AI 的连通性，大部分人打开 Claude Code 一般都是先输入个“hi”、“你好”、“你是谁”之类的话确认下 AI 正不正常。
但是开局一句 hi 花费10块人民币的门槛费，也是颇有些让人哭笑不得。
所以关于如何才能节省 Token 这件事，我决定专门写一篇文章好好讲一讲。
Token 计费是怎么组成的？
还是先做个科普，说下 Token 的组成部分。
你发给模型的话，算输入 token；模型回给你的内容，算输出 token；两部分都会计费。
比如你发一句“帮我写个请假邮件”，看起来很短，但系统实际很可能还会顺手把前面几轮聊天记录、隐藏提示词、你的附加要求一起打包发给模型。
于是表面上你只问了一句话，实际上模型“看到”的内容可能比你想象中多得多。你可以把它理解成一个很朴素的公式：总花销 = 输入的钱 + 输出的钱。所以，问题越长，越贵；AI 回得越长，越贵；聊天轮数越多，也越容易变贵，因为历史上下文常常会被反复带上重新计算。举个最简单的例子：如果这一轮你输入了 100 token，模型输出了 200 token，那就按 100 + 200 算；但如果下一轮系统又把上一轮内容一起喂进去，输入可能就变成 400 token，哪怕你新发的话并不多，费用也会明显往上窜。
当然，一般来说输入比输出便宜，命中缓存又比输入便宜，而这些都需要考虑 Token 的区间，区间越大模型算力要求越高，自然也会越贵。
很多时候，贵的肯定不是你刚打的那句话，而是系统为了回答你，偷偷把你一堆旧内容也一起读了。
真正让 Token 爆炸的，往往不是“你问了什么”，而是“你怎么管理上下文”
搞懂计费规则之后，你会发现一个更关键的事实：大多数 AI 成本问题，看起来像是 prompt 问题，实际上是上下文管理问题。
历史聊天、系统提示词、规则文件、工具说明、网页内容、终端日志、项目代码、上传文档……这些东西只要被重新读一遍，就都要重新算钱。
所以真正决定成本的，往往不是你这一轮多打了几个字，而是这套系统有没有做到三件事：
-
别让模型反复重读没必要的旧内容
-
别让模型读进太多低信噪比的垃圾内容
-
别让模型输出一堆不影响结果的语言泡沫
也正因为这样，这篇文章我不再按“零散省钱技巧”来讲，而是按上下文管理来讲，两块就够：
-
系统层的上下文管理：用外部工具替你自动省
-
使用层的上下文管理：不装工具，也能立刻降成本
系统层的上下文管理，用“科技”替你省
如果说手动省 Token 靠的是“自觉”，那工具真正帮你做的，其实是把上下文管理机制化。
它的价值不只是省钱，更是把那些会重复、稳定、无意义烧钱的环节，直接从系统层面改掉。
但工具很多，也不建议什么也不了解乱装。最好的办法当然不是“哪个火装哪个”，而是先看：你的上下文，究竟是贵在日志、贵在规则文件、贵在仓库输入，还是贵在整条 Agent 链路。
这里我尽量列了一些当前搜罗到的还算是比较热门的工具，毕竟“科技与狠活”，主打一个开箱即用，安上就能自动省。（笑）
终端输出类：专门解决“日志太吵”
AI 对接 CLI 指令，就会有很多多余信息出现。
这是编码场景里最常见、也最容易立刻见效的一类。
1. RTK：把终端废话先砍掉，再喂给模型
RTK 可以理解成一个 CLI 输出压缩器。
它专门处理这些情况：git status、pytest、cargo test、npm build、grep、ls
这些命令表面上是“有结果”，但实际上里头 70%～90% 都是噪音：空行、提示语、重复成功日志、无意义说明、颜色字符、样板输出。
RTK 做的事非常直接：
-
过滤噪音
-
合并重复信息
-
保留失败项和关键摘要
-
必要时保留原始输出供回看
它最适合的人群：
-
Claude Code 用户
-
Codex 用户
-
Cursor / Copilot / OpenClaw 用户
-
让 AI 高频跑命令、看测试、看 Git 结果的人
它最大的优点是：不用你改变习惯。
你还是照常跑命令，只是系统先帮你瘦身，再把结果喂给 AI。
它的局限也很清楚：
-
主要针对 shell / CLI 输出
-
不是全场景上下文优化器
-
特别底层的问题，有时还是得回头看完整原始输出
一句话：RTK 是“别让 AI 吃日志垃圾”。
2. Omni：跟 RTK 很像，但更强调“上下文质量”
Omni 和 RTK 属于同一大类：都是在命令输出到达 AI 之前先做拦截和过滤。
但 Omni 更强调一个概念：省 token 只是结果，更重要的是让上下文更干净。
因为终端输出真正的问题，不只是贵，而是乱：
-
warning 太多
-
成功日志太多
-
错误被埋在中间
-
加载条、进度条、提示语太多
Omni 的思路是：Less noise, more signal。
它的一些特点包括：
-
智能过滤终端噪音
-
原始输出可归档回看
-
有 session intelligence，会结合当前会话状态处理
-
能看压缩前后差异和统计节省情况
它适合谁？
-
重度 terminal + AI 用户
-
想让 AI 看得更准，不只是想让它更便宜的人
-
编码 Agent 用户
它和 RTK 的区别可以这样理解：
-
RTK：更成熟，更像通用 CLI 压缩器
-
Omni：同样压终端，但更强调“语义信号纯度”
一句话：Omni 省的不只是 token，也是在给 AI 提纯上下文。
3. distill：不是固定压缩，而是“按你的问题蒸馏结果”
如果 RTK 和 Omni 更像“规则型过滤器”，那 distill 走的是另一条路：
不是先定义怎么压，而是先定义“你到底想知道什么”。
比如：
-
bun test | distill "测试过没过？只返回 PASS / FAIL 和失败用例名" -
git diff | distill "改了哪些文件？每个文件一句话总结" -
terraform plan | distill "这次变更是否安全？只返回 SAFE / REVIEW / UNSAFE"
它的核心不是“把日志变短”，而是把日志变成当前任务最需要的那个答案。
它适合的场景是：
-
原始输出很长
-
你的目标很明确
-
你并不想看完整输出，只想拿一个任务导向的摘要
它的优点：
-
非常灵活
-
适合复杂命令输出
-
能直接对准“当前问题”做蒸馏
它的限制：
-
你必须把问题说清楚
-
本质上还是要靠模型蒸馏，属于“智能摘要”而不是纯规则压缩
-
不一定适合所有高频命令都默认套一层
一句话：distill 是“别把整坨日志给我，直接告诉我结论”。
输出风格类：专门解决“AI 太爱说废话”
这类工具解决的不是输入，而是输出。
简单说就是：模型明明能一句话说完，为什么非得写三段。
4. Caveman：把 AI 从“写作文模式”拉回“给答案模式”
Caveman 的思路非常直给：保留技术信息，砍掉语言泡沫。
它会强制模型少说这些东西：
-
好的，我来帮你分析一下
-
以下我从几个方面来说明
-
希望以上内容对你有帮助
保留的则是：代码、路径、命令、错误信息、关键结论
它适合这些场景：
-
编码问答
-
排障
-
PR review
-
高频技术对话
-
不需要文学修饰的工作流
它的优点：
-
上手最快
-
见效最快
-
直接压输出 token
-
很多时候不仅更便宜，还更清楚
它的限制：
-
主要压的是输出
-
对“大输入上下文”帮助有限
-
写教程、写长文、写文案时不一定适合
另外它还有配套的 caveman-compress，会顺手把 CLAUDE.md 这类常驻规则文件也压一层。
一句话：Caveman 做的不是让 AI 变笨，而是让它闭嘴，只说重点。
记忆和规则文件类：专门解决“每轮都在交固定税”
也很多人也没发现哈，真正“刺客”的成本不是新 prompt，而是那些**每轮都会被自动加载的玩意儿。
比如：CLAUDE.md、MEMORY.md、USER.md、AGENTS.md、各种项目说明和偏好文件。
这些东西你平时可能不会太注意，但它们只要反复带，就会稳定扣费。
5. Claude-Mem：把“全量注入历史”改成“按需检索记忆”
Claude-Mem 解决的是一个很典型的问题：
-
你不想每次新开会话都从零开始
-
但你也不想每轮都把全部旧历史再读一遍
它做的不是“永久把历史塞在上下文里”，而是把过去会话整理成：
-
可搜索记忆
-
语义摘要
-
observation 索引
-
可按需取回的项目历史
它的价值在于：把“全部带上”改成“先搜，再筛，再展开”。
它适合谁？
-
长周期项目
-
经常断开重连的人
-
跨天协作、跨会话延续任务的人
它的优点：
-
减少重复介绍背景
-
保留连续性
-
记忆越多，分层检索越值钱
它的限制：
-
配置更重
-
管不好会把脏信息也长期保留下来
-
更像工程工具，不是即装即爆省的那种
一句话：Claude-Mem 不是“让 AI 永远记住”，而是“别每次都重读全部历史”。
6. HAM：把一个巨型 CLAUDE.md 拆成按目录分层的小册子
HAM 的思路特别适合大项目。
它抓住的问题是：很多项目只有一个超级肥的 CLAUDE.md，结果 AI 每次一开工都先重读整本项目说明书。
HAM 的办法是：
-
根目录放全局规则
-
src/放共享规则 -
src/api/放 API 规则 -
src/components/放组件规则 -
src/db/放数据库规则
这样 AI 在某个目录工作时，只读：根规则、当前目录规则、必要时再读父级目录规则。而不是每轮都背整本项目圣经。
它适合谁？
-
Claude Code 用户
-
多模块项目
-
项目规则越来越多的人
它的优点：
-
非常符合工程现实
-
对大项目很友好
-
从源头减少静态上下文的重复加载
它的限制：
-
更偏 Claude Code 生态
-
需要目录结构本身清晰
-
更像一种上下文组织方法，而不是黑箱插件
一句话：HAM 是把项目记忆从一本大词典，改成按楼层摆放的小册子。
7. Token Saver：专门压 MEMORY.md、USER.md 这些反复加载的固定文件
Token Saver 的目标非常明确：不是优化聊天，而是专打常驻 markdown 文件。
它通常会做几件事：
-
扫描工作区内常驻规则文件
-
评估哪些文件最肥
-
计算可节省多少 token
-
先自动备份
-
再压缩
-
支持回滚
这个工具最适合：
-
OpenClaw 用户
-
规则文件很多的人
-
长期把项目规范、偏好、背景写进 markdown 的人
它为什么很值钱？
因为这些文件不是一次性成本，而是高频重复成本。压掉一半，不是省一半一次，而是省一半乘以几十轮几百轮。
它的优点：
-
目标非常明确
-
很适合解决“固定税”
-
有备份、审计、回滚，适合普通人
它的限制：
-
主要解决规则文件，不是全场景工具
-
人类可读性可能会下降
-
对没有常驻大文件的人，收益不一定大
一句话：Token Saver 省的不是一轮聊天，而是每天都在反复收税的那些固定文件。
代码仓库和输入上下文类：专门解决“仓库太大，别瞎喂”
这一类解决的是更大的问题：不是一句 prompt 太长，而是仓库、代码、文件范围本来就太大。
8. SWE-Pruner：按任务意图裁掉无关代码，只留当前真正相关的部分
SWE-Pruner 不是普通文本压缩器。它做的是：按任务意图剪枝上下文。
比如一个问题只和几个函数、几段逻辑有关，它就尽量保留这些，砍掉外围大量无关代码。
这和简单摘要完全不同。因为代码不是文章，有些细节：一个条件分支、一个错误处理、一个函数签名等等，丢了就会影响推理。
它适合谁？
-
大型仓库用户
-
多文件工程任务
-
复杂排障
-
编码 Agent 重度用户
它的优点：
-
更偏根治输入端大头
-
对代码场景很精准
-
比全文摘要更贴近真实编码需要
它的限制：
-
偏工程化、偏代码
-
不适合普通聊天写作
-
小项目收益没那么夸张
一句话：SWE-Pruner 不是让 AI 少说，而是让它别把整个仓库都读一遍。
9. Repomix：如果你必须把整个仓库喂给 AI，至少别用最蠢的方式喂
很多人喂仓库给 AI 的方式特别原始：
-
一个个复制文件
-
目录乱贴
-
全仓源码硬塞进聊天框
-
贴到后面自己都不知道贴过什么
Repomix 做的，就是把整个仓库打包成 AI 更容易读、你也更容易控制 的格式。它支持：
-
按 ignore 规则排除垃圾文件
-
统计 token
-
生成 XML / Markdown / JSON / Plain Text
-
用
--compress只保留代码结构骨架 -
只打包指定 include 范围
-
处理远程 GitHub 仓库
它最适合：
-
整仓代码审查
-
快速理解别人的项目
-
用浏览器 AI 分析本地仓库
-
远程仓库快速打包
它的优点：
-
特别适合“仓库级输入准备”
-
远程仓库很方便
-
输出结构清晰，可控性高
-
--compress能减少实现细节带来的浪费
它的限制：
-
更像预处理工具，不是实时代理
-
如果你只改一个函数，用它打全仓就太重了
-
它解决的是“更聪明地喂仓库”，不是实时自动省
一句话：Repomix 不是让你多喂仓库，而是让你在必须喂仓库时别用最浪费的方式。
10. PromptPacker：给浏览器聊天用户准备的本地上下文打包器
PromptPacker 更适合这种工作流：
-
打开 ChatGPT / Claude 网页版
-
看本地项目
-
复制粘贴代码
-
想把项目上下文带进去，又怕贴太多、贴太乱
它的思路和 Repomix 有点像，但更偏向：
-
本地快速打包
-
浏览器聊天使用
-
AST 骨架化
-
context tiers：全文 / 骨架 / 忽略
-
自动跟踪文件变化
它适合谁？
-
重度网页版 ChatGPT / Claude / Gemini 用户
-
不一定用 Agent，但经常要把代码解释给 AI 的人
-
想把手工复制粘贴变聪明的人
它的优点：
-
贴近日常工作流
-
更轻量
-
很适合浏览器聊天工具
-
通过 skeletonization 减少实现细节 token
它的限制：
-
更像个人工具
-
生态和成熟度没那么大
-
不是平台级基础设施
一句话：PromptPacker 解决的是“我怎么把本地代码更省地塞进网页聊天框”。
平台级上下文层：专门解决“不是一个点在贵，而是整条链路都在贵”
如果你已经不是普通用户，而是在做复杂 Agent、RAG、工具链系统，那前面那些单点工具可能还不够。你需要的是一层总控。
11. Headroom：想做整个 AI 应用的“上下文压缩总线”
Headroom 的野心很大。它不是只管某个环节，而是想在整个链路里拦截和压缩：
-
工具输出
-
DB 查询结果
-
RAG 检索结果
-
文件读取结果
-
API 响应
-
长会话历史
它的形式也很多：代理、SDK、wrap、MCP、各种框架集成。Headroom 最值得注意的地方有三个：
-
不是简单截断，而是尽量保留可逆能力
-
不只压 token，还考虑缓存命中
-
适合多 Agent / 多框架 / 平台级接入
它适合谁？
-
Agent 平台开发者
-
复杂工作流用户
-
RAG、多工具、多数据源系统
-
想系统性压整体成本的人
它的优点：
-
视角最全
-
覆盖对象最广
-
很像基础设施层
它的限制：
-
配置和理解门槛高
-
对普通人来说太重
-
更适合团队和平台，而不是轻量单兵用户
一句话：Headroom 不是修一个点，而是想成为整个 AI 应用的上下文压缩层。
12. 动态 Skill 路由 / 向量检索：别把 59 个工具说明全塞进 system prompt
这里主要看到到是腾讯云 COS 向量桶官方推出的 OpenClaw 专用 Skills：cos-vectors-skill，需要在腾讯云开通 COS 向量桶。
所以我只是把功能列在这里，主要是通过动态 Skill 路由和向量检索来减少 Token 消耗的这种思想。
很多 Agent 平台越用越贵，不是因为任务复杂，而是因为系统越来越“全能”：一个天气 Skill、一个飞书插件、一个数据库工具、一堆 MCP Server、一堆默认 Prompt 文件等等。
然后用户随便只发一句“你好”，系统也会把整车工具说明书一起塞进去。
动态 Skill 路由的思路是：
-
先把工具/Skill 描述向量化
-
每条用户消息先做语义匹配
-
只取最相关的 Top-K 工具
-
只把这些工具注入当前上下文
它适合：
-
OpenClaw
-
多 Skill / 多 MCP 平台
-
工具非常多的团队
它的优点：
-
是平台级降本
-
不只省钱，还会减少误选工具
-
降低上下文噪音
它的限制：
-
更像架构方案，不像傻瓜插件
-
检索不准会漏工具
-
需要维护索引和召回逻辑
一句话：它做的不是压语言，而是阻止系统每轮都把全家桶工具背上。
13. agent-browser：网页交互时，别把整页 HTML 原样喂给模型
浏览器 Agent 最大的问题是：网页上下文本来就大，而且里面大部分都是噪音。
传统做法会把：HTML、CSS、JS、DOM、各种样式和脚本等等一股脑喂进去。
但模型很多时候真正要做的只是：
-
找输入框
-
找按钮
-
点击元素
-
读结果区块
agent-browser 的思路是：
-
把网页抽象成交互元素树
-
给元素编号
-
让模型只通过简短指令操作
比如它看到的不是整页 DOM，而是：
-
1：搜索框
-
2：提交按钮
-
3：结果列表
这样模型只需要说：
-
点击 2
-
在 1 输入关键词
-
读取 3
它适合谁？
-
浏览器 Agent 用户
-
网页搜索、自动填表、页面操作用户
-
已经上 browser automation，但 token 烧得太猛的人
它的优点：
-
浏览器场景降本很明显
-
上下文更清晰
-
更适合模型做动作决策
它的限制：
-
只适用于网页交互
-
不是通用省 Token 工具
-
更偏工程集成
一句话：agent-browser 的价值，是别让 AI 为了点个按钮先读完整页 HTML。
一张表看懂这些“科技”
这么多工具感觉大家应该也看累了，划到这里的就直接看表吧，如果有特别感兴趣的可以再专门去看看对应的工具。
终端输出优化
| 工具 | 方式 | 核心作用 | 主要省哪里 | 最适合谁 | 最大优点 | 最大限制 |
|---|---|---|---|---|---|---|
| RTK | CLI 工具 | 压缩 CLI / 测试 / Git 输出 | 终端输出 token | 编码 Agent 用户 | 见效快、改动小、通用性强 | 主要管 shell 命令输出 |
| Omni | 终端中间层 | 过滤终端噪音并提纯上下文 | 终端输出 token | 重度 terminal + AI 用户 | 不只省钱，还提升上下文质量 | 与 RTK 重叠较大 |
| distill | CLI 管道蒸馏器 | 按问题蒸馏命令输出 | 高价值命令输出 | 想要任务定制摘要的人 | 更贴目标，而不是泛泛压缩 | 依赖 prompt 质量，通常还要额外模型参与 |
输出风格控制
| 工具 | 方式 | 核心作用 | 主要省哪里 | 最适合谁 | 最大优点 | 最大限制 |
|---|---|---|---|---|---|---|
| Caveman | Prompt / 输出压缩器 | 压缩 AI 输出风格 | 输出 token | 讨厌废话的人 | 上手最快，回答更利落 | 对输入端帮助有限 |
记忆 / 规则文件
| 工具 | 方式 | 核心作用 | 主要省哪里 | 最适合谁 | 最大优点 | 最大限制 |
|---|---|---|---|---|---|---|
| Claude-Mem | 检索式记忆层 | 可检索的跨会话长期记忆 | 历史上下文重复加载 | 长周期项目 | 延续上下文而不必全量重读 | 配置较重 |
| HAM | 目录规则组织法 | 按目录拆分项目记忆 | 静态项目上下文 | Claude Code、大项目用户 | 把巨型 CLAUDE.md 变成分层小册子 | 更偏 Claude Code |
| Token Saver | Markdown 压缩器 | 压缩常驻 markdown 规则文件 | 固定上下文税 | OpenClaw / 规则文件多的人 | 专打反复加载的固定成本 | 主要解决规则文件 |
仓库 / 代码输入
| 工具 | 方式 | 核心作用 | 主要省哪里 | 最适合谁 | 最大优点 | 最大限制 |
|---|---|---|---|---|---|---|
| SWE-Pruner | 代码上下文剪枝器 | 任务感知代码剪枝 | 代码输入上下文 | 大仓库工程任务 | 少读无关代码，保留关键语义 | 偏代码工程 |
| Repomix | 仓库打包器 | 仓库打包与结构压缩 | 仓库级输入 | 整仓分析、远程仓审查、网页 AI 用户 | 全仓喂给 AI 时更可控、更整洁 | 更像预处理工具 |
| PromptPacker | 本地上下文打包器 | 本地代码上下文打包 | 浏览器聊天输入 | 网页版 ChatGPT / Claude 用户 | 非常贴近日常复制粘贴工作流 | 更轻量，偏个人工具 |
平台级上下文
| 工具 | 方式 | 核心作用 | 主要省哪里 | 最适合谁 | 最大优点 | 最大限制 |
|---|---|---|---|---|---|---|
| Headroom | 代理 / SDK / MCP 层 | 整条上下文链路压缩层 | 工具输出、RAG、DB、文件、历史等 | Agent 平台 / 复杂应用 | 视角最全，像基础设施 | 配置重，门槛高 |
| 动态 Skill 路由 | 架构方案 / Skills | 只注入当前相关工具 | Tool/Skill/MCP 描述 | 多工具平台 | 平台级降本，减少噪音和误选 | 更像架构方案 |
网页交互
| 工具 | 方式 | 核心作用 | 主要省哪里 | 最适合谁 | 最大优点 | 最大限制 |
|---|---|---|---|---|---|---|
| agent-browser | Skills | 网页交互上下文抽象化 | HTML / DOM 输入 | 浏览器 Agent 用户 | 不再把整页网页源码喂给模型 | 只适用于网页自动化 |
不靠工具，也能立刻省下来的使用方式
如果说上面的“科技”是在帮你修的是“系统层面的坏习惯”，那这一块说的，就是你自己使用 AI 时最容易犯的低级错误。
这部分是真·无侵入，是我觉得这个时代每个人都应该掌握的跟 AI 聊天的基础技能。
别把 AI 当微信聊
这是最常见的浪费源。以前我一直觉得没人会这么用 AI 的，但实际上就是有些人这么用了。 错误做法一般长这样：
-
“不对”
-
“你理解错了”
-
“我是说上面第二段”
-
“再改一下”
-
“再换个语气”
你每发一条，系统就更长一截。
所以更省的做法是：
-
能编辑原消息就编辑原消息
-
新任务开新会话
-
聊到 15～20 轮就总结一次，再开新窗口继续
-
把需求一次说完整，不要拆成微信式补充
一句话：消息条数越多，重复加载越贵。
输入先做减法，别让模型读垃圾
很多人老盯着输出，说 AI 输出一堆没办法啊balabala的，但其实模型输出真的不多，真正的大头还是在输入部分。
更省的输入方式包括：
-
少寒暄，直接下指令
-
精准指定文件、函数、段落，不要让 AI 全仓乱找
-
修 bug 就贴 bug 相关代码，不要把 500 行上下文全扔进去
-
PDF 先转成干净文本或 Markdown
-
截图能转文字就转文字
-
图片压到最低可用分辨率
-
RAG / 搜索别一口气喂十段，先筛最相关的几段
可以把这个原则记成一句话：
AI 时代最值钱的不是信息量，而是信噪比。
输出必须控长，别为礼貌付费
刚刚说了输入，但是输出 token 确实是更贵的，这块并不是没有办法控制，只要合适的提示词你就可以不让模型自由发挥。有些通用的东西你甚至可以写进你的 Agent.md 中。
实用做法是：
-
明确说“50 字以内”
-
明确说“三条 bullet points”
-
明确说“只给代码，不解释”
-
明确说“不要寒暄，不要复述我的问题，直接给结论”
-
能 JSON 就 JSON，能结构化就别散文化
很多时候你买的是答案，结果账单上记的是：
-
开场白
-
过渡句
-
客套结尾
-
复述需求
这些全都没必要。
做好上下文卫生，别让 AI 一直翻旧账
都在说大模型有什么短期记忆，长期记忆的，但其实现在的大模型并没有真正的长期记忆，这块前沿大模型公司比如 OpenAI、Anthropic 也一直在想办法。
所以当下，还是需要你去主动帮它做“赛博断舍离”。
比较有效的方式有：
-
长对话定期
/compact//clear -
没有太多关联的新任务直接打开新窗口再和 AI 交互
-
如果在进行中，突然想问些问题，那么善用
/btw功能 -
固定背景写进长期配置，而不是每轮重贴
-
系统提示词和规则文件尽量短
-
不同场景拆不同规则，按需加载
-
利用 Prompt Cache，让稳定内容别老改
你会发现，很多所谓 Token 爆炸，本质上是：上下文卫生太差。
模型和工作流要分工，别拿保时捷去买菜
很多最大的浪费，不是不会写 prompt，而是不会选模型。
这块算是进阶一点，比如说用Claude Opus 很贵，然后干所有活儿都用 Opus。这种算是很多人都有的情况，毕竟不用切换当然方便。然后消费自然也就上来了。可以了解一下 OpenCode，或者子代理相关的一些知识，来通过不同的模型处理不同等级的任务。
原则很简单：
-
简单任务用便宜模型
-
复杂任务再上大模型
-
资料整理、分类、格式化别次次动旗舰
-
架构、复杂排障、多文件推理再上贵模型
再进一步一点：
-
先让 AI 出计划，再执行
-
没搞清楚前先问，不要盲改
-
给搜索 / 工具调用设上限
-
一旦发现死循环，立刻打断
真正浪费 Token 的，不是 AI 回得长，而是它在错误方向上勤奋地白干活。
适合普通人马上照做的 5 个动作
这块其实真的不复杂，但总有些小伙伴觉得好像很难。我觉得吧，如果非要我推荐，那就先把这 5 件事做了，不是当成需要遵守的指令，这就是习惯：
-
新任务开新会话
-
尽量编辑原消息，不要连续补充纠错
-
问题一次说完整，别分成三四条发
-
限制输出长度：只要结论 / 要点 / 代码
-
别把整坨日志、整页网页、整份 PDF 原样喂给模型
最后的结论
最近总是有小伙伴问我说怎么节省 Token。
我本来不想写的，因为我本身在日常使用的时候没有也暂时不会上这些科技。
没有必要强行为了流量去介绍这些我觉得“尚不成熟”的压缩科技。
这次一次性把所有框架粗略盘点了一遍，也算是给大家一个交代了，大家可以按需取用试试效果。
说不定有些确实能满足你的需求，当然也要注意是否因为信息压缩而导致了 AI 能力下降。
因为其实很多所谓的压缩率高，很可能会导致关键信息的丢失，从而导致 AI 效果失真。
所以其实我本身连compact指令都很少用，更多的是及时在下一个任务的时候切换窗口。
我相信如果有效且无副作用的话，那么官方自然会集成，或者是成为业界人人都会用的常用插件。
就比如说 agent-browser 这样的skills，没有什么的侵入性，也能在帮我完成浏览器操作的工作，顺便还节省 Token，岂不美哉。
所以对节省 Token 来说，我的建议就一句话，就是学会聊天，管好你的上下文。
世界在变，时代也在前进。
框架层出不穷如雨后春笋。
而你掌握的和 AI 的交流方式，我相信永远不会过时。
我是单向箔，我们下次再见。
