1. 一个月的账单摆在面前，先搞清楚这1.73亿token是怎么烧出去的

九月份过完，我打开WorkBuddy后台看了一眼用量统计，1.73亿token。说实话第一反应不是心疼，是好奇——这玩意儿按官方价到底要花多少钱？因为WorkBuddy本身走的是订阅制，我实际掏的钱跟这个token量完全不成比例，但如果换成按API计费的方式去算，数字会非常有意思。

先把背景交代清楚。WorkBuddy是一个AI编程助手类的工具，跟CodeBuddy算是同一体系下的产品，核心能力是理解代码仓库、生成代码、做代码审查、跑自定义指令这些。它跟直接调API最大的区别在于：你不需要自己管上下文拼接、不需要自己维护对话历史、不需要自己处理缓存策略，这些它都在后台帮你做了。代价就是，你很难直观感受到自己到底消耗了多少token。

1.73亿token这个数字，放在个人开发者身上算是相当激进的用量。我九月份主要在做三件事：一个中型项目的重构、两个小工具的开发、以及大量的代码审查和文档生成。日均下来大概570万token左右，按每天工作8小时算，每小时消耗70万token上下。这个强度不算离谱，但绝对算不上轻量。

为什么要算这笔账？原因很简单。第一，我想知道订阅制到底帮我省了多少钱，这直接决定了要不要续费。第二，我想搞清楚token都花在哪了，哪些操作是"吞金兽"，哪些是"性价比之王"。第三，如果你也在用类似的工具，或者正在考虑从直接调API切换到这类集成工具，这笔账能帮你做决策。

需要提前说明的是，下面的计算基于公开的官方定价体系，不同模型价格差异很大，我会分模型来算。另外，缓存命中率是这里面的关键变量，它能让实际成本差出好几倍，这一点后面会重点讲。

2. 拆解token消耗结构，别被总数吓到

2.1 输入token和输出token的比例关系

1.73亿token不是铁板一块，它分成输入和输出两部分，而这两部分的价格完全不一样。以主流模型为例，输入token通常比输出token便宜3到5倍。所以搞清楚比例，比盯着总数有用得多。

我翻了一下后台的明细，九月份的输入输出比例大概是这样的：

这个比例其实很典型。AI编程助手类工具，输入永远是大头，因为它每次都要把大量代码文件塞进上下文里。你让它改一个函数，它可能要把整个文件甚至关联的几个文件都读一遍。输出反而相对克制，因为生成的代码量通常不会太大。

提示：如果你发现自己输出token占比超过30%，要么是在大量生成新代码，要么是模型在"废话"，后者可以通过优化提示词来改善。

2.2 缓存命中率才是真正的省钱开关

这是整个成本计算里最容易被忽略、但影响最大的变量。所谓缓存命中，就是你的请求里有一部分内容跟之前的请求重复了，服务端可以直接复用之前算好的结果，不用重新计算。这部分token的价格通常只有正常输入token的10%甚至更低。

九月份我的缓存命中率大概在65%左右。这个数字怎么来的？因为WorkBuddy会维护对话历史和代码上下文，很多内容在连续对话中是重复的。比如你连续让AI改同一个文件的多个函数，文件内容就会被反复送进去，但只有第一次是"全新"的，后面都算缓存命中。

缓存命中率对成本的影响有多大？举个例子。假设1.42亿输入token，如果全部按正常价格算，和65%走缓存价格算，差距可能是2到3倍。这就是为什么同样是用AI编程工具，有人觉得便宜有人觉得贵——用法不同，缓存命中率天差地别。

提升缓存命中率的实操心得：

• 尽量在同一个对话会话里完成相关任务，不要频繁开新会话。新会话意味着上下文全部重新计算。
• 把稳定的系统提示词、项目规范放在会话开头，这些内容后续每次请求都能命中缓存。
• 避免在对话中途大段修改已经发送过的代码，改动越大，缓存失效越多。
• 如果工具支持，开启"项目级上下文缓存"，让整个项目的代码索引常驻缓存。

2.3 不同模型的token单价差异

WorkBuddy支持切换模型，不同模型的价格能差出一个数量级。我九月份主要用了三档模型：

旗舰模型贵但能力强，适合复杂重构和架构设计；标准模型性价比最高，日常编码和审查够用；轻量模型适合格式化、简单补全这类任务。我的策略是：能用标准模型解决的绝不上旗舰，只有遇到标准模型反复出错的情况才升级。

这个策略直接影响了最终账单。如果1.73亿token全部走旗舰模型，成本会比现在高出一大截。所以算账之前，先看看你的模型使用分布是否合理。

3. 按官方价实算：1.73亿token到底值多少钱

3.1 计算前的假设和参数说明

在开始算之前，我必须把假设说清楚，否则算出来的数字没有意义。以下计算基于公开的官方定价体系，取一个中间偏上的价格水平作为参考，实际价格会因模型版本、促销活动、批量折扣等因素浮动。

核心参数：

