一项流传三个多月的说法称，与 agent 交互时采用 caveman 式短句可减少 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/caveman 对应）：
Author here. A few people are arguing against a stronger claim than the repo is meant to make. As well, this was very much intended to be a joke and not research level commentary.
This skill is not intended to reduce hidden reasoning / thinking tokens. Anthropic's own docs suggest more thinking budget can improve performance, so I would not claim otherwise. What it targets is the visible completion: less preamble, less filler, less polished-but-nonessential text.
作者在此明确界定了作用范围：该 skill 仅压缩 visible completion 中的开场表述与填充文本，不涉及隐藏的 reasoning 与 thinking token。这一界定与后文的实测结果直接相关，8.5% 的上限正源于此。
该回复下方有一条以 caveman 语体转述其内容的评论：「It joke. No yell at me. It kind of work?」作者的定性并未阻止该方法被当作一项可靠的成本优化手段广泛采用。
实验设计与配置
JetBrains AI 团队基于 Harbor 0.17 构建 Docker 沙箱执行 paired 实验。agent 侧使用 Claude Code 2.1.200 的 headless 模式，模型为 claude-sonnet-5，reasoning effort 设为 low。评测集为 SkillsBench，在 87 道任务中执行 86 道，每道任务依其自带测试用例给出 0 至 1 的分值。
两组配置完全一致，唯一变量是是否启用该 skill，且采用强制触发方式。该 skill 在常规使用中需由用户显式声明 "caveman mode" 或 "be brief" 才会激活，本次测试在每条回复中附加强制指令以确保其始终生效。实验共执行三轮，约 240 次调用，直接支出约 106 美元。
token 节省的实测值
首轮仅执行 10 道任务，测得节省 29.5%，与流传数值接近。同一组 10 道任务重复三轮取均值后，该数值收窄至 6.7%。样本扩展至 82 组 paired 任务后，最终收敛于 8.5%，输出 token 由 59.2 万降至 54.2 万。
由于本次测试采用强制触发，8.5% 应视为该方法的节省上限。在常规使用中，是否触发由用户自行判断，不会覆盖全部回复，实际节省比例只会低于此值。
输出质量的配对比较
这一维度的结论比节省幅度更具参考价值。在 82 组 paired 任务中，启用该 skill 后得分更高者 10 组，更低者 8 组，持平 64 组，sign test 的 p 值为 0.82，不构成统计意义上的差异。平均任务得分为 baseline 组 0.326、skill 组 0.311，差值 0.015，在满分 1 分的尺度上可以忽略。
值得注意的是，skill 组在单项比较中胜出的任务多于落败的任务，均分却低于 baseline，说明其失分幅度大于得分幅度。
这一结果与作者对作用范围的界定一致。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 给出的建议是：若认可这种表达方式，可以继续使用，实测未发现质量代价；但不应将其作为成本优化手段，个位数百分比即为可获得的上限，且该上限建立在手动强制触发的前提之上，常规场景下只会更低。
依据以上材料，可按场景分别判断：
| 场景 | 判断 |
|---|---|
| 偏好简短的表达方式 | 可以使用，实测未发现质量代价 |
| 以降低成本为目的 | 预期需下调一个数量级，个位数百分比为上限，且系强制触发下的上限 |
| 任务涉及 long-context、dependency audit 等场景 | 单次成本可能因单一任务的计价档跳变被完全抵消，不宜依据均值判断 |
| 判断是否适用于自身任务类型 | Dan Luu 的结果表明结论因任务而异，方向可能与官方均值相反，依据自身实际用量测量比套用 README 数值可靠 |
以上四项无法归并为统一结论。选取与自身场景对应的一项作为判断依据即可。
思考总结
社区在"怎么写一个 skill"上已经积累了大量经验，模板、目录结构、最佳实践都相当成熟。但在"怎么判断一个 skill 是否有效"上，公开可参考的方法几乎没有。这项声明能在无人验证的状态下流传三个多月，原因之一正在于此：使用者没有可依循的验证路径，只能采信文档里的数字。
上图这五个环节，没有一项依赖特殊工具或大规模算力。门槛不在资源，而在是否愿意把"我觉得它有用"改写成一个可证伪的命题：先界定清楚测的是什么，再把样本扩到足以推翻自己的第一印象。这次评测里最关键的是第二步。首轮 10 道任务测出 29.5%，看上去足以支持原始声明；如果就此停手，得到的结论会与最终结论完全相反。
结论只对被测的那个对象有效，方法却可以搬到自己的任何一次选型上。所以每一次有机构公开这类评测，值得先看它怎么测，再看它测出了什么。
参考链接
- Denis Shiryaev,《Does Speaking to Agents Like Cavemen Really Save 65% of Tokens? We Test》, JetBrains AI 官方博客: blog.jetbrains.com/ai/2026/07/...
- Dan Luu,《Agentic test processes, LLM benchmarks, and other notes on agentic coding from Galapagos Island》: danluu.com/ai-coding/
- 作者 JBrussee-2 在该帖下的回复（原始出处，含"intended to be a joke"与适用范围说明）: news.ycombinator.com/item?id=476...
- caveman skill 仓库: github.com/JuliusBruss...
- Hacker News,《Caveman: Why use many token when few token do trick》（904 分 / 366 评）: news.ycombinator.com/item?id=476...
- Hacker News,《I benchmarked Claude Code's caveman plugin against "be brief."》（89 分 / 67 评）: news.ycombinator.com/item?id=479...
- Hacker News,《Caveman Mode Save Token?》（16 分 / 7 评）: news.ycombinator.com/item?id=476...
若需确认自身项目中同类 token 优化手段的实际效果，建议使用可量化 token 与成本的工具直接测量：github.com/androidZzT/...