1. 一个月的账单摆在面前，先别急着掏计算器

九月份过完，我打开 WorkBuddy 的用量面板，看到那个数字的时候愣了一下：1.73 亿 token。不是 173 万，是 1.73 亿。第一反应是面板是不是统计口径出了问题，第二反应是——如果这些量全部按官方标价走，我这个月怕是要吃土。

先把结论摆前面：这 1.73 亿 token 如果完全按官方原价、零缓存、零折扣结算，账单会落在四位数美元的量级，换算成人民币轻松破万。但实际我掏的钱远低于这个数，原因就藏在 token 的构成结构里——输入、输出、缓存命中、缓存写入，这四类 token 的单价能差出十倍甚至几十倍。很多人算 API 成本只盯着"输入多少钱、输出多少钱"两个数字，结果要么高估到不敢用，要么低估到月底被账单打脸。

这篇东西写给两类人：一类是正在用 WorkBuddy 或者类似 AI 编程助手、想搞清楚自己到底在烧多少钱的开发者；另一类是准备把 AI 助手接进团队工作流、需要提前做成本预算的技术负责人。我会把 1.73 亿 token 这个真实数字拆开，一层层算给你看，顺便把缓存命中率这个"省钱命门"讲透。看完你至少能做到两件事：第一，拿到自己的用量数据后能独立估算真实成本；第二，知道从哪些地方下手能把账单压下来。

需要提前说明的是，下面涉及的具体单价我会用行业里公开的常见档位来举例演算，不同模型、不同时期的价格会有浮动，你实际结算时以自己账户后台的价目为准。但计算逻辑和拆解方法是通用的，换成任何一家主流模型服务商都适用。

2. 先把 token 的账本结构搞清楚，不然算的都是糊涂账

2.1 输入、输出、缓存，三类 token 三种命

很多人对 token 计费的理解停留在"用多少字算多少钱"，这个认知在早期聊天场景里勉强够用，但放到 WorkBuddy 这种编程助手场景里就完全不够了。编程助手的 token 消耗结构和聊天机器人有本质区别，它每一轮对话都要把大量上下文重新喂给模型：你的项目文件、之前的对话历史、系统提示词、工具调用返回结果，这些加起来动辄几万 token。

所以真实的 token 账本至少分这么几类：

• 输入 token（Input）：你发给模型的所有内容，包括系统提示、历史对话、代码文件、工具返回。
• 输出 token（Output）：模型生成的内容，包括回答文本和工具调用参数。
• 缓存写入 token（Cache Write）：第一次把某段上下文写进缓存时产生的费用，通常比普通输入贵。
• 缓存读取 token（Cache Read）：后续命中缓存时读取的费用，通常比普通输入便宜一大截。

这四类的单价关系，用一句话概括就是：缓存读取最便宜，普通输入居中，缓存写入偏贵，输出最贵。不同服务商的具体倍率不一样，但大方向一致。你如果只按"输入+输出"两栏去算，等于把最省钱的那部分和最贵的那部分混在一起平均，算出来的数字既不准也没法指导优化。

2.2 为什么编程助手的缓存命中率能决定生死

WorkBuddy 这类工具的工作模式是多轮连续对话 + 大上下文。你让它改一个函数，它可能要读十几个相关文件；你追问一句，它又要把前面所有内容重新过一遍。如果每一轮都按普通输入价重新计费，成本会指数级膨胀。

缓存机制就是来解决这个问题的。当你的对话历史、项目上下文在一段时间内保持稳定，服务商可以把这部分内容缓存起来，下一轮直接以缓存读取价计费。这个价格通常是普通输入价的十分之一左右，有的档位甚至更低。换句话说，缓存命中率每提高 10 个百分点，整体输入成本就能降一大截。

我九月份这 1.73 亿 token 里，缓存读取占了相当大的比例，这也是为什么实际账单没有按原价爆炸。后面我会用具体数字演算给你看，缓存命中率从 60% 提到 90%，账单能差出多少钱。

2.3 一个容易被忽略的坑：缓存写入不是免费的

新手常有的误解是"缓存 = 省钱"，于是拼命想把所有东西都塞进缓存。但缓存写入本身是要收费的，而且单价比普通输入还贵。如果你的上下文频繁变动——比如每轮都在改系统提示、每轮都插入新的文件内容——那缓存会不断失效重建，你付了一堆缓存写入的钱，却几乎没享受到缓存读取的便宜。

