Caveman 深度解析：83K+ Stars 的 Token 压缩神器——用「原始人语言」让 AI 编程代理省 65% 算力的完整实战指南

why use many token when few token do trick

一、AI 编程代理的「钱包燃烧」困境

2026 年，AI 编程代理（Coding Agent）已经从「尝鲜玩具」变成了开发者的日常生产力工具。Claude Code、GitHub Copilot、Cursor、Codex、Gemini CLI——几乎每个主流 IDE 和终端都集成了某种形式的 AI 编程助手。

但一个残酷的现实是：用得越多，烧得越快。

以 Claude Code 为例，2026 年 4 月 Anthropic 进行了一轮价格调整后，重度用户的日均成本估算从 6 美元飙升到了 15-20 美元。一个典型的调试会话——你把错误信息贴给 AI，它洋洋洒洒写了一大段分析，你追问，它再写一大段——2 小时轻松烧掉 40 美元。

问题出在哪里？不是 AI 不够聪明，而是它太啰嗦了。

来看一个真实的例子。当你问 Claude Code「为什么我的 React 组件在反复重渲染？」时，它的典型回答是：

The reason your React component is re-rendering is likely because you're
creating a new object reference on each render cycle. When you pass an
inline object as prop, React's shallow comparison sees it as a different
object every time, which triggers a re-render. I'd recommend using
useMemo to memoize the object.

这段回答消耗了 69 个 output tokens。内容正确，但充满了「The reason... is likely because」「I'd recommend」这类礼貌性填充词。

如果你用 Caveman 模式，同样的回答变成：

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

19 个 tokens。技术信息零损失，token 消耗降低 72%。

这不是压缩算法，不是模型蒸馏，不是缓存复用——这是一种极其朴素但出奇有效的思路：让 AI 少说废话。

二、Caveman 是什么？

Caveman 是一个由开发者 JuliusBrussee 创建的开源项目，在 GitHub 上已经突破 83,000 Stars，日增 Star 超过 2,800，是 2026 年 7 月 GitHub Trending 榜单上最火爆的项目之一。

它的核心定位非常精准：一个 Claude Code / Codex / Gemini / Cursor / Windsurf / Cline / Copilot 等 30+ AI 编程代理的技能插件（Skill/Plugin）。

安装一条命令，AI 代理立刻学会「说人话」——去掉客套寒暄、去掉凑字数的废话段落、去掉模棱两可的修饰词，只输出最骨干的技术信息。

项目口号极其传神：

Caveman no make brain smaller. Caveman make mouth smaller.

（Caveman 不是让脑子变小，是让嘴巴变小。）

它压缩的是 AI 的输出表达，而不是 AI 的知识能力。技术准确性保持 100%，只是换了一种更高效的表达方式。

三、技术原理：语用压缩梯度体系

Caveman 的技术实现并不复杂——它不是什么神经网络压缩算法，而是一套精心设计的**提示词工程（Prompt Engineering）**系统。

3.1 核心机制：System Prompt 约束

Caveman 通过预设的系统提示词（System Prompt）或技能指令，约束模型的输出风格。它将 AI 的「人格」设定为一个只说关键词、省略虚词和敬语的「原始人」。

这套约束的核心逻辑建立在大语言模型的生成机制之上。LLM 在生成回答时，每个 token 都基于概率分布采样。默认情况下，模型倾向于使用礼貌、完整且语法严谨的自然语言——这是训练数据中「高质量回答」的统计特征。

Caveman 通过系统级指令，将这个概率分布偏移到「极简技术表达」的空间：

# Caveman Core Rules

- No filler words. No pleasantries. No "I'd be happy to".
- Subject-verb-object. Fragments OK.
- Code, commands, errors: byte-for-byte exact.
- Safety warnings: MUST switch back to full English.
- Keep user's language. Don't translate.

3.2 六级压缩梯度

Caveman 设计了六个压缩等级，用户可以随时通过 /caveman <level> 切换：

Normal（原始模式）——AI 的默认输出风格：

You should wrap the object in useMemo, since a new reference is
created on every render.

Lite（轻度压缩）——去掉填充词，保留完整句法：

Wrap object in useMemo. New ref created every render.

Full（默认压缩）——主谓宾结构，碎片化表达：

