麦式参考 MickerBook Reference

Token

Token

也常被叫作:词元计费单位

你可能会这么说

「账单上写着用了多少 token,我不知道这是什么单位。」

Token Token

AI 把文字切成的小块,既是它的处理单位,也是计费和容量的单位。

AI 不是按字、也不是按词处理文字,而是按 token——一种介于两者之间的小块。中文大致一个字一个 token(有时两个字一个),英文常见单词多是一个 token,长单词会被切成几块。代码里的符号和缩进也各占 token。

知道这个有三个实际用处。一是估成本:费用按输入 + 输出的 token 总量算,所以贴一整个项目进去是真的会花钱,而且是每一轮都重复花。二是估容量上下文窗口的大小就是用 token 数表示的。三是解释延迟:输出越长越慢,因为它是一个 token 一个 token 生成的。

最容易被忽略的一点:在长对话里,历史消息会被反复重新计费。 你说的第一句话,在第二十轮时仍然会被再算一次。所以长对话的成本不是线性增长,而是越来越快。这也是「分几轮做、每轮给简短交接」比「一个对话干到底」更省钱的原因。

长什么样 真实可交互,不是截图

你好          → 约 2 tokens
Hello world   → 2 tokens
const x = 1;  → 约 6 tokens(符号和空格都算)
一段 500 字中文 → 约 500-700 tokens
✕ 花钱的用法把整个项目贴进去
在一个对话里连续干几小时
让它输出一大段无用的复述
✓ 省钱的用法只贴相关文件
分几轮做,每轮给简短交接
让它直接给结论和改动

这些数字是量级参考,不同模型的切法不一样。你只需要记住量级,不需要精确计算。

拆开看,里面有这几块

  1. 1
    输入 token Input

    你发过去的全部内容,包括历史消息和贴入的文件。

  2. 2
    输出 token Output

    它生成的内容。通常单价比输入贵。

  3. 3
    累计重算 Re-billing

    长对话里,历史部分每轮都会重新算一次输入。

容易搞混?这样区分

Token 上下文窗口 Context window

token 是单位,上下文窗口是上限。就像升是单位、油箱容量是上限。

看 上下文窗口
Token 字数 Character count

字数是给人看的,token 是给模型算的。中文大致接近,英文和代码差别很大——尤其代码里的符号会明显多算。

什么时候用得上

账单突然变高

先看有没有长对话没结束,或者反复贴大文件。这两个是最常见的原因。

回复很慢

多半是输出太长。要求它直接给结论和改动,不要复述你的需求。

长任务

分几轮做。每轮开头给一段简短交接,比让历史无限累积便宜得多。

你可以这样跟 AI 说

直接复制下面这段,把【】里的换成你的情况。它比一句「帮我加个 X」多说清楚了:改哪里、不许动啥、做完交什么。

回答时请注意成本和效率:

1. 不要复述我的需求,直接给结论和改动。
2. 需要看文件时先告诉我需要哪几个,我贴给你,不要要求整个项目。
3. 命令输出很长时,只贴关键部分(但报错原文要完整保留)。
4. 如果这个对话已经很长、你感觉早期内容可能已经丢失,直接告诉我,我们分一轮新的继续,你给我一段 5 行以内的交接(目标、已完成、下一步、必须遵守的约束)。

它说「做好了」,你怎么自己验

这是本站的重头戏。AI 最会的不是写代码,是说「已完成」。这一条,它通常最多做到「概念」这层:只是说清了要做什么,还没有任何东西在跑。

要亲眼看到这些,才算数

  • 看一眼平台的用量页面,确认实际消耗和你的感觉一致。
  • 如果成本异常,检查是否有超长对话或反复贴入的大文件。
  • 要求它不复述需求之后,观察输出长度是否真的下降。

它常这么糊弄你

  • 「贴的越多它理解越好」——不成立。内容过多时中间部分的注意力会下降,钱也白花。
  • 把「上下文窗口很大」当成「可以随便塞」。容量和效果是两件事。
  • 长对话不结束,以为只有新消息在计费。历史每轮都会重新算。

这是一个成本常识,停在「概念」层:知道量级就够,不需要精确计算。

考考你 选一个你觉得对的

为什么长对话的成本会越来越快地增长?