Claude Code 压缩插件 Caveman 与 “be brief” 对比：令牌数和质量谁更优？

Claude Code 压缩插件 Caveman 与 “be brief” 基准测试：谁在令牌数和质量上更胜一筹？

2026 年 4 月 29 日，有人对热门的 Claude Code 压缩插件 Caveman 与 “be brief” 进行了对比。此次对比涵盖 24 个提示、六个类别和五种测试方式。结果显示，“be brief” 这两个词在令牌数和回答质量上都不逊色于 Caveman。

测试内容

本次测试涵盖六个类别，共 24 个提示，包括错误诊断、概念解释、架构权衡、多步骤设置、安全和破坏性操作以及错误解释。每个提示都有相应的评分标准，包括答案必须涵盖的事实（`key_points`）、必须使用的术语（`must_use_terms`）以及必须避免的错误声明（`must_avoid`）。

数据集结构如下：
interface PromptCase {
id: string;
category: string;
prompt: string;
key_points: string[];
must_use_terms?: string[];
must_avoid?: string[];
}

以下是一个实际的示例：
{
"id": "bug_01",
"category": "bug_diagnosis",
"prompt": "我有 `const [count, setCount] = useState(0); function handleClick() { setCount(count + 1); setCount(count + 1); }`。我期望每次点击 `count` 增加 2，但实际上只增加 1。为什么？",
"key_points": [
"`count` 存在过时闭包",
"两次调用都将 `count` 设置为相同的值",
"使用函数式更新器 `setCount(c => c + 1)`"
]
}

测试采用五种方式：
- **基线**：Claude 的默认设置，无额外指令。
- **简洁**：在每个提示前添加 “Be brief.”。
- **精简、标准、极致**：Caveman 插件的三个不同强度级别。

每种方式都在 `claude - opus - 4 - 7` 上通过 `claude - p` 运行完整的 24 个提示数据集。另外使用一个单独的 Claude 实例（`claude - sonnet - 4 - 6`）根据每个提示的评分标准对回复进行评分，包括关键点的语义匹配、必需术语的字面匹配以及对需避免声明的陷阱检测。测试框架是开源的，可查看 [此处](https://github.com/max - taylor/cc - compression - bench)。

质量未受影响

各种方式的得分相差不超过 1.5%。基线方式得分为 0.985，简洁方式为 0.985，精简方式为 0.976，标准方式为 0.975，极致方式为 0.970。每种方式都能 100% 覆盖 `key_points`，在 120 个回复中没有触发任何 `must_avoid` 声明。这表明压缩并没有导致实质性内容的缺失，抛开质量因素，唯一值得比较的指标就是令牌数。

主要测试结果

| 方式 | 平均令牌数 |
| --- | --- |
| 基线 | 636 |
| **简洁** | **419** |
| 精简 | 401 |
| 标准 | 404 |
| 极致 | 449 |

“Be brief.” 相比基线方式减少了 34% 的令牌数。Caveman 的精简和标准模式与 “Be brief.” 的表现相近。而极致模式作为最严格的模式，在三种 Caveman 模式中生成的答案最长。

按类别拆分分析

按类别拆分令牌数能让结果更加清晰。在错误诊断、概念解释、架构权衡和错误解释类别中，极致模式的令牌数最短，或者与其他 Caveman 模式持平，说明压缩效果符合预期。

在多步骤设置和安全警告类别中，所有 Caveman 模式的表现波动较大。从整体来看，极致模式较为突出，但并非表现更差。三种 Caveman 模式在这两个类别中的表现都不太稳定。

原因在于 Caveman 的 “自动清晰化” 规则，该规则会在涉及安全警告、不可逆操作和多步骤序列时，明确放弃压缩。而这正是上述两个类别所涉及的情况。当触发安全保护机制时，三种模式都会采用更自然的表述方式，压缩功能不再起作用。这并非缺陷，而是一种设计特性，体现了 Caveman 知道何时停止压缩。

那么 Caveman 到底有什么用？

如果 “be brief” 在令牌数和质量上与 Caveman 相当，那么 Caveman 的价值就不在于压缩，而在于结构。

- **输出结构一致**：每个 Caveman 回复都遵循相同的模式，这种可预测性是 “be brief.” 所不具备的。如果你希望在不同会话中保持统一的风格，或者有下游工具需要处理 Claude 的输出，这种一致性就显得尤为重要。

- **强度调节功能**：可以在会话中通过斜杠命令切换精简、标准和极致模式，这是 “be brief.” 无法做到的。

- **长会话中的持续性**：Caveman 通过 `SessionStart` 和 `UserPromptSubmit` 钩子在每个提示中重新注入规则集，目的是在长会话中保持回复模式的稳定性。基准测试并未对这一点进行测试，因为每次运行都是通过 `claude - p` 进行的单次测试。但这种机制是真实存在的，而在 `CLAUDE.md` 中使用 “be brief.” 则没有类似的功能。

- **安全保护机制**：自动清晰化规则在处理破坏性操作时放弃压缩，这就是上述图表中表现出的差异。Caveman 能够明确区分何时停止压缩，而 “be brief.” 则无法做到这一点。在测试数据中，这并没有影响最终结果，“be brief.” 也从未触发过 `must_avoid` 声明，但这种设计是存在的。

视频中未提及的内容

- **精简模式漏用了一个必需术语**：在一个关于队列权衡的问题（SQS 与 BullMQ 与 Kafka 的比较）中，精简模式的 Markdown 表格格式将比较内容压缩得过于紧凑，导致遗漏了 “at - least - once” 这个术语，得分 0.70。这是 120 个回复中唯一得分低于 0.90 的情况。虽然只有一个案例，但对于强制使用特定术语的基准测试来说，这是一个真实存在的失败模式。

- **极致模式触发了其他模式未出现的工具使用行为**：在一个 Dockerfile 设置问题中，极致模式回复开头为 “Need write perms. Retry after approve, or paste inline:”。它试图调用写入工具，但被阻止，最后还是将文件内容直接输出。这单个回复使极致模式在设置类别中的平均令牌数增加了约 1300。Caveman 简洁的示例似乎会促使模型优先使用工具，这是压缩风格带来的一个意外副作用。

- **架构权衡类别中的令牌数膨胀并非预期**：最初的研究文档认为，Caveman 的 `[事物] [动作] [原因]` 模式会使模型在多选项比较问题上倾向于使用项目列表。但进一步观察发现，精简和标准模式虽然有相同的模式，但输出更加清晰（精简模式常使用表格，标准模式使用散文形式）。因此，这种模式并非令牌数膨胀的原因，目前还无法明确其具体原因。

实际建议

如果你只想要更简短的输出，可在提示或 `CLAUDE.md` 中使用 “be brief.”。这两个简单的词在令牌数和质量上与 Caveman 相当。

当你需要在不同会话中保持一致的输出结构时，可以选择 Caveman。这是基准测试后凸显出的 Caveman 的优势。

更重要的启示是：大多数提示工程建议都没有与普通的默认设置进行对比测试。建议大家进行测试验证。

**代码仓库**：[cc - compression - bench](https://github.com/max - taylor/cc - compression - bench) · **视频**：[youtu.be/wijoYNiZq3M](https://youtu.be/wijoYNiZq3M) · **Caveman 插件**：[juliusbrussee/caveman](https://github.com/juliusbrussee/caveman)

如果你有想要在相同数据集上进行基准测试的压缩策略，测试框架对策略没有限制。添加一种测试方式只需一个 shell 脚本。欢迎提交 Pull Request。