Caveman 深度解析：让 AI 告别废话，65% Token 节省背后的工程智慧

🪨 "why use many token when few do trick" — 一个开源技能如何用"原始人说话法"重新定义 AI 编程效率

一、背景：Token 经济的隐形成本

在 2026 年的 AI 编程实践中，一个长期被忽视却成本惊人的问题浮出水面：LLM 输出中充斥着大量无意义的填充词（filler words）。

让我们先看一组真实的 API 调用数据，感受一下这个问题的规模：

这不是理论推演，而是 JuliusBrussee/caveman 项目用真实 API 调用测出的数据——平均节省 65% 的输出 Token，部分场景高达 87%。

更关键的是：Token 节省了，技术准确性 100% 保留。

二、Caveman 是什么

Caveman 是一个 Claude Code / Codex 插件/技能（skill），核心功能只有一个——让 AI 用最简洁的方式说话。

它不是让 AI 变笨，而是让 AI 只说该说的。

# 安装（支持 40+ AI 编程工具）
npx skills add JuliusBrussee/caveman

# 指定特定工具安装
npx skills add JuliusBrussee/caveman -a cursor
npx skills add JuliusBrussee/caveman -a cline
npx skills add JuliusBrussee/caveman -a windsurf

# Claude Code 插件安装
claude plugin marketplace add JuliusBrussee/caveman

安装后，只需说一句 talk like caveman 或敲 /caveman，Caveman 模式即刻激活。

2.1 三档强度可选

Caveman 不是非此即彼的二元开关，而是提供了精细的三档强度：

以下是同一技术问题在三档强度下的回答对比（解释 React 组件重渲染 bug）：

🪶 Lite（保留语法，专业简洁）：

"Your component re-renders because you create a new object reference each render. Inline object props fail shallow comparison every time. Wrap it in useMemo."

🪨 Full（标准 Caveman，碎片句式）：

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

🔥 Ultra（极限压缩，电报风格）：

"Inline obj prop → new ref → re-render. useMemo."

三种回答传达的信息量完全一致，但字数从 ~50 词压缩到 ~10 词。级别会保持到手动切换或会话结束。

2.2 精确的保留规则

Caveman 的压缩规则极为精准，以下内容原文保留：

而这些内容一律删除：

三、核心原理：不是变笨，是更聪明

3.1 Caveman 的压缩机制

Caveman 背后的洞察其实非常朴素：大多数 LLM 输出中，有效信息密度极低。

以一个常见的认证中间件修复场景为例：

正常回复（69 tokens）：

"The reason your authentication middleware is not properly validating the token expiry is likely because you're using < instead of <= in your conditional check. When a token's expiry timestamp equals the current time, the < operator treats it as already expired, which causes valid tokens to be rejected. I'd recommend changing the comparison operator from < to <= to fix this issue."

Caveman 回复（19 tokens）：

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

两句说的是同一件事，但后者的信息密度是前者的 3.6 倍。

为什么会这样？LLM 在训练中被大量人类对话数据fine-tune过，而人类对话天然有大量社交性填充词：

• "当然，我很乐意帮助你"
• "让我看看这个问题"
• "根据我的经验"

这些在人类交流中显得友好礼貌的词，在 AI 编程助手场景下是纯粹的开销。Caveman 就是把这层社交外衣剥离的工具。

3.2 科学研究背书：简洁反而更准确

2026 年 3 月，一篇发表在 arXiv 上的论文 "Brevity Constraints Reverse Performance Hierarchies in Language Models"（arXiv:2604.00025）从学术角度验证了 Caveman 的思路：

在特定基准测试中，强制大模型输出简短答案，准确率提升了 26 个百分点——完全逆转了"越详细越好"的性能层级。

论文的核心发现：

• 详细答案中的冗余信息会干扰模型的推理链，导致更多错误
• 简洁答案迫使模型直接触达核心逻辑，减少中间环节的噪声累积
• 在技术问答场景中，简洁性与正确性呈正相关

这给了 Caveman 坚实的学术基础——它不只是"更少字"，而是"更少干扰，更多正确"。

3.3 双向压缩：Caveman Compress

Caveman 只解决了输出端的 Token 浪费。但问题在输入端同样严重。

每个项目的 CLAUDE.md、MEMORY.md 等记忆文件，在每次会话开始时都会被完整加载。一个 1000 Token 的项目记忆文件，每次启动项目都要消耗这些 Token，日积月累非常可观。

Caveman Compress 就是解决这个问题的配套工具：

/caveman-compress CLAUDE.md

执行后，同目录下会生成两个文件：

CLAUDE.md          ← Caveman 压缩版（Claude 每次读取的版本，Token 更少）
CLAUDE.original.md ← 原始人类可读版（你编辑和查阅的版本）

压缩效果实测：

3.4 Caveman Compress 工作原理

Caveman Compress 是一个本地 Python 管道，设计哲学是**"能用本地解决的不浪费 Token"**：

文件类型检测（本地） → Claude 压缩（1次API调用） → 验证（本地）
                                                        ↓
                                                   若出错：定向修复（1次调用，精确修复）
                                                        ↓
                                                   最多重试2次，失败则回退原始文件

