最近在几个技术群里看到有人分享一个叫“caveman”的Claude Code技能号称能节省65%的token。第一反应是这不就是当年电报体、火星文的AI版吗但仔细一想这种“省token技能”背后其实反映了一个更本质的问题我们到底是在优化AI的使用效率还是在用技术手段掩盖工具本身的缺陷1. 为什么“省token技能”会突然流行起来如果你用过Claude Code、Cursor这类AI编程助手肯定遇到过这种情况你问一个简单问题AI却给你写了一段小作文。代码只有三行解释却用了三百字。这种“过度解释”现象在当前的AI助手中很常见。原因很简单大语言模型在训练时被灌输了大量的人类对话模式而人类在解释技术问题时往往倾向于详细说明。caveman这类技能的核心思路很直接让AI说话像原始人一样简洁。去掉所有修饰词、礼貌用语和重复解释只保留核心信息。从技术实现上看它本质上是一个精心设计的提示词工程。但这里有个关键问题被忽略了token节省真的是我们最应该关心的指标吗在实际使用中我发现这种极端简洁的表达方式带来了新的认知负担。当你看到“New ref/render. useMemo it.”这样的回复时确实节省了token但理解成本却增加了。特别是对新手开发者来说这种电报体回复可能比原来的长篇大论更难懂。2. token节省的真相数字游戏还是真实价值让我们看看caveman官方提供的基准测试数据任务正常回复(token)Caveman回复(token)节省比例解释React重渲染bug118015987%修复认证中间件70412183%设置PostgreSQL连接池234738084%表面上看节省惊人但这些数字背后有几个需要警惕的地方2.1 输入token的成本被忽略了caveman技能本身需要约1-1.5k的输入token来加载。这意味着如果你的对话回合数较少实际净节省可能很小甚至为负。更重要的是这种技能改变了AI的思考过程。原本AI可能会通过详细推理来确保答案正确现在却被迫直接输出结论。这在简单问题上没问题但在复杂场景下可能影响答案质量。2.2 可读性与效率的权衡在实际编程协作中代码的可读性往往比简洁性更重要。同样的逻辑也适用于AI助手的回复。考虑这个例子正常回复“这个重渲染问题是因为每次渲染都创建了新的对象引用。React的浅比较会认为这是不同的prop从而触发重渲染。建议使用useMemo来缓存这个对象。”Caveman回复“New ref each render. useMemo it.”前者虽然用了更多token但解释了问题的根源和解决方案的原理。后者虽然简洁但假设你已经理解了React的重渲染机制。2.3 不同经验水平的需求差异对于资深开发者来说可能确实只需要关键提示。但对于学习阶段开发者详细的解释更有价值。这里就引出了一个更深层的问题我们使用AI编程助手的目标是什么如果只是为了快速解决问题那么简洁回复确实更高效。但如果是为了学习和理解那么详细的解释可能更有价值。3. 电报体技能的局限性为什么这只是阶段性方案从技术演进的角度看我认为这种“省token技能”只是一个过渡性方案。原因如下3.1 治标不治本当前AI助手“话多”的根本原因是模型在不确定性下的保守策略。模型倾向于提供更多信息来降低误解风险。真正的解决方案应该是让AI更好地理解用户的意图和知识水平从而提供恰到好处的回答。这需要模型能力的提升而不是外部的文本压缩。3.2 交互效率的假象在真实的编程工作流中我们与AI的交互往往是多回合的。如果第一轮回复过于简洁很可能需要后续的追问和澄清反而增加了总体的交互成本。相比之下一个适度详细的首次回复可能一次性解决所有问题总体效率更高。3.3 忽略了AI作为学习工具的价值对于很多开发者来说AI编程助手不仅是生产力工具也是学习工具。通过阅读AI的详细解释我们可以学习到新的编程模式、最佳实践和问题排查思路。如果为了节省token而牺牲了教育价值可能是一种短视的优化。4. 更可持续的AI使用策略基于以上的分析我认为相比追求极致的token节省以下策略可能更有长期价值4.1 根据场景选择详细程度聪明的做法不是一味地追求简洁或详细而是根据具体场景动态调整快速调试需要简洁直接的答案学习新概念需要详细的解释和示例代码审查需要平衡指出问题和解释原因架构设计需要全面的考虑和权衡分析一些AI工具已经开始提供“详细模式/简洁模式”的切换这比固定的电报体更实用。4.2 优化提问技巧很多时候AI回复冗长的原因是我们提问不够精准。通过改进提问方式可以自然获得更合适的回复低效提问我的React组件为什么一直在重渲染高效提问用一句话解释为什么内联对象prop会导致React组件重渲染给出最简洁的解决方案。4.3 关注整体工作流效率token成本只是AI编程助手总成本的一部分。更重要的是考虑整个工作流的效率答案准确性错误答案的成本远高于token成本学习曲线工具是否容易上手和使用集成度与现有开发环境的配合程度可靠性在不同场景下的稳定表现5. 从工具使用到心智模式的转变更深一层看我们对“省token技能”的热情反映了一种有趣的心智模式我们总是倾向于优化可量化的指标即使这些指标不能完全代表真实价值。在软件开发中我们见过很多类似的现象过度追求代码行数减少却忽略了可维护性过度优化算法时间复杂度却忽略了实际数据规模过度关注测试覆盖率数字却忽略了测试用例的质量真正的工程智慧在于知道什么时候优化什么时候不优化。对于AI编程助手的使用我认为我们应该更多关注这个工具是否帮助我更好地理解了问题这个交互过程是否提升了我的编程能力长期使用是否会形成良性的学习循环6. 实践建议如何理性看待token优化如果你确实关心token使用效率我建议采取以下更平衡的方法6.1 先验证后优化不要一上来就启用各种省token技能。先正常使用一段时间了解自己的典型使用模式记录你最常见的任务类型分析哪些场景确实存在回复冗长问题评估token成本在你的总成本中的占比6.2 选择性使用压缩技能对于确认存在冗长问题的特定场景可以针对性使用压缩技能。比如日常的代码片段生成简单的API使用查询熟悉的编程模式确认但对于学习新概念、复杂调试等场景保持详细回复可能更有利。6.3 建立自己的效率评估框架不要只看token数字建立多维度的效率评估# AI助手效率评估维度 - **答案质量**解决方案是否正确、完整 - **理解成本**需要多少时间理解AI的回复 - **学习价值**是否学到了新的知识或方法 - **交互效率**总共需要多少轮对话才能解决问题 - **经济成本**token、时间、注意力的总成本6.4 关注工具的自然演进主流AI工具都在不断改进他们的回复策略。Anthropic、OpenAI等公司都在研究如何让AI更好地适应用户需求。很多时候等待工具的自然改进比使用第三方压缩技能更可持续。7. 结语超越数字游戏caveman这类省token技能确实体现了社区对AI使用效率的关注这种创新精神值得肯定。但从长远来看我认为这更像是一个阶段性产物。随着AI模型能力的提升和交互设计的改进我们很可能不再需要这种外部的文本压缩技巧。AI会自然地理解什么时候需要详细解释什么时候可以简洁回复。在这个过程中作为使用者我们更需要培养的是判断力知道在什么情况下追求极致优化是有意义的什么情况下应该关注更本质的价值。毕竟最好的工具使用策略不是追求某个数字的最优化而是让工具真正服务于我们的学习和创造过程。