这里有个经验判断：一段上下文如果预计会被复用 3 次以上，缓存才划算。低于这个次数，缓存写入的额外成本可能盖过读取省下的钱。WorkBuddy 在长会话场景下天然满足这个条件，所以缓存策略对它特别重要；但如果你只是零散地问几个不相关的问题，缓存反而可能是负担。

3. 1.73 亿 token 拆开算，官方价到底多少钱

3.1 先设定一套演算用的价格档位

为了让计算可复现，我设定一套行业里常见的价格档位（单位：美元 / 百万 token），这套数字仅用于演算逻辑，不代表任何特定服务商的实际报价：

这套档位的设计逻辑是：输出最贵（模型生成算力消耗大），缓存读取最便宜（只是读取已有内容），缓存写入略贵于普通输入（写入有额外开销）。记住这个相对关系，比记住具体数字更重要。

3.2 按"零缓存、纯输入输出"的极端情况算

先算最坏情况：假设这 1.73 亿 token 完全没有缓存，全部按普通输入和输出计费。编程助手场景下，输入通常远大于输出，我按经验取一个输入占 85%、输出占 15%的比例：

• 输入 token：1.73 亿 × 85% = 1.4705 亿
• 输出 token：1.73 亿 × 15% = 0.2595 亿

代入单价：

• 输入成本：147.05 × 3.00 =441.15 美元
• 输出成本：25.95 × 15.00 =389.25 美元
• 合计：830.40 美元

按汇率 7.2 换算，约合人民币5979 元。这是零缓存、零折扣的极端上限。注意这里输出只占 15%，却贡献了将近一半的成本，这就是输出单价高的威力。

3.3 加入真实缓存结构后的账单

现实中 WorkBuddy 的缓存命中率相当高。我九月份的实际数据里，缓存读取 token 大约占总量的 70%，缓存写入占 5%，剩下的 25% 才是普通输入和输出。重新拆：

• 缓存读取：1.73 亿 × 70% = 1.211 亿
• 缓存写入：1.73 亿 × 5% = 0.0865 亿
• 普通输入：1.73 亿 × 20% = 0.346 亿
• 输出：1.73 亿 × 5% = 0.0865 亿

代入单价：

• 缓存读取：121.1 × 0.30 =36.33 美元
• 缓存写入：8.65 × 3.75 =32.44 美元
• 普通输入：34.6 × 3.00 =103.80 美元
• 输出：8.65 × 15.00 =129.75 美元
• 合计：302.32 美元

约合人民币2177 元。对比零缓存情况的 830 美元，缓存直接省掉了超过 60% 的成本。这就是为什么我说缓存命中率是省钱命门——它不是锦上添花，是决定账单量级的关键变量。

3.4 缓存命中率每变一点，账单跟着变

为了让你直观感受缓存命中率的杠杆效应，我固定总 token 量 1.73 亿、输出占比 5% 不变，只调整缓存读取的比例，看账单怎么变：

从 50% 提到 90%，账单从 2756 元降到 1790 元，省了将近 1000 块。而这只是把缓存命中率往上提了 40 个百分点，工作量可能只是调整一下会话组织方式。这笔账算下来，任何做 AI 应用的人都该把缓存优化当成一等大事。

4. 把账单压下来的实操手段，我踩过的坑都在这

4.1 会话组织方式直接决定缓存命中率

缓存能不能命中，核心看上下文前缀是否稳定。服务商的缓存机制大多是基于前缀匹配的：如果你的对话历史从第一轮开始就保持不变，后面每一轮都能命中前面部分的缓存；但如果你在中途修改了系统提示、或者把新内容插到了历史中间，缓存就会从修改点开始失效。

我在九月初犯过一个典型错误：为了让 WorkBuddy"记住"新的项目规范，我每隔几轮就更新一次系统提示词。结果每次更新都导致缓存全量重建，那一周的缓存写入成本明显偏高。后来我改成把项目规范一次性写死在会话开头，中途不再改动，缓存命中率立刻上了一个台阶。

具体做法上，我建议：

• 系统提示、项目背景、编码规范这类稳定内容放在最前面，一次设定不再改。
• 新的需求、新的文件内容追加在对话末尾，不要插到中间。
• 如果确实需要切换任务，开新会话比在旧会话里改上下文更划算。

4.2 控制上下文长度，别让历史无限膨胀

WorkBuddy 默认会保留很长的对话历史，这对连贯性有好处，但历史越长，每一轮要处理的输入 token 越多。哪怕命中缓存，缓存读取也是要按量计费的，1.73 亿 token 里那 1.2 亿缓存读取就是这么堆出来的。

