今年以来，越来越明显地感觉到，大模型 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 技巧，更依赖于系统工程的治理。