新智元报道
最近，一款名为“caveman”的AI插件迅速走红于Hacker News社区，其GitHub星标数量已突破两万大关。
该插件的核心理念是简化对话流程，剔除所有不必要的冠词、客套语和废话，号称能将输出的token节省约75%。
先看一张图。
观察“JuliusBrussee/caveman”项目的GitHub star数量增长曲线可以发现，在初期阶段，star数的增长十分缓慢，但从某个时间点开始，数字急剧上升。
在短短半天时间内，该插件的星标数量从几十个飙升至500多个，并最终超过两万个。
一个名为“caveman”的Claude Code插件在开发者的推动下爆红网络。
这种现象反映了社区用户对AI冗长对话的厌烦情绪达到了临界点，促使他们寻找解决方案。
很快就有网友称此插件为“2026年最棒的提示词技术”，认为它能够有效减少那些无用的礼貌和铺垫语句所占用的token数量。
此款插件的核心功能是使AI助手像原始人一样进行交流，删去诸如“the”、“please”、“thank you”等词汇以及其他一切不影响信息传达但会消耗大量token的内容。
项目作者Julius Brussee认为，少量的token完全可以准确地表达完整的意思，而无需冗长的文字描述。
caveman插件旨在以最简洁的方式让智能体进行沟通，在保持技术准确性的同时尽可能压缩输出内容，并声称可将token使用量减少约四分之三。
该项目由开发者Julius Brussee创建于GitHub平台，仓库地址为“JuliusBrussee/caveman”。
在README文件中，作者提出了一个核心问题：为什么一些简单的事情需要如此多的token来表达？
caveman不仅适用于Claude Code和Codex，而且它的主要作用是让智能体像原始人那样说话，在不牺牲技术准确性的前提下将输出压缩至极致。
该项目的核心思路在于简化对话流程，减少不必要的词汇使用，并声称可以节省大约75%的token消耗。
然而，这种做法是否真的能为用户省去四分之三的成本呢？这一点仍然值得讨论。
在项目文档中，caveman的核心理念被定义为“Ultra-compressed communication mode”（超压缩通信模式），旨在通过像原始人一样说话的方式减少token的使用量。
扒开SKILL.md
网友傻眼，就这？
当用户输入特定指令时，例如“caveman mode”，或调用“/caveman”，该插件便会启动。
在SKILL.md文件中，作者详细规定了节省token的具体规则：去除冠词、语气填充语句以及客套话；保留技术术语和代码块；使用更简短的同义词。
例如，在lite模式下，插件会去掉填充词和犹豫表达，但仍保持完整的句子结构与正常的书面感。
full模式则进一步压缩语言表达，允许使用碎片句，并采用短语替换长词。
并写明：
ultra模式则是大量缩写、省略连接词并用箭头表示因果关系，力求以最简洁的方式传达信息。
文档里还特别提醒，在涉及安全警告或需要多步骤操作的情况下，仍需保持清晰的表达方式。
实际上，caveman并未对模型架构进行任何修改，也未在推理机制层面做出压缩。其本质是一条精心设计的system prompt，用来规范AI助手的回答风格。
作者Julius Brussee也在Hacker News上的讨论中澄清，此插件并不针对隐藏思考过程中的token使用情况。
模型内部的推理流程并不会因为caveman而缩短，它主要压缩的是最后输出给用户的那部分内容。
Anthropic官方文档提到，技能名称和描述本身也会占用上下文预算。因此加载任何技能都会消耗一定的token。
所以从整体来看，实际的成本节省可能并没有达到作者宣称的75%那么高。
也就是说，尽管caveman确实能够显著压缩输出长度，但这并不能直接等同于同等比例的成本下降。
代码块不改。
根据项目仓库中提供的测试脚本和示例表格显示，使用caveman后token消耗量减少了大约22%至87%，平均节省了65%的token。
但截至目前为止，外界还无法完全复现项目的每一个结果验证过程。
此外，作者也在讨论帖中指出，这些测试数据仅是初步评估，并不代表最终结论。
近年来，Anthropic为Claude Code提供了较为完善的技能与插件机制。只需创建一个SKILL.md文件，Claude便能识别它作为一个功能模块加载使用。
项目仓库中确实存在.claude-plugin、plugins/caveman和skills/caveman等目录结构，证明caveman已按照官方文档标准进行了封装处理。
- 这意味着开发者可以通过一个简单的SKILL.md文件来修改Claude Code在特定任务中的行为方式和输出风格。
- 回到最初的问题：caveman是否真的有用？
- 该插件主要压缩的是用户可见的输出文本，并不对隐藏思考过程中的token使用量进行干预，而后者往往是成本的主要组成部分。
举个例子：
真正想要优化token成本的关键，在于模型分层调用、上下文窗口管理、prompt工程以及缓存策略等更为复杂的操作层面。
但caveman真正值得我们关注的地方在于，它反映了一种新的趋势：用户已经不再愿意忍受AI的冗长对话，并开始寻找解决办法。
正是由于这种情绪的存在，“山顶洞人式”的插件才会受到如此多的关注与讨论。
实际上，在各大技术社区中不乏对AI废话连篇现象的哀叹与抱怨。
比如，用户往往只需两行正则代码就能解决问题，而AI却要撰写五段自然语言解释。
在Hacker News等平台上的讨论也反映了这一点：用户已经厌倦了AI在每一次交互中都要重复的客套话和冗长介绍。
此外，高昂的成本也是让许多开发者感到不满的原因之一。他们认为自己正在为那些无用的信息支付额外费用。
因此，当大家宁愿让AI像原始人那样直接沟通也不愿忍受冗余输出时，主流AI厂商也许应该重新审视自己的产品设计思路了。
一味追求算力业务的增长并不是长久之计。关键在于如何让用户真正满意并减少不必要的计算消耗。
其实，用户之所以越来越无法接受这些不必要的信息输出，背后隐藏着深层次的问题亟待解决。
最后，在GitHub上查看caveman项目和Claude Code的技能文档可以获得更多信息：
README里的75%，到底靠不靠谱？
从仓库公开内容看，作者确实提供了benchmark脚本，也在README里列出了若干任务的token对比，区间从22%到87%，平均65%。
但截至目前，公开仓库里能直接看到的是测试脚本和示例表格；外界仍难以仅凭仓库当前内容完整复核每一项结果的复现实验链条。
作者在HN帖子里表示：这只是初步测试，不是严格的基准测试。
不过，「简洁表达是否会伤害AI性能」这个问题，学术界确实有人研究过。
https://arxiv.org/pdf/2401.05618
2024年的论文《The Benefits of a Concise Chain of Thought on Problem-Solving in Large Language Models》显示：
当研究者要求模型使用更简洁的推理链时，GPT-3.5和GPT-4的平均回答长度下降了48.70%，而整体解题能力几乎没有明显下降；但在数学题上，GPT-3.5的表现平均下降了27.69%。
2026年的论文《Brevity Constraints Reverse Performance Hierarchies in Language Models》则更进一步指出：
在部分基准上，对大模型加入简洁约束，准确率可提升26个百分点，甚至可能改变不同规模模型之间原本的表现排序。
https://arxiv.org/pdf/2604.00025
以上两篇论文，为「简洁未必伤性能」提供了研究背景。
但必须说清楚：它们研究的是brevity作为通用提示策略的效果，不是对caveman这个GitHub仓库的专项评测。
README引用这些研究，最多只能说明它的思路并非毫无理论背景，不能直接当作对项目自身效果的严格验证。
Claude Code的插件生态
开始起来了
caveman能火，还有一个背景原因：
Anthropic已经为Claude Code提供了相对完整的skill与plugin机制。
https://code.claude.com/docs/en/skills
根据Anthropic官方文档，开发者只需创建一个SKILL.md文件，Claude就能把它识别为skill；其中description用来决定何时自动加载，name则会变成可直接触发的斜杠命令。
官方文档还明确写了plugin级skill的路径结构是
/skills/
/SKILL.md
。
而caveman仓库中，确实能看到.claude-plugin、plugins/caveman、skills/caveman等目录，说明它不是一个停留在「几句提示词」层面的玩具，而是按照Claude Code的skill/plugin机制包装出来的扩展。
这也意味着，开发者确实可以通过一个SKILL.md，在不改模型底层的前提下，改变Claude Code在特定任务中的调用方式和输出风格。
某种意义上，这已经有点像早期VS Code扩展生态：
先有一批看起来轻量、甚至带点玩笑感的扩展冒出来，随后才逐渐长成更严肃、更细分的工作流工具。
开发者苦AI废话久矣
回到那个最初的问题：caveman到底有没有用？
如果把它当成一个严格意义上的「省钱工具」，那就需要更谨慎。
它压缩的只是可见输出文本，并不触及hidden reasoning tokens，而后者往往才是Claude Code成本的大头。
再加上skill本身也会占用上下文，端到端算下来，真实节省大概率到不了75%。
真正想优化token成本，关键也不在这里。模型分层调用、上下文窗口管理、prompt工程、缓存策略，这些才是真正的主战场。
但caveman真正值得关注的地方，不在于它是不是开出了一剂完美药方，而在于它本身就是一个信号。
当一个开发者把「让AI少说废话」这件事做成插件，放到GitHub上，被上千人认真讨论，在HN上爆火，事情的重点就已经变了。
它说明，AI工具的冗长，不再只是一个可以忍受的小毛病，而是严重到用户开始自己动手修正的程度。
实际上，开发者们在情绪上早就已经破防了：去各大社区看一眼，满屏皆是对AI 废话的哀叹抱怨：
我只需要两行正则代码，它非要给我写5个自然段的正则历史散文；
求求你别再对我说「Certainly! Here is the……」了，直接给我报错或者给我代码不行吗？
在Hacker News上，这种哀叹和抱怨更是与使用成本挂钩：
我简直是在花15刀/100万Token的价钱，来阅读AI对我的道歉和寒暄。
只因为要改一个标点，它竟然把整个800行的文件重新输出了一遍，看着API余额肉眼可见地往下掉，我都快破产了。
当大家宁愿让AI像「山顶洞人」一样说话，也不愿意继续为冗余输出多付token成本时，真正应当反思的也许是那些主流AI大厂。
为什么直到今天，他们还没有把「克制」做成一种基础能力。
不要别总盯着算力生意，而是要认真想想，用户到底为什么越来越受不了这些没必要的输出。
参考资料：
https://github.com/JuliusBrussee/caveman
[92] [91] [90] [89] [88] [87] [86] [85] [84] [83] [82] [81] [80] [79] [78] [77] [76] [75] [74] [73] [72] [71] [70] [69] [68] [67] [66] [65] [64] [63] [62] [61] [60] [59] [58] [57] [56] [55] [54] [53] [52] [51] [50] [49] [48] [47] [46] [45] [44] [43] [42] [41] [40] [39] [38] [37] [36] [35] [34] [33] [32] [31] [30] [29] [28] [27] [26] [25] [24] [23] [22] [21] [20] [19] [18] [17] [16] [15] [14] [13] [12] [11] [10] [9] [8] [7] [6] [5] [4] [3] [2] [1]
https://news.ycombinator.com/item?id=47647455