今年以来越来越明显地感觉到大模型 Token 账单涨得真快 — 特别是 AI 编程的重度用户。过去很多工具还有“管饱套餐”比如按调用次数计价。但现在转向按量计费重度使用时原来够用的额度很快就会见底尤其是在大型开发任务中。本文试图从工程角度来总结有哪些常见的方法与策略可以帮助降低不必要的 Token 消耗让你的账单不再失控。这些方法包括上下文清场把聊天记录变成工程交接代码导航不让模型在代码中迷路复杂任务先 Plan一轮计划换掉三轮返工工具分流不让所有 Agent 背同一个工具箱输入噪声治理测试/CI日志自动过滤Prompt Cache与知识沉淀让重复内容可复用模型分层杀鸡不要总用宰牛刀上下文按需加载只加载当前需要的输出精简管住模型的表达欲善用开源 Token 压缩工具01 AI Coding 的 Token 为什么越来越贵AI Agent 正在从少数人的尝鲜工具变成日常工具。特别是像“龙虾”这类 Agent 火爆后重度使用者越来越多模型厂商依靠轻度用户来平衡重度用户的模式越来越难持续改变计价策略也是必然。但更重要的是随着模型与 Agent 能力的不断增强在大型的研发项目中每次任务的复杂度与 Token 总量也在不断膨胀。过去你可能只是让 AI 改一个函数、解释一段代码现在你会让它读仓库、找文档、理解架构、调用工具、分析日志、测试并修 Bug连续工作几小时来完成一个完整需求。于是Token 消耗不再只是你输入的那几句话和看到的最终代码而是包括代码仓库上下文、工具与 Skills 定义、搜索结果、日志输出、测试信息、历史对话以及 Agent 多轮循环中不断追加的中间过程。对于行业项目还有一层更重的成本领域知识上下文。业务规则、数据模型、接口契约、存量代码 — 这些内容模型无法自身推断必须显式提供。而一旦提供不当还会导致模型反复犯错或频繁返工。这里真正贵的地方是让模型一遍遍理解项目、定位问题、读取文档、分析失败、重新尝试等 — 上下文快速膨胀。这种情况下省 Token 就不能只靠少说几句话没准会烧更多而要从上下文加载、工具调用、压缩、重试策略等多方面做结构性治理。02十个省 Token 的工程方法首先强调所谓省 Token 方法不要被当成教条。任何方法都可能有它们失效甚至反噬Token 不降反升的场景。01 上下文清场把聊天记录变成工程交接基本思想简单说就是不要让模型背着整段历史聊天继续工作。很多会话都是被过去的任务拖慢先讨论修改了权限模块接着看缓存问题中间再贴几段日志分析最后再让它提交代码。对人来说前面的会话内容早已无关但对模型来说只要还在会话上下文里就会持续消耗 Token。怎么做完成一个阶段把仍然有效的信息如果有的话生成一段“工程交接摘要”目标、结论、已确认文件、已排除方向、仍然有效的失败证据、下一步建议等。不要保留早已结束的讨论过程。一些场景也可以借助一些自动化的 Memory 产品参考深度体验 AgentMemory给企业 AI Coding 装上共享工程记忆层。比如你先花了很多轮讨论了半天的设计方案否定了很多 AI 的建议最终达成了一致。此时前面大量的讨论已经没有参考价值。更好的做法是方案确认后生成落盘的决策带着它进入新会话。适用边界同一任务连续小步推进盲目清理会破坏 Prompt Cache 命中、触发重复错误。清理的对象应是无关历史不是可缓存的稳定前缀和重要状态。02 代码导航不让模型在代码中迷路基本思想想象下我们接手一个陌生项目无论是代码修复还是故障排除也不会从第一行读到最后一行代码而是会先看目录、README再或者错误日志、入口程序再判断该打开哪些文件。AI 也应该这样。企业应用系统的代码库往往模块众多、存量代码厚重Agent 盲目搜索的代价更高。解决关键是三件事配合排除噪声文件、建立代码地图、人在关键时刻直接指路。怎么做常见的方法有排除规则。用.cursorignore/.copilotignore排除规则文件过滤掉诸如node_modules、dist、大型数据文件等防止无关文件进入上下文。建代码地图。推荐使用 GitNexus/Graphify/Understand-anything 等工具创建代码关系图谱。不仅可以省 Token还可以用来提高代码质量。人工指路。当你知道问题在哪里直接用file或folder告诉 Agent省掉整个搜索链路帮助 Agent 跳过不必要的工具调用和尝试。适用边界小代码仓库构建“地图”可能反而造成额外开销不如直接读代码。排除规则也不要太过激进防止 Agent 找不到关键信息。03 复杂任务先 Plan用一轮计划换掉三轮返工基本思想复杂 Coding 任务最容易产生 token 浪费的不是要写很长的代码而是返工。对于简单的任务模型一次出成品的概率更高即使返工代价也很小。但是如果在复杂的编码任务中如果从一开始模型就走入“歧路”会在后续的步骤中不断叠加错误等到人类审核时要求全部返工的概率极大。所以在开始任务之前先和模型“讨论”确定好计划校准好方向、路线和规则确认无误后再实施。怎么做下面几种形式都属于先 Plan 再实施直接通过 Prompt 规划。比如你可以要求 Agent 不要动代码先列出修改计划、影响面、风险甚至测试计划等直到你审核通过。Plan Mode。很多 Coding Agent 都有 Plan 模式这是最简单的方式。SDD规范驱动开发。对于大型项目的开发任务SDD 是一种把复杂任务拆成多个可审核的步骤、并逐步推进的方法可以极大的提高项目可控性降低返工的概率。对于行业项目Plan 的价值尤其大 — 因为约束更多现有 API 契约不能破坏、数据库字段不能随意改等等而模型对这些隐性约束的感知天然不足。Plan 阶段正是暴露这些盲区的最佳时机。适用边界小任务里 Plan 是纯开销。模型一次成功率提高Plan 的边际收益就下降了。04 工具分流不让所有 Agent 背同一个工具箱基本思想工具不是越多越好最好是当前阶段需要什么就接入什么就像修东西你也不会把整间工具箱都倒在桌上。Agent 也是一样。如果你的工具特别多那么不要把所有工具一股脑的塞给Agent而是根据任务类型为它准备刚好够用的工具环境。怎么做为不同任务配备不同的工具集这在不同的开发环境中会有差异。以 Copilot 为例一种是项目级 MCP 配置。不要把所有的工具都配置在用户级范围内而是在项目级配置 MCP Server让 Copilot 在处理该项目任务时访问外部工具和数据源。这适合放一些本项目需要的工具而非全局工具。第二种是自定义 Agent。Copilot 支持 Custom Agents为不同任务创建专门的 Copilot 版本。比如一个 Agent 专门处理前端问题一个 Agent 专门处理后端 Bug一个专门做代码评审而每个 Agent 可以配备不同的工具集这就很适合做“工具集分流”。适用边界工具定义会放在 Prompt 里而稳定的 Prompt 前缀有利于 Prompt Cache。如果每轮都增删反而会破坏缓存命中一些常用轻工具应该稳定保留。05 输入噪声治理测试/CI日志过滤基本思想进入模型的无效输入越多浪费的 Token 越多。AI Coding 中两种常见的噪声源是未过滤的日志/测试输出和过于宽泛的测试命令。一种好的方式是先过滤再把关键线索与证据交给模型。怎么做日志过滤。只把失败用例名、错误类型、断言信息、关键调用栈和相关文件路径给模型比如用grep、正则或脚本把原始输出压缩成错误摘要而完整的日志则落盘备查。在 Cursor 等工具中可以利用 Hook 机制把日志过滤自动化。测试命令收窄。Agent 测试是喜欢用pytest或npm test这类全量命令。必要时可以改成pytest -k test_xxx只跑相关用例。适用边界这是几乎不会“反噬”的方法。唯一风险是过滤太狠把真正线索删掉。另外测试也不能收窄到只跑修改点 — 必要的回归测试不能省。06 Prompt Cache与知识沉淀让重复内容可复用很多人在看模型使用的账单时常常会看到命中 Cache 的 Token 消耗这里的 Cache 就是Prompt Cache。Prompt Cache 强调“稳定前缀”是因为模型会从左到右顺序处理上下文。某一段文本的中间状态不仅取决于它自身还取决于它前面的内容。只有前缀完全一致时模型读完这段前缀后的状态才能复用Cache。基本思想在 AI Coding 里系统提示词AGENTS.md等、基本规则、仓库结构、可用工具与Skill、编码规范等内容通常会在一个项目的多个任务中反复出现。这些内容如果每次都以相同顺序出现在上下文前部就更容易命中 Prompt Cache。不过在 Cursor、Claude Code 这类开发工具里很多系统提示是自动注入的用户并不能精确控制完整 Prompt 的拼接顺序。所以更现实的做法不是“控制整个 Prompt ”而是让自己能控制的项目上下文尽量稳定。怎么做每个任务的上下文可以分成两类稳定项目上下文放进固定文件或配置。如全局规则Rules、全局上下文术语、架构、Skill 定义重复使用的流程与约束等。这类内容要尽量保持稳定不要频繁修改。动态任务上下文放在每次对话中。如当前问题、任务目标、错误信息、临时约束等。另外高频使用的流程与领域知识用 Skill 固化领域知识沉淀为上下文文档。这些内容天然利于缓存命中。对于行业项目领域知识往往也是最值得沉淀的 — 它们变化慢、复用率高每次重新解释是最大的浪费。适用边界不要指望把大量规范全塞进前缀指望永远 Cache — 每次任务都带上不相关内容反而适得其反。07 模型分层杀鸡不要总用宰牛刀基本思想AI Coding 里很多活并不需要用最强模型。如果你让最强模型来干日志整理、文件摘要、归类等任务就像让架构师去写代码不划算 — 无形之中就浪费了 Token。模型分层不是简单的“尽量用最便宜的模型”而是让不同难度的任务走不同模型以达到性价比的最大化。怎么做模型分层使用的核心是任务分层。比如我们可以把 AI Coding 中的任务粗略分成三层。第一层是低认知负载。比如文档总结、日志压缩、文件摘要、函数签名提取等。这类任务难度小且结果容易检查适合交给小模型或本地 Ollama 模型。第二层是常规实现任务。比如普通 Bug 修复、单测补齐、局部重构、简单接口适配。这类任务需要一定代码理解能力但风险可控可以交给中档模型。第三层是高价值与高复杂度任务。大型系统的架构设计、跨模块的系统改造、百万行以上的代码库分析与精确修改、关键 Review。这类任务一旦判断错后续返工成本与风险很高应该交给最强的模型。在主流开发工具中你可以通过切换模型完成分层Claude Code 也可以在 Subagent 中指定不同模型。适用边界低价模型最重要的使用原则是风险小、且容易检查或验证。如果前置任务虽然难度不大但做错会把后续工作全部带偏就不该冒险。08 上下文按需加载只加载当前需要的企业级 AI Coding 最大的问题之一是上下文太多特别是领域与工程知识。一个真实系统里不只有几条 rules还会有系统架构、编码规范、API 规约、数据库约束、业务知识、历史决策、测试说明、部署规则等。如果每次任务都把这些内容全部塞给模型Token 会涨得很快模型也更容易被无关信息干扰。基本思想一次任务真正需要的上下文通常是有限的。比如做数据库迁移不一定需要前端规范开发后端服务不需要知道 UI 设计规范做功能设计也不一定需要读取编码规范。所以更好的方式不是把所有工程知识塞给模型而是建立一套分层加载策略什么内容永远加载什么内容按阶段加载什么内容只在需要时加载。怎么做可以借鉴 LLM Wiki 的思路用 LLM 帮助整理领域知识、生成结构、建立索引和加载指南。索引告诉模型“有哪些知识、在什么位置”加载指南告诉模型“什么阶段、什么任务、什么模块应该读哪些内容”。比如设计阶段优要优先读业务规则、架构边界和接口契约编码阶段要读编码规范数据库变更必须读数据模型等前端开发要读取 UI 组件规范等。核心就是一句话先读索引再按需加载不要每次翻整个知识库。适用边界按需加载的分层上下文会带来额外的维护成本。所以小项目没必要搞得太复杂一份简短清晰的规则文件往往就够了。09 输出精简管住模型的表达欲基本思想很多人只关注输入了多少 Token却忽略了输出 Token 通常比输入 Token 贵 3-5 倍。现在的模型特别是推理模型往往有很强的表达欲重新输出整个文件而不是只替换几行、大段解释、冗余注释、过度设计的代码等。过度的输出不仅费钱还会在多轮对话中作为历史被反复送入模型。所以控制输出的格式、规则甚至预算是一种好的习惯。怎么做控制输出的确要比控制输入困难但还是可以借助一些指令和约束。比如在 Prompt 中明确输出要求与约束。比如只输出修改的函数不要输出整个文件、不需要解释直接给代码、用 diff 格式输出变更等或者在规则中比如 Cursor 的 Rules 加入要求精简结果的约束。控制 Thinking Token。部分推理模型如 Claude 的 extended thinking的思考过程也消耗 Token。最好通过budget_tokens限制思考预算或直接不使用 extended thinking 。输出模板。把常见任务的输出格式固定下来比如代码 Review 只输出“风险点 建议修改”等限制模型的自我发挥空间。适用边界对于复杂项目的架构讨论、设计评审等场景模型的详细解释和推理本身就是价值所在。没有必要为了省几个输出 Token 而牺牲输出质量 — 毕竟一次返工就会让你前功尽弃。精简输出只适合明确、重复、结果导向的一些编码任务。10 善用开源 Token 压缩工具基本思想最后一个方法是直接借用一些开源的工具来实现智能过滤和压缩减少 Token 消耗。怎么做一些知名的 Token 压缩的工具有命令输出智能过滤与压缩如 RTK。根据命令类型测试、构建等对其输出自动过滤与压缩仅保留关键信息和上下文去掉无用的噪声信息。仓库结构化摘要如 Repomix。把代码仓库“打包”成 AI 友好的输入用目录、文件路径、函数/类签名替代完整实现体。适用边界压缩永远是用质量换省 Token的交易。如果压缩太狠很容易丢失重要的线索让模型误解意图从而推理出完全错误的结果。所以合适的策略是先明确自己的痛点再判断是否需要这些工具并承担可能的风险代价。03 总结除了这里的方法你可能还听过一些思路比如使用 Subagent 独立处理边界清晰、长输入、短结论的子任务给主 Agent 减负使用 PTC程序化工具调用减少 MCP 工具结果的往复设置重试熔断机制等等。不过这些方法有的难把控比如 Subagent 更多时候会增加 Token 消耗有的则依赖特定模型或SDK比如 PTC这里不再展开。如果你正被巨额 AI Coding 账单困扰不妨从最简单、且效果显著的一些方法开始补代码地图、稳定 Prompt 前缀、模型分层使用等。对于领域知识厚重的行业项目最值得长期投入的是知识沉淀和按需加载 — 把业务规则、术语、架构决策变成结构化的按需稳定供给既减少盲目的“灌输”上下文也有利于稳定的 Prompt Cache。总之在企业级的 AI Coding 项目中Token 成本的控制不是简单的 Prompt 技巧更依赖于系统工程的治理。