我的做法是定期做上下文清理：一个任务完成后，如果后续任务和它无关，就开新会话；如果有关联，就手动把已完成部分的详细历史压缩成一段简短摘要，替换掉原始的长对话。这样既保留了关键信息，又砍掉了大量冗余 token。

这里有个量化参考：一段 5 万 token 的对话历史，如果压缩成 5000 token 的摘要，后续每轮能省下 4.5 万 token 的输入量。按 20 轮计算就是 90 万 token，哪怕全是缓存读取价，也是实打实的钱。

4.3 输出 token 才是真正的成本大头，要主动约束

前面算过，输出单价是普通输入的 5 倍。1.73 亿 token 里输出只占 5%，却贡献了 129 美元，占比超过四成。所以控制输出长度比控制输入更有效。

约束输出的手段有这么几个：

• 在提示词里明确要求简洁：比如"只输出修改后的代码，不要解释""用一句话回答"。
• 避免让模型复述已知内容：很多模型喜欢把你说的话再重复一遍，这是纯浪费。可以在系统提示里禁止这种行为。
• 工具调用参数尽量精简：WorkBuddy 调用工具时会生成结构化参数，参数越复杂输出 token 越多。设计工具接口时保持参数简洁。

我实测下来，光是加一句"不要复述我的问题，直接给答案"，输出 token 就能降 15% 到 20%。这个改动零成本，收益立竿见影。

4.4 模型选型：不是所有任务都值得上最贵的模型

WorkBuddy 支持切换不同模型，不同模型的单价能差好几倍。我九月份的教训是前期偷懒，所有任务都用同一个高配模型，包括那些简单的格式化、重命名、写注释的活儿。后来我把任务分了级：

分级之后，我估算整体成本又降了两成左右。关键认知是：模型能力是过剩还是不足，取决于任务难度，不是越贵越好。

5. 常见问题与排查技巧实录

5.1 用量面板数字和实际账单对不上怎么办

这是最常见的问题。用量面板通常统计的是原始 token 数，而账单是按计费 token 数算的，两者口径不同。缓存读取在面板里可能显示为完整 token 量，但计费时按折扣价算，所以你会看到"面板数字很大，账单没那么吓人"。

排查思路：先确认面板统计的是哪几类 token，再对照账单明细里的分类。如果账单明细只给了总额没给分类，可以自己按本文第 3 节的方法反推——用总额除以各类单价，看哪类占比合理。

5.2 缓存命中率突然掉下来是什么原因

缓存命中率不会无缘无故下降，通常是这几个原因：

• 系统提示被改动：哪怕改一个字符，缓存前缀就失效。
• 会话被中断重建：网络波动导致会话重置，缓存丢失。
• 上下文插入了变动内容：比如把当前时间戳、随机 ID 放进了系统提示。
• 缓存过期：多数服务商的缓存有存活时间，长时间不活动会失效。

我遇到过一次命中率暴跌，查了半天发现是系统提示里有个动态生成的会话 ID，每次请求都不同，导致缓存永远无法命中。把那个 ID 挪到对话末尾后，命中率立刻恢复。系统提示里绝对不能放任何动态内容，这是血泪教训。

5.3 怎么判断该不该开新会话

判断标准很简单：新任务和旧任务的上下文重合度。如果重合度高（比如都在改同一个模块），继续用旧会话，让缓存发挥作用；如果重合度低（比如从后端任务切到前端任务），开新会话，避免把无关的历史也拖着走。

我给自己定的规则是：任务切换超过两次，或者历史超过 30 轮，就考虑开新会话。这个阈值可以根据你的实际项目调整，但核心逻辑是别让无关上下文白占 token。

5.4 常见问题速查表

6. 我个人的几条成本控制心得

用 WorkBuddy 这几个月，最大的体会是：AI 助手的成本不是"用多少付多少"那么简单，它是一个可以被主动设计的变量。同样 1.73 亿 token，组织得好和organizing得差，账单能差出一倍。

几条我反复验证过的心得：第一，把缓存命中率当成核心指标来盯，它比总 token 量更能反映你的成本健康度；第二，输出约束的收益远大于输入优化，因为输出单价高；第三，模型分级是长期省钱的基本功，别让高配模型干低配的活；第四，定期复盘用量结构，看看哪类 token 在涨，涨得合不合理。

最后分享一个我最近在用的笨办法：每周花十分钟，把用量面板的四类 token 抄到一张表里，算一遍当周成本，和上周对比。数字一有异常波动，立刻能定位到是哪次操作导致的。这个习惯帮我抓出过好几次缓存失效的问题，省下的钱远超那十分钟的时间成本。