1. 1.73 亿 token 到底是个什么量级
先把数字摆出来：1.73 亿 token。这个量级放在个人开发者身上，属于"重度使用"档位；放在小团队里，属于"一个主力账号跑满一个月"的水平。很多人对这个数字没概念，我换个说法——一本《三体》三部曲大概 90 万字，按中文粗略折算约 120 万 token，1.73 亿 token 相当于你让模型把整套三部曲从头到尾读了 140 多遍。如果按英文算，1 token 约等于 0.75 个单词，1.73 亿 token 差不多是 1.3 亿个英文单词，够你把维基百科英文版主干内容过好几轮。
但 token 这个计量单位有个坑：它不是"你输入了多少字"，而是"输入 + 输出 + 缓存 + 工具调用中间态"的总和。WorkBuddy 这类工具型产品，一次任务往往不是一问一答，而是"读文件 → 规划 → 调工具 → 看结果 → 再规划 → 再调工具"的多轮循环。每一轮循环里，系统提示词、历史对话、工具返回结果都要重新塞进上下文。所以真实消耗的 token 量，通常是你肉眼看到的对话字数的 5 到 20 倍。
我拿一个具体场景给你算笔账。假设你让 WorkBuddy 帮你重构一个 3000 行的 Python 项目：
- 首次读取项目结构 + 关键文件：约 4 万 token 输入
- 系统提示词 + 工具定义：每轮固定 8000 token 左右
- 一次重构任务平均 15 轮工具调用：15 × 8000 = 12 万 token 的固定开销
- 每轮工具返回的代码片段、报错信息：平均 3000 token，15 轮就是 4.5 万
- 最终输出的重构代码 + 说明：约 2 万 token
一个任务下来，20 万 token 打底。1.73 亿除以 20 万，大约是 865 个这种规模的任务。9 月 30 天，平均每天 28 个中等复杂度任务。这个强度，说实话，不是"随便玩玩"，是真的把 WorkBuddy 当主力生产力工具在用。
提示：token 消耗的大头往往不在你写的那几句提示词上，而在系统提示词、工具定义和历史上下文的重复注入。想省 token，先盯住"轮数"和"上下文长度"，而不是抠自己打字的字数。
2. 按官方价把 1.73 亿 token 拆开算钱
2.1 为什么不能用一个单价直接乘
新手最容易犯的错，就是拿一个"每百万 token 多少钱"直接乘以 173。这么做算出来的数字，误差可能高达 3 到 5 倍。原因有三个：
第一，输入和输出不同价。几乎所有主流模型，输出 token 的单价都是输入的 3 到 5 倍。WorkBuddy 这种工具型产品，输出占比其实不高，大部分是输入（上下文重复注入），所以整体成本会比"全按输出价"低不少。
第二，缓存命中与否差价巨大。现在主流 API 都支持 prompt caching（提示词缓存），命中缓存的输入 token 单价通常只有未命中的 10% 到 25%。WorkBuddy 的系统提示词、工具定义这些固定内容，如果缓存策略做得好，能省下一大笔。
第三，不同模型混用。一个成熟的使用者不会所有任务都用最贵的旗舰模型。简单任务用便宜的小模型，复杂推理才上旗舰。1.73 亿 token 里，很可能有 60% 到 70% 是跑在便宜模型上的。
2.2 三种典型价格档位的估算
我按当前市场上常见的三档模型价格来做一个区间估算。注意，这里用的是"每百万 token"的通用量级，具体数字请以你实际使用的模型官方定价为准。
| 模型档位 | 输入单价（每百万 token） | 输出单价（每百万 token） | 缓存命中输入单价 |
|---|---|---|---|
| 旗舰推理型 | 较高（基准 1x） | 约 3-4x | 约 0.1-0.25x |
| 主力通用型 | 中等（约 0.2-0.3x） | 约 0.8-1.2x | 约 0.1x |
| 轻量经济型 | 低（约 0.02-0.05x） | 约 0.1-0.2x | 约 0.1x |
假设 1.73 亿 token 的构成是这样的（这是我从实际使用经验里总结的一个比较典型的分布）：
- 旗舰模型：占 15%，约 2600 万 token，其中输入 2200 万、输出 400 万
- 主力通用模型：占 55%，约 9500 万 token，其中输入 8500 万、输出 1000 万
- 轻量经济模型：占 30%，约 5200 万 token，其中输入 4800 万、输出 400 万
再假设整体缓存命中率在 40% 左右（这个数字对工具型产品来说算中等偏上），那么实际计费的输入 token 会打不少折扣。
2.3 一个可复现的估算过程
我不直接给你一个"最终答案"，因为不同模型定价差异太大，给了反而误导。我给你一套可以自己代入的计算模板：
总成本 = Σ(各模型输入token × 输入单价 × (1 - 缓存命中率 × 缓存折扣)) + Σ(各模型输出token × 输出单价)以主力通用模型这一档为例，假设输入单价是每百万 token 3 元，输出是每百万 token 12 元，缓存命中率 40%，缓存单价是输入的 10%：
- 输入成本 = 8500 万 / 100 万 × 3 × (1 - 0.4 × 0.9) = 85 × 3 × 0.64 = 163.2 元
- 输出成本 = 1000 万 / 100 万 × 12 = 10 × 12 = 120 元
- 这一档合计约 283 元
按同样的逻辑套到旗舰档和轻量档，旗舰档因为单价高，即使量少也会占大头；轻量档量大但单价低，反而贡献有限。整体算下来，1.73 亿 token 的月度成本，落在几百元到两三千元这个区间是比较合理的。如果你的缓存策略做得差、旗舰模型占比高，冲到四五千也不奇怪；如果优化得好、大量用轻量模型，压到两三百也有可能。
注意：上面所有单价都是示意性的量级参考，不是任何具体产品的报价。真正算账时，请打开你所用模型的官方定价页，把输入价、输出价、缓存价三个数字抄下来，代入上面的公式。
3. 缓存命中率才是账单的隐形开关
3.1 缓存到底缓存了什么
很多人以为缓存是"缓存我的提问"，其实不是。Prompt caching 缓存的是提示词前缀——也就是每次请求里那段固定不变的开头部分。对 WorkBuddy 这类工具来说，这段前缀包括：系统角色设定、工具（skill）的完整定义、项目级的规则文件、以及前面若干轮已经发生过的对话历史。
只要下一次请求的前缀和上一次"逐字节一致"，这部分就能命中缓存，按折扣价计费。一旦你在中间插了一句新话、改了一个工具定义、或者系统提示词里带了时间戳，缓存就断了，后面全部按原价重算。
3.2 为什么工具型产品的缓存命中率天然偏高
WorkBuddy 这种 agent 型工具，天然适合缓存，原因是它的请求结构非常"规整"：
- 系统提示词几乎不变
- 工具定义在一次会话内固定
- 历史对话是单调递增的（只追加，不修改）
这意味着，在一个长任务里，第 15 轮请求的前缀，完全包含了第 14 轮的前缀。理论上，如果缓存策略完美，第 15 轮里 90% 以上的输入都能命中缓存。这也是为什么我说"缓存命中率是账单的隐形开关"——同样 1.73 亿 token，命中率 20% 和命中率 70%，账单能差出一倍多。
3.3 提升命中率的几个实操动作
我在实际使用中总结了几个能明显提升缓存命中率的习惯：
- 不要在系统提示词里塞动态内容。比如当前时间、随机 ID、每次变化的文件列表。这些一旦进前缀，缓存必断。把它们放到用户消息里，而不是系统提示里。
- 工具定义保持稳定。如果你用的是支持自定义 skill 的版本，尽量在一次会话里不要频繁增删 skill。每改一次工具定义，前缀就变了。
- 长任务不要中途"清空重开"。有些人遇到卡顿就新开一个会话，结果前面攒的缓存全废了。正确做法是在同一会话里继续，让前缀持续复用。
- 把大段参考资料放在对话靠前的位置。前缀缓存是从头开始匹配的，越靠前的内容越容易被后续请求复用。
提示：如果你发现某个月的 token 账单异常高，第一件事不是去砍功能，而是去后台看缓存命中率。命中率低于 30%，说明你的使用方式在"反复重算前缀"，优化空间极大。
4. 模型混用：把贵模型用在刀刃上
4.1 什么任务值得上旗舰模型
1.73 亿 token 里，如果全部跑旗舰模型，账单会非常难看。但反过来，如果全部跑最便宜的模型，很多任务根本做不好，反复重试反而更费钱。关键是把任务分级。
我的分级经验是这样的：
- 必须上旗舰：复杂的架构设计、跨多文件的逻辑推理、难以定位的 bug 根因分析、需要长链条思考的算法题。这类任务用便宜模型，往往要来回试五六次，总成本反而更高。
- 主力通用模型足够：常规的代码补全、单文件重构、文档撰写、格式转换、简单的数据清洗。这类任务占日常使用的 60% 以上。
- 轻量模型就够：文件分类、简单的正则生成、格式校验、关键词提取、批量重命名。这类任务用旗舰模型纯属浪费。
4.2 一个真实的任务分配比例
我自己的使用习惯，大概是这样的分布：
| 任务类型 | 占比 | 推荐模型档位 | 单任务平均 token |
|---|---|---|---|
| 复杂推理/架构 | 10% | 旗舰 | 30-50 万 |
| 常规开发/写作 | 55% | 主力通用 | 15-25 万 |
| 简单批处理 | 35% | 轻量经济 | 3-8 万 |
按这个比例算，1.73 亿 token 里，旗舰只占约 1700 万，主力约 9500 万，轻量约 6000 万。这个结构下，账单会非常健康。如果你的实际分布是"旗舰占 50%"，那账单翻两三倍是必然的。
4.3 切换模型的时机判断
很多人不知道该什么时候切模型。我的判断标准很简单：看任务是否需要"想很久"。
如果任务的特点是"步骤明确、每步都不难、只是量大"，用轻量模型。如果任务是"每一步都依赖上一步的结论，中间任何一步错了后面全崩"，用旗舰模型。如果任务是"我大概知道怎么做，但懒得写"，用主力通用模型。
还有一个实用技巧：先用旗舰模型做一次规划，再用轻量模型执行。比如重构一个大项目，让旗舰模型输出一份详细的重构计划（哪些文件改什么、按什么顺序），然后让轻量模型照着计划逐个文件执行。这样既保证了方向正确，又把执行成本压到了最低。
5. 从 1.73 亿 token 反推使用强度与优化空间
5.1 这个用量说明什么
1.73 亿 token 一个月，平均每天约 577 万 token。按每天工作 8 小时算，每小时约 72 万 token，每分钟约 1.2 万 token。这个速率，说明 WorkBuddy 基本处于"持续运行"状态——不是偶尔问一句，而是挂着跑长任务、批量处理、自动化流程。
这种使用强度下，有几个数字特别值得关注：
- 单任务平均 token：如果单任务平均超过 50 万，说明任务粒度太粗，或者上下文管理有问题。
- 重试率：如果同一个任务反复重试超过 3 次，说明模型选错了，或者提示词写得不够清晰。
- 缓存命中率：前面说过，低于 30% 就是明显的优化信号。
5.2 三个最容易被忽视的浪费点
第一，把整个大文件塞进上下文。有些人习惯把几千行的文件整个丢给模型，其实模型只需要看相关的那几十行。正确做法是先做检索（grep、搜索），只把命中的片段喂进去。这一项就能省下大量输入 token。
第二，让模型"复述"已知信息。比如你让它改一个函数，它先把整个函数原样输出一遍再改。这种输出纯属浪费。可以在提示词里明确要求"只输出修改的部分，不要重复原文"。
第三，工具返回结果不做裁剪。很多工具（比如跑测试、读日志）返回的内容非常长，但真正有用的可能就几行。如果不在工具层做裁剪，这些垃圾内容会进入上下文，并且在后续每一轮里被重复计费。这是 agent 型工具最大的隐形开销。
5.3 一个可落地的优化清单
我把自己的优化动作整理成一份清单，你可以对照检查：
- 检查系统提示词里有没有动态内容（时间戳、随机数、变化的列表）
- 检查工具定义是否在一次会话内保持稳定
- 检查是否有"整个大文件进上下文"的情况，改成检索后片段注入
- 检查工具返回结果是否做了长度限制和内容裁剪
- 检查是否有"输出重复原文"的提示词习惯
- 检查任务分级是否合理，旗舰模型占比是否超过 20%
- 检查缓存命中率，低于 40% 就要专项优化
按这份清单逐条过一遍，通常能把总 token 消耗压下来 30% 到 50%，账单自然跟着降。
6. 算账之外：token 成本该怎么看待
6.1 不要只盯着单价
我见过太多人纠结"哪个模型每百万 token 便宜两毛钱"，却忽略了真正的成本大头——返工成本。一个便宜模型如果做不对任务，你要重试三次，总成本是贵模型一次做对的 1.5 倍，还搭进去你的时间。所以选模型的第一原则不是"便宜"，而是"一次做对的概率"。
6.2 把 token 当成"算力预算"来管理
1.73 亿 token 这个数字，本质上是一份"算力预算"。就像你管理服务器资源一样，token 也需要分配：哪些任务值得多花，哪些任务必须省着用。我的做法是给不同类型的任务设一个"预算上限"，比如单文件重构不超过 20 万 token，超了就说明方法有问题，停下来重新规划，而不是硬着头皮让模型继续跑。
6.3 一个反直觉的结论
用了这么久，我最大的体会是：省 token 的最好方法，不是少用，而是用对。把任务拆清楚、把上下文管好、把模型选对，token 消耗自然就下来了。反过来，如果你一边用旗舰模型跑简单任务，一边把整个代码库往上下文里塞，那再怎么"省"也是白搭。
1.73 亿 token 听起来吓人，但拆开看，它不过是一个重度使用者一个月的正常产出。真正值得关注的，不是这个数字本身，而是它背后反映的使用习惯——缓存命中率多少、模型分配是否合理、有没有明显的浪费点。把这些搞清楚了，账单是多少，心里自然就有数了。
最后分享一个我自己的小习惯：每个月月底把 token 用量按任务类型导出来，看看哪类任务消耗最多、哪类任务性价比最低。坚持几个月，你会对自己的使用模式有非常清晰的认识，优化起来也就有的放矢了。
