Token：AI的"词汇单位"

本章要点

在上一章，我们反复提到"上下文窗口"是用 Token 来衡量的。你可能已经对这个词感到好奇：Token 到底是什么？为什么 AI 不直接用"字数"来计算？为什么同样是 100 个字，中文和英文消耗的 Token 数量不一样？

这一章，我们来揭开 Token 的神秘面纱。理解 Token，不仅能帮你更准确地估算 AI 的使用成本，还能让你在编写提示词、处理代码时做出更明智的选择。你会发现，Token 这个概念看似技术细节，实则与日常使用的方方面面都息息相关。

读完这一章，你会获得：

• 理解 Token 的本质：AI 处理文本的基本单位
• 了解 Token 的计算规则：为什么不同语言、不同内容消耗的 Token 不同
• 掌握 Token 与字数的关系：如何快速估算一段文本的 Token 数量
• 认识 Token 对使用成本的影响：API 计费背后的逻辑
• 学会优化 Token 使用：如何在保证效果的前提下节省成本

从"字"到"Token"：为什么要换个单位？

一个直观的困惑

让我们从一个简单的例子开始。

假设你要估算一段文字的长度，你会怎么做？数一下有多少个汉字，或者多少个英文单词，对吧？这是人类自然而然的做法。

但当你查看 AI 产品的技术文档时，你会发现它们谈论的是"Token 数量"——上下文窗口是"128K Token"，API 价格是"每百万 Token 3 美元"。为什么 AI 领域不用"字数"，非要发明一个"Token"的概念呢？

这背后有深刻的技术原因。

计算机眼中的文本

要理解 Token，我们首先要理解：计算机是如何"看"文本的。

对你来说，"猫"是一个字，"cat"是一个单词，它们都是有意义的语言单位。但对计算机来说，这些东西最初只是一串数字编码。

在计算机内部，所有的文本都以某种编码形式存储。最常见的是 UTF-8 编码，在这种编码下：

• "猫"需要 3 个字节来表示
• "A"只需要 1 个字节
• "🐱"这个表情符号需要 4 个字节

如果你用"字节数"来衡量文本长度，你会发现一个尴尬的事实："猫"（3 字节）比"A"（1 字节）"长"，但这和我们直觉上的"字数"完全不同。

更重要的是，字节是计算机存储的单位，不是语言处理的单位。当 AI 要"理解"一段文字时，它需要的不是字节，而是有意义的语言片段。

Token：AI 处理文本的基本单位

Token 可以通俗地理解为：AI 处理文本时的最小有意义单位。

它可能是一个字、一个词，甚至可能是半个词或一个标点符号。具体怎么切分，取决于 AI 使用的"分词器"（Tokenizer）——这是一个专门的算法，负责把原始文本切分成 Token 序列。

让我们看几个具体的例子（以 GPT 系列模型使用的分词器为例）：

文本	Token 数量	说明
"你好"	2	每个汉字通常对应 1 个 Token
"Hello"	1	常见英文单词通常是 1 个 Token
"AI"	1	常见缩写也是 1 个 Token
"unbelievable"	3	被拆成 "un" + "believ" + "able"
"12345"	5	连续数字通常每个数字是 1 个 Token
"🐱"	1-3	表情符号的 Token 数因模型而异

看到这个表格，你可能已经发现了规律：Token 的切分并不是简单地按"字"或"词"来划分，而是基于统计规律——那些在训练数据中经常一起出现的字符组合，会被切分成一个 Token。

为什么要这样切分？

你可能会问：为什么不直接按字切分？那样不是更简单吗？

答案是：效率。

想象一下，如果 AI 每次处理文本都按单个汉字来，那么它要学会"人工智能"这个概念，就需要分别理解"人"、"工"、"智"、"能"这四个字，然后再把它们组合起来。这不仅效率低下，而且很多词语的含义并不是组成它的字的简单相加。

