Token 预算日益紧张，怎么把每一分都花在刀刃上

1. 额度为何下降这么快？原因是大模型每次都要“重读”

使用 WorkBuddy 或公司内部的 AI 工作台时，你也许有过这样的疑惑：只是问了几个问题，额度为何已经见底？

大模型 API 实际上没有记忆，也就是无状态。它能延续对话，是因为客户端每次都会打包先前的聊天记录，再连同新问题一起发送。

因此，费用并非匀速增长，而会像滚雪球般不断扩大。第一轮发送 2k token，到第五轮时历史记录可能累计至 20k，第十轮则可能达到 60k。此后哪怕只是随口问几个字，也要为这 60k 上下文再次付费。


使账单迅速上涨的真正原因并非提问次数，而是每次请求携带的冗余信息。如果对话混入大量废弃代码和历史讨论，其单次提问成本可能达到干净对话的十倍。

所以节省 token 的核心思路很清楚，主要包括三件事：

1. 当前这轮任务是否真的需要使用那么昂贵的模型？

2. 能否缓存那些被重复发送的内容？

3. 历史对话中有哪些无用内容可以删除？

下面我们从模型、缓存、工作流和提示词四个方面来拆解。

2. 模型选择：大材小用最耗钱

同一模型家族中，大模型与小模型的单价通常相差数倍。许多人习惯始终使用最贵的旗舰模型，即便任务只是修改错别字或翻译一句话，这正是最容易被忽略的成本漏洞。

以 Claude 家族为例，其官方每百万 token 定价如下：

模型、输入单价、输出单价、适用场景

|------|------|------|---------|

| Haiku 4.5 | $1 | $5 | 翻译、格式整理、改错别字、简单归类 |

| Sonnet 4.6 | $3 | $15 | 日常主力：写文案、整理纪要、常规分析 |

| Opus 4.8 | $5 | $25 | 多份资料综合、深度推理、复杂报告 |

| Fable 5 | $10 | $50 | 极其复杂的长程自动化任务 |

Haiku 与 Opus 的价格相差 5 倍，OpenAI 或 Gemini 入门档和旗舰档之间的差距可能更加明显，甚至超过 20 倍。

需要留意以下两个基本定价机制：

1. 输出价格远高于输入。在 Claude 家族里，输出 token 单价为输入的 5 倍。因此，应压缩模型输出，并尽量让模型一次给出正确答案，节约的正是价格最高的输出 token。

2. 上下文过长可能触发惩罚定价。部分模型，例如 Gemini 1.5 Pro，在上下文超过特定长度，如 128k 后，单价会直接翻倍。这表示长对话不仅包含更多 token，单价也会升高。

日常使用 WorkBuddy 之类的工具时，道理同样如此。产品、运营或用户研究经理处理翻译短文、整理格式、归类零散记录等简单任务时，小模型如 Haiku 已经足够；撰写正式文案、开展常规数据分析，可用中档模型如 Sonnet；只有综合多份资料并进行深度推理的复杂任务，才需要大模型如 Opus。

## 3. Prompt Caching：省钱效果最显著的隐形机制

如果说挑选模型省的是零钱，那么 Prompt Caching（提示词缓存）就是能把账单砍掉大半的利器。不过，这需要你了解它的工作原理，否则可能一分钱都省不下来。

其核心机制叫作“前缀匹配”。连续两次请求开头的大段内容，也就是前缀，如果完全相同，大模型便能复用上一次的计算结果。被缓存的内容通常仅按标准输入价格的 10% 左右收费，相当于一折。

当然，缓存也有成本。写入缓存时会有一定的价格溢价（例如 5 分钟有效期的缓存写入是 1.25 倍价格，1 小时的是 2 倍价格）。但只要这个缓存被重复命中两三次，成本就完全收回了。对于需要频繁重发 System Prompt、工具定义、大型参考文档的 Agent 工具来说，缓存几乎就是白送的福利。

不过，想有效利用缓存，就必须理解“前缀匹配”的严格条件：任何一个字节发生变化，它后面的全部缓存都会失效。


在实际编写 Prompt 或配置工作台时，可以遵循以下几点：

- 把不容易变的内容放在最前面。比如 System Prompt、工具（Tools）定义、大段的参考文档，这些应该集中堆在请求的最上方。

应将频繁改变的信息放到最后，例如当前时间戳、用户刚输入的问题和随机生成的 ID，这些内容必须置于末尾。

不要在前缀中混入动态值。如果开头误放了未排序的 JSON 字典、UUID 或动态拼接的用户名，即使后面的参考文档一字未变，全部缓存仍会失效。

