发送前先做 token 预算

团队第一次因为一条提示词争论价格时，通常是因为直觉给错了方向。直觉会说「用便宜模型就行」，而账单说的是另一件事：真正决定花费的不是每百万 token 的单价，而是你让它生成多少。

两侧成本，而不是一个价格

单次调用的花费由两部分相加：你发出去的输入 token，和模型回来的输出 token。它们的单价不同，通常输出贵三到四倍。

这个简单事实解释了大部分「为什么用了便宜模型却更贵」的情况。用低价模型生成一段长回答，总花费完全可以超过用高端模型做一次简短回答 —— 因为把变量从单价换成了长度。

长输入与长输出是两种工程问题

按主导因素把请求分成两类，预算就清晰了：

• 输入主导：翻译、总结、评审长文档。成本几乎全部由你粘贴进去的内容决定，模型的输出单价几乎不参与。
• 输出主导：生成、扩写、写代码。成本由你要求的长度决定，输入单价几乎不参与。

判断属于哪一类只需要问一句：这次任务里，长的那一边是我写的还是它写的？

一个可以在三十秒内做完的流程

1. 把提示词完整粘进 token 估算器 —— 包括系统提示与示例，它们同样是输入 token。
2. 按语言看估算：中文等宽字符约 1 token 字，其余约 1 token/4 字符。
3. 在候选模型之间切换，比较输入与输出两侧的数字。
4. 只在高价值的那次调用上换模型。同一批任务里，把简单重复的那些放到低价模型上通常就够了。

把估算当成尺度，而不是账单

任何在浏览器里做的估算都是启发式的，因为供应商的分词器不对外公开，而且各家不同。缓存命中、批量折扣、长上下文计费档位都会让实际价格偏离。

正确的用法是相对比较：同一段输入在几个模型之间的比例关系相当稳定，而绝对值会漂。把它当作量尺，而不是发票。

在发送之前算一次 token 与两侧成本，是这套流程里最便宜的一步。它不改变模型质量，但它会改变你把哪条提示词交给哪个模型 —— 而这件事通常比换模型本身省钱得多。