我为了研究如何节省 token，把所有 token 都烧光了
降低大语言模型（LLM）成本的努力揭示了一个尴尬的权衡：许多“节省 token”的技巧会增加复杂度、破坏上下文缓存，或者只是把浪费转移到别处，而不是消除浪费。评论者比较了多模型流水线、固定与动态提示、本地与云端部署等策略；一些人认为，除非隐私或规模足以证明硬件投入合理，否则云 API 仍然比大多数本地方案更便宜且更强大。更深层的技术细节之下，是关于 LLM 辅助代码和产品究竟是否真正有价值，还是大多只是无法交付的“slop”的更大张力，以及如何超越轶事式说法来衡量真实生产力提升。
节省 token 的策略与研究工作流
- 许多人描述了与文章类似的经历：LLM 并不是“无知”，而是缺乏纪律，会在反复走进死胡同时消耗 token。目标变成了减少重复的死胡同，而不是探索本身。
- 建议的流程是：先用更便宜/更小的模型进行假设生成和广泛探索，然后把提炼后的结果交给更强的模型。并行的低成本假设往往能胜过一次昂贵调用。
- 当延迟可接受时，批量计价和“过夜”任务被提议用来降低成本。
- 有人建议在早期阶段混用多个供应商的模型以获得多样性。
上下文、缓存与提示设计
- 几位用户表示，巧妙的节省 token 技巧常常会破坏上下文前缀缓存，反而让整体成本更高。
- 固定、稍大一些的前缀，加上偶尔的总结，可能比动态检索和剪枝方案更有效。
- 让模型自己管理压缩（例如通过编辑器集成）对一些人来说效果出奇地好；通常只需让上下文自然填充，然后再总结即可。
- 还讨论了按难度进行自适应模型路由；问题包括切换模型时需要重放整个历史，以及不同模型之间注意力缓存不兼容。
本地模型 vs 云模型与经济性
- 一个强烈观点是：对大多数人来说，除非你已经拥有大量硬件或有严格的隐私需求，否则云模型比本地模型更便宜也更好。
- 也有人认为，对于重度用户很多的组织、已经拥有计算资源的组织，或者作为对供应商锁定和规则变化的对冲，本地模型是有意义的。
- 有人提出“90% 本地 / 10% 前沿模型”的模式，但指出判断何时切换并不简单。
工具、代理与避免重复劳动
- 提到了各种工具：记忆/缓存 MCP、skills 文件，以及会根据过往聊天周期性更新“规则/skills”的工作流，以阻止反复做同样的步骤。
- 有人担心，许多代理和产品仍在反复解决同样的问题；因此提出为代理共享知识库，让可复用的解决方案逐步收敛。
交付、“slop” 与现实价值
- 围绕 AI 辅助项目究竟是否真正有用，还是只是“slop”，展开了激烈争论。
- 有些人表示，借助 LLM 他们更快地交付了内部工具、迁移、游戏和硬件。
- 也有人质疑：对于用户现在也能自己构建的东西，交付出来的价值何在，并批评那些文档由机器人撰写的 AI 项目。
- 对“已交付”的定义（付费用户 vs 个人工具 vs OSS）也存在争议。
幻觉与可靠性
- 有人怀疑幻觉不可能通过规则或流程被消除；他们认为这是当前模型的内在特性。
- “没有幻觉”的说法也被质疑为过度夸大。