而如果"人工智能"作为一个整体被切分成 1-2 个 Token，AI 就能直接把这个概念当作一个单位来学习，效率要高得多。

同样，对于英文，把 "unbelievable" 切分成 "un" + "believ" + "able" 也是基于类似的逻辑：这三个部分都有独立的意义（否定前缀、词根、后缀），分别学习它们，比死记硬背 "unbelievable" 这个词的完整形式更加灵活——这样 AI 遇到 "uncomfortable"、"unhappy" 等新词时，也能举一反三。

Token 是如何计算的？

分词器的工作原理

分词器是 Token 计算的核心。它的工作原理可以简单概括为：

在训练阶段，分词器会分析海量的训练数据，找出哪些字符组合最常一起出现。然后，它会把这些高频组合定义为独立的 Token。

在使用阶段，当新的文本输入进来时，分词器会尽可能地用定义好的 Token 去匹配文本，把文本切分成最短的 Token 序列。

这个过程叫做"编码"（Encoding）——把人类可读的文本，转换成 AI 可处理的 Token 序列。

中英文的差异

这是你在使用 AI 时最需要了解的 Token 计算规则之一。

中文：由于汉字数量庞大，而且每个字都是独立的表意单位，中文的 Token 切分相对简单——通常每个汉字对应 1 个 Token，常见的两字词、三字词可能被切分成 1 个 Token。

英文：英文的 Token 切分就复杂得多。常见单词（如 "the", "and", "is"）通常是 1 个 Token，但生僻词、复合词、专业术语往往会被切分成多个 Token。

让我们看一个直观的对比：

中文："人工智能正在改变世界"
Token 序列：[人工][智能][正在][改变][世界] 或类似
数量：约 5-6 个 Token

英文："Artificial intelligence is changing the world"
Token 序列：[Artificial][ intelligence][ is][ changing][ the][ world]
数量：6 个 Token

注意英文中的空格：在很多分词器中，空格会附着在后面的单词上，成为那个 Token 的一部分。这也是为什么上面的英文例子中，"intelligence" 前面有一个空格。

代码的 Token 计算

作为用 AI 辅助编程的读者，你肯定会关心：代码的 Token 是怎么计算的？

代码的 Token 计算遵循同样的原则，但有一些特点值得注意：

1. 标点符号和特殊字符

在代码中，括号、分号、引号等符号频繁出现。这些符号通常是独立的 Token。

# 这行代码
def hello():

# 可能被切分成
[def][ hello][():]
# 或其他类似形式

2. 缩进很重要

Python 代码中的缩进（空格或 Tab）也会被计入 Token。每一级缩进都可能增加 Token 数量。

3. 变量名和函数名

user_name = "张三"  # user_name 可能被切分成 2-3 个 Token
username = "张三"   # username 可能是 1 个 Token

这就是为什么在编写提示词时，简洁的变量名不仅对人类友好，也能节省 Token。

4. 重复代码的 Token 消耗

# 方案 A：重复 10 次
print("Hello")
print("Hello")
# ... 重复 10 次

# 方案 B：使用循环
for i in range(10):
    print("Hello")

虽然两种方案功能相同，但方案 A 会消耗更多的 Token。当你在上下文中放入大量代码时，这种差异会累积起来。

直观估算 Token 数量

虽然精确计算 Token 需要使用专门的分词器工具，但在日常使用中，我们可以用一些经验法则来快速估算：

中文：1 个汉字 ≈ 1 个 Token

英文：1 个 Token ≈ 0.75 个单词（或者说，100 个英文单词约等于 130-150 个 Token）

代码：代码的 Token 密度通常比自然语言高，因为有很多符号和缩进。大致可以按 1 行代码 = 5-15 个 Token 来估算，具体取决于代码的复杂程度。

这些估算虽然不精确，但足以帮你在日常使用中做出判断：这段文本会不会超出上下文窗口？这个提示词会不会太长？

Token 与上下文窗口的关系

为什么用 Token 而不是字数？

