当 AI 开始学“原始人说话”：这个 GitHub 小项目，戳中了大模型时代最贵的痛点
一个玩笑项目，为什么突然让开发者共鸣
GitHub 上这几天冒出一个很有网感的项目，名字叫 caveman。它的口号也很直接：why use many token when few token do trick。翻成大白话就是，能少说就别多说。这个项目是给 Claude Code 用的一个 skill，核心思路简单到近乎粗暴——让 AI 用“原始人风格”回答问题，砍掉寒暄、铺垫、委婉语和各种不必要的连接词，但保留代码、术语和技术结论。
项目作者给出的示例很有代表性。普通模式下，Claude 会认真解释为什么 React 组件重复渲染：对象引用变了、浅比较失败了、建议用 useMemo。到了 caveman 模式，就变成一句话：“New object ref each render. Inline object prop = new ref = re-render. Wrap in useMemo.” 意思一点没少，语气却像一块石头砸过来。
你很难不笑一下。可笑完之后，很多开发者会立刻意识到：这不只是个梗。对频繁使用 AI 编程助手的人来说，输出 token 就是时间，就是钱，也是上下文窗口里最宝贵的空间。以前大家嫌 AI 啰嗦，只是体验问题；现在模型按 token 计费、长上下文越来越贵，啰嗦已经开始变成成本问题。caveman 把这个问题戏剧化了，但它戳中的，恰恰是今天 AI 开发工具最现实的一根神经。
省下的不只是字数，而是整条工作流的摩擦
很多人第一次接触大模型时，会把“说得像人”视为进步。模型会先客气一句“我很乐意帮你”，再给出背景解释、风险提醒、替代方案，最后温柔收尾。这种风格在面向普通消费者时很讨喜，甚至会让人误以为它更聪明、更可靠。
但在工程场景里，事情往往相反。程序员真正想要的，常常不是一篇友善的说明文，而是一把准头很高的扳手：问题在哪、为什么、怎么改、改完可能影响什么。尤其当你在调试线上 bug、看 CI 报错、改一段本来就熟悉的代码时，太多修辞会把重点冲淡。caveman 的价值，不在于“模仿原始人”，而在于它把 AI 回答里那些长期默认存在、但并不总有必要的语言包装，直接拔掉了。
更关键的是，这种压缩不是简单的“少说话”，而是一种对信息密度的重新分配。项目 README 里专门强调，代码块仍然正常写，技术术语保持精确，报错信息原样引用，Git commit 和 PR 文案也不强行“原始人化”。换句话说，它削掉的是语言里的泡沫，而不是知识本身。这也是为什么作者敢把“75% token reduction”和“full technical accuracy”放在一起讲。
如果这个逻辑成立，它带来的好处不只是一点点输出费用的下降。输出更短，生成更快，交互节奏会明显变化。开发者在一轮轮问答中等待的时间减少了，上下文被冗词挤占的比例降低了，真正用于代码、日志和设计信息的空间反而增加了。对重度用户来说，这种提升比“便宜了几分钱”更重要，因为它直接作用在工作流的摩擦系数上。
这件事为什么偏偏在今天显得重要
如果把时间拨回两年前，caveman 大概只会被当成一个 prompt engineering 段子收藏。可放在 2025 年的 AI 开发工具环境里，它变得比看上去严肃得多。
一个背景是，编程助手已经从“写几行补全”进化到了“长期协作代理”。Claude Code、GitHub Copilot、Cursor、Aider 这一类工具，越来越多地承担起阅读仓库、修改文件、解释错误、执行命令、生成提交信息的任务。模型不再只吐一小段代码，而是在一个复杂软件项目里来回穿梭。结果就是，token 消耗被放大了。一次看似普通的调试会话，实际可能吞掉海量上下文。
另一个背景是，大模型行业这些年一直在追求更大上下文、更强推理、更完整的工具调用能力，但对“表达是否足够经济”关注不够。厂商更乐于宣传模型能看 100 万 token，却不太会告诉你，里面有多少 token 是“当然可以，我来帮你看看”。这就像我们造出了更大的仓库，却没有认真讨论过仓库里是不是堆满了包装泡沫。
从这个角度看，caveman 有点像一次来自社区的反讽：你们都在卷模型规模、卷推理链、卷代理能力，我先卷一下废话率。它不一定是最终答案，但它提醒了所有做 AI 产品的人——高质量回答，不等于长回答；自然语言的“拟人化”，也不天然等于效率。
事实上，类似思路并不是第一次出现。过去就有不少用户会在系统提示词里加入“be concise”“no fluff”“answer in bullets”等要求，甚至有人专门训练“极简回复风格”的工作流模板。caveman 的不同之处在于，它把这种民间经验打包成了一个可安装、可触发、带明确人格设定的插件。一个原本零散的技巧，被做成了产品化的小工具，传播速度自然快得多。
有趣归有趣，但“少说”也有边界
我喜欢这个项目的幽默感，也认同它对低效语言的精准吐槽，但如果把它神化成“AI 交互终极方案”，那也有点过头了。
问题的第一层，是语气压缩和认知压缩不是一回事。很多时候，模型输出冗长，并不只是因为礼貌，而是因为它在用重复解释来掩盖不确定性。你把“我建议你考虑”删掉，不代表答案就真的更对。有些复杂问题——例如架构设计、数据库迁移、权限系统、安全边界——本来就需要上下文、前提和风险说明。过度追求短句，可能会把关键的 caveat 一起砍掉。
第二层是，开发者并不是唯一用户。工程团队内部也有不同角色：资深程序员希望直奔结论，新手可能反而需要更多讲解；凌晨两点排障时，你想要的是“哪一行有问题”，但做方案评审时，你又需要模型把利弊掰开揉碎。也就是说，简洁是一种场景偏好，不是普适真理。真正成熟的 AI 产品，恐怕不是永远像 caveman 一样说话，而是能理解什么时候该短、什么时候该展开。
还有一个更值得琢磨的问题：如果“压缩表达”真的能显著节省成本，平台会不会把这件事更系统地做起来？比如默认区分“调试模式”“教学模式”“审阅模式”，不同模式控制不同信息密度；再比如让输出 token 预算可视化，告诉用户这次回答花了多少、哪些部分是冗余。和这些产品级设计相比，caveman 还只是一个轻巧的民间补丁。但很多行业趋势，恰恰就是从这种半开玩笑的补丁开始的。
一块石头，敲出了 AI 产品设计的新问题
我很喜欢 README 里那句带点中二气质的话：Same fix. 75% less word. Brain still big. 这句话其实把大模型时代的一个尴尬真相说透了：AI 已经足够聪明，接下来用户在意的，不只是它“会不会”，而是它“怎么说”“说多少”“值不值这个价”。
过去几年，AI 产品竞争的主旋律是能力上限。谁写得更像人，谁回答得更完整，谁上下文更长，谁工具调用更强。现在，另一个维度开始抬头了：效率美学。一个真正好用的模型，不该只是知识渊博，还要懂得克制。尤其在代码场景中，表达的克制几乎是一种工程美德。
这也是我觉得 caveman 值得被报道的原因。它当然不是一项底层突破，没有新模型、没有新架构、没有融资新闻，甚至连功能本身都简单得有点恶作剧。但它像一面镜子，照出了 AI 行业常被忽略的一件事：我们一边高喊智能代理时代来了，一边却默许这些代理每天浪费大量 token 去说客套话。技术越强，浪费越贵；模型越大，啰嗦越不该成为默认设置。
也许接下来会有更多类似工具出现：有的追求极简，有的专为代码审查压缩语言，有的干脆按成本实时调节回答风格。等这股潮流真正成熟之后，我们回头看，caveman 可能会像一个很小、但很典型的信号——AI 产品开始从“更像人”走向“更像工具”。这未必性感，却很可能更重要。
说到底，程序员未必真的想和一个彬彬有礼的聊天机器人一起写代码。很多时候，他们只想要一句准话：哪错了，怎么改，别绕弯子。原始人也许不会写 React，但他显然懂一个现代互联网商业逻辑：少说废话，省钱。