📑 本页目录（点开跳转）
主线 1 · 文字怎样进入模型
⏱ 9 分钟 ｜ ⭐ 主线第一站：先看这一页
🎯 一句话
模型既看不到汉字，也不知道“词”的意思。它先把文字切成一小块一小块的 token，换成编号，再把编号换成向量；后面所有“理解”和“生成”都发生在这些向量上。
先只记三件事
- token 不是字，也不一定是词。 “机器学习”可能是一个 token，也可能被切成多个；取决于模型的词表。
- token 是模型的计费和容量单位。 同样一段内容，切得更碎，就更贵、占的上下文也更多。
- 模型不擅长逐字符操作。 数字、拼写、倒序、精确计数交给程序，比让模型硬猜可靠得多。
跟着一个例子走
假设你输入：“猫追老鼠”。Tokenizer 可能切成 [猫] [追] [老鼠]，再把它们变为三个编号。编号本身没有意义；模型查一张很大的嵌入表，把每个编号换成一串几千维的数字。
这些数字不是人能直接读懂的中文释义。把它当成每个 token 的“可计算名片”：后面的 Transformer 会不断修改名片，让“猫”不只是猫，而是“正在追老鼠的那只猫”。
词表不是人工逐条写出来的
最常见的造词表思路叫 BPE。开始时把文本切得很细，然后反复统计“哪两个相邻小块最常一起出现”，把高频组合合并成一个新 token。于是常见词、常见词根、常见代码片段会变短；罕见名字、拼写错误和生僻词会被拆得更细。
这就是为什么模型可能把英文 unbelievable 切成 un + believ + able，也解释了为什么不同模型的 token 数不能直接互相套用：词表不同，切法就不同。
为什么不干脆“一字一 token”或“一词一 token”？
一字一 token 的好处是永远不会遇到生词，但句子会很长，注意力计算和费用都会变高；一词一 token 虽然短，却会碰到无限多的新词、名字和拼写。子词切分是在“词表不能无限大”和“句子不能太长”之间找折中。
实用提醒：问模型接口价格、上下文长度、输出上限时，都看 token，不看汉字数。中文、代码、JSON 的 token 密度通常不同；不能只拿字符数去猜。
上下文窗口：它能带多少张名片进来？
上下文窗口就是一次能放进模型的 token 总数，包含：你的指令、历史聊天、检索到的资料，以及模型刚刚生成的内容。窗口大不等于每一段都能被同样好地利用；重要信息仍要放得清楚、取得精准。
容量和效果是两件事
“支持 128K 上下文”只说明这 128K token 能塞进模型；它不保证模型能把每一段都用好。真实长文任务还要处理干扰、相似段落、跨段关联和“中间信息容易被忽略”等问题。
实际写提示词时，可以把内容按作用放：稳定规则放开头，当前任务与最关键的材料放靠近结尾的位置；长资料不要无差别整本塞入，而是先检索、压缩，再把少量真正相关的片段给模型。
✅ 检查点
- 为什么“模型看到的不是汉字”？
- 为什么很长的聊天记录会挤掉可用空间？
- 为什么精确数数、反转字符串更适合交给工具？
点开核对
模型先把文字换成 token 编号和向量；窗口装的是所有输入与输出 token；逐字符题目会被切分方式干扰，程序更可靠。
🔗 想再深一层，去哪一套
| 去哪 | 为什么 |
|---|---|
| 智能体工程教程 04 · 上下文工程 | ⭐ 窗口就这么大，于是得管：放什么、什么时候压缩、什么时候丢 |
| AI 基础设施 16 · KV Cache | 「能带多少张名片」的成本那一面：上下文里每个 token 都要占一份缓存 |
🛑 可以停在这里
到这里已经够进入下一章。BPE、词表训练、多语言切分差异，只有你要做分词器或批量省 token 时才需要深挖。
⚡ 走神救援
文字会先被切成 token，再变成向量。后面的“模型理解句子”，其实是在不断更新这些向量。下一页看：这些 token 怎样互相交换信息。