Caveman 阅读分析与使用笔记

这篇文章解决什么问题

caveman 是 Julius Brussee 维护的一个 AI agent 沟通压缩工具，仓库地址：

• JuliusBrussee/caveman

它的口号很直白：

why use many token when few do trick

表面看，它像一个搞笑风格 prompt：让 agent 像“穴居人”一样说话。

但真正值得分析的地方不在梗，而在它抓住了 AI 工具使用里的一个高频浪费：

• agent 回复太长
• 礼貌话太多
• 解释铺垫太多
• 同一个技术结论绕好几遍
• 每轮对话都在消耗输出 token
• 长期会话里，用户读信息的成本也变高

caveman 的目标不是让模型变笨，而是让模型少说废话。

一句话：

caveman 是一种输出压缩层，压的是表达，不是判断。

先说结论

• caveman 不适合所有场景，但很适合 coding agent 的日常协作。
• 它的核心价值是把“简洁回复”写成可复用 skill，而不是每次都提醒 agent “少废话”。
• 它不是单纯要求短，而是要求保留技术信息、删除客套、删掉套话、减少解释性填充。
• 它支持 lite、full、ultra、文言文等不同压缩强度。
• 它还扩展出 caveman-commit、caveman-review、caveman-compress 等工具化能力。
• 最大收益不是省钱本身，而是降低阅读噪音，让人更快看到结论。

我的判断：

caveman 是一个“沟通协议”项目，不是一个“模型能力增强”项目。

它为什么有价值

AI agent 最常见的坏习惯之一，是输出过度包装。

比如你问：

这个 React 组件为什么一直重新渲染？

普通回复可能是：

这个问题通常是因为你在每次 render 时创建了新的对象引用。
当你把 inline object 作为 props 传给子组件时，React 的浅比较会认为它每次都是不同对象。
建议使用 useMemo 记住这个对象。

这段没错，但如果你每天和 agent 交互几十轮，类似铺垫会变成噪音。

caveman 风格会变成：

Inline object prop = new ref each render。React shallow compare 失败。用 useMemo。

信息没有少：

• 原因还在
• 机制还在
• 解决方法还在

少掉的是：

• “通常”
• “建议”
• “让我解释一下”
• “这个问题可能是”
• 多余语法包装

这就是它的核心价值。

它压缩的是什么

caveman 压缩的是自然语言外壳。

它主要删这些东西：

类型	示例	为什么删
客套话	“当然可以”“很高兴帮你”	不提供技术信息
弱语气	“可能”“通常来说”“我建议”	很多场景只是习惯性缓冲
冗余连接	“首先我们需要注意的是”	拖慢阅读
解释铺垫	“这个问题的根本原因在于”	结论可以直接说
重复强调	“简单来说，也就是说”	信息重复
过度完整句	为了语法完整多写一倍词	读者不需要

但它不能删这些东西：

• 文件路径
• 命令
• 代码
• 错误信息
• 参数名
• 版本号
• 关键限制
• 安全警告
• 不确定性来源

所以好用的 caveman 不是“乱缩写”，而是“只删非技术信息”。

它不是普通的“简短回答”

很多人会把它理解成：

请你回答短一点。

这不够。

“短一点”容易出问题：

• 只给结论，不给原因
• 删掉边界条件
• 删掉验证方式
• 删掉风险提醒
• 变成谜语

caveman 更像一套明确规则：

• 技术信息保留
• 代码不改
• 命令不改
• 错误原文保留
• 客套删掉
• 套话删掉
• 句子可碎片化
• 用短词替长词
• 必要时恢复正常表达

这比“短一点”稳定。

强度分层

项目里把压缩分成多种模式。

lite

lite 是最适合普通团队的模式。

特点：

• 删除废话
• 保留正常语法
• 仍然像职业工程师
• 不刻意搞笑

适合：

• 工作沟通
• 技术文档审阅
• 普通项目协作
• 不想让风格太强的团队

例子：

组件重复渲染，因为每次 render 都创建新对象引用。用 useMemo 固定引用。

full

full 是项目默认风格。

特点：

• 句子碎片化
• 省掉冠词和部分连接词
• 更像压缩笔记
• 读起来更快

适合：

• coding agent 日常协作
• 熟悉上下文的用户
• 高频多轮任务
• 不介意强风格的人

例子：

New object ref each render。Inline prop = re-render。useMemo。

ultra

ultra 是最大压缩。

特点：

• 大量缩写
• 用箭头表达因果
• 只保留骨架
• 对新手不友好

适合：

• 高度熟悉上下文
• 临时状态汇报
• 已知问题定位
• token 极度紧张

例子：

Inline obj → new ref → rerender。useMemo。

文言文模式