• 输入token：1.42亿，其中65%缓存命中，35%正常计费
• 输出token：3100万，全部正常计费
• 旗舰模型占比35%，标准模型占比50%，轻量模型占比15%
• 缓存命中价格按正常输入价格的10%计算

这里要特别说明缓存命中的计算方式。假设正常输入价格是X，缓存命中价格是0.1X，那么实际输入成本 = 1.42亿 × (0.65 × 0.1X + 0.35 × X) = 1.42亿 × 0.415X。也就是说，65%的缓存命中率把输入成本压到了原来的41.5%。这个杠杆效应非常明显。

3.2 分模型档位的详细计算过程

为了让你能直接套用，我把计算过程拆开写。以下价格用相对值表示，你可以替换成你实际使用的模型价格。

旗舰模型部分（35%的用量）：

• 输入token：1.42亿 × 35% = 4970万
• 其中缓存命中：4970万 × 65% = 3230.5万，按0.1倍价格计
• 正常计费输入：4970万 × 35% = 1739.5万
• 输出token：3100万 × 35% = 1085万

假设旗舰模型输入价格是每百万token 10个单位，输出是每百万token 30个单位：

• 缓存输入成本：3230.5万 / 100万 × 10 × 0.1 = 3.23个单位
• 正常输入成本：1739.5万 / 100万 × 10 = 17.40个单位
• 输出成本：1085万 / 100万 × 30 = 32.55个单位
• 旗舰模型小计：约53.18个单位

标准模型部分（50%的用量）：

• 输入token：1.42亿 × 50% = 7100万
• 缓存命中：7100万 × 65% = 4615万
• 正常计费输入：7100万 × 35% = 2485万
• 输出token：3100万 × 50% = 1550万

假设标准模型输入价格是每百万token 3个单位，输出是每百万token 9个单位：

• 缓存输入成本：4615万 / 100万 × 3 × 0.1 = 1.38个单位
• 正常输入成本：2485万 / 100万 × 3 = 7.46个单位
• 输出成本：1550万 / 100万 × 9 = 13.95个单位
• 标准模型小计：约22.79个单位

轻量模型部分（15%的用量）：

• 输入token：1.42亿 × 15% = 2130万
• 缓存命中：2130万 × 65% = 1384.5万
• 正常计费输入：2130万 × 35% = 745.5万
• 输出token：3100万 × 15% = 465万

假设轻量模型输入价格是每百万token 0.5个单位，输出是每百万token 1.5个单位：

• 缓存输入成本：1384.5万 / 100万 × 0.5 × 0.1 = 0.07个单位
• 正常输入成本：745.5万 / 100万 × 0.5 = 0.37个单位
• 输出成本：465万 / 100万 × 1.5 = 0.70个单位
• 轻量模型小计：约1.14个单位

总计：约77.11个单位。

如果你把"单位"理解成美元，那就是77美元左右；如果理解成人民币的某个比例，按汇率换算即可。关键是这个计算框架，你可以把自己的实际用量和实际价格代进去。

3.3 如果没有缓存，账单会变成什么样

这是最值得看的一组对比。假设缓存命中率为0，所有输入token都按正常价格计费：

• 旗舰模型输入成本：4970万 / 100万 × 10 = 49.70个单位（原来20.63）
• 标准模型输入成本：7100万 / 100万 × 3 = 21.30个单位（原来8.84）
• 轻量模型输入成本：2130万 / 100万 × 0.5 = 1.07个单位（原来0.44）
• 输出成本不变：约47.20个单位

无缓存总计：约119.27个单位。

也就是说，65%的缓存命中率帮我省了大约42个单位，相当于总成本的35%。如果缓存命中率能提到80%，还能再省一大截。这就是为什么我说缓存命中率是真正的省钱开关。

注意：不同平台对缓存的计算方式不一样，有的按前缀匹配，有的按语义匹配，有的只对特定模型开放缓存。用之前一定要看清楚规则，否则你以为命中了其实没命中。

4. 从账单反推：哪些操作最烧token，怎么优化

4.1 烧token排行榜：我的实测数据

算完账之后，我回头分析了九月份的具体操作，整理出一个"烧token排行榜"。这个榜单对优化用量非常有参考价值：

全仓库代码审查排第一，这个不意外。它需要把大量代码文件塞进上下文，输入token量巨大。但它的缓存命中率还不错，因为审查通常是定期做，代码变动不大，很多文件内容可以复用缓存。

大型重构排第二，这个是最"贵"的操作。因为它涉及跨文件修改，每次改动都会导致大量缓存失效，而且需要旗舰模型来保证质量。我九月份做了两次大重构，token消耗相当可观，但这是必要的投入，省不得。

日常编码辅助反而是性价比最高的。因为它在同一个会话里连续进行，上下文高度复用，缓存命中率能到80%以上。你写一个函数，AI补全，再写下一个，前面的上下文都能命中缓存。

4.2 三个立竿见影的省token技巧

技巧一：把大任务拆成小任务，但别拆太碎。

