---
title: "什么是 Tokenize(分词)"
description: "大语言模型并不直接处理字符，而是处理 token；本文说明中英文与代码的分词差异，以及它如何决定调用成本、窗口预算和往上下文里塞文档的写法"
---

## Token:模型眼里的"字"

大语言模型不直接处理字符或单词,而是处理 **token**。Tokenize(分词)就是把文本切成 token 序列、再映射成整数 ID 的过程:

```text
"function calculateTotal(items) {"
        │  tokenizer(BPE)
        ▼
["function", " calculate", "Total", "(items", ") {"]
        ▼
[1723, 11294, 7575, 17444, 8850]   ← 模型实际看到的
```

主流模型(GPT 系列、Claude 系列)都使用 **BPE(Byte Pair Encoding)** 类算法:从字节开始,把语料中高频出现的相邻片段逐步合并成更大的单元。于是:

- 高频英文单词通常是 **1 个 token**(`function`、`return`);
- 低频词被拆成几段(`calculateTotal` → `calculate` + `Total`);
- 任何生僻字符最终都能回退到字节级表示,所以模型永远不会"不认识"某个字符,只是会用更多 token。

## 经验换算

| 内容 | 大致比例 |
| --- | --- |
| 英文散文 | 1 token ≈ 4 个字符 ≈ 0.75 个单词 |
| 代码 | 比英文散文略费,大量符号、缩进各占 token |
| 中文 | 1 个汉字 ≈ 1~2 个 token,**比英文按信息量算更贵** |
| JSON/日志 | 非常费,引号、括号、转义符全是 token |

这解释了几个日常现象:

- 同样一段话,中文提示词消耗的 token 常比英文多,**用中文和 Agent 交流没问题,但往上下文里塞大段中文文档要有预算意识**;
- 把一个 500KB 的 JSON 日志直接粘贴给 Agent,可能一下吃掉十几万 token;
- 压缩变量名并不能显著省 token(反而可能因为变成生僻组合被拆得更碎)。

## 为什么开发者必须关心 token

1. **计费单位就是 token**:API 按输入 token + 输出 token 计价,缓存命中的 token 打一折(见[缓存篇](/guide/prompt-caching))。
2. **上下文窗口按 token 计**:200K / 1M 说的都是 token 数,不是字符数(见[上下文窗口篇](/guide/context-window))。
3. **工具输出也是 token**:Agent 跑一条 `npm test` 打出 2000 行日志,这些日志会 tokenize 后进入上下文——所以 Claude Code 会截断超长命令输出,你自己写工具/脚本时也应该让输出精简(`| tail -20`、`--quiet`)。

## 实用技巧

- **估算**:粗略地,英文文本字节数 ÷ 4 ≈ token 数;精确计数可用 Anthropic 的 [count_tokens API](https://docs.claude.com/en/docs/build-with-claude/token-counting) 或 OpenAI 的 `tiktoken` 库。
- **在 Claude Code 里查看**:`/context` 命令可以看到当前上下文里系统提示、工具定义、MCP、消息各占多少 token。
- **控制粘贴物**:贴日志前先自己筛一遍;贴代码时只贴相关函数而非整个文件。
- **让 Agent 的"眼睛"省着用**:引导它用 `grep`/局部读取而不是整文件通读——这正是 [RepoPrompt](/guide/repoprompt) 和 [Explore 子代理](/guide/tool-explosion#对策四用子代理隔离高噪音工作) 要解决的问题。