为什么原始人说话能让 AI 节省 65% Token？Caveman 项目深度解析
前言：一个 19 岁开发者的反直觉实验
2026 年的 GitHub Trending 榜上，一个名叫 Caveman 的项目格外扎眼——不是因为它的功能有多复杂，而是因为它的 slogan 太反常识：why use many token when few token do trick。
这句话改编自经典的迷因，用在 AI 对话语境里却意外地精准。作者 Julius Brussee 是个 19 岁的独立开发者，他的项目让 Claude Code、Cursor、Windsurf 等 AI 编程助手强制用穴居人式的极简语言回复——砍掉所有客套话、填充词和冗余解释，只输出最核心的技术事实和行动指令。
结果：平均减少 65% 的输出 Token，最高可达 75%，而技术准确性分毫未损。
这个项目从 2026 年 4 月到 7 月，狂揽超过 8.3 万 Star，日增 Star 稳定在 1000 以上，成为 2026 年最受关注的 AI 编程效率工具之一。
但我真正想探讨的不只是节省多少钱，而是这个项目背后揭示的一个被忽视的 AI 交互盲区：我们一直在教 AI 怎么说得更详细，却从来没想过——是不是说得更少，效果反而更好？
今天这篇，我来彻底拆解 Caveman 的底层原理、实战效果、以及它对 AI 编程工作流的真实影响。
一、你每天被 AI 废话偷走了多少 Token？
先来算一笔账。
假设你每天和 Claude Code 进行 50 轮对话，每轮 AI 回复约 2000 个 Token。用普通模式，2000 Token × 50 = 10 万 Token/天。按 Claude 3.5 Sonnet 的定价（约 3 美元/百万输出 Token），一天大约花掉 0.30 美元。一个月就是 9 美元。
听起来不多？但这只是一个人。如果你的团队有 10 个开发者，月成本 90 美元；100 人团队，月成本 900 美元。一年下来轻松过万。
而这还只是正常使用——很多人没有意识到，AI 回复里充斥着大量信息噪声：
| 噪声类型 | 典型示例 |
|---|---|
| 元话语 | 让我来解释一下、根据我的分析、总的来说 |
| 缓和语气词 | 可能、或许、基本上、实际上 |
| 社交填充词 | 当然！我很乐意、不用客气、很高兴能帮到你 |
| 冗余解释 | 用三种方式重复同一个概念以确保全面 |
一个真实的对比实验（来自 Caveman 的 benchmark）：
普通模式：
当然，我很乐意帮你分析这个问题！根据我对代码的检查，在 useEffect 的第二个参数数组中，你并没有包含 setCount 这个 setter 函数。这意味着每次组件重新渲染时，setCount 的引用都会变化，可能导致不必要的副作用触发。让我来详细解释一下这个问题以及推荐的最佳实践方案……
Caveman 模式（Full 档）：
缺少 setCount 依赖。添加进依赖数组，否则闭包捕获旧值，导致 stale closure。
两条消息技术含义完全一致，但 Token 消耗差距约 10 倍。
二、Caveman 的核心原理：从告诉 AI 简洁到强制 AI 简洁
2.1 为什么告诉 AI 简洁不起作用
很多人会说：这有什么难的，直接让 AI 简洁回复不就行了？
还真不行。我在测试时发现，直接在 Prompt 里加请简洁回答的效果极不稳定——AI 偶尔会简短，但大部分时候还是回归它的本性：生成流畅、详细、符合人类阅读习惯的冗长文本。
原因在于：大语言模型被训练成生成符合人类语言习惯的文本。人类语言习惯天然包含大量冗余、客套和缓冲词。模型在预训练阶段见过无数这样的文本，它的默认模式就是多说一些更安全。
Caveman 的核心创新，不是简单地说请简洁，而是通过 Prompt 工程从根本上改变 AI 的语言风格认知。
2.2 Prompt 重写：语言风格的系统性重塑
Caveman 的 skills 文件本质上是一个 Prompt 重写系统。它通过三层机制强制 AI 改变说话风格：
第一层：系统级语言规范
You are a caveman. You speak in very short, direct sentences.
Never use:
- Certainly, Of course, I would be happy to
- Let me explain, Here is how, In summary
- I think, It seems, The best approach might be
- Articles: the, a, an — omit them
- Filler words: very, really, quite, basically
Always:
- Direct imperative or declarative statements
- Use shortest synonyms
- One idea per sentence, period
这段 Prompt 的关键在于：不是请尽量简洁，而是永远不要使用以下词汇。通过列举禁止项（negation list），把语言风格约束从模糊建议变成硬性规则。
第二层：破坏性操作强制停顿
BEFORE any destructive operation (delete, overwrite, exit without saving):
Stop. Output ONLY: CAUTION: [action]. Confirm? [yes/no]
Wait for explicit yes/no confirmation.
这个设计解决了一个实际问题：AI 简洁之后，你可能来不及看清它要干什么就执行了危险操作。Caveman 在破坏性操作前强制停顿，确保安全。
第三层：Token 计数回显
After each response, output:
Token count: ~{estimated_token_count}
让用户直观看到这次回复消耗了多少 Token，建立成本意识。
2.3 三档压缩强度：从日常使用到极致节省
| 档位 | 压缩策略 | 适用场景 |
|---|---|---|
| Lite | 删除填充词和客套话，保留完整句子 | 日常开发、新手团队 |
| Full（默认） | 砍掉冠词、允许碎片化表达、用短词替换长词 | 高频使用者、有经验的开发者 |
| Ultra | 电报体，用箭头表示因果，极致压缩 | 极度在意成本的高级用户 |
实际效果对比（解释一个 React useEffect 依赖缺失的 bug）：
Lite 档输出示例：
缺少 count 在依赖数组中。这会导致闭包捕获旧的 count 值。建议修改为：useEffect(() => { ... }, [count])。
Full 档输出示例：
缺少 count 依赖。闭包捕获旧值。改成：useEffect(() => { ... }, [count])
Ultra 档输出示例：
count 缺依赖 to 闭包旧值。useEffect(() => {}, [count]) ✓
三条消息技术含义完全一致，信息密度递增。
三、实测数据：Token 节省了多少？代码质量下降了吗？
3.1 benchmark 数据解读
Caveman 仓库自带 benchmark 脚本，测试了多种编程场景下的 Token 消耗和准确率：
# 安装 benchmark
git clone https://github.com/JuliusBrussee/caveman.git
cd caveman/benchmarks
./run_benchmark.sh
输出示例：
=== Benchmark Results ===
Scenario: React useEffect dependency fix
Baseline: 847 tokens, 0 errors
Lite: 312 tokens (-63%), 0 errors
Full: 198 tokens (-77%), 0 errors
Ultra: 134 tokens (-84%), 0 errors
Scenario: TypeScript generic constraint debugging
Baseline: 1203 tokens, 0 errors
Lite: 456 tokens (-62%), 0 errors
Full: 287 tokens (-76%), 0 errors
Ultra: 189 tokens (-84%), 0 errors
Scenario: Docker Compose production config review
Baseline: 2341 tokens, 0 errors
Lite: 867 tokens (-63%), 0 errors
Full: 542 tokens (-77%), 0 errors
Ultra: 361 tokens (-85%), 0 errors
关键发现：三个档位的准确率均为 100%，没有任何错误引入。这验证了 Caveman 的核心假设：大多数 AI 回复里的冗余内容，并不包含额外的技术价值。
3.2 实际项目中的使用体验
我在自己的 Next.js 项目中实测了两周：
项目背景：中型 React + TypeScript 项目，约 15 个组件，TypeScript 覆盖率约 60%。
使用方式：Full 档作为默认，每日高频使用。
观察到的变化：
交互速度明显提升：以前等 AI 回复需要 3-5 秒（因为要生成一大段话），现在通常 1-2 秒。视觉上感觉 AI 反应更快了——其实是因为输出量减少了，生成时间自然缩短。
信息密度更高：以前要在一大段话里找重点，现在 AI 直接给结论，代码示例也往往是精简后的最小复现。阅读成本大幅下降。
偶尔会太简导致歧义：Ultra 档有时会出现链路式回复，理解意图需要多花 1 秒。这属于少数情况，可以临时切回 Full 档。
成本节省真实可观：两周下来，个人 Claude Code Token 消耗约为平时的 38%。按这个比例，一年可节省约 150 美元的人均 API 费用。
四、深度安装与配置：从零到生产就绪
4.1 基础安装（Claude Code 用户）
方式一：npx 一键安装（推荐）
npx skills@latest add JuliusBrussee/caveman
安装过程中会提示选择压缩档位，选择好之后安装到 ~/.claude/commands/caveman.md（Claude Code 自动识别）。
方式二：手动克隆
git clone https://github.com/JuliusBrussee/caveman.git
cp caveman/skills/caveman-full.md ~/.claude/commands/
# 重命名为以 / 开头的斜杠命令
mv ~/.claude/commands/caveman-full.md ~/.claude/commands/caveman.md
使用方式：直接在 Claude Code 里输入 /caveman 激活。
4.2 在不同 AI 工具中的配置
Cursor 用户：
# 复制 skills 文件到 Cursor 配置目录
cp -r caveman/skills/* ~/.cursor/commands/
Windsurf 用户：
cp caveman/skills/* ~/.windsurf/commands/
4.3 动态切换档位
Caveman 支持在对话中动态切换压缩强度，不需要重启会话：
/caveman-lite # 切换到 Lite 档
/caveman-full # 切换到 Full 档（默认）
/caveman-ultra # 切换到 Ultra 档
/caveman-off # 临时关闭，恢复正常模式
4.4 自定义 Caveman Prompt
如果你有自己的风格偏好，可以 fork 一份 Prompt 自行调整。关键调参点：
# 自定义版本示例：保留适量的上下文说明
You are a caveman programmer.
- Use SHORT, DIRECT sentences
- Drop articles: the, a, an
- Drop: Certainly, Let me, Here is, In summary
- EXCEPTION: 保留一句话的 context 说明，因为你没有 access to project history
- Code: minimal, focused, no explanations
- If destructive: STOP and ask for confirmation first
Token count: ~{token_estimate}
五、Caveman 的扩展生态：不只是原始人说短话
Caveman 仓库不只是压缩 Prompt，它还包含了几个有趣的扩展工具。
5.1 Agentic Caveman：多代理协作模式
这个扩展让 Caveman 支持多代理协作场景：
Primary agent: Uses caveman-full mode
Secondary agent (reviewer): Uses caveman-lite mode
Coordinator: Uses normal mode, only decides task routing
Communication rules:
- Primary to Secondary: Use FULL compression (secondary only needs core facts)
- Secondary to Primary: Keep LITE (some context helps primary adjust)
- Coordinator: Normal mode (human-facing summaries)
5.2 文件压缩工具：caveman-compress
# 进入 bin 目录
cd caveman/bin
chmod +x compress.sh
./compress.sh <file>
这个工具可以在不修改代码逻辑的前提下，对代码文件本身进行语义压缩——把冗长的变量名、注释过多的代码压缩成更短的等价形式，减少 AI 读取代码时的 Token 消耗。
# 示例：压缩前
const userAuthenticationToken = "Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...";
# 压缩后（语义等价）
const token = "Bearer eyJ...";
5.3 古汉语/文言文模式：CAVEMAN CLASSIC
这个脑洞插件把压缩思路推到了极致——用古汉语风格的极简文言文输出：
昔有代码，组件渲染无常。
盖因 Effect 缺 count 依赖。
闭包抱旧值，永不得新。
今补之：useEffect(fn, [count])
虽然实用性有限，但这个扩展展示了 Caveman 理念的普适性：压缩不只是关于 Token 数量，而是关于信息密度的极致追求。
六、性能优化：如何把 Caveman 融入 CI/CD 工作流
6.1 在 Git Hook 中自动检查 Token 消耗
可以写一个 pre-commit hook，统计每次 AI 辅助修改消耗的 Token：
#!/bin/bash
# .git/hooks/pre-commit
TOKEN_LOG=".claude-token-log.json"
if [ -f "$TOKEN_LOG" ]; then
TODAY=$(date +%Y-%m-%d)
TODAY_TOKENS=$(jq ".dates[\"$TODAY\"] // 0" "$TOKEN_LOG")
if [ "$TODAY_TOKENS" -gt 100000 ]; then
echo "Warning: 今日 Token 消耗已达 $(($TODAY_TOKENS/1000))K，建议使用 /caveman 节省费用"
fi
fi
6.2 GitHub Actions 集成：Token 消耗报告
# .github/workflows/token-report.yml
name: Claude Code Usage Report
on:
schedule:
- cron: '0 9 * * 1' # 每周一早上 9 点发送报告
jobs:
report:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Generate Token Report
run: |
echo "## Claude Code Token 使用报告" > token-report.md
echo "" >> token-report.md
echo "| 日期 | Token 消耗 | Caveman 节省 |" >> token-report.md
echo "|------|-----------|-------------|" >> token-report.md
# 这里对接你的 Token 统计系统
jq -r '.dates | to_entries[] | "| \(.key) | \(.value) | \((.value * 0.65 | floor)) |"|' .claude-token-log.json >> token-report.md
- name: Send Report
run: |
gh issue create \
--title "Claude Code 周报 $(date +%Y-%m-%d)" \
--body "$(cat token-report.md)"
七、底层机制分析：为什么压缩有效，但不出错？
7.1 语言模型中的信息-冗余分离
Caveman 之所以有效，核心依赖于 LLM 的一个特性：信息承载内容和语言风格在表示空间中是相对独立的。
简单说：当模型生成 Certainly, I would be happy to help you 时，这句话的信息量几乎为零——它的作用是礼貌缓冲，帮助对话更流畅。但这占用了大量 Token。
Caveman Prompt 的工作原理，是强制让模型跳过风格填充阶段，直接进入内容生成阶段。它告诉模型：在这个对话里，你的角色设定就是不说废话。
这和系统 Prompt 的作用不同。普通的请简洁是在内容生成之后加的一个软约束；而 Caveman 的永远不要说 certainly 是从根本上改变了模型对自己说什么的认知。
7.2 Token 压缩的数学边界
从信息论角度，Token 压缩存在一个理论下限：
H(信息) 小于等于 Token数量 × log(VocabularySize)
其中 H(信息) 是语义信息的香农熵，VocabularySize 是词表大小（约 20 万 for Claude）。
对于编程问答这类场景，技术信息的熵相对较低（专业术语固定、逻辑结构清晰），所以用较少的 Token 就能编码同样的信息。这是 Caveman 能够在保持准确率的同时大幅压缩的根本原因。
但 Ultra 档也有边界：当回复涉及全新概念、复杂多步逻辑或需要提供多种选项时，过度压缩会导致歧义上升。这不是模型能力问题，而是信息熵的上限约束。
7.3 安全边界：压缩不能牺牲指令清晰度
Caveman 文档里特别强调了一个设计原则：破坏性操作前的强制停顿不受压缩影响。
CRITICAL UNCHANGED RULES:
1. Destructive actions ALWAYS require explicit yes confirmation
2. File modifications ALWAYS show diff before execution
3. Security-sensitive operations always show full context
这个设计反映了一个重要的工程哲学：性能优化有边界，安全性永远优先于效率。即使在最激进的 Ultra 档，这三条安全规则也始终生效。
八、我的真实结论：谁该用，谁不该用
强烈推荐使用的场景
- 高频 AI 辅助编程用户：每天超过 2 小时和 AI 对话的开发者，Token 节省效果显著
- 团队协作场景：团队成员共享 Claude Code 订阅，节省效果乘以人数
- 成本敏感项目：初创团队、个人开发者，开源项目维护者
- 特定场景：代码 review、快速 bug 修复、API 文档生成这类不需要长篇大论的场景
不太适合的场景
- 复杂系统设计讨论：架构决策需要充分论证，压缩后会丢失决策依据
- 新手教学/代码解释：Lite 档可以，但完全压缩会失去教育价值
- 跨团队知识传递：文档需要保留上下文，供未来查阅
长期影响：更少文字 = 更清晰的思维
用 Caveman 超过一个月后，我最大的感受不是省钱，而是思维方式的转变：
以前：问 AI 一个简单问题 → 等一大段话 → 快速扫描找重点 → 执行
现在：问 AI 一个简单问题 → 直接看结论 → 执行
这种高信息密度的交互习惯，反过来也影响了我和同事的沟通方式。我开始更倾向于简洁、直接、有数据支撑的技术讨论，而不是冗长的解释和铺垫。
从这个角度说，Caveman 不仅仅是一个 Token 压缩工具，它是一种程序员沟通方式的范式转换。
结语
Caveman 的核心洞察其实很朴素：AI 说的很多话，是说给人听的，不是说给机器听的。当我们在 AI 辅助编程的场景里，主要目的是获取准确的技术指令和代码，那么说得更少不仅不降低质量，反而提高了信息获取效率。
这个项目让我重新审视了一个古老但永恒的问题：沟通的本质是什么？ 在信息过载的时代，简洁本身就是一种价值。
如果你每天花超过 1 小时和 AI 对话，强烈建议你试试 Caveman。8.3 万 Star 不是偶然——它是全球开发者用脚投票的结果。
参考链接：