Caveman 爆红背后，是 token 经济学开始浮出水面

今天 HN 上另一个很有意思的项目叫 Caveman。表面看，它像个标准的互联网玩笑：让 Claude Code 或 Codex 用"穴居人说话方式"回答问题，少说废话、保留术语、极限压缩输出，据说能省掉大量 token。光看名字，很容易把它当成一个梗项目。但它能迅速引起这么多开发者共鸣，原因其实不只是好笑，而是它碰到了一个正在变得越来越现实的问题：在 AI coding 时代，token 已经不只是账单单位，而是产品体验本身。

以前大家谈 token，主要想到的是 API 成本。多生成一点，贵一点；少生成一点，省一点。可一旦你开始高频使用 coding agent，就会发现 token 牵扯的远不只是价格。它还决定响应速度，决定同一上下文窗口里还能塞多少内容，决定你读一段回答要花多久，也决定 agent 能不能在长会话里持续保持清醒。也就是说，token 不是后台财务指标，它已经变成一种前台交互资源了。

Caveman 的流行，说明越来越多人开始意识到这个变化。很多 AI 回答的问题，从来不是信息不够，而是包装太厚。用户要的是"哪一行错了""为什么会重渲染""修复方案是什么"，结果模型先来一大段礼貌铺垫，再加一层重复解释，最后才进入正题。单次看还好，一旦进入 agent 工作流，这些冗余会快速累积，变成真实的摩擦。它们占用 token，占用上下文，也占用你的注意力。

所以 Caveman 这个项目虽然用的是玩笑形式，背后却有一个很严肃的信号：大家开始把"输出压缩"当成正式能力，而不是文风偏好。过去我们总觉得模型越会说越好，越完整越专业。但在很多开发场景里，真正有价值的不是"更像一个尽责客服"，而是"更像一个高质量同事"。高质量同事不会每次都先说"很高兴帮你"，也不会把你已经知道的前提再复述一遍。他会直接说重点，并且在该精确的地方足够精确。

这件事再往下看，会发现它其实和 prompt engineering 的下一阶段有关。前几年大家主要研究怎么把需求说清楚，好让模型理解。接下来越来越重要的，可能是怎么约束模型的表达密度、信息颗粒度和输出体积。换句话说，我们不只是在优化"模型回答什么"，也在优化"模型回答时浪费多少带宽"。带宽这个词在这里很贴切，因为 token 说到底就是认知带宽、系统带宽和预算带宽的共同单位。

这也是为什么我觉得 Caveman 值得记下来。它不一定会以现在这个形态长期存在，但它代表的思路会留下来。未来的 agent 产品大概率都会更认真地处理几件事：哪些场景需要极简回答，哪些场景需要层级化展开，哪些信息该默认省略，哪些信息该按需展开，以及如何在不损失正确性的前提下，让模型少说但更有用。今天 Caveman 只是把这件事做得很显眼，也做得很像一个 meme。

对开发者来说，这里面有几个很实际的启发。第一，如果你日常高频使用 AI coding 工具，应该开始像管理缓存和带宽一样管理 token，不只是为了省钱，更是为了减少上下文污染。第二，团队在设计内部 agent 时，不妨把"输出风格压缩"单独当成一个产品层问题，而不是交给模型自由发挥。第三，好的 AI 体验未必来自更长回答，反而常常来自更短但更结构化的回答。很多时候，用户不是想看模型展示自己懂很多，而是想尽快拿到能继续推进工作的最小必要信息。

还有一个更有意思的地方。Caveman 的 README 里提到，压缩输出主要影响的是回答 token，而不是思考 token。这个区分很关键。很多人会下意识认为"少说一点"会不会也让模型"少想一点"。但在不少场景里，真正浪费的恰恰不是思考，而是表达。模型可以在内部做足够复杂的推理，然后用更克制的方式把结果吐出来。对于 coding assistant 来说，这几乎就是理想状态：脑子可以大，嘴可以短。

如果把这件事放到更大的行业背景里看，它其实也说明了 AI 工具正在从"能力展示期"走向"效率优化期"。能力展示期的产品喜欢让你惊叹，最好每次回答都像一篇完整的小作文；效率优化期的产品则开始追求另一种成熟：不要废话，不要拖长，不要把真正重要的信息埋进一大段看似周到的措辞里。前者适合演示，后者才适合长期工作。

所以，Caveman 爆红看似只是一个好玩的插件，其实背后是一种越来越清晰的共识：agent 时代的竞争，不只是模型会不会做事，还包括它会不会克制地说话。谁更会管理 token，谁就更有可能做出真正顺手的 AI 工具。

嗯，为什么要用很多 token。现在越来越多开发者开始认真问这个问题了。