现在我们可以回答开头提出的问题了：为什么上下文窗口的大小用 Token 来衡量，而不是字数或字节数？

原因一：公平性

如果用"字数"，那中文用户就占了便宜——同样意思的内容，中文通常比英文短。如果用"字节数"，英文用户占便宜。Token 提供了一种相对公平的衡量标准，不管你用什么语言，处理同样的信息量，消耗的 Token 数量大致相当。

原因二：一致性

AI 模型内部处理的就是 Token 序列。无论输入是中文、英文还是代码，最终都转换成 Token。用 Token 来衡量，能准确反映模型实际处理的工作量。

原因三：成本控制

Token 与计算资源直接相关。每一个 Token 都要经过模型的层层计算，Token 越多，计算量越大，成本越高。用 Token 计费，能更准确地反映资源消耗。

上下文窗口的实际含义

让我们重新理解一下上下文窗口的数值。以 Claude Sonnet 4 的 200K Token 为例：

对于中文：大约能容纳 15 万汉字。这相当于一本 300 页的书。

对于英文：大约能容纳 15 万个单词。这相当于一本长篇小说。

对于代码：取决于代码的密度，大约能容纳 1-3 万行代码。

但要注意，这是理论上限。实际使用中，你还要考虑：

• 系统提示词通常占几百到几千 Token
• AI 的回复也要消耗 Token（而且这部分是你无法预先控制的）
• "迷失在中间"现象意味着，即使内容在窗口范围内，模型对中间部分的关注度也会降低

Token 的"输入"与"输出"

在使用 AI 的 API 时，你会发现 Token 被分为"输入 Token"和"输出 Token"：

输入 Token：你发送给 AI 的所有内容，包括你的问题、提供的背景信息、对话历史等。

输出 Token：AI 生成的回复。

这两部分的计费通常是分开的。以 2025 年底的市场行情为例，输出 Token 的价格通常是输入 Token 的 3-5 倍。原因很简单：生成输出比处理输入要复杂得多——AI 需要一个字一个字地预测，每生成一个 Token 都要进行一次完整的推理。

这意味着，如果你让 AI 生成很长的回复，即使你的输入很短，成本也会显著增加。

Token 如何影响你的使用成本

API 计费的基本逻辑

如果你通过 API 使用大语言模型，费用几乎完全由 Token 数量决定。

典型的计费方式是：

总费用 = (输入 Token 数量 × 输入单价) + (输出 Token 数量 × 输出单价)

不同模型、不同服务商的价格差异很大，但基本逻辑是一样的：Token 越多，费用越高。

一个实际的例子

假设你正在使用 Claude Sonnet 4 的 API，价格约为：

• 输入：3 美元 / 百万 Token
• 输出：15 美元 / 百万 Token

你让 AI 帮你审查一段代码：

• 你发送了 5000 Token 的代码和问题（输入）
• AI 生成了 2000 Token 的审查意见（输出）

这次调用的费用约为：

• 输入：5000 × 3 / 1,000,000 = 0.015 美元（约 1 毛钱人民币）
• 输出：2000 × 15 / 1,000,000 = 0.03 美元（约 2 毛钱人民币）
• 总计：约 3 毛钱人民币

看起来很少，对吧？但如果你：

• 在一个很长的对话中继续发送请求（每次都要附带历史记录）
• 让 AI 生成非常详细的回复
• 频繁地进行 API 调用

成本就会迅速累积。

长对话的隐性成本

这是使用 API 时最容易忽视的成本陷阱。

假设你进行了一个长达 100 轮对话的会话，平均每轮：

• 你的消息：500 Token
• AI 的回复：1500 Token

到第 100 轮时，上下文已经积累了约 20 万 Token 的历史记录。这时你发送一条新的 500 Token 的消息：

输入 Token = 20 万（历史）+ 500（新消息）= 20.05 万 Token

仅仅这一条消息的成本：

• 输入：200,500 × 3 / 1,000,000 = 0.6 美元（约 4.2 元人民币）