项目还提供 Wenyan 模式，也就是文言文压缩。

这个点很有意思。

中文本来就比英文更紧凑，而文言文进一步减少虚词和结构词。对懂中文的人来说，它能把技术判断压得更短。

但我不建议在工程团队里默认开文言文。

原因：

• 可读性门槛高
• 容易变成风格展示
• 团队成员未必都能快速理解
• 技术术语和文言文混写有时别扭

文言文模式适合玩，或者极端压缩场景。日常工程还是 lite/full 更稳。

它支持哪些工具

从 README 看，caveman 已经不是只给一个 agent 用。

它覆盖：

工具	支持方式
Claude Code	plugin / hooks / statusline
Codex	Codex plugin / $caveman
Gemini CLI	extension / 命令
Cursor	npx skills add
Windsurf	npx skills add
Cline	skill / rules
GitHub Copilot	custom instructions
其他 agent	通过 npx skills 或手工规则接入

这说明它不是只写了一个 prompt，而是在做跨 agent 的行为层。

真正可迁移的不是安装脚本，而是规则本身：

Terse like caveman. Technical substance exact. Only fluff die.

这句话可以放进很多 agent 的规则文件里。

它的 skill 写法

核心 skill 很短，但边界很清楚。

它主要定义了几类规则：

1. 激活方式

用户说这些话时启用：

• caveman mode
• talk like caveman
• less tokens
• be brief
• /caveman

这类触发词设计很实用。

因为用户通常不会每次都说“请启用某某 skill”，而是自然地说“少废话”“简洁点”。skill 能识别这些语义，就更容易进入正确模式。

2. 持久性

它强调：

ACTIVE EVERY RESPONSE

意思是启用后持续生效，直到用户说：

• stop caveman
• normal mode

这点很重要。

如果每轮都要重新提醒“少废话”，这个 skill 本身就失去价值。

3. 删除规则

它明确要求删：

• 冠词
• filler
• pleasantries
• hedging

也就是把英语里大量“听起来礼貌但技术无效”的部分干掉。

中文里对应的是：

• “好的”
• “当然”
• “一般来说”
• “其实”
• “简单来说”
• “我可以帮你”
• “这个问题可能是因为”

中文用 caveman 时，不一定要变成奇怪语法。关键是删掉这些铺垫。

4. 保真规则

它也明确说：

• 技术术语准确
• 代码块不改
• 错误信息原样保留
• commit / PR 场景正常写
• 高风险场景恢复清晰表达

这让它避免变成“为了短而短”。

caveman-compress：压缩输入，不只压缩输出

caveman 主体解决输出 token。

但项目里还有 caveman-compress，目标是压缩输入 token。

典型场景是：

CLAUDE.md 每次 session start 都会被读入。

如果这个文件很长，每次启动 agent 都在重复消耗上下文。

caveman-compress 的思路是：

• 保留人类可读原文备份
• 生成压缩版给 agent 读取
• 技术信息不动
• 只压缩 prose
• 代码、URL、路径、命令、版本号保留

这和普通摘要不一样。

普通摘要会丢信息。caveman-compress 更像“语法压缩”：

原文：当你修改 Vue 文件时，请先参考同目录组件风格，避免引入新的抽象。
压缩：改 Vue 前看同目录风格。勿新抽象。

含义基本保留，但 token 少很多。

这对长期 agent 项目很有价值。因为真正贵的不是一次回复，而是每次会话都加载的规则、记忆、约束。

caveman-commit 和 caveman-review

项目还提供两个很实用的小 skill。

caveman-commit

目标是生成更短 commit message。

它强调：

• Conventional Commits
• subject 不超过 50 字符
• 更关注 why than what
• 不写长篇解释

这适合 agent 生成 commit 时避免：

feat: implement comprehensive functionality for handling user authentication improvements and token validation

更好的写法：

fix: reject expired auth token

caveman-review

目标是一行 code review。

格式类似：

L42: bug: user null. Add guard.

这很适合 PR 评论。

很多 AI code review 的问题是“像老师写作文评语”，太长，问题点反而埋在后面。

一行评论更接近真实 review：

• 行号
• 类型
• 问题
• 修法

少即是多。

Benchmark 怎么看

README 里给出了一组 benchmark，平均输出 token 从 1214 降到 294，节省约 65%。

但这里要冷静看。

这个数据说明：

• 输出长度确实能大幅下降
• 对解释类和排障类任务收益很大
• 不同任务收益差异明显

它不直接证明：

• 所有任务质量都不变
• 所有人都喜欢这种风格
• 所有团队都适合默认启用
• 复杂设计文档也能无损压缩

项目自己也强调一点：

caveman 影响的是 output tokens，不影响 thinking/reasoning tokens。