- 对话中途避免频繁改动配置。换模型、修改 System Prompt、或者临时增删插件工具，都会打破原有缓存。

留意 API 响应里的 cache_read_input_tokens 字段。若该数值始终为 0，说明前缀中存在会变化的“隐形干扰源”，需要进一步排查。

4. 工作流优化：日常节省 token 的核心战场

模型调整和缓存利用属于技术层面的单点优化，真正决定账单厚度的是日常开发的工作流设计。因为每一个操作都会直接决定传给大模型的历史记录里包含多少无用信息。

切换话题时，及时清理上下文

若把无关任务放在同一对话，例如讨论完本周问卷分析，又在原窗口修改下月活动方案，那么问卷分析的所有内容都会作为历史记录，在后续每轮对话中反复打包。陈旧上下文不会自行消失，较好的习惯是每完成一个独立任务，就使用 /clear 或打开新窗口。

合理利用上下文自动压缩功能

当前，多数主流 AI 编程工具和工作台已内置上下文压缩机制 Compaction。对话长度接近模型窗口上限时，系统会自动把早期详细记录压缩成简短的结构化摘要，不再发送完整原文。不要以人工方式勉强维持超长对话，让自动压缩机制介入，可以减少不少隐性开销。

把重活、脏活交给子袋里 Subagent

这是当前多 Agent 工作流里非常实用的节省方法。面对大范围资料检索、多份文件读取、批量数据处理等高消耗任务，可由主对话派生一个子袋里负责执行。子袋里具有独立上下文窗口，即便读取大量文件并产生海量中间结果，最终也只向主对话返回一份精炼摘要。


这种设计既能把大量检索噪声隔离在子窗口中，防止主线 token 激增，也有一项隐性优势：子任务通常可交给更便宜的模型，如 Haiku/Flash，最后汇总和深度决策时才使用主模型 Sonnet 或 Opus。

以精准引用取代全量粘贴

应尽可能借助 @文件 引用、局部检索或 RAG 等机制，使工具只读取和分析真正相关的代码片段。不要为图方便而把整个文件或长篇接口文档全部贴入对话。同一份大文件读取一次并记录要点即可，反复读取等同于重复付费。

注意 MCP 工具引发的上下文膨胀

接入 MCP（Model Context Protocol）服务时要注意：连接某个 MCP Server 后，其中全部工具定义 Tool Definition 默认会常驻每轮对话的上下文，即使本轮完全没有使用。因此，只应挂载当前任务必需的连接器。若只是偶尔执行脚本，直接让 Agent 运行 CLI 命令，通常比挂载完整 MCP 服务更节省空间。

5. 提示词策略：提高单次沟通效率

在 API 无状态的收费模式下，每一次“你来我往”的纠错和补充，都会导致之前的历史数据被重新打包发送。因此，通过优化提示词来减少对话的往复次数，就是最直接的省钱方式。

尽量一次完整说明需求

使用 Agent 工具时，第一轮提问质量十分关键。应尽可能一次提供最终目标、具体约束和相关背景资料。如果需求含糊，等模型生成后再用五六轮不断修补，不仅结果容易偏离目标，每次提问产生的历史数据开销也会成倍上升。

清楚规定输出格式

提问时应直接说明所需回答格式，例如“直接给出修改后的文案，不要解释”或“结果整理成一个表格”。这样既能防止模型输出过多无用内容，也可减少因格式不符而重新调整所产生的额外沟通。

### 定期精简常驻的 System Prompt

如果你在使用自定义的 AI 工作台，注意不要在 System Prompt 里塞入大量冗余的设定或过长的背景说明。因为这部分系统提示词在每一轮对话中都会被计入输入费用。一些非通用的 Few-Shot（少样本）示例，最好只在特定会话中按需提供，并尽量确保这部分内容能稳定触发 Prompt Caching 缓存。

降低模型试错概率

先花一分钟整理需求，使模型一次给出正确答案，是最节省 token 的方法。反之，如果自己尚未想清楚就让模型猜测和盲目尝试，就必须不断为模型的每次“误解”与“重写”付费。

6. 如果你使用 CodeBuddy

CodeBuddy（偏编程的版本）按积分计费，且内置了几个能直接帮你省额度的指令，顺手记一下：`/context` 看当前上下文都被谁占了（System Prompt、工具、历史消息各占多少），`/cost` 复盘这次会话花了多少、缓存命中如何，`/clear` 在换任务时一键清场、从零计费。模型也分 `lite`、`default`、`reasoning` 三档，简单事务主动切到 `lite` 就够，别让高端模型空跑。