而且随着对话继续，这个成本还会持续上升。这就是为什么当你使用 API 开发应用时，需要特别关注对话长度管理。

优化 Token 使用的实用技巧

技巧一：精简提示词

在编写提示词时，问自己：这句话真的必要吗？

优化前：

你好，我是一个编程初学者，正在学习 Python。我想请教一个问题。
我最近在写一个项目，是关于数据处理的。我的代码遇到了一个问题。
问题是这样的：...

优化后：

Python 数据处理问题：...

多余的客套话、背景介绍会消耗 Token，但对解决问题没有实质帮助。直接进入主题，既节省 Token，也能让 AI 更聚焦于核心问题。

技巧二：使用简洁的变量名和格式

在提供代码时：

# 消耗更多 Token
user_account_information = fetch_data_from_database(user_identifier)

# 消耗更少 Token（功能相同）
user_info = fetch_data(db, user_id)

当然，代码的可读性仍然是最重要的。不要为了节省 Token 而写出难以理解的代码。但在提示词中提供示例代码时，简洁的写法是更好的选择。

技巧三：控制输出长度

如果你不需要长篇大论，可以在提示词中明确要求简洁：

请简要说明...
用 3 句话总结...
只列出关键要点，不要详细解释...

这样可以有效减少输出 Token，降低费用，同时也能得到更聚焦的回答。

技巧四：适时开启新对话

正如我们在上一章讨论的，当对话变得很长时，开启一个新会话，把关键信息整理后重新发送，不仅能提高回答质量，也能显著降低成本——你不需要为几十轮历史记录付费。

技巧五：使用系统提示词设置默认值

如果你使用的平台支持系统提示词（System Prompt），把通用的要求放在那里：

系统提示词：请用中文回答，保持简洁，代码示例使用 Python。

这样就不需要在每次对话中重复这些要求，节省了重复说明的 Token。

技巧六：分块处理大文档

当你需要 AI 处理一份很长的文档时，不要一次性全部发送。分成几个部分分别处理：

1. 先把文档分成几个逻辑段落
2. 分别发送给 AI 处理
3. 最后让 AI 汇总结果

这样做有两个好处：

• 避免超出上下文窗口
• 每个部分都能得到更好的处理质量（避免"迷失在中间"）
• 总体 Token 消耗可能更低（因为不需要一次性加载整个文档）

Token 计算工具

在线 Token 计算器

如果你想精确计算一段文本的 Token 数量，可以使用在线工具：

• OpenAI Tokenizer：https://platform.openai.com/tokenizer
• Tiktoken（OpenAI 的官方库）：可以在本地使用

这些工具使用与实际模型相同的分词器，计算结果准确。

编程中的 Token 计算

如果你需要在程序中计算 Token，可以使用相应的库：

Python 示例：

import tiktoken

# 获取 GPT-4 使用的分词器
encoding = tiktoken.encoding_for_model("gpt-4")

# 计算 Token 数量
text = "你好，世界！"
tokens = encoding.encode(text)
print(f"Token 数量: {len(tokens)}")
print(f"Token 列表: {tokens}")

# 解码回文本
decoded = encoding.decode(tokens)
print(f"解码结果: {decoded}")

不同模型可能使用不同的分词器。GPT-4 和 GPT-3.5 使用的是 cl100k_base，而 Claude 使用的是不同的分词器。在使用时要注意选择对应的分词器。

估算的实用公式

如果没有精确计算工具，可以使用这些经验公式：

中文：

Token 数量 ≈ 汉字数量 × 1.0 到 1.2

英文：

Token 数量 ≈ 单词数量 × 1.3

代码：

Token 数量 ≈ 行数 × 10（粗略估算）

这些估算值在实际使用中通常够用，特别是在你需要快速判断文本是否会超出上下文窗口时。

常见误区与注意事项

误区一：认为 Token = 字数

很多人刚开始接触 Token 时，会简单地认为 1 个 Token = 1 个字或 1 个单词。这个误解会导致严重的估算错误。

