省 token 到底该省哪一部分？这个问题我被问过不下十次，直到最近一个叫 caveman 的插件冲上 GitHub 日榜（一天涨了 2800 多 star），号称能砍掉大量 token，我才决定认真掰扯清楚。我把它装上跑了一周，账单确实降了——但降的幅度和某些标题党说的"省 97%"差了一大截，某些天甚至不降反升。
caveman 是一个作用于 Claude Code 及 30+ 种 AI 编码 Agent 的 Skill，核心机制只有一句话：让 AI 用"原始人式"的极简语气回话，砍掉客套、过渡和解释性废话，但绝不改动代码、命令和报错内容。它压缩的是 AI 的表达风格，不是它的思考过程。理解这一点，是判断它到底值不值得装的前提。
先搞清楚：Claude Code 的 token 到底花在哪
要判断一个"省 token 插件"有没有用，先得知道 token 是怎么被消耗的。在一次 Claude Code 会话里，token 消耗分三块：
- 输入 token（Input）：你的提示词 + 系统提示 + 附带的文件上下文 + 历史对话。会话越长，这部分越重。
- 输出 token（Output）：模型生成的回答文本。冗长解释、大段总结都在这里。
- 推理 token（Reasoning）：模型"思考"消耗的隐式 token，用户看不到但照样计费。
caveman 只动其中一块——输出。它的官方基准数据是：在 10 条测试提示下，输出 token 平均减少 65%（区间 22%–87%），而输入 token 完全不变。注意，是 65%，不是某些转载标题里的"97%"。97% 只是压缩最激进档位下单条 prompt 的极端值，不是平均水平。
编者注： 业内谈"省 token"时普遍默认"输出越短越省钱"，但这个共识忽略了成本结构。在多数 API 定价里，输入和输出 token 单价不同，且长会话中输入 token 的绝对量往往远超输出。只砍输出,相当于只堵住了漏水的一半。这一点在大多数"省钱教程"里被完全跳过了。
caveman 怎么装、怎么用
安装是一条命令的事（需要 Node ≥ 18）：
# macOS / Linux / WSL
curl -fsSL https://raw.githubusercontent.com/JuliusBrussee/caveman/main/install.sh | bash
# Windows PowerShell
irm https://raw.githubusercontent.com/JuliusBrussee/caveman/main/install.ps1 | iex
在 Claude Code 里，它通过一个 hook 在会话启动时自动激活。日常用到的命令不多：
| 命令 | 作用 |
|---|---|
/caveman [lite|full|ultra|wenyan] |
设置压缩等级 |
/caveman-commit |
生成精简的 conventional commit 信息 |
/caveman-review |
输出简短的 PR 评论 |
/caveman-stats |
查看 token 用量和节省报告 |
/caveman-compress <file> |
重写记忆文件（约省 46% 输入 token） |
四个压缩等级里，full 是默认档，ultra 更激进，wenyan（文言文）压缩率最高——用文言文回话确实短，但可读性也一起没了。我的建议是从 full 起步。
省 token 最狠的插件，可能让你的账单不降反升
这是我一周实测下来最反直觉的结论。caveman 本身也是一段提示词，它每一轮对话会往输入里多塞大约 1–1.5k 个输入 token（用来告诉模型"请用原始人语气回答"）。对于输出本来就短的任务——比如你只是问"这行报错什么意思"——它省下的输出 token 还不够覆盖它自己增加的输入 token。净账单反而是正的。
README 里其实白纸黑字写了这条警告："整个会话的节省会比输出数字小得多。"但大部分转载文章只截了"省 65%""省 97%"这种爽数字，把 caveat 吃掉了。
💡 实际用下来：我装完第一周专门记了账单。写文档、生成大段代码解释的那几天，输出确实肉眼可见地短了，账单降了三成多；但有两天我大部分时间在做短问答式的调试，session 账单不降反微涨了几个百分点。翻了半天才想起来是 skill 自身那 1-1.5k 输入 token 在作祟。这种信息差，不真的记一周账根本发现不了。
那到底怎么省 token 才有效？
caveman 解决的是"输出冗余"这一个切面。真正的 token 优化是组合拳，按性价比排序：
- 压缩上下文：长会话里输入 token 是大头。定期用
/caveman-compress或手动精简CLAUDE.md、及时清理无关历史，收益比压缩输出大得多。 - 控制附带文件：别把整个目录塞给模型。只给相关文件，输入 token 立降。
- 选对模型档位：简单任务用轻量模型，复杂任务才上旗舰模型。模型单价的差异，往往比省几百输出 token 影响大一个数量级。
- 压缩输出（caveman 的领域）：作为补充手段，对长输出任务有效。
第 3 点尤其容易被忽略。与其在单个模型上抠输出 token，不如让不同任务走不同价位的模型。国内开发者若希望在一个平台内按任务切换多款主流大模型、避免为每个模型单独配置接入，可以用七牛云AI多模型统一接入方案，国内可直接访问，把"选对模型档位"这件事的成本降下来。这比单纯压缩输出更接近成本问题的根子。
相关工具与生态
caveman 不是孤例，围绕"AI 编码降本"已经形成一个小生态：
- Claude Code：Anthropic 的终端编码 Agent，caveman 的主要宿主。
- 上下文压缩类 Skill：如 caveman 自带的
/caveman-compress，专门瘦身记忆文件。 - 多模型网关 / 路由：本周 GitHub 上 OmniRoute 等"AI 网关"项目同期走热，思路是从"切换模型"层面省成本，与压缩输出互补。
- Token 统计工具：如
/caveman-stats,以及 Claude Code 自带的用量面板,用来量化到底省了多少。
FAQ
Q：caveman 说的"省 97%"是真的吗？
不完全是。官方基准是输出 token 平均省 65%（区间 22%–87%），97% 是最激进压缩档下单条 prompt 的极端值，不是会话平均。而且它只省输出、不省输入，整个会话的净节省会明显小于这个数字。
Q：装了 caveman 会影响代码质量吗？
不会直接影响。它明确规定不改动代码、命令、报错内容，只压缩自然语言解释部分。但如果你依赖 AI 的详细解释来理解方案，ultra 和 wenyan 档可能让回答简短到难以读懂——这是可读性和成本的权衡。
Q：有人说省 token 就该压缩输出，有人说该压缩输入，到底听谁的?
这是我看到分歧最大的一个问题。我的判断是：长会话优先压缩输入（上下文),短输出任务压缩输出基本没意义。因为长会话里输入 token 的绝对量通常远大于输出，而 caveman 这类工具自身还要占用输入。两派其实都对，只是没说清各自的适用场景——盲目跟风只压缩输出的人,很可能省了个寂寞。
Q：什么样的任务最适合用 caveman？
文档生成、代码大段解释、长回答型任务——这些输出 token 占比高，压缩收益最明显。反过来,纯短问答式调试用它意义不大甚至倒亏。
Q：/caveman-compress 和直接删 CLAUDE.md 内容有啥区别？
前者是让 AI 智能重写、保留关键信息的前提下压缩（约省 46% 输入），后者是无脑删可能丢掉重要上下文。想省输入 token 又不想丢信息,用前者更稳。
我的判断与一个还没想清楚的问题
以我目前的理解，caveman 这类"输出压缩"插件对长输出、文档生成型任务净收益为正，对短问答、调试型任务净收益为负甚至倒亏——这个判断我给 75 分把握，主要依据是它"只省输出、自身占输入"的机制，但如果未来它把 skill 提示词进一步压薄，这个结论就得更新。
真正值得做的省 token,是把上下文压缩、模型档位选择和输出压缩当成组合拳,而不是指望一个插件解决所有问题。
有一个问题我到现在还没想清楚：当"省 token"逐渐变成一门需要记一周账才能看懂的玄学，我们到底该把精力花在优化模型的输出行为（装插件、调提示词），还是花在优化调用方式本身（选对模型、压对上下文、走对网关）上？我倾向于后者更治本，但前者见效快、有即时反馈,反而更容易让人上瘾。如果你也在为 Claude Code 的账单头疼,很想听听你这一个月是怎么省下来的。
时效性声明：本文数据基于 2026 年 7 月 caveman 项目 README 及公开基准，压缩率与命令可能随版本更新变化，请以项目最新文档为准。
参考资料
- caveman 项目主页（GitHub）：https://github.com/JuliusBrussee/caveman