7. 盘点日常最耗钱的三类典型误区

理解底层机制后，再来看实际使用 AI 工作台分析问题时，哪些三种操作最容易让人不知不觉付出额外成本。

误区一：一次塞入几十份原始文档

开展用户调研或竞品分析时，很多人习惯把收集到的十几份访谈笔录和参考文件全部选中，直接拖入对话框后开始提问。

这些大文件进入会话后，会作为历史记录的一部分参与计费。此后每次提问，系统都会重新发送全部笔录。例如，你只想了解“第 3 个用户提到的痛点是什么”，大模型仍须再次阅读其余十几万字。一次加入过多内容还可能触发工作台的自动压缩机制，使早期详细数据变成简短摘要；需要准确引用某段原文或数字时，反而无法找到。

更有效率的方法：

采用“先索引，后局部”的方式。第一轮让大模型快速阅读全部文档，但只生成包含核心议题标签和文档主旨的索引清单。之后处理具体问题时，仅调入并阅读最相关的两三份特定文档。

采取分而治之的方式。完成 A 主题分析后立即新开窗口，不让无关原始文档长期留在当前会话背景里。

- 如果确实需要整体分析，请把大批文档作为“稳定前缀”放在对话的最开头，此后不要再对其进行任何修改，以此来确保 Prompt Caching 能够发挥作用。

误区二：同一个对话窗口持续一整周

为了方便，许多人一直在同一个窗口对话。今天提问后不关闭，明天仍在这里继续，最终整个项目完成时，对话已经累计上百轮。

这会把“滚雪球”效应推到极致。第十轮时，单次提问成本已经不低；达到上百轮后，即便只输入几个字，系统也会反复为一周前已废弃的想法支付昂贵重读费用。上下文过长还会严重分散模型注意力，使输出质量明显降低，最终既多花钱，效果也更差。

更有效率的方法：

养成“一事一议，完结即关”的习惯。写问卷和写报告属于两个独立任务，应分别放在不同窗口中完成。

及时沉淀阶段性成果。对需要跨天开展的长期工作，应随时把现阶段核心结论整理成大纲或背景文档。第二天打开新会话时，直接加入这份精炼的结论摘要，即可在干净且便宜的上下文中继续推进。

误区三：需求表述含糊，转而向大模型发泄情绪

模型回答不符合预期时，有人会发送缺乏实际指导意义的反馈，例如“不对，再想想！”、“逻辑不对，认真点！”，甚至输入一连串感叹号。

这种提问方式不仅无法解决问题，还会造成双重浪费。一方面，模糊需求迫使大模型盲目猜测，每次猜错和纠正都会继续累积历史 token，徒增费用；另一方面，“认真点”等情绪化词语同样占用输入 token，却没有提供任何具体规则或约束，无法使大模型变得更聪明。

更有效率的方法：

第一轮沟通应尽量给出清晰输入，包括目标、限制条件及所需输出格式。多用一两分钟整理要点，可以免除后续反复沟通和纠错的成本。

与其责备模型，不如提供明确的格式样例。告诉大模型“我希望输出类似这样的格式：[示例]”，比使用任何感叹号都有效，也能直接提供参照锚点。

如果对话已经明显偏离方向，不应在受污染的上下文中勉强纠正。直接关闭当前窗口，重新打开对话并梳理需求，才是最方便也最节省费用的方法。

8. 精简上下文，节省的不只是额度

梳理这些策略后可以发现，它们的内在原则完全一致：每轮交互都尽可能只让大模型阅读与当前任务真正相关的内容。

无论是及时清空历史（`/clear`）、通过合理排布触发缓存（Prompt Caching）、利用子袋里隔离海量数据，还是按需分配模型，这些方法的本质都是在主动对抗上下文自然膨胀的趋势。

这种做法的收益并不局限于账单数字。上下文越干净、越聚焦，大模型的注意力就越集中，生成的代码和分析也会更加准确。混有大量陈旧无效信息的超长对话，不但成本高，还很容易让大模型生成内容时“走神”或出现幻觉。

下一次发现自己的额度消耗异常迅速时，不妨先停下来，回头看一眼当前的对话历史。看一看在这堆冗长的数据里，到底有多少是模型本来不需要去读的。 ","createTime":1781865576,"ext":{"closeTextLink":0,"comment_ban":0,"description":"","focusRead":0},"favNum":0,"html":"","isOriginal":0,"likeNum":0,