实际上：

• 中文通常是 1 字 ≈ 1 Token
• 英文通常是 1 词 ≈ 1.3 Token
• 代码的 Token 密度更高

误区二：忽略系统提示词的 Token

在使用 ChatGPT、Claude 等产品时，你看不到系统提示词，但它确实占用了 Token。当你觉得"明明没发多少内容，怎么就超出限制了"时，可能是系统提示词占用了相当一部分空间。

误区三：不考虑输出 Token 的成本

很多人在估算成本时只考虑输入，忽略了 AI 回复的 Token 消耗。但实际上，输出 Token 通常更贵（单价是输入的 3-5 倍），而且长回复会迅速累积成本。

误区四：认为压缩文本就能大幅降低 Token

虽然精简提示词能节省一些 Token，但不要期望通过压缩文本大幅降低成本。因为：

• 有意义的压缩空间有限
• Token 切分是基于统计规律，不是基于语义，有时候"压缩后"的文本反而消耗更多 Token
• 过度压缩可能导致信息丢失，影响 AI 的理解

与其绞尽脑汁压缩文本，不如优化整体使用策略：精简提示词、控制输出长度、适时开启新对话。

从 Token 看 AI 的本质

理解 Token，不仅仅是学会计算成本。它还能帮助我们更深刻地理解 AI 的工作方式。

AI 看到的是 Token，不是文字

当你给 AI 发送"你好"时，AI 看到的不是这两个汉字，而是类似 [24323, 51245] 这样的 Token ID 序列。

当你在阅读这段话时，你能直接理解每个字的意义。但 AI 需要先把 Token 转换成内部的向量表示，然后在神经网络中进行复杂的计算，才能"理解"（或者说"处理"）这段文本。

这不是说 AI 的理解方式比人类低级——只是不同。人类经过亿万年的进化，大脑已经优化了处理语言的神经回路。而 AI 需要在没有任何先验知识的情况下，完全从数据中学习语言的规律。

Token 就是这个学习过程的中间产物：它把连续的语言切分成离散的单位，让 AI 能够逐个处理、逐个学习。

Token 决定了 AI 的"粒度"

Token 的切分方式，某种程度上决定了 AI 处理语言的"粒度"。

如果 Token 切分得很细（比如每个字符都是独立 Token），AI 能学到很精细的语言规律，但处理效率会降低。

如果 Token 切分得很粗（比如把整个常用词组都切成一个 Token），处理效率会提高，但灵活性会降低——遇到训练数据中没有的词组，AI 可能处理不好。

现代分词器在这之间寻找平衡：常用词作为独立 Token，生僻词切分成子词（subword）。这让 AI 既有足够的词汇量，又能处理新词和拼写错误。

Token 是理解 AI 局限性的窗口

理解了 Token，我们就能更好地理解 AI 的一些"奇怪"行为：

为什么 AI 有时会混淆形近字？

因为 Token 是基于统计的，不是基于字形。如果两个词在训练数据中经常被混淆，AI 学到它们时就会产生混淆。

为什么 AI 处理数字计算会出错？

因为数字通常被切分成独立的 Token，长数字序列对 AI 来说是一串没有内在规律的 Token，而不是具有数学意义的数值。

为什么 AI 能写诗却算不准复杂数学题？

因为诗歌的语言模式在训练数据中大量存在，AI 学得很好。但精确计算的规律需要真正的数学理解，而不仅仅是模式匹配。

Token 是 AI 与语言之间的接口。理解这个接口的特点，就能理解 AI 能力的边界。

小结

这一章，我们深入探讨了 Token 这个看似技术细节、实则至关重要的概念。

Token 是 AI 处理文本的基本单位。它不是简单的"字"或"词"，而是基于统计规律切分的语言片段。中英文的 Token 计算方式不同，代码的 Token 密度通常比自然语言更高。

