Caveman 暴动：给 AI 下命令，别跟它客气

摘要：一个 19 岁小哥做的 Caveman 项目，靠"把提示词砍成穴居人语"在 GitHub 上拿了 86K stars。它的口号是"why use many token when few token do trick"。但它真的能省 65% 的 Token 吗？JetBrains 在 86 个真实工程任务上实测，输出 token 只少了 8.5%。这篇文章不吹不黑，讲清 Caveman 是什么、为什么"原始人语"有效、65% 这个数字的水分在哪，以及我们写 Java 后端到底能带走什么。

你让 AI 帮忙改一个空指针的 bug，它先回你三段："当然！我很乐意帮你解决这个问题。让我先分析一下这段代码……"。你说"把那个方法名改一下"，它把整个 800 行的文件重新输出一遍。你盯着 API 余额，看它肉眼往下掉。

我们都习惯了。习惯了 AI 的客套，习惯了它把一句话能说清的事铺成一篇小作文。

直到一个 19 岁的小哥受不了了，做了个东西叫 Caveman。GitHub 上 86K stars，标语很直白："why use many token when few token do trick"（能用几个 token 搞定，何必用一堆）。还有一句更妙的："Brain still big. Mouth small."（脑子还是大的，嘴给我闭上）。

这股"暴动"本质上不是技术有多牛，而是它戳中了所有人被 AI 废话文学折磨的集体痛点。

Caveman 到底是什么

先说清楚，它不是新模型，也不是什么库。它是一个 Claude Code 的 Skill——说白了，就是一段写进系统提示词的指令。

它的核心逻辑只有一句话：压缩自然语言，但绝不碰技术内容。你写的代码块、文件路径、URL、报错堆栈，原样保留；被砍的只是那些冠词、连词、客套话（the / a / and / please / 当然 / 让我先）。

它给了四档强度：

• Lite：删填充词，保留语法，日常最温和；
• Full：砍冠词，句子碎片化，作者日常推荐这档；
• Ultra：极致电报体，基本只剩主谓宾；
• Wenyan：文言文模式，中文语境下意外地好用。

还配了四个子技能：/caveman-commit（50 字内提交信息）、/caveman-review（一行 PR 评论）、/caveman-compress（压缩记忆文件）、/caveman-stats（统计耗能）。

它也不是孤例。同一时期还有 ponytail（改决策逻辑）、dao-code（优化缓存）、OmniRoute（路由套利）——一股叫 Token Economy 的运动，共识就一句：每个 token 都该有价值。Caveman 是里面最出圈的那个。

"原始人语"为什么真的有效

这事儿不是玄学，机制上说得通。

大模型靠注意力机制理解你，而注意力根本不需要完整的英语语法。冠词、连词、客套话的语义贡献接近于零，但吃起 token 来一点不含糊。"Please help me to fix the bug in the following code" 和 "fix bug:"，表达的意图一模一样，token 数差出好几倍。

更关键的一点：输出 token 通常比输入贵 3 到 5 倍。Caveman 压的主要是 AI 的回复——也就是贵的那一端。这就能解释为什么它自称基准测试里输出 token 从 1214 降到 294，省了 65%。

还有个反直觉的发现：压短回复，准确率不降反升。2026 年 3 月一份预印本说，强制简洁回答能在部分 benchmark 上把准确率最高提 26 个百分点——道理是，逼着模型只给最确信的判断，反而少说废话少出错。联合国一份报告也提到，冗长客套的 prompt 平白增加算力和能耗。

落到我们写 Java 后端的场景，对比特别明显。

啰嗦版 code review 提示词：

请你仔细阅读下面这段 Spring 服务的代码，
帮我检查一下有没有潜在的空指针风险、
事务配置是否正确，以及是否符合团队的编码规范，
如果可以的话，请尽量给出修改建议。谢谢！

电报版：

review 这段代码。查：1) 空指针 2) 事务注解 3) 团队规范。
只列问题，给行号，不写客套。

后者意图一点没少，token 砍掉一大半，AI 还更不容易跑偏去写一堆"总体而言"。

泼盆冷水：65% 是吹出来的

但那个最抓眼球的数字，得打个问号。

JetBrains 用 Harbor 加 SkillsBench，在 86 个真实软件工程任务上跑了 Caveman。结果：输出 token 只减少了 约 8.5%，离宣称的 65% 差了老远。

更有意思的是过程。前 10 个任务看起来确实像省了 30%，但随着任务规模一上去，比例直接掉到 8.5%。像极了那种"小样本很猛、一上量就现原形"的优化。

根因其实很朴素：Agent 工作流里 token 的大头，根本不在对话文本上。读文件、推理、调工具、生成代码，这些才是吞 token 的黑洞。你把"谢谢"和"当然"砍了，省下的也就是那点零头。

所以诚实的结论是：Caveman 能省 token，但省的是输出层那点对话税，不是你账单的大头。别指望靠它把 API 费用砍掉三分之二。

那它在哪还有用？恰恰是你我天天干的活——代码审查、debug、写提交信息。这些场景 AI 的回复往往很长、废话很多，开 Caveman 压缩输出，体感最明显。你让它审一个 PR，它回你"第 42 行可能 NPE、第 88 行事务没加 @Transactional，改完"——比回你半屏分析小作文舒服多了。

Java 后端能带走什么

我不会因为一个爆款项目就否定我们之前聊的东西。那篇写"给 Java 后端写 Prompt 不是玄学"，那是正经方法论；Caveman 是它的反面教材，但两件事底层共识是一样的：精准、去填充、每个字都得有信息量。

具体到日常，我能带走的就四条：

第一，清晰永远大于啰嗦。 不管是写 elaborate 的团队规范，还是写电报式命令，目标都是减少歧义。Caveman 提醒我们，那些客套和铺垫，除了耗 token 没别的作用。

第二，分场景开。 审查、debug、提交这些"AI 输出很长"的活，适合 terse 模式；但写技术方案文档、写给新人的教程，就该把上下文铺够，别开压缩——那里需要的是完整，不是省字。

第三，做成团队资产而不是个人自觉。 呼应那篇，把"terse review"做成一个团队 Prompt snippet，挂在共享工具里强制模板，比指望每个人记得"说话简短"靠谱得多。新人接手，自动继承这套纪律。

一个放在团队库里的 review snippet 长这样：

/caveman-review
你只做代码审查，不修改代码。
输出格式：每行一个问题，[文件名:行号] 问题 (严重度)。
严重度：高/中/低。无问题就写 "LGTM"。
禁止写：总结、客套、改进建议之外的内容。

第四，一句心法：每个 token 都得有价值。 这跟之前那篇 Harness Engineering 是同一股劲——都是在抠"AI 跑起来到底浪费在哪"。

真值得记的教训，不是"以后要像穴居人一样跟 AI 说话"。而是我们太习惯 AI 的废话，习惯到忘了每个 token 背后都是真金白银的算力和钱。Caveman 是一面镜子，照出的是我们和 AI 对话里那些早已被默认、却毫无必要的冗余。

Brain still big. Mouth small. 这句话，也许该贴在每个用 AI 写代码的人的显示器上。

作者：唐悦玮 | 从后端出发，用 AI 拓展到全栈的工程师。