Kulaxyz/token-diet

token-diet 是一个为 Claude Code、Cursor 等主流编程 AI 代理设计的常驻优化脚本。它像一个后台管家，自动修剪 AI 在编程对话中产生的冗余信息，从而显著降低 API 调用成本，同时承诺不损失代码的正确性。任何频繁使用这些 AI 编程工具的开发者都可能成为它的用户。

今天，一个开发者在使用 Cursor 或 Claude Code 进行项目开发时，工作流通常是线性的：提出需求，AI 生成代码、解释、测试和文档，开发者再审查和迭代。这个过程会产生大量上下文，包括 AI 礼貌性的开场白、冗长的解释、重复的代码片段以及并非每次都需要完整读取的文件内容。开发者手动处理这些冗余的方式非常有限，要么忍受高昂的 token 成本，要么在每次对话中不厌其烦地要求 AI“说得简洁点”，但这又会打断工作流，且效果不稳定。

真正的卡点在于，开发者无法精细控制 AI 输出的“信息密度”。他们支付 token 费用，购买的应该是解决问题的核心代码和关键逻辑，而不是 AI 的“语言风格”和“叙事习惯”。例如，AI 回复中“Great question! The reason is...”这样的固定句式，或者为了展示思考过程而重复的代码块，都在消耗预算却不增加价值。开发者自己写脚本去后处理这些输出不仅麻烦，更难以在 AI 每次交互时实时、智能地生效。

token-diet 切入的正是 **上下文管理层**。它没有创造新的 AI 能力，也没有改变模型本身，而是聚焦于管理 AI 与开发者之间信息传递的“带宽”和“格式”。它通过一套预设规则（如精简回复措辞、按需读取文件、合并工具调用、限制非关键测试数量等），在 AI 代理的输出生成后、计入上下文前进行过滤和优化，直接减少了流入付费上下文的 token 数量。

旧方案就是开发者自己承担全部成本，或者进行低效的手动干预。随着 Claude Code、Cursor、Windsurf 等基于大模型的编程代理成为开发者日常工具，使用频率从“偶尔问询”转向“持续结对编程”，token 消耗从可忽略的测试成本变成了每月固定的、可观的运营开支。此时，单纯“换一个更便宜的模型”可能牺牲代码质量，而“手动要求简洁”则破坏了流畅的协作体验。成本变得具体且持续，优化需求就从“可有可无”变成了“值得专门解决”。

这个项目能在一天内获得大量关注，透露出一个明确变化：**AI 编程工具正从“尝鲜阶段”进入“生产运营阶段”**。当开发者开始长期、高频地将 AI 代理集成到核心工作流中，像管理云服务账单一样管理 AI 使用成本就成为了刚需。优化对象从单次提示（Prompt Engineering）转向了整个会话生命周期（Session Lifecycle）的效率。

对于 Builder 而言，今天可以直接通过一行命令安装 token-diet，让它作为后台服务运行，对支持的 AI 代理实现无感优化。它最值得学习的设计在于其“常驻”与“规则化”的思路：不是让用户每次去“命令”AI，而是将优化策略沉淀为一套自动执行的、可配置的守则，无缝嵌入现有工具链。这种在现有交互界面之下，通过“中间件”形式优化资源消耗的模式，可以迁移到任何资源受限的持续交互场景中，例如优化持续运行的 AI 客服对话的上下文，或是管理多步自动化工作流中每一步的输入输出数据量。