关键设计：

• 本地优先：文件类型识别、格式验证、语法检查全部本地完成，API 调用只用于真正需要语言理解的压缩步骤
• 精确修复：出错时只对问题段落重新调用，而非重新压缩整个文件
• 保守回退：任何失败都保留原始文件，不会造成内容丢失

3.5 全链路 Token 节省

当 Caveman 和 Caveman Compress 同时启用时，效果是叠加的：

四、实战对比：代码评审场景

最能体现 Caveman 价值的场景是代码评审（Code Review）——这是开发者最需要快速反馈、但传统 LLM 回复最冗长的场景之一。

4.1 场景：安全漏洞评审

Prompt： "Review this PR for security issues"

正常回复（687 tokens，节选）：

"Looking at this pull request, I can identify several security concerns that should be addressed before merging. First, there's a potential SQL injection vulnerability in the getUserById function where user input is directly concatenated into the SQL query string without proper parameterization. This could allow an attacker to inject malicious SQL code...

Second, the authentication middleware appears to be missing rate limiting, which could make the endpoint susceptible to brute force attacks. I would recommend implementing a rate limiting mechanism using a library like express-rate-limit...

Additionally, there's no input validation on the API endpoint, which could lead to unexpected behavior or security issues with malformed input data..."

Caveman 回复（398 tokens，完整）：

"Security issues found:

1. SQL injection in getUserById. User input concatenated directly into query string. Use parameterized queries:

-- Before (vulnerable)
db.query('SELECT * FROM users WHERE id = ' + userId)
-- After (safe)
db.query('SELECT * FROM users WHERE id = ?', [userId])

2. Auth endpoint missing rate limiting. Brute force possible. Add express-rate-limit:

import rateLimit from 'express-rate-limit';
app.use('/auth', rateLimit({ windowMs: 15*60*1000, max: 5 }));

3. No input validation on API. Add schema validation (e.g., zod, joi).

Fix these before merge."

节省：42%，核心安全问题 100% 覆盖，无遗漏。

4.2 场景：Git Rebase vs Merge 对比

Prompt： "Explain the difference between git rebase and git merge"

正常回复（702 tokens，节选）：

"Both git rebase and git merge are ways to integrate changes from one branch into another, but they do it in fundamentally different ways with different trade-offs. Understanding when to use each is an important part of Git workflow management...

Caveman 回复（292 tokens，完整）：

"Both integrate branch changes. Different how."

正常回复 用 3 段详细解释背景、适用场景、注意事项；Caveman 用一句概括后直接进入技术细节对比表格。

这个场景节省了 58% Token，但读者反而更容易快速找到自己需要的信息。

五、技术架构解析

5.1 整体架构

Caveman 项目虽小（本质上是一套 prompt 规则），但其架构设计颇为精巧：

┌─────────────────────────────────────────┐
│            User Session                 │
│                                         │
│   /caveman → 激活 Caveman System Prompt │
│                                         │
│   模型输出 → Caveman Filter             │
│   ├── 移除 filler（本地规则引擎）         │
│   ├── 保留技术术语（精确匹配）             │
│   ├── 保留代码块（AST 感知）              │
│   └── 输出压缩后响应                       │
└─────────────────────────────────────────┘

Filter 层是关键：它不需要模型重新推理，而是在模型输出后进行规则化的后处理。这保证了：

1. 零额外推理开销：没有第二次 LLM 调用
2. 确定性：相同输入总是产生相同的压缩输出
3. 低延迟：后处理延迟在毫秒级

5.2 Caveman Compress 架构

输入文件 (CLAUDE.md, 1000+ tokens)
        │
        ▼
┌───────────────────┐
│ 本地文件类型检测    │  ← 纯本地，零 API 消耗
│ .md/.txt/其他     │
└─────────┬─────────┘
          │
          ▼
┌───────────────────┐
│ Claude 压缩调用    │  ← 1次 API 调用
│ System: "Compress" │
│ Input: 文件内容    │
└─────────┬─────────┘
          │
          ▼
┌───────────────────┐
│ 本地验证           │  ← 检查关键信息是否保留
│ 1. 代码块完整性    │
│ 2. URL/路径有效性  │
│ 3. 术语准确性      │
└─────────┬─────────┘
     ┌────┴────┐
     │ 通过？   │
     └────┬────┘
     Yes  │  No (重试<=2)
     ▼    │
   写入   │
compressed.md
          │
     No (>=3次失败)
          │
     回退原始文件

5.3 压缩策略分类

Caveman 的压缩并非"简单截断"，而是规则化的结构化压缩：

类型 1：填充词移除（Pattern-based）

"I'd be happy to help you with that" → 删除
"The reason this is happening is because" → "because"
"I would recommend that you consider" → 删除

类型 2：语法压缩（Grammar-aware）

"Inline object as a prop" → "Inline object prop"
"Wrap the object in useMemo" → "Wrap in useMemo"

类型 3：逻辑链压缩（Context-aware）

如果前一句已经铺垫了技术背景，后续句中的指示代词
"this" / "that" 压缩为直接指代