也就是说，它不是让模型少思考，而是让模型少说话。

这是好事。因为我们要的是：

脑子正常，嘴短一点。

Evals 的意义

项目里提到 evals/，并且强调不是只拿 verbose 和 caveman 比，而是做三臂评估：

• verbose
• terse
• skill

这个设计值得肯定。

因为如果只比较“啰嗦回复”和“caveman 回复”，那很容易得出虚假的胜利。

真正要证明的是：

caveman 不只是短，而是比普通 terse prompt 更稳定。

这类评估思路比具体数字更有价值。

AI 工具项目如果只说“节省 75% token”，还不够。要说明：

• 和谁比
• 样本是什么
• 任务类型是什么
• 是否保留正确性
• 是否只是风格变化

caveman 至少意识到了这个问题。

它适合什么场景

适合 coding agent 日常协作

比如：

• 定位 bug
• 解释报错
• 总结修改
• 汇报进度
• 给下一步建议
• 说明验证结果

这些场景里，用户通常想要结论，不想要长篇铺垫。

适合高频多轮会话

多轮任务里，每轮少 100-300 token，累积收益很明显。

尤其是 agent 一边读文件、一边汇报状态、一边修问题时，短回复更舒服。

适合 code review

PR review 本来就应该短、准、可执行。

caveman-review 风格适合指出明确问题：

L88: auth bypass。缺 role check。

适合命令行 agent

CLI 场景里屏幕空间有限，长回复会打断节奏。

caveman 的信息密度适合终端。

它不适合什么场景

不适合教学型文章

如果读者是新手，过度压缩会让理解变难。

比如讲 Transformer、微调、上下文窗口时，需要类比、铺垫、例子。此时 caveman ultra 会损害效果。

不适合需求澄清初期

复杂需求一开始需要问清背景。

如果 agent 过度压缩，可能把关键问题问得太硬，用户体验变差。

不适合安全、法律、医疗等高风险场景

这类场景需要完整上下文和明确免责声明。

caveman skill 自己也说了：安全警告、不可逆操作、多步骤容易误解时，要恢复清晰表达。

不适合正式对外文档

产品文案、用户手册、商务邮件不应该默认 caveman。

它是内部协作压缩协议，不是所有输出的写作风格。

中文环境怎么用

中文里直接照搬英文 caveman 会很怪。

英文 caveman 常见做法是删冠词、碎片化句子。但中文没有冠词，本来就更短。

中文更适合删这些：

• “好的”
• “可以的”
• “下面是”
• “我们可以看到”
• “简单来说”
• “一般情况下”
• “需要注意的是”
• “我建议你”
• “如果你愿意的话”

例如普通回复：

好的，这个问题一般是因为你在每次渲染时创建了新的对象引用，所以 React 会认为 props 发生了变化。我建议你用 useMemo 固定这个对象。

中文 caveman：

每次渲染新对象引用。React 认为 props 变。用 useMemo 固定。

技术信息没丢，字数少一半以上。

在 AGENTS.md 里怎么写

如果要在项目里长期启用，可以写成：

## 交流方式

- 使用简体中文。
- 先给结论，再给原因。
- 使用 caveman 风格：删客套、删铺垫、保留技术细节。
- 代码、命令、错误信息、路径不要压缩。
- 高风险操作、复杂步骤、用户要求解释时恢复完整表达。

不要写成：

- 回复越短越好。

因为“越短越好”会鼓励模型丢信息。

正确目标是：

- 信息密度高，废话少，关键约束不丢。

和 prompt-optimizer 的关系

本站已有：

• prompt-optimizer 阅读分析与使用笔记

两者解决的问题不同。

项目	解决什么
prompt-optimizer	怎么把任务 prompt 写清楚
caveman	怎么让 agent 输出更短、更密

一个是输入设计，一个是输出压缩。

二者可以配合：

1. 用 prompt-optimizer 写清楚任务规则。
2. 用 caveman 控制 agent 回复风格。

例如：

任务 prompt 很完整，但回复要求 caveman full。

这样 agent 仍然知道完整任务约束，但对用户输出更短。

和 Superpowers 的关系

本站已有：

• Superpowers 阅读分析与使用笔记

Superpowers 管流程，caveman 管表达。

项目	更像什么
Superpowers	agent 工程流程
caveman	agent 沟通压缩协议

可以这样组合：

• Superpowers 要求先写完成标准、TDD、review、verification。
• caveman 要求汇报时别废话。

这不是冲突。

流程可以严谨，表达可以简短。

和 andrej-karpathy-skills 的关系

本站已有：

• andrej-karpathy-skills：把 AI 编程的坏习惯写成约束

