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）、利用子袋里隔离海量数据，还是按需分配模型，这些方法的本质都是在主动对抗上下文自然膨胀的趋势。 这样做带来的好处不仅是账单上的数字。一个更加干净、聚焦的上下文环境，能让大模型的注意力更加集中，产出的代码和分析也会更加精准。那些夹杂了太多陈旧垃圾信息的超长对话，不仅成本高昂，还极易导致大模型在生成内容时“走神”或产生幻觉。 下一次发现自己的额度消耗异常迅速时，不妨先停下来，回头看一眼当前的对话历史。看一看在这堆冗长的数据里，到底有多少是模型本来不需要去读的。