六、使用场景与最佳实践

6.1 适合的场景

Caveman 在以下场景效果最佳：

1. 日常 bug 修复：不需要背景铺垫，直接说问题在哪、怎么修
2. 代码评审：快速定位问题，不需要冗余描述
3. 重构建议：聚焦改动点，简洁明了
4. 技术选型讨论：快速对比优劣，不需要逐条论证
5. 调试排查：错误 → 原因 → 修复路径，三步直达

6.2 不适合的场景

Caveman 不是万能的，以下场景建议慎用或切换到 Lite 档：

1. 新手教学 / 概念解释：需要循序渐进，Caveman 的跳跃式风格可能让人困惑
2. 架构设计讨论：需要充分论证，Caveman 的碎片风格不适合展示思维过程
3. 代码解释任务：需要上下文引导，帮助读者理解"为什么这样写"
4. 敏感/复杂决策：需要权衡利弊，简洁表达会丢失重要边界条件

6.3 团队使用建议

对于希望在团队中推广 Caveman 的技术负责人，以下几点值得考虑：

推荐起步方式：

• 个人项目先试，让每个开发者感受 Token 节省的实际效果
• 熟悉后逐步推广到 code review 场景
• 重要文档评审保留 Full/Ultra，细节评审可用 Ultra

文化适配：

• Caveman 风格可能让习惯了"详细回复"的人感到不适应
• 建议团队内部形成共识：评价标准是"是否解决了问题"，而非"回复是否详尽"
• 可以将 Caveman 视为"工具"，而非"态度"——回复简洁不代表不认真

七、项目现状与生态

7.1 关键数据

7.2 同作者其他项目

JuliusBrussee 的其他作品同样值得关注：

• Blueprint — 规格驱动的开发框架，将自然语言需求转化为 blueprints，然后并行构建产出可用软件
• Revu — macOS 本地优先的学习应用，内置 FSRS 间隔重复算法，支持记忆卡、考试和学习指南

7.3 局限性

客观来看，Caveman 目前有以下局限：

1. 英文为主：Caveman 的压缩规则针对英文设计，中文场景效果有限
2. 非通用解决方案：对于真正需要详细论证的技术决策，压缩可能导致信息不足
3. 依赖特定 Agent：需要 Claude Code / Codex 等支持 skill/plugin 机制的 AI 工具
4. Ultra 档适用性窄：极限压缩在生产代码评审中效果不错，但不适合代码解释类任务

八、启示与思考

8.1 AI 效率的新维度

Caveman 现象揭示了一个更深刻的问题：LLM 的输出效率远未达到最优。

大多数 LLM 在编程场景下的默认输出风格，延续了"对话助手"的人设——礼貌、详细、解释充分。但编程助手的核心价值不是"像人一样说话"，而是解决问题。

当一个 bug 修复建议从 687 个 Token 压缩到 398 个 Token（节省 42%），同时核心信息 100% 保留，这意味着人类开发者花费在阅读 LLM 回复上的时间也相应减少。这不是噱头，而是真实的工程效率提升。

8.2 "简洁即正确"的范式转变

传统观点认为：AI 回复越详细，越可靠、越专业。

Caveman 和相关学术研究正在动摇这个假设。在某些场景下，过度详细的回复反而更容易引入错误——因为模型在构建详细论证的过程中，可能在某个中间环节引入不准确的信息。

简洁的回复迫使模型"直接给答案"，中间环节的噪声被压缩，核心逻辑更清晰。

8.3 Token 经济的下一步

Caveman 从输出端和输入端双向压缩 Token，开启了一个值得关注的方向：Token 经济优化。

当 AI 编程工具的 Token 成本成为团队的重要支出时，类似 Caveman 这样的工具会从"有趣实验"变成"必需品"。可以预见，未来会出现更多专注于 AI Token 效率的工具和最佳实践。

九、安装与快速上手

9.1 一键安装

# 通用安装
npx skills add JuliusBrussee/caveman

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

9.2 使用方式

激活：Caveman 模式
触发：/caveman  |  "talk like caveman"  |  "caveman mode"
切换级别：/caveman lite  |  /caveman full  |  /caveman ultra
停用：stop caveman  |  normal mode

9.3 Caveman Compress 安装

# 在项目目录下执行
cd your-project
npx caveman-compress CLAUDE.md
npx caveman-compress MEMORY.md

9.4 验证安装

# 测试 Caveman 是否生效
/caveman
# 然后问一个技术问题，观察回复是否简洁

十、总结

Caveman 是一个典型的"小想法、大价值"的开源项目。它没有使用任何复杂的新技术，只是将一个简单的人类观察——"AI 回复有太多废话"——转化为一套可量化的工程实践。

关键数据一览：

在 AI 编程工具日益普及、Token 成本持续累积的 2026 年，Caveman 提供了一种不需要换模型、不需要调参数，只改变输出风格的效率优化路径。

最终，用一句话总结 Caveman：

🪨 Caveman no make brain smaller. Caveman make mouth smaller. Same answer. Less word.

参考资料：Caveman GitHub 仓库、arXiv:2604.00025、Blueprint 项目）