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 账本至少分这么几类输入 tokenInput你发给模型的所有内容包括系统提示、历史对话、代码文件、工具返回。输出 tokenOutput模型生成的内容包括回答文本和工具调用参数。缓存写入 tokenCache Write第一次把某段上下文写进缓存时产生的费用通常比普通输入贵。缓存读取 tokenCache Read后续命中缓存时读取的费用通常比普通输入便宜一大截。这四类的单价关系用一句话概括就是缓存读取最便宜普通输入居中缓存写入偏贵输出最贵。不同服务商的具体倍率不一样但大方向一致。你如果只按输入输出两栏去算等于把最省钱的那部分和最贵的那部分混在一起平均算出来的数字既不准也没法指导优化。2.2 为什么编程助手的缓存命中率能决定生死WorkBuddy 这类工具的工作模式是多轮连续对话 大上下文。你让它改一个函数它可能要读十几个相关文件你追问一句它又要把前面所有内容重新过一遍。如果每一轮都按普通输入价重新计费成本会指数级膨胀。缓存机制就是来解决这个问题的。当你的对话历史、项目上下文在一段时间内保持稳定服务商可以把这部分内容缓存起来下一轮直接以缓存读取价计费。这个价格通常是普通输入价的十分之一左右有的档位甚至更低。换句话说缓存命中率每提高 10 个百分点整体输入成本就能降一大截。我九月份这 1.73 亿 token 里缓存读取占了相当大的比例这也是为什么实际账单没有按原价爆炸。后面我会用具体数字演算给你看缓存命中率从 60% 提到 90%账单能差出多少钱。2.3 一个容易被忽略的坑缓存写入不是免费的新手常有的误解是缓存 省钱于是拼命想把所有东西都塞进缓存。但缓存写入本身是要收费的而且单价比普通输入还贵。如果你的上下文频繁变动——比如每轮都在改系统提示、每轮都插入新的文件内容——那缓存会不断失效重建你付了一堆缓存写入的钱却几乎没享受到缓存读取的便宜。这里有个经验判断一段上下文如果预计会被复用 3 次以上缓存才划算。低于这个次数缓存写入的额外成本可能盖过读取省下的钱。WorkBuddy 在长会话场景下天然满足这个条件所以缓存策略对它特别重要但如果你只是零散地问几个不相关的问题缓存反而可能是负担。3. 1.73 亿 token 拆开算官方价到底多少钱3.1 先设定一套演算用的价格档位为了让计算可复现我设定一套行业里常见的价格档位单位美元 / 百万 token这套数字仅用于演算逻辑不代表任何特定服务商的实际报价token 类型单价美元/百万 token相对普通输入的倍率普通输入3.001.0x缓存写入3.751.25x缓存读取0.300.1x输出15.005.0x这套档位的设计逻辑是输出最贵模型生成算力消耗大缓存读取最便宜只是读取已有内容缓存写入略贵于普通输入写入有额外开销。记住这个相对关系比记住具体数字更重要。3.2 按零缓存、纯输入输出的极端情况算先算最坏情况假设这 1.73 亿 token 完全没有缓存全部按普通输入和输出计费。编程助手场景下输入通常远大于输出我按经验取一个输入占 85%、输出占 15%的比例输入 token1.73 亿 × 85% 1.4705 亿输出 token1.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%25.95194.63382.77275660%31.14155.70349.03251370%36.33116.78315.55227280%41.5277.85282.06203190%46.7138.93248.581790从 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 常见问题速查表现象可能原因处理方式账单远超预期缓存命中率低、输出过长检查系统提示稳定性约束输出缓存写入成本高上下文频繁变动稳定前缀动态内容后置面板与账单不符统计口径差异按分类 token 反推核对命中率突然下降提示词改动或缓存过期排查动态内容保持会话活跃简单任务成本高模型档位过高按任务难度分级选模型6. 我个人的几条成本控制心得用 WorkBuddy 这几个月最大的体会是AI 助手的成本不是用多少付多少那么简单它是一个可以被主动设计的变量。同样 1.73 亿 token组织得好和organizing得差账单能差出一倍。几条我反复验证过的心得第一把缓存命中率当成核心指标来盯它比总 token 量更能反映你的成本健康度第二输出约束的收益远大于输入优化因为输出单价高第三模型分级是长期省钱的基本功别让高配模型干低配的活第四定期复盘用量结构看看哪类 token 在涨涨得合不合理。最后分享一个我最近在用的笨办法每周花十分钟把用量面板的四类 token 抄到一张表里算一遍当周成本和上周对比。数字一有异常波动立刻能定位到是哪次操作导致的。这个习惯帮我抓出过好几次缓存失效的问题省下的钱远超那十分钟的时间成本。