人类打字习惯与Token计数

# 人类打字习惯与Token计数 来源：https://pankajpipada.com/posts/2026-05-08-human-habits-tokens/ 2026年5月8日 | 阅读时间：3分钟 人类打字追求速度、语气和习惯。分词器根据常见模式分割文本，供应商按token计费。这意味着诸如拼写错误、速记词、填充词、粘贴的ID以及多余的空格等普通习惯会改变token数量，却几乎不影响语义。 我是从一个很小的提示词注意到这一点的：5个词，2个拼写错误，13个token。我修正了拼写后再发送：6个token，包括句号。 下面的计数使用OpenAI的分词器（https://platform.openai.com/tokenizer）和Claude的API分词器（https://claude-tokenizer.vercel.app/）。总体而言，在我的使用中，相同文本在Claude上输出的token比OpenAI更多。这里的计数是针对独立字符串的。在实际提示词中，计数会因周围空格、标点和大小写而略有变化。 ## 拼写错误 字母颠倒、漏字母、重复字母、相邻键误触：这些都是常见的打字习惯，都会计费。 - `template`→`1`,`tempalte`→`3` - `loaded`→`1`,`lodaed`→`2`, Claude:`3` - `assistant`→`1`,`assitant`→`2`, Claude:`3` - `simple`→`1`,`simpel`→`2` - `like`→`1`,`liek`→`2` 意图相同。分割不同。 常见拼写会被压缩。罕见拼写会碎裂。在代码中，这会快速累积：同一个糟糕的标识符/变量名/函数名会出现在声明、引用、日志、错误、diff等各处。 当我为工作打字时（代码、提示词、短信等），我的左手比右手稍快，导致一些字母颠倒。我以前用谷歌搜索或发短信时从不纠正自己。现在看来这个差异居然有定价模型。 ## 词形 词形也很重要。快速检查： - `describe`→`1`,`describer`→`2`,`describers`→`3` - `error`→`1`,`errored`→`2` 一个小后缀对人类来说似乎无害。分词器可能会以非常不同的方式分割它。 ## 对话习惯 人类聊天包含大量低信号填充词： - 填充词：`just`、`basically`、`actually`、`really` - 犹豫词：`maybe`、`I think`、`kind of`、`sort of` - 客套话：`hey`、`please`、`thanks`、`sorry` - 结尾词：`etc.`、`or so`、`and all that`。`etc.`有点复杂。如果它替代了一个冗长的无用尾巴，可以节省token。如果只是挂在句尾，大多只是增加噪音。 - 聊天噪音：`lol`、`haha`、`...`、`!!`、`??` - transcript填充词：`uh`、`um`、`you know`、`like` 微小的表达习惯也计费： - `Good`→`1`/`Good...`→`2` - `Yes`→`1`/`Yes!!`→`2` - `Ok/Okay`→`1`/`Ok/Okay???`→`2` - `yes`→`1`/`yesss`→`3` - `really`→`1`/`reeeally`→`3` 这些有助于表达语气。很少有助于任务。 ## 输入更短不一定更便宜 人类优化按键次数。分词器优化常见文本。两者不是一回事。 - `please`→`1`/`pls`→ Claude:`2` - `thanks`→`1`/`thx`→`2` - `without`→`1`/`w/o`→`2`, Claude:`3` 大多数时候，标准词典词汇是1个token，而且几乎总是更明确、更清晰，更接近文本模型在训练时看到的内容，比速记词更好。 ## 静默的Token泄漏 有些东西不是对话式的，但出现在正常工作中，仍然会增加token： - UUID、哈希、时间戳、请求ID。例如UUID —`019d6ce9-7cfe-753a-b6d6-df719510c9e3`→`24`, Claude:`26` 例如RFC 3339时间戳 —`2026-05-08T21:00:00+05:30`→`16`, Claude:`17` - 长URL和文件路径 - 开头空格、结尾空格。正常的内部间距通常没问题。边界空白处会变得奇怪。 ## 结论 模型可能从所有这些中恢复语义。计费不会。 人类按习惯打字。分词器按模式计费。 这有点烦人，因为现在连`tempalte`都感觉像是一个需要纠正的计费项。