New ref each render. Wrap object in useMemo.

Ultra（极限压缩）——最短的完整句子：

New ref/render. useMemo it.

Wenyan（文言文模式）——用文言文表达，因为文言文每个 token 承载的信息密度最高：

每渲染则新引用生。以useMemo裹之。

这个设计非常巧妙：不同等级对应不同的语用压缩强度，用户可以根据场景选择。日常开发用 Full，追求极限省 token 用 Ultra，需要极致信息密度用 Wenyan。

3.3 安全机制：自动切换回正常语言

Caveman 的一个关键设计是：在执行任何破坏性操作之前，自动切换回正常的英语输出。

比如当你让 AI 执行 rm -rf / 之类的危险命令时，Caveman 不会用原始人语言输出安全警告，而是会切换回完整的、清晰的英语表达，确保你理解操作的后果。

这是一个非常负责任的设计——压缩表达不能压缩安全。

3.4 语言保持：压缩风格，不翻译

Caveman 有一个重要特性：它保持用户使用的语言。

你用中文提问，它用极简中文回答；你用西班牙语提问，它用极简西班牙语回答。它压缩的是表达风格，而不是语言种类。

唯一的例外是 Wenyan 模式——这是一个故意的设计，因为文言文的 token 信息密度在所有中文变体中是最高的。

四、性能基准：65% 的平均输出 Token 节省

Caveman 项目在 benchmarks/ 和 evals/ 目录下提供了完整的、可复现的基准测试数据。以下是基于 Claude API 真实 token 计数的测试结果：

关键发现

1. 解释类任务节省最多（81%-87%）：因为这类任务中 AI 最喜欢「废话连篇」，Caveman 的压缩效果最显著
2. 重构类任务节省最少（22%）：因为代码变更本身需要精确描述，压缩空间有限
3. 平均节省 65%：这是一个非常可观的数字

诚实的数字警告

Caveman 项目非常坦诚地指出了一个重要事实：Caveman 只压缩输出 tokens，输入和推理 tokens 不受影响。

而且技能本身每次会话会增加约 1-1.5K 的输入 tokens（系统提示词）。因此：

• 整个会话的实际节省率低于 65% 的输出节省率
• 在已经很简洁的工作负载中（比如纯代码生成），可能会出现净亏损
• 真正的收益在于可读性和速度，成本节省是「附赠品」

项目引用了一篇 2026 年 3 月的学术论文 Brevity Constraints Reverse Performance Hierarchies in Language Models 来支持一个反直觉的发现：

限制大模型输出简短回答，在某些基准测试上反而能提高约 26 个百分点的准确率。

换句话说：有时候少说话 ≠ 说不清楚，少说话 = 说得更准。

五、安装与实战

5.1 一键安装

Caveman 的安装极其简单，一条命令搞定：

# macOS / Linux / WSL / Git Bash
curl -fsSL https://raw.githubusercontent.com/JuliusBrussee/caveman/main/install.sh | bash

# Windows PowerShell 5.1+
irm https://raw.githubusercontent.com/JuliusBrussee/caveman/main/install.ps1 | iex

安装脚本会自动检测你机器上安装的所有 AI 编程代理（Claude Code、Cursor、Gemini CLI、Windsurf 等），然后为每个代理安装对应的技能/插件。耗时约 30 秒，需要 Node ≥ 18。

5.2 针对特定代理安装

如果你只想为某个特定代理安装：

# Claude Code 插件
claude plugin marketplace add JuliusBrussee/caveman && claude plugin install caveman@caveman

# Gemini CLI 扩展
gemini extensions install https://github.com/JuliusBrussee/caveman

# Cursor / Windsurf / Cline / Codex 等 30+ 代理
npx skills add JuliusBrussee/caveman -a cursor

5.3 常用命令

5.4 实战场景演示

场景 1：调试错误

claude "React: Maximum update depth exceeded"

Normal 模式输出（约 120 tokens）：

Sure! I'd be happy to help you with that. The issue you're experiencing
is most likely caused by your authentication middleware not properly
validating the token expiry. Let me take a look and suggest a fix.
The root cause is that...

Caveman 模式输出（约 40 tokens）：

Bug in auth middleware. Token expiry check use < not <=. Fix:

