Caveman 深度解读：75%省 token 是数字游戏，真正值钱的是三层隐藏设计

> 项目：JuliusBrussee/caveman > Star：38,183（截至 2026-05-28） > 作者：Julius Brussee > 仓库：https://github.com/JuliusBrussee/caveman > 主页：https://juliusbrussee.github.io/caveman/

---

一场关于"废话"的社会运动

4月4号建的仓库，15天冲到38000 Star。这不是技术突破，是一场社会运动——开发者们受够了AI的废话。

Caveman的slogan很直接："why use many token when few token do trick"。装上它，Claude Code会从：

> "The reason your React component is re-rendering is likely because you're creating a new object reference on each render cycle..."

变成：

> "New object ref each render. Inline object prop = new ref = re-render. Wrap in useMemo."

69个token压到19个。漂亮。但问题来了——这75%的节省，是数字游戏。

---

第一层（表面）：输出压缩——省的是"嘴"

Caveman的核心是一个system prompt技能，告诉agent：

• 删掉冠词（a, an, the）
• 删掉填充词（just, really, actually, simply）
• 删掉客气话（sure, certainly, happy to）
• 用短同义词（fix 而不是 "implement solution"）
• 不修饰（跳过 "might be worth considering"）
• 允许片段，技术术语保持精确
• 代码块不动，只压缩代码外的自然语言

三个强度等级：

• lite：删掉填充词，保留语法
• full：删掉冠词，用片段（默认）
• ultra：最大压缩，电报式

实测数据（官方benchmark）：

任务	正常模式	Caveman	节省
解释React重渲染bug	1,180	159	87%
修复auth中间件token过期	704	121	83%
设置PostgreSQL连接池	2,347	380	84%
重构callback到async/await	387	301	22%
平均	1,214	294	65%

看着很美。但有个扎心的真相。

---

75%是数字游戏的真相

Claude Code的账单结构长这样：

一次典型100K token会话：
├── 输入token: 94,000 (94%)
│   ├── 工具调用结果: ~60,000
│   ├── 历史上下文: ~25,000
│   ├── CLAUDE.md/项目记忆: ~5,000
│   └── 用户新消息: ~4,000
└── 输出token: 6,000 (6%)
    ├── 代码生成: ~3,000
    ├── 工具调用参数: ~1,500
    └── 自然语言解释(prose): ~1,500

Caveman只压缩最后一项——prose。它不动代码、不动工具调用、不动思考过程。

所以在一个100K token的会话中：

• 表面节省：75% of 1,500 = 1,125 token
• 实际会话级节省：1.1%

有博主做了更精确的计算：在agentic工作流中，8次工具调用烧掉15,000输入token，最终压缩回答省100输出token。总成本节省不到1%。

这就是用户说的"数字游戏"。

---

第二层（真正值钱）：输入压缩——caveman-compress

Caveman-compress是被人忽视的大杀器。它做一件事：

把你的CLAUDE.md、project notes、记忆文件，重写成caveman语。

实测数据：

文件	原始	压缩后	节省
claude-md-preferences.md	706	285	59.6%
project-notes.md	1,145	535	53.3%
claude-md-project.md	1,122	636	43.3%
todo-list.md	627	388	38.1%
平均	898	481	46%

为什么这比输出压缩值钱？

因为CLAUDE.md是每个会话都要重新注入的。输出压缩省一次，输入压缩省每一次。

一个每天开20次会话的开发者：

• 输出压缩：每次省1,000 token × 20 = 20,000 token/天
• 输入压缩：每次省2,000 token × 20 = 40,000 token/天

输入压缩的长期收益是输出压缩的两倍。

---

第三层（最有野心）：cavecrew子智能体 + caveman-shrink MCP中间件

这是Caveman生态里最有意思的部分。

cavecrew-*：压缩的子智能体

Caveman提供了三个子智能体：

• cavecrew-investigator：定位代码
• cavecrew-builder：编辑1-2个文件
• cavecrew-reviewer：diff review

它们比普通Claude Code子智能体少发约60%的token。关键机制：

子智能体的输出会重新注入主上下文。如果子智能体发回10,000 token的详细报告，主上下文就少了10,000 token的可用空间。Cavecrew把它压到4,000 token，主上下文寿命延长了。

在长期会话中（特别是Claude Code的200K上下文窗口），这决定了你能干多少活而不触发上下文截断。

caveman-shrink：MCP中间件

npx caveman-shrink 是一个MCP中间件，包装任何MCP server，压缩工具描述。

MCP工具描述通常很长（几百到几千token）。caveman-shrink把它们压掉约40%。在工具多的项目中（比如有几十个MCP工具），这也是一笔不小的节省。

---

那到底该不该装Caveman？

一句话判断标准：

> 你的Claude Code账单里，输出token占比多少？

• <5%： Caveman对你几乎没价值。你的token都烧在工具调用和上下文上。
• 5-15%： 可以装，但别期待奇迹。主要收益在caveman-compress的输入压缩。
• >15%： 值得装。你可能是做大量代码审查、文档生成、或者单轮对话为主的任务。

真正适合Caveman的场景

1. 代码审查流水线：大量PR review，每轮省40-70%解释文字 2. 文档生成：需要Claude写大量自然语言说明 3. 教学/解释类任务："给我解释这个概念" 4. 长会话生存：配合cavecrew子智能体，延长上下文寿命

不适合的场景

1. 深度agentic工作流：工具调用占主导，压缩 prose 无关痛痒 2. 一次性短查询：本身就没几个字，压缩空间有限 3. 需要精细解释的场景：压缩会吃掉 nuance，比如 "useMemo和useCallback的区别"

---

更有趣的问题：为什么"废话"存在？

Caveman火到这个程度，说明了一个被忽视的问题：AI的废话是结构性的，不是功能性的。

2026年3月的一篇论文 *Brevity Constraints Reverse Performance Hierarchies in Language Models* 发现：

• 限制模型简短回答，准确率提升了26个百分点
• 大模型和小模型的性能差距缩小了三分之二
• 机制："自发尺度依赖的 verbosity"——大模型过度阐述，反而把自己绕进错误答案（overthinking）

这意味着Caveman不仅省钱，可能还提高了准确率。

---

一句话总结

Caveman的75%是数字游戏——在典型Claude Code会话中，prose只占token总量的个位数百分比。

真正值钱的是两层隐藏设计： 1. caveman-compress：每次会话省46%输入token，长期复利 2. cavecrew + caveman-shrink：子智能体和MCP中间件压缩，延长上下文寿命

如果你的账单结构是"输出为主"，Caveman是神器。如果是"agentic工作流为主"，它的价值有限——除非你用上compress和cavecrew。

---

参考

• 项目地址：https://github.com/JuliusBrussee/caveman
• 作者博客：https://www.juliusbrussee.com/
• 论文：Brevity Constraints Reverse Performance Hierarchies in Language Models (2026.03)
• 相关评测：https://andrew.ooo/posts/caveman-claude-code-skill-token-savings-review/

#Caveman #ClaudeCode #Token优化 #AI代理 #成本优化 #vibecoding