65%省Token实测：真正管用的只有两个字

一个叫 caveman 的仓库最近在 GitHub 上刷屏了。它的自我介绍写着：为什么用很多 token，当很少 token 就能搞定。号称能让编程智能体省下 65% 的 token，办法是"像原始人一样说话"。

这个梗好笑到光靠笑话就传开了。也正因为这样，它值得被实测一遍，而不是随手转发。

有人真的动手了：弄坏一个真实的 C# 程序，让同一个智能体的四个版本去修，用项目自己指定的分词器数每一个 token，再把所有答案编译一遍，确认"更短"没有变成"更差"。

三个发现出乎意料，其中一个任何文档里都没写。

一、标题数字和它自己的文档打架

仓库描述说 65%，来自"像原始人一样说话"。但项目文档页的副标题写的是另一回事：安装技能获得更短的回答，或者用命令行代理把输入 token 砍掉 33.2%。

这根本不是同一个说法。caveman 其实是两个产品：

• 技能（skill）——一套写作规则，让智能体的回答变短，改的是模型"说什么"，也就是输出 token。
• 代理（proxy）——一个本地程序，在模型读到文件之前先压缩它们，改的是模型"看到什么"，也就是输入 token。

33.2% 属于代理，而描述把功劳记在了"像原始人一样说话"头上，那是技能。它推销的是自己产品的另一半。

不过文档比营销诚实得多，里面甚至有一句坦白，后来被拿来当对照组："be concise"（保持简洁）本身就已经拿到了大部分收益。

二、它不是一堆提示词文件

原本的猜测是：这不过是 markdown 文件里一段聪明的文字，运气好火了。错了。把仓库目录拉下来按扩展名分组：

• Go（代理+引擎）640 个文件，6.6 MB，占 30.9%
• JS / TS 450 个文件，5.6 MB，占 26.5%
• Python 103 个文件，1.3 MB，占 6.3%
• Markdown（全部文档）179 个文件，1.1 MB，占 5.2%
• skills/ 里那个"原始人" 64 个文件，0.3 MB，占 1.3%

整个仓库 1785 个文件、21.2 MB，31% 是 Go——一个真正的代理和一个真正的压缩引擎。那个著名的"像原始人一样说话"指令，只占仓库的 1.3%。

梗在门面上，门后面是一台编译器。

三、实测：65% 是真的，但来自另一个模式

测试用的 bug 有可验证的通过/失败标准：一个 C# 购物车会悄悄丢东西。给 Dictionary 当键的对象，插入时哈希算一次，之后改掉 Sku，GetHashCode 返回的值就变了，查找会去探测另一个桶，什么也找不到，Equals 根本没被调用。条目没消失，只是够不着了。

每次的提示词完全一样（276 个 token）：解释失败原因，返回修正后的类。四个变体，每个跑三次，用 o200k_base 数 token：

• plain：896 / 951 / 688，均值 845
• concise：541 / 669 / 598，均值 603，省 28.7%
• caveman：475 / 577 / 395，均值 482，省 42.9%
• ultracave：314 / 317 / 293，均值 308，省 63.6%

所以标题数字是能实现的——但来自最大压缩模式，不是描述里宣传的原始人腔调。腔调本身落在约 −43%。而"Be concise."三个 token、零安装，拿到 −28.7%。

这不是第一个测的人。Max Taylor 用 24 个提示词、第二个模型打分，把 caveman 和"Be brief"对比过，发现两个词的提示词在 token 和质量上都打平。两次测试在 /ultracave 上有分歧，但都同意关键的那部分：大部分节省是免费的。

四、压缩还顺带砍掉了波动

看离散程度。plain 在 688–951 之间（±15%），/ultracave 在 293–317 之间（±4%）。简洁模式不只是更小，还明显更可预测——如果你在给一次长智能体运行做预算，这比均值更重要。

五、技能不是免费的

那些规则每次会话都要发给模型。用同一个分词器量：skills/caveman/SKILL.md 是 1158 个 token，skills/ultracave/SKILL.md 是 608 个 token。教模型少用 token，要先花 1158 个 token。

对比免费的两个词提示词，/caveman 每次回答省约 120 个 token，回本需要约 10 次回答；/ultracave 每次省约 295 个 token，回本约 2 次。两个维度上 /ultracave 都更划算——开销减半，节省翻倍还多。

项目自己提了一个前提：如果这些规则待在缓存的提示词前缀里，开销会被摊薄。他们没测，测试者也没测。

六、答案变差了吗？没有

这是大多数 token 基准测试跳过的一步。把每个答案里修正后的类提取出来，对着原始 Cart 编译并运行。四个全部编译通过，四个全部打印 PASS。

/ultracave 的完整答案只有 11 行，而且是对的。它用 init 让身份字段不可变，于是那行引发 bug 的赋值语句从静默损坏变成了编译错误。压缩没有丢东西。/caveman 的答案甚至抓到了 plain 从没提过的第二个 bug：Sku 为 null 时 GetHashCode 会抛异常。而 plain 的开场白是"没拿到探测 .NET SDK 的权限"——正是这些规则要删掉的废话。

七、没人写过的发现：它压的是形状，不是格式

再说代理，也就是描述忘了记功的那部分。npm 包只是前端，压缩引擎是另一个签名二进制。引擎不在时它会老实交代：0% 压缩，输入原样通过。

引擎就位后，喂四个真实文件：

• build.log（.NET 构建）：945 → 945，省 0%
• repo.json（嵌套 API）：1965 → 1965，省 0%
• records.json（400 条记录）：19994 → 2509，省 87.5%
• export.csv（400 行）：8409 → 314，省 96.3%

文档宣传"CSV、日志、YAML、测试输出、JSON"能省 98–99%。真实数据上：整齐的表格数据效果惊人，CSV 省 96.3%，400 条 JSON 记录省 87.5%，这个形状上宣传成立。但构建日志和嵌套 API 响应，正好 0%。不是识别错了——直接问引擎，它正确判定为 code 和 json，只是对它们无事可做。

规则不在 README 里：它压缩的是形状，不是格式。重复记录的行能漂亮地塌缩，散文式的日志和深层嵌套对象不行。如果你的智能体上下文主要是构建输出和 API 响应，这部分对你几乎没用。

每个压缩结果都带一个看着吓人的标记：对模型有损。模型确实看不到原文，部分内容被移除了。但每次压缩都返回一个恢复句柄。拿它要回原文再比对：46886 字节进，46886 字节出，逐字节相同。对模型有损，在磁盘上无损。

结论分两半

技能：跳过。打上 be concise。两个词，三个 token，不用安装，独立基准测试发现效果相当。原始人腔调比它多买约 14 个百分点，代价是 1158 个 token 的开销和大约十次回答才回本。

代理：确实不错，但有条件。如果智能体整天读 CSV、导出文件和记录转储，96% 是真的，你能感觉到。如果它读的是源码、构建日志和嵌套 API 响应，你等于装了个几乎不干活的代理。

不是炒作，是标签贴错了。工程比梗所暗示的更好——可验证的签名供应链，引擎拒绝把恢复存储写进权限宽松的目录。但原始人是营销，Go 代码才是产品，而被分享最多的那部分，恰恰是最不值钱的那部分。

更普适的一课不花钱：在装东西省 token 之前，先试试少要点。整个对照组只有两个词长。

方法说明：每个变体 n=3，单一任务、单一模型，所以这些数字读作"在这个任务上"，不是"普遍情况"。这里的输出 token 测量和项目那个 33.2% 的输入 token 数字不可比，是两种不同的主张。测试环境为 caveman 4.0.1、.NET 10，token 用 o200k_base 计数。