场景 2：代码审查

claude review

Caveman 评论风格：

L12: 🔴 SQL injection. Use parameterized query.
L45: 🟡 Unused import. Remove.
L78: 🟢 Good. No change needed.
L102: 🔴 Race condition. Add mutex.

场景 3：生成提交信息

/claude /caveman-commit

输出：

fix: null check on user.token before expiry comparison

Middleware skipped validation when token was undefined.
Added guard clause. Bug existed since v2.1.0.

六、caveman-compress：永久压缩输入 tokens

Caveman 最被低估的功能之一是 /caveman-compress 命令。它可以将你的记忆文件（如 CLAUDE.md、项目笔记等）重写为 caveman 风格。

为什么要这么做？因为这些文件在每次会话开始时都会被加载为输入 tokens。压缩它们 = 永久减少每次会话的输入成本。

实测数据：

平均 46% 的输入 token 节省，而且是一次压缩、永久受益。

七、生态体系：五件套构建完整 Token 优化栈

Caveman 并不是孤立存在的。JuliusBrussee 构建了一个完整的 Token 优化生态系统，五个工具各司其职：

7.1 caveman（本项目）

压缩 AI 代理的输出表达。让代理少说废话，保留技术准确性。

7.2 caveman-code

一个完整的终端编程代理，从头到尾都是 caveman 风格。相比 Codex，相同任务的 token 消耗降低约 2 倍。支持 20+ 模型提供商、计划模式（Plan Mode）、自动目标循环（Autopilot Goal Loop）。

npm install -g @juliusbrussee/caveman-code

7.3 cavemem

跨会话记忆压缩工具。AI 代理在不同会话之间需要「记住」上下文，cavemem 负责压缩这些跨会话记忆，减少历史上下文的 token 开销。

7.4 cavekit

构建循环工具，基于规格驱动（Spec-Driven）的任务管理。从 inbox → active → archive 的工作流，减少代理在任务管理上的「猜测性」token 消耗。

7.5 cavegemma

将 Caveman 的压缩能力直接烘焙进模型权重。这是一个基于 Google Gemma 模型的微调版本，模型本身就学会了压缩表达，无需外部提示词干预。

7.6 同门技能包

JuliusBrussee/skills 仓库还包含五个配套技能：

八、为什么 Caveman 能火？三个深层原因

8.1 精准切中痛点

Caveman 不是在解决一个「可能有」的问题，而是在解决一个「每天都在烧钱」的真实痛点。每个使用 AI 编程代理的开发者都经历过「AI 回复太长、太啰嗦」的困扰。

8.2 解决方案极其简单

不需要训练新模型，不需要搭建基础设施，不需要修改代理源码——一条命令安装，立刻生效。这种「零门槛、即时收益」的方案天然具有病毒传播性。

8.3 幽默的品牌定位

「原始人语言」「OOG」「brain still big, mouth small」——这种幽默感让一个本质上是「省 token」的枯燥技术项目变得极具传播力。开发者愿意分享它，不仅因为有用，还因为有趣。

九、与同类方案的对比

在 Token 优化领域，Caveman 并不是唯一的玩家。但它的定位非常独特：

9.1 vs 模型压缩/蒸馏

模型压缩（如 GPTQ、AWQ）和知识蒸馏是通过减少模型参数来降低推理成本。Caveman 不碰模型本身，只压缩输出表达。两者可以叠加使用。

9.2 vs 上下文压缩/摘要

上下文压缩（如 LongLLMLingua）是对输入上下文进行压缩，减少输入 tokens。Caveman 主要压缩输出（caveman-compress 也能压缩输入文件）。两者互补。

9.3 vs 缓存/复用

缓存方案（如 Anthropic Prompt Caching）通过缓存重复的提示词前缀来减少计算。Caveman 通过减少输出长度来节省 tokens。两者完全正交。

9.4 vs RTK/Caveman 压缩（OmniRoute 项目）

OmniRoute 网关项目中也实现了类似的 Token 压缩功能（RTK + Caveman 双层压缩）。但 Caveman 作为独立工具的优势在于：它直接集成到编程代理的技能系统中，使用更自然，不需要额外的网关层。

十、wenyan 模式：当原始人遇上文言文

