GitHub Trending 上有个项目最近同时挂上了 Hacker News 第一和 GitHub 第一，名字起得相当放飞：caveman（穴居人）。它的全部主张用一句话就能说完——”why use many token when few token do trick”，让 AI 编码助手把废话咽回去，回答短一点、上下文读少一点，代码一个字符都不许动。
我第一反应是：这不就是每个月看着 API 账单的我们想要的吗。但”让模型装穴居人”这件事听着就不太靠谱，于是我把它拉到自己的 M4 Mac 上实测了一遍。这篇记录真实跑出来的数字、撞上的坑，以及哪些场景我不会用它。
caveman 是什么：六块石头
项目本体在 GitHub 上以 Apache-2.0 开源，118,000+ star，一条 npx @caveman-ai/cli@latest 就能装进 Claude Code、Codex、OpenCode 等 30 多个编码 Agent。4.0 版本把它拆成了六个独立开关的模块，官方管它们叫”六块石头”：
| 石头 | 干什么 | 官方给出的数字 |
|---|---|---|
| Say less | 让 Agent 用”短句语音”回答，代码保持逐字精确 | 63 → 20 token，修复方案不变 |
| Read less | 日志、JSON、CSV 在模型读之前先压缩 | 全会话输入 token 少 33.2% |
| Auto | 按问题难度挑模型和努力档位 | 比 Opus xhigh 便宜 54% |
| Blocks | 代码模式下复用已写过的脚本 | 单次测试输出 397 → 76 token |
| Waste fixes | 找出 token 都花在哪并修掉 | 官方自标”未测” |
| Browse | 网页抓取结果压缩后再进上下文 | 页面缩小 129.8 倍 |
这些数字有第三方背书：Adobe Research 的 CAVEWOMAN 论文在八个模型上复验了这种”压缩输出风格”，成本降到原来的 1/1.4 到 1/2.4；JetBrains 用 86 个真实编码任务做了配对 A/B，没测出质量损失，输出 token 少 8.5%；Elastic 也在自己的场景复刻了一版，响应 token 少 63.6%。但别人的数字永远是别人的，我的问题是：装到我这种”免费额度抠着用”的环境里，它还剩多少真实价值？
实测一：shrink 压缩器，不花一个 token 就能全测完
六块石头里，Read less 依赖的底层是一个独立的 Go 工具 caveman-shrink，专门压缩 MCP 工具目录——就是每个 Agent 启动时都要塞进上下文的那份”我有哪些工具”清单。它是纯本地确定性程序，不依赖任何模型，这意味着可以往死里测。
官方 README 给的用法是管道过滤，我一开始用 npm 启动器 npx -y caveman-shrink 跑，直接报”missing upstream command”——这个 npm 包其实是 MCP 中间件包装，要套在真正的 MCP server 外面用。想用 README 里那个独立压缩器，得自己从源码编译（仓库 shrink 目录，go build 一条命令，国内环境记得 GOPROXY=https://goproxy.cn,direct，默认的 proxy.golang.org 我这边直接超时）。
编译好之后，我先压了官方自带的测试样本（1,782 字节、379 token 的两工具目录）：
# 压缩：stdin 进 stdout 出，压缩报告走 stderr
./caveman-shrink-bin < catalog.json > catalog.min.json
# 379 -> 197 token，ratio 0.48
# 按工具逐条体检，不落盘
./caveman-shrink-bin lint catalog.json然后造了个更接近真实场景的靶子：用脚本生成一个 40 个工具、66,750 字节的 GitHub 风格 MCP 目录（每个工具带长描述、enum、default、required）。压测结果：
# build_big.py 核心逻辑：40 个 GitHub 风格工具，长描述里埋约束句
verbs = ["list", "get", "create", "update", "delete", "search"]
for i in range(40):
tools.append({
"name": f"{verbs[i % 6]}_{nouns[i % 10]}",
"description": "... Rate limits apply: the server must back off ...",
"inputSchema": {"type": "object", "properties": props, "required": req},
})结果让我意外的好：
| 指标 | 结果 |
|---|---|
| 压缩率 | 14,137 → 8,968 token（-36.6%），字节 66,750 → 41,628 |
| 结构面（工具名/参数/required/enum/default/type） | 40 个工具逐一比对，100% 保留 |
| 约束句里的 “must” | 压缩前后各 216 处，零丢失 |
| 注解膨胀（schema title、examples） | 被剔除，title 从 56 处减到 16 处 |
| 可逆性 | recover 恢复后 sha256 与原文件逐字节一致 |
| 坏输入 fail-open | 喂乱码原样透传，退出码 0 |
两个细节值得说。第一，可逆设计比我预想的讲究：压缩时把原始字节存进本地 SQLite，返回的句柄就是原文件的哈希，caveman-shrink recover ccr_xxx 能一字不差地还原——这意味着压缩不是”有损赌博”，出问题随时退路。第二，lint 和压缩报告的口径不一样：同一个目录，lint 报 15.1%，压缩报 36.6%，因为 lint 只统计描述文本、压缩统计整个 JSON 的 token。看数字的时候别拿这两个口径互相比。
一个 40 工具的目录能省 5,000 多 token 的系统提示开销，如果 Agent 一天跑几十个会话、每个会话都带全量目录，这笔账在 API 计费下是实打实的。这部分是我今天测得最扎实的结论：shrink 的”结构不丢、约束不丢、可逆”三个声称全部成立。
实测二：Say less 语音，一题对照就撞上了额度墙
Say less 是 caveman 的灵魂：一段 1,158 token（o200k 计）的规则，教模型”先给答案、砍掉客套、代码逐字保留、每句一个信息点”。它的规则文件写得相当克制——明确禁止装穴居人腔调（”no me think”），明确禁止改用户的 prompt（Adobe 的研究说改 prompt 会反噬），明确要求安全警告和不可逆操作必须用完整句子。
我在 OpenCode 里做了对照实验：同一组 8 道开发题（React 重渲染、Python GIL、报错根因分析、写函数、危险删除命令、索引原理、正则、测试日志分析），模型用 nemotron-3.5-lightning:free，caveman 规则通过 prompt 注入——这等价于 caveman 对不支持 hooks 的宿主的官方安装路径（规则文件注入）。
第一题就出了很能说明问题的对照。问”React 组件 props 没变却总是重渲染，为什么，怎么修”：
| 组 | 输出 | 内容 |
|---|---|---|
| 基线 | 467 token / 1,975 字符 | 一张七行的成因表 + 修复代码块 + DevTools 诊断三步 |
| caveman | 53 token / 260 字符 | “Props change identity. New object/array reference each render triggers re-render. Fix: Wrap component with React.memo. Stabilize references with useCallback/useMemo.” |
输出 token 降了 88.7%。关键是我把两个答案都核了：caveman 版短归短，技术事实一点没丢——先说根因（引用变化触发重渲染），再说修复顺序（先稳定引用再上 memo），这个顺序恰恰是很多博客会讲错的点。基线版那张七行表格当然更有教学价值，但如果你只是要个修复方案，多出来的 400 token 是纯开销。
顺手测了个附带的东西：让另一个组写 is_leap(year) 闰年判断，输出 37 token，我把函数抠出来跑了 1900/2000/2024/2023/2100/1600 六个用例全对——基线模型在”只给函数”这种指令下的 payload 保真没问题，这正好对应 caveman 规则里”代码不动一个字符”的底线。
然后我就撞墙了。完整交代这轮实验的翻车现场，因为它对预算有限的读者可能比压缩率本身更有用：
- OpenCode 的免费模型额度是账号级日限额：glm-5.3-flash-free 跑了约 18 个请求后挂掉，换 iceman-free、deepseek-v4.1-flash-free 全部报同一个”Free usage limit reached”，换模型无效。
- 切到 openrouter 的 nemotron-3.5-lightning:free 又跑完两轮 16 个请求，接着报”Rate limit exceeded: free-models-per-day”——openrouter 免费档每天 50 个请求，且要求数十 token 的系统开销都算在内。
- 结果就是 Say less 的 8 题完整对照我只拿到了 1 题。剩下 7 题（包括我最想看的”危险删除命令会不会触发完整句子”的安全例外行为）只能留给额度恢复后补测，此处如实标注：未实测，需人工确认。
这轮翻车还白捡了三个投递机制的发现。其一，skill 装进 OpenCode 项目目录后能否生效，取决于模型自己会不会调用 skill 工具：GLM 系会（日志里能看到 → Skill "caveman"），nemotron 从头到尾不理它，8 轮全部回复”没有 caveman 这个技能”——装了 skill 不等于生效，验证要看日志而不是看感觉。其二，OpenCode 的 opencode run 命令行模式不会自动把项目 AGENTS.md 注入上下文，模型得自己 Glob+Read 才能读到规则；想让规则必达，走 prompt 注入最稳。其三，官方 install.sh --dry-run 在非交互 shell 里挂了 6 分钟没有任何输出，最后被我手动杀掉——脚本里应该有 TTY 交互步骤，想无人值守预览的别指望它。
什么场景我不会用它
写完这些数字，我的判断反而清晰了。三类场景我建议绕开：
新手教学场景。 基线答案那张七行成因表对学习者是真价值，caveman 版”修法+顺序”对已经懂原理的人才是效率。你在给团队写 onboarding 文档、让 AI 解释一个你陌生的领域时，省下的 token 远抵不上丢失的解释梯度。
中文对话为主的场景。 Say less 的整套规则（ASD-STE100 受控英语、冠词可省、20 词上限）都是为英文设计的。官方倒是给了一个 megacave 文言文模式，”技术之实皆存，唯赘言去之”，听着很妙，但今天额度耗尽没测成，未实测，需人工确认。中文语境下的实际收益，我建议你自己拿两个问题试了再装。
拿它当银弹降本。 官方最大的两个数字里，33.2% 是 Read less 在 Claude Code 会话里的输入侧（我没测），54% 是 Auto 模式对照 Opus 旗舰（需要注册它的云服务，我没测）。我测到的硬数据是：shrink 对工具目录压 36.6%，say-less 对”要修不要课”类问题压 88%。如果你的账单大头是长上下文阅读，shrink 值得装；如果是模型输出本身，先想想你的问题是不是本来就只需要短答案。
未实测清单
Auto 模式（需 Caveman Cloud 账号）、Read less 的全会话 33.2%（依赖 Claude Code hooks 路径）、Browse 的 129.8 倍压缩、Blocks 复用脚本、megacave 文言文模式、以及 Say less 在 Claude Code 原生环境的表现。这些留待额度充足时补测。
但今天测过的部分已经够我下结论：caveman 不是玄学。它的核心思路——”压缩表达方式，不碰代码和数字”——在确定性部分（shrink）经得起逐字节校验，在语音部分经得起单题对照。装不装，取决于你的账单构成；但至少，”让 AI 少说话”这件事，数字站在它那边。
复现环境
macOS 26.5.2 / Apple M4 / 16GB；Go 1.x（goproxy.cn 镜像）编译 caveman-shrink；OpenCode 2.1.4 + glm-5.3-flash-free 与 openrouter/nemotron-3.5-lightning:free；token 计数统一用 tiktoken o200k_base。全部原始输出保存在测试目录，需要的话可以逐题核对。
延伸阅读：如果你在关心 Agent 时代的 token 账单，之前写的企业 AI 成本的真实账单值得对照看；想了解更多往 Agent 上挂技能的玩法，可以读Cloudflare 安全审计技能的免费模型实测和graphify 代码知识图谱实测；把 Agent 编码工作流串起来的思路可以看DeepSeek Code Harness 与 Agent 编码之争。