andrej-karpathy-skills 关注 AI coding 的行为边界：

• 不脑补
• 不过度设计
• 不乱改
• 有完成标准

caveman 关注沟通成本：

• 少客套
• 少套话
• 少重复
• 保信息密度

如果说前者解决“做事别乱”，后者解决“说话别长”。

一个实际例子：修改完成汇报

普通 agent 汇报：

我已经完成了这个修改。本次主要新增了一个组件，并且在主题入口里进行了注册。同时我也检查了相关文件，确认标签能够正常从 frontmatter 中读取。由于你之前要求不主动运行项目命令，所以我没有执行构建或启动命令。你可以手动启动项目进行验证。

caveman 风格：

完成。改 2 文件：新增 ArticleTags，挂 doc-before。tags 读 frontmatter。
未跑构建：按你规则不主动运行。你手动看文章标题上方。

这就是它适合 coding agent 的原因。

一个实际例子：错误分析

普通回复：

这个错误的原因是你正在从 tags.data.js 中使用默认导入，但是 VitePress 的 data loader 会生成命名导出 data，因此当前模块并没有 default export。你需要把 import tags from "./tags.data.js" 改成 import { data as tags } from "./tags.data.js"。

caveman 风格：

原因：`.data.js` 导出 `data`，无 default。改：

import { data as tags } from "./tags.data.js";

更短，但更直接。

一个实际例子：code review

普通 AI review：

这里可能存在一个潜在的问题。如果 user 为空，那么访问 user.name 会导致运行时错误。建议在这里添加一个空值判断，或者在上游保证 user 一定存在。

caveman review：

L42: bug: user 可能为空。访问 name 前加 guard。

PR 评论就该这样。

使用建议

默认用 lite 或 full

中文项目里，我建议：

• 日常解释：lite
• coding agent 协作：full
• 状态汇报：full
• 已知上下文下的短任务：ultra
• 正式文档：不用

不要压缩代码和错误

错误信息必须原样保留。

比如：

SyntaxError: The requested module '/notes/tags.data.js' does not provide an export named 'default'

不要压成：

default export error

后者会丢排查信息。

不要把“不确定”删掉

如果 agent 不确定，必须说不确定。

caveman 不能把：

我没有运行项目，只能确认静态文件修改。

压成：

完成。

正确压缩：

静态改完。未跑项目，运行效果未验证。

不要影响用户要求的文章风格

如果用户要写长文、教程、案例分析，就不应该用 ultra。

可以做到：

• 对话汇报 caveman
• 文档正文正常详写

这也是最实用的组合。

它的局限

局限一：风格有门槛

不是所有人都喜欢这种说话方式。

有些团队会觉得它太硬，甚至不礼貌。

解决办法：用 lite。

局限二：新手可能读不懂

压缩表达依赖读者已有背景。

例如：

Inline obj → new ref → rerender

懂 React 的人秒懂，新手可能不懂。

局限三：复杂方案需要展开

架构设计、迁移计划、安全说明不能一味压缩。

这类内容要先完整表达，再在结论层保持简洁。

局限四：token 节省不是唯一目标

省 token 有价值，但不能压过准确性。

如果为了短导致：

• 风险没说
• 步骤不清
• 假设没交代
• 验证没说明

那就是坏压缩。

最小实践清单

如果不安装，只借鉴它的思想，可以这样用：

1. 回复先给结论。
2. 删除客套和铺垫。
3. 保留技术原因。
4. 保留命令、路径、错误原文。
5. 风险和未验证状态不能删。
6. 复杂步骤用清晰表达，不硬压。
7. code review 用一行指出问题。
8. commit message 短，讲关键意图。
9. 项目规则和记忆文件可考虑压缩版本。
10. 用户要求详细解释时，停止压缩。

我对这个项目的评价

caveman 最有价值的地方，是把一个很小的经验做成了跨工具、可复用的协作层。

它不是在发明新能力，而是在修一个每天都会遇到的问题：

AI 太会说话，反而让人读得累。

这个问题在 coding agent 里尤其明显。

写代码时，用户通常不想看漂亮话，只想知道：

• 问题在哪
• 怎么改
• 改了什么
• 怎么验证
• 还有什么风险

caveman 的价值就是把这些信息前置，把废话拿掉。

最后总结

caveman 是一个输出压缩 skill。

它的关键词不是“搞笑”，而是：

• brevity
• token saving
• technical accuracy
• persistent style
• multi-agent support
• input compression
• evals

它适合 AI 编程协作，尤其适合命令行 agent、高频多轮任务、code review、状态汇报。

它不适合教学长文、正式对外文案、高风险复杂说明。

最好的用法不是“永远短”，而是：

简单事短说，复杂事先说清，再短总结。