上下文窗口的大小是用 Token 来衡量的。理解这一点，能帮你更准确地判断 AI 能处理多长的内容，以及什么时候会开始"失忆"。

Token 直接影响使用成本。无论是通过 API 开发应用，还是在使用有额度限制的产品，优化 Token 使用都是重要的技能。精简提示词、控制输出长度、适时开启新对话，都是有效的策略。

Token 也是理解 AI 本质的窗口。它让我们看到：AI 不是在"阅读"文字，而是在处理离散的符号序列。这种处理方式既有惊人的能力，也有固有的局限。

随着你对 AI 使用的深入，Token 这个概念会变得越来越自然。你会下意识地估算提示词的长度，会在意代码的简洁程度，会在长对话时考虑开启新会话。这些习惯，会让你成为一个更高效的 AI 使用者。

至此，第五章关于 AI 基础原理的内容就全部结束了。从 AI 如何学习，到大语言模型的基本概念，再到上下文窗口和 Token，我们已经建立起对 AI 工作原理的系统性理解。

下一章，我们将回到实践，开始探索 AI 辅助前端开发的世界。带着你对 AI 原理的新理解，你会发现自己能更聪明、更有效地使用这些工具。

练习

思考题 1：Token 计算实践

估算以下文本的 Token 数量（分别估算中文部分和英文部分）：

人工智能（Artificial Intelligence）是计算机科学的一个分支，
它企图了解智能的实质，并生产出一种新的能以人类智能相似的方式做出反应的智能机器。

然后用在线 Token 计算器验证你的估算，看看误差有多大。思考：为什么实际结果和你的估算有差异？

实践题 2：观察不同内容的 Token 消耗

准备三段长度相近但内容不同的文本：

1. 一段中文散文
2. 一段英文技术文档
3. 一段 Python 代码

使用 Token 计算器，分别计算它们的 Token 数量。比较：

• 哪种内容的 Token 密度最高？
• 为什么代码的 Token 消耗通常比自然语言高？
• 如果这三段文本都在你的提示词中，你会如何安排它们的顺序？

思考题 3：成本优化策略

假设你正在开发一个 AI 应用，需要频繁调用 API。当前的平均请求：

• 输入：3000 Token
• 输出：2000 Token
• 每天调用 1000 次

计算当前每天的成本（假设输入 3 美元/百万 Token，输出 15 美元/百万 Token）。

然后设计一个优化方案，目标是在不影响用户体验的前提下，将成本降低 30% 以上。你的方案是什么？有哪些取舍？

实践题 4：探索分词器的边界

使用在线 Token 计算器，测试以下内容：

1. 常用词 vs 生僻词：比较 "hello" 和 "sesquipedalian" 的 Token 数
2. 有无空格：比较 "helloworld" 和 "hello world" 的 Token 数
3. 数字：比较 "1234567890" 和 "1 2 3 4 5 6 7 8 9 0" 的 Token 数
4. 特殊字符：测试各种标点符号、表情符号的 Token 消耗

观察规律，思考：什么样的文本写法会消耗更多 Token？什么样的写法更节省？

讨论题 5：Token 与语言公平性

由于分词器的训练数据主要来自英文互联网，中文用户在使用时通常需要消耗更多的 Token（同样意思的内容，中文可能需要 1.5-2 倍的 Token）。

这带来几个问题：

1. 成本公平性：中文用户使用同样的服务，需要支付更高的费用
2. 性能影响：同样的上下文窗口，中文能容纳的内容更少
3. 技术原因：为什么中文的 Token 效率通常低于英文？

你认为这个问题应该如何解决？是否有更好的分词方案？

思考题 6：未来的 Token

现在，Transformer 架构和基于 Token 的处理方式是主流。但研究者正在探索其他可能性：

• 用字节级模型直接处理原始文本，不需要分词
• 用更智能的分词方式，根据语义动态切分
• 用多模态 Token 统一处理文本、图像、音频

你认为 Token 这个概念在未来会如何演变？它会消失，还是会以新的形式继续存在？