大任务一次性提交，上下文巨大，缓存利用率低。但拆得太碎，每次都要重新建立上下文，反而更贵。我的经验是：按"功能模块"拆分比较合适。比如重构一个模块，就针对这个模块开一个会话，把相关文件一次性加进去，然后在这个会话里完成所有改动。这样上下文稳定，缓存命中率高。

技巧二：善用"只读"和"可写"的区分。

很多操作其实不需要AI修改代码，只需要它理解代码。比如"这个函数是干什么的"、"这个bug可能在哪"，这类只读操作可以用轻量模型，而且不需要把整个文件都塞进去，只给相关片段就行。我九月份有大量token是花在"让AI读代码"上，后来改成只给关键片段，省了不少。

技巧三：定期清理和重建会话。

这听起来跟"保持会话"矛盾，但其实要分情况。如果一个会话已经很长，上下文里堆了大量历史对话，而当前任务跟历史关系不大，那就该开新会话。因为长会话的每次请求都要带上全部历史，即使命中缓存，累积起来也是成本。我的做法是：一个任务一个会话，任务完成就关掉。

4.3 模型选择的决策树

什么时候用旗舰，什么时候用标准，什么时候用轻量？我总结了一个简单的决策树：

• 需要跨文件推理、架构设计、复杂bug定位 → 旗舰模型
• 单文件内的编码、重构、审查 → 标准模型
• 格式化、简单补全、注释生成、代码解释 → 轻量模型
• 不确定 → 先用标准模型试，不行再升级

这个决策树帮我省了不少钱。九月份我一开始习惯性用旗舰模型做所有事，后来发现很多任务标准模型完全够用，切换之后成本明显下降，质量没有明显损失。

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

5.1 token用量异常飙升怎么排查

九月份有一次我发现某天的token用量突然翻倍，排查了半天才找到原因。这里把排查思路整理出来：

第一步：看时间分布。是集中在某个时段，还是全天均匀升高？集中在某个时段，说明是某个特定操作导致的。

第二步：看操作类型。对比前几天的操作记录，找出新增的或频率变高的操作。我当时是新增了一个"全仓库文档生成"的任务，它把每个文件都读了一遍，token量自然大。

第三步：看缓存命中率。如果缓存命中率突然下降，说明上下文复用变差了。常见原因是频繁开新会话，或者代码改动太大导致缓存失效。

第四步：看模型分布。是不是不小心把轻量任务切到了旗舰模型？这种情况很常见，尤其是切换模型后忘了切回来。

5.2 缓存命中率上不去的五个原因

5.3 关于WorkBuddy和CodeBuddy的选择

这两个工具经常被拿来比较。我的使用体会是：WorkBuddy更偏向"工作流集成"，它把很多操作封装成了skill和自定义指令，适合有固定工作模式的团队；CodeBuddy更偏向"编码辅助"，交互更轻量，适合个人开发者快速上手。如果你主要做代码审查和文档，WorkBuddy的skill体系能帮你省不少事；如果你主要写代码，CodeBuddy的响应更直接。

token消耗方面，两者底层调用的模型能力差不多，差异主要在封装层。WorkBuddy因为集成了更多自动化流程，单次操作的token量可能更大，但完成的任务也更多。算性价比要看"每个任务"的成本，而不是"每次请求"的成本。

5.4 几个容易踩的坑

坑一：以为订阅制就不用管token。订阅制确实不按token收费，但很多平台有"公平使用"条款，用量过大可能被限速或要求升级。了解自己的token用量，能帮你预判风险。

坑二：忽略输出token的成本。输出token通常比输入贵好几倍，让AI"多写点"的代价比想象中大。需要简洁输出时，明确告诉AI"只给代码，不要解释"。

坑三：在错误的模型上省钱。用轻量模型做复杂重构，反复出错反复重试，总成本可能比直接用旗舰模型还高。该花的钱要花。

坑四：不记录用量。我九月份能算出这笔账，是因为有记录。建议每周花五分钟看一下用量统计，及时发现异常。

6. 这笔账算完之后，我的实际决策

算完1.73亿token的账，我最直接的感受是：订阅制的价值不在于"无限用"，而在于"不用管"。如果按API计费，我九月份大概要花77个单位的钱，而订阅费远低于这个数。但前提是，我的用法是"高效"的——缓存命中率65%，模型选择合理，任务拆分得当。如果我用法粗暴，缓存命中率只有30%，模型全用旗舰，那实际成本可能翻两三倍，订阅制的优势就没那么明显了。

所以这笔账的真正价值，不是告诉你"订阅制划算"，而是告诉你"你的用法值多少钱"。同样的1.73亿token，用法不同，价值能差出一倍。我接下来的优化方向很明确：把缓存命中率从65%提到75%以上，把旗舰模型的使用占比从35%降到25%，把全仓库审查的频率从每周一次改成每两周一次但审查得更深入。

最后分享一个我一直在用的小习惯：每个月月底花十分钟，把当月的token用量、缓存命中率、模型分布、主要操作类型记在一个表格里。连续记三个月，你就能看出自己的使用模式，哪些是必要的投入，哪些是浪费。这个习惯帮我省下的钱，远超记录本身花的时间。