Caveman 翻车了：号称省 65% token，官方实测只有 8.5%

一项关于“原始人模式”的实测：节省65%的token？真相是8.5%

圈子里流传着一套说法：跟AI agent交互时，用“原始人”式的短句能省掉65%的输出token。这方法甚至被打包成skill，写进了不少工作流里。听起来挺诱人，对吧？

但JetBrains的团队花了106美元做了次对照实测，结果很有意思：实际节省只有8.5%，而且是在强制触发条件下的上限。更关键的是，输出质量根本没看出什么统计意义上的差异。奇葩的是，如果把整轮支出加起来，启用这个skill的那组反而更贵了。

这次测试的支出规模本身就值得单独拿出来聊聊。过去两年，代码产出的速度提升了几个数量级，但验证产出质量的手段几乎还停在原地。这个落差带来的成本，其实都转嫁给了使用者：在缺乏独立评测的情况下，你只能靠工具自己的文档来判断它好不好用。

这个声明就凭README里一个数字被广泛采纳了，三个多月里没人去验证。而确立结论所需的支出，不过是106美元。这期间，每个照此改动工作流的使用者，都在承担另一组成本：配置调整的时间、错误配置下多花的token，以及结论修正后的返工。这笔账没人算过，但量级肯定比106美元高得多。

这里有个结构性的问题：验证成本是可计量、可归因的，所以在预算里最先被砍掉；但不验证的成本分散在不同人、不同时间点上，很难归集，所以长期进不了决策视野。

65%这个数字的出处

这个方法的具体要求，说白了就是省去那些客套词，只保留代码和命令原文。

Dan Luu核对过那份README，发现同一份文档里并存着好几个互相矛盾的数值：省75%、省65%、减少一半token、速度提升3倍。这就有点意思了。

2026年4月5日，介绍这个方法的帖子上了Hacker News，拿了904分、366条评论。同月还有一条89分的对照测试帖和一条16分的讨论帖。之后三个月，这方法被反复引用。

不过，作者本人后来在帖子里做了说明（用户名JBrussee-2，仓库JuliusBrussee/ca veman）：

作者明确界定了作用范围：这个skill只压缩可见输出中的开场白和填充文本，不涉及隐藏的推理和思考token。这个界定跟后面的实测结果直接相关——8.5%的上限正源于此。

有意思的是，这条回复下面，有人用“原始人语体”转述了内容：“It joke. No yell at me. It kind of work?” 作者的解释，并没有阻止这个方法被当作可靠的成本优化手段来广泛使用。

实验设计与配置

JetBrains AI团队基于Harbor 0.17搭了Docker沙箱，做了配对实验。agent那边用的是Claude Code 2.1.200的headless模式，模型是claude-sonnet-5，reasoning effort设成low。评测集是SkillsBench，在87道任务里执行了86道，每道任务按自带测试用例给出0到1分。

两组配置完全一样，唯一的变量就是是否启用这个skill，而且用的是强制触发方式。这个skill在常规使用中需要用户自己说“ca veman mode”或“be brief”才会激活，但这次测试在每条回复里都附上了强制指令，确保它始终生效。实验跑了三轮，大约240次调用，直接支出106美元。

token节省的实测值

第一轮只跑了10道任务，测出来节省29.5%，跟流传的数值挺接近。但同一组10道任务重复三轮取均值后，这个数字就收窄到了6.7%。样本扩大到82组配对任务后，最终收敛到8.5%，输出token从59.2万降到54.2万。

因为这次测试是强制触发，所以8.5%应该算是这个方法的节省上限。在常规使用中，触不触发全靠用户自己判断，不会覆盖所有回复，所以实际节省比例只会更低。

输出质量的配对比较

这一维度的结论，比节省幅度更有参考价值。在82组配对任务中，启用skill后得分更高的有10组，更低的8组，持平的64组。sign test的p值是0.82，不构成统计意义上的差异。平均任务得分，baseline组是0.326，skill组是0.311，差了0.015，在满分1分的尺度上基本可以忽略。

值得注意的是，skill组在单项比较中赢的任务比输的多，但均分却更低，说明它失分的幅度比得分的幅度大。

这跟作者对作用范围的界定是一致的。agent输出的主体是代码、diff、工具调用和报错原文，这个skill明确保留了这些，只压缩了工具调用之间的叙述性文本。这部分在总输出里占比有限，所以既节省有限，也很难对结果质量产生实质影响。

token节省与实际支出的背离

按8.5%的token节省来算，成本应该下降一成左右，逐题核算也符合这个预期。但汇总整轮支出后，启用skill的那组反而高了11.6%：40.60美元对36.39美元。

原因在于一道dependency audit任务，在skill组里的token用量超过了20万这个long-context计价档，这一题单次支出就达到8.29美元，而baseline组同一任务只有0.33美元。在另一轮执行中，同一任务又在baseline组产生了一次3.25美元的outlier。这种波动跟任务本身有关，跟是否启用skill无关，但它的幅度足以在单次执行中完全抵消一成的节省预期。

Dan Luu的独立复现

Dan Luu自己也独立做过同类对照实验，覆盖了三种任务、多个模型和多档reasoning effort。他结果的离散程度比JetBrains的还高：在一种任务上，这个skill表现明显更好；在另外两种任务上，多数情况相反。而且，换了模型或reasoning effort后，方向还会反转。他的结论是：各条件之间的差异需要更大样本才能分清楚，但整体均值上的差距，不足以支持专门用这个模式。

按场景的适用判断

JetBrains给出的建议是：如果你认可这种表达方式，可以继续用，实测没发现质量代价。但别把它当成成本优化手段，个位数百分比就是上限，而且这个上限还建立在手动强制触发的前提下，常规场景下只会更低。

根据这些材料，可以按场景分别判断：

以上四项无法归并成统一结论。选取跟自身场景对应的一项作为判断依据就行。

思考总结

社区在“怎么写一个skill”上已经积累了相当多的经验，模板、目录结构、最佳实践都很成熟。但在“怎么判断一个skill是否有效”上，公开可参考的方法几乎没有。这个声明能在无人验证的状态下流传三个多月，原因之一就在这里：使用者没有可依循的验证路径，只能采信文档里的数字。

上图这五个环节，没有一项依赖特殊工具或大规模算力。门槛不在资源，而在是否愿意把“我觉得它有用”改写成一个可证伪的命题：先界定清楚测的是什么，再把样本扩到足以推翻自己的第一印象。这次评测里最关键的是第二步。首轮10道任务测出29.5%，看上去足以支持原始声明；如果就此停手，得到的结论会跟最终结论完全相反。

结论只对被测的那个对象有效，方法却可以搬到自己的任何一次选型上。所以，每一次有机构公开这类评测，值得先看它怎么测，再看它测出了什么。