Caveman 最出圈的功能之一是 Wenyan（文言文）模式。这个模式用文言文来表达技术内容，因为文言文每个 token 承载的信息密度在所有中文变体中是最高的。

为什么文言文的 token 效率高？因为 LLM 的 tokenizer 对中文的处理方式是将每个汉字（或常用词组）映射为 1-3 个 tokens。文言文用更少的字表达更多的意思，自然消耗更少的 tokens。

示例：

# Normal 模式（英文，69 tokens）
The reason your React component is re-rendering is likely because you're
creating a new object reference on each render cycle.

# Full Caveman 模式（英文，19 tokens）
New object ref each render. Inline object prop = new ref = re-render.

# Wenyan 模式（文言文，约 12 tokens）
每渲染则新引用生。因内联对象作属性，React浅比较视为异物，遂重渲染。

文言文模式不仅省 token，还有一种独特的「赛博古典」美感——用两千年前的语言风格讨论 React Hooks，这种反差感本身就很有传播力。

十一、实际成本分析

让我们用真实数字来算一笔账。

假设你是一个重度 Claude Code 用户：

• 每天使用 4 小时
• 平均每 3 分钟一次交互
• 每次交互平均 1,200 output tokens（Normal 模式）
• Claude Sonnet 4 定价：$15 / 1M output tokens

Normal 模式日成本：

80 次交互 × 1,200 tokens × $15/1M = $1.44/天 output tokens

Caveman Full 模式日成本：

80 次交互 × 294 tokens × $15/1M = $0.35/天 output tokens

日节省：$1.09，月节省：$32.70

加上 caveman-compress 压缩记忆文件后，输入 tokens 也能节省约 46%，假设输入 tokens 占总成本的 60%：

额外节省：$1.44 × 0.6 × 0.46 ≈ $0.40/天

综合月节省：约 $45

对于团队来说，如果 10 个开发者都使用 Caveman，月节省约 $450。一年就是 $5,400。

十二、局限性与注意事项

12.1 不适合所有场景

• 学习/教学场景：如果你需要 AI 详细解释一个概念，Caveman 的压缩输出可能不够充分
• 文档生成：生成文档时需要完整的、礼貌的语言表达
• 初次接触新技术：详细解释比碎片化表达更有帮助

12.2 压缩质量依赖模型能力

Caveman 的效果高度依赖底层模型的指令遵循能力。在较弱的模型上，压缩可能导致信息丢失或表达混乱。推荐在 Claude Sonnet 4 / GPT-4o / Gemini 2.5 Pro 等强模型上使用。

12.3 净节省不一定为正

如前所述，Caveman 技能本身会增加 1-1.5K 输入 tokens。在已经很简洁的工作负载中（纯代码生成、简单查询），可能出现净亏损。建议在交互密集的调试、讨论、架构设计场景中使用。

12.4 团队协作一致性

如果团队中只有部分人使用 Caveman，代码审查和讨论的风格差异可能导致沟通成本增加。建议团队统一使用同一压缩等级。

十三、总结与展望

Caveman 的成功揭示了一个被忽视的 AI 工程化问题：我们一直在优化模型本身，却很少优化人与模型之间的沟通方式。

从 Prompt Engineering 到 Context Engineering，再到 Caveman 代表的「Output Engineering」，AI 工程化的边界正在不断扩展。

几个值得思考的方向：

1. 输出风格能否自适应？ 未来可能出现根据任务类型自动切换压缩等级的智能系统
2. 模型能否原生支持极简模式？ Anthropic、OpenAI 等厂商是否会将类似功能内置到模型 API 中
3. Token 压缩是否会成为标准中间件？ 就像 HTTP 压缩（gzip）成为 Web 标准一样，Token 压缩可能成为 AI 代理的标准基础设施
4. 更多语言的信息密度优化？ 文言文之外，是否还有其他自然语言变体具有更高的 token 信息密度

Caveman 用最简单的方式解决了一个真实的问题。它不是银弹，但它证明了一个道理：

在 AI 时代，少即是多。

项目地址：https://github.com/JuliusBrussee/caveman

Star 数：83,000+

安装命令：curl -fsSL https://raw.githubusercontent.com/JuliusBrussee/caveman/main/install.sh | bash

许可证：MIT