用 Claude Code 的人大多盯着屏幕右下角那个额度条一路往下掉，然后就习惯性地把指令写得更短一点（prompt，也就是你给 AI 的那句要求）。有个开源技能说不用——让 AI 反过来说话短点就行，最多能砍 65% 的计费单位（token，模型读写文字的最小单位，也是账单单位）。它叫 caveman，中文圈一般叫「洞穴人」，从 Hacker News 头条一路火到 10.8 万 Star。
我把它的仓库整个搬进隔离沙箱，逐项复现：它自己提交在仓库里的评测快照、它自带的基准测试（benchmark，也就是一套标准考题）脚本、404 个自动化测试，以及那份写着 65% 的仓库简介。结论先放这：它省的是 AI 的「嘴」，不是「耳朵」，而 65% 这个数字只对聊天式问答成立——真实编码任务上，官方第三方实测是 8.5%。
它是什么，怎么做到的
caveman 不是一个模型，是一层「说话纪律」。装完之后 AI 还是那个 AI，只是回答从求职信变成了电报稿。它规定得很细：
- 删冠词、删客套、删「当然可以」「这是个好问题」这类开场白，删「just / really / basically」这类纯填充词
- 代码、命令、文件路径、报错原文一字不改。它专门写了一句话：只有代码周围的散文会被压缩
- 安全警告和「你确定要删库吗」这类不可逆确认，自动切回完整句子，做完再切回去
最反直觉的一条是它禁止为了「像原始人」而加词。别人模仿原始人会说 when it not，它说这比 when not 多花一个 token，却表达同一件事，属于净亏——压缩是唯一的风格。它的规则文件里甚至把「自己造 cfg / impl / req 这类缩写」列为禁止项，理由是分词器会把它们切成和完整单词一样多的片段，零节省，读者还得多解码一次。这一条是我在这个仓库里读到最有工程味的地方：它不装傻，它算过账。
等级分成日常三档（轻、标准、极简）和文言三档，默认是标准档。文言档在中文上按「汉字数」而非 token 数宣传削减，规则里自己标注了这个区别。
除了「管说」的技能本身，仓库里还有两层「管读」的东西：一个跑在本机的代理程序，把日志、测试输出、结构化数据、网页抓取结果在你发给模型之前先压一遍（原文落在本地数据库，随时可以取回）；以及一个可以塞进你自己代码里的中间件。这两层是商业许可，不是开源（下面第 6 条细说）。
实测：我把它的评测快照跑了一遍，也把它的测试跑了一遍
⚠️ 先说清楚边界：真跑一轮「带技能 vs 不带技能」的模型对比，需要 Claude Code 命令行加商业接口额度，评测机不具备。所以下面凡是模型生成的分数，都是仓库自己提交的数据；我复现的是这些数据的算法、结论口径和一致性。
第一步复现快照。仓库里存着一次完整评测：10 道开发问题、每道题跑三种条件（不加系统提示 / 只加一句「Answer concisely.」/ 那句加上技能全文），模型是 claude-opus-4-6，生成时间 2026-04-08。我按它自带的评测脚本口径重算（它用 tiktoken 这套开源分词器数 token）：
| 十道题 | 只加「简短回答」 | 加上 caveman | 削减 |
|---|---|---|---|
| 解释数据库连接池 | 339 | 41 | 省 87.9% |
| 为什么会 CORS 报错 | 328 | 138 | 省 57.9% |
| 哈希表怎么处理冲突 | 167 | 103 | 省 38.3% |
| 怎么修 Node 内存泄漏 | 227 | 226 | 省 0.4% |
| 十题合计 | 2,045 | 1,026 | 中位省 50%、均值省 46% |
三道题的表现就是这个技能的完整画像：问题越像聊天、越要让 AI 讲道理，省得越多；问题越像「给我代码」，省得越少，甚至一分不省。十道题里最差的那道只省了 0.4%（227 token 变 226），而离散度是 24.7 个百分点——这意味着「省 50%」这个中位数容易让人误以为稳定，其实它是一堆差异极大的结果平均出来的。
第二步，找矛盾。同一个仓库里，它的首页文档引用了两家第三方的测量：Adobe 研究院的论文测出输出侧压缩把实际成本降到 1/1.4 到 1/2.4（最好情况 1/3）；JetBrains 用 86 个真实编码任务做配对 A/B，测出省 8.5% 的输出 token、约 10% 的成本，而且这是「强制开启」的上限值（自动触发只会更少），质量上没有可检测的退化（符号检验 p = 0.82，82 组配对里 8 题更好、10 题更差、64 题打平）。
10 道聊天题省 50%，86 个真实编码任务省 8.5%。差距不是谁在撒谎，而是分母换了：在编码 agent（也就是能自己多步干活的 AI 程序）里，token 大头是代码和工具调用，而 caveman 明确不动这两样。它自己在首页文档里也把两句话并排写出来，这点是诚实的。
第三步，也就是这篇文章真正的发现：65% 这个数字，仓库早就把它从后端撤了，只剩 GitHub 简介还挂着。可复现的证据链有三条：
- 它自己的《诚实数字》文档里，输出削减那一栏写的是「未公布（Not published）」，理由是没有提交过经过复核的原始结果。
- 首页本该放基准表格的位置，是一段 HTML 注释占位，写着「这里尚无经过复核的接口基准结果」。
- 提供「已省多少」的后端统计早就不报数字了，代码注释里写明历史上的固定比例字段已不再使用，状态栏也不再显示节省百分比。
- 但 GitHub 仓库简介今天仍然是原话：「cuts 65% of tokens」。而这不是没发现——仓库在 2026-07-02 的提交里自己写了一句：「GitHub 仓库简介还写着『cuts 65%』，应该改成『约省 50-65% 输出 token（实测）』。本地提交改不了它。」
时间线更能说明问题：7 月 2 日先把宣传从「约 75%」改成「约 50-65%」并补上方法；7 月 3 日又发了一个提交，把「所有产品面」统一拉平成一句话 65%；直到 9 月 8 日，后端口径才撤回成「只报告日志里真实显示的内容」。一次改小、一次改回大、一次撤数字——三次里改动最小的那个位置，恰好是唯一改不动的地方。
顺手还挖到两个快照本身的问题，都属于「数字对不上现在的仓库」。
一是这份快照是 2026-04-08 一次跑完的单轮结果（每道题每种条件只跑一次、默认温度、没有显著性检验），而它测的那个技能文件在之后又改过 22 次，最近一次是 9 月 8 日——也就是说这份「50%」代表的不是今天的 caveman。
二是快照里参与竞速的四个技能中，中文版和西语版两个已在加入的次日删除，「压缩」那一路也已改名；而现在技能目录下躺着 20 个技能文件。这段对比数字连参赛者名单都对不上今天。
第四步，跑测试。仓库指定的测试命令是 node --test tests/installer/.test.mjs tests/hooks/.test.mjs。我在沙箱里跑完 404 个：381 通过、17 跳过、6 失败。
其中 3 个我看过失败原因，属于我们沙箱侧的限制：一个是容器里 /tmp 与根目录不同设备、跨设备硬链接被拒，两个是同时跑多个测试用例时 Node 起线程池撞上沙箱的进程数上限。
另外 3 个都跟 OpenClaw 的自动检测有关，我尝试把 OpenClaw 从系统查找路径里隔离后仍然复现——它们的失败信息是「没找到 OpenClaw 工作区」。
不下定论说这是仓库缺陷（真实用户的机器环境千差万别），但可以确定的是：这 6 个红不是「装了 OpenClaw 的机器才有」那么简单。
第五步，量体量。最近 30 天有 100 次提交、分布在 11 天里，持续集成流水线累计跑过 516 次、最近 5 次全绿；140 个待处理 issue，npm 上的命令行工具近 30 天下载 83,484 次。一句话：这不是蹭热度的仓库，维护强度是实打实的。
和同类比，你该装吗
「省 token」这个赛道其实分三层，装之前先分清你要省哪一层。
压读的一层：flowctx 走 OpenClaw 上下文引擎，实测砍 56% 输入 token 且解题率没掉；context-mode（也就是「上下文模式」）用 MCP 沙箱（MCP，也就是模型上下文协议、给 AI 接外部工具的通用接口）把 315KB 的工具输出压成 5.4KB。
压说的一层就是 caveman，以及管输出风格的 i-have-adhd。再往上是 ECC 这类整体工程纪律。这三篇我们之前都单独写过，文末可以顺着看。
caveman 的位置很特别：它是唯一同时做「说」和「读」的，而「说」那一半是 MIT 这种最宽松的开源许可、免费永久，「读」那一半要装本地代理。
第 6 条得单独说，因为它影响「能不能用在公司项目里」：这个仓库是混装许可。
技能目录、命令行工具、开发套件都是 MIT；但真正做压缩的几块——压缩引擎主体、本机代理、改写器、网页驱动、命令行输出压缩——是被称为 BSL-1.1 的商业许可，不是开源促进会认可的那种开源。
它允许你自用、自托管、内部生产使用，但不允许把它作为托管或嵌入式服务提供给第三方，那需要单独商业授权；变更日是 2030-06-21，届时转成 Apache 2.0。GitHub 接口给出的许可字段是「无法识别」，正是因为这个混装。
| 你想核实的 | 去哪看（都在仓库里） | 我跑出来的 |
|---|---|---|
| 评测快照与算法 | 自带的评测目录，含结果快照与评测脚本 | 十题合计 2,045 → 1,026 个计费单位，中位省 50% |
| 「未公布」的原话 | 文档目录里的《诚实数字》页 | 输出削减一栏确为「未公布」 |
| 测试命令与结果 | 项目配置里声明的测试命令 | 404 个用例：381 通过 / 17 跳过 / 6 失败 |
| 沙箱侧两个失败的成因 | 一个是跨设备硬链接被系统拒绝，一个是线程池起不来 | 均与沙箱限制一致，非项目缺陷 |
| 许可混装 | 根目录的许可文件与逐目录许可说明 | 逐目录列明，引擎相关目录为商业许可 |
最后是我实测下来觉得该提醒的三件事。
一，规则文件本身每次调用都要作为输入发一遍，当前那份技能正文约 1,650 token（按同一个分词器算），短问答里它可能比需要的还贵——仓库自己的 issue 里就有用户测出净亏。
二，按请求或按积分计费的工具（比如 GitHub Copilot 那类按「次」算的），回答短了还是同一次请求，一分钱省不下来。
三，首页公开过一条用户自测：某个 Cursor 的 A/B 里带 caveman 反而花了 430 万 token、对不带的 100 万，耗时还翻倍；仓库承认这条无法复现。
所以正确读法是——规则重复注入、以及缓存（也就是把算过的结果存起来、下次直接用）计费这两件事，能盖过输出端的节省，请在自己的任务上量一遍。
判断
装，但要装着正确的期待。它是一层写作纪律，不是省钱魔法：你的活越像聊天、越按 token 付费、回答里散文越多，它越值；你的活越像「给我代码」、越按次数付费，它就越接近零。8.5% 是真实编码任务上的上限，不是地板；50% 只在十道聊天题里成立。项目真正值得学的地方，反倒是它那份把「我什么时候会亏」写进文档的自觉——以及它到现在还没改掉的那句 65% 简介，提醒所有人：仓库里的数字会随文档更新一起改，产品页面上的那句话不会。
关注 AI商业快讯，每天一篇 AI 热点深度解读。
相关阅读：
