Token 和上下文窗口------AI 记性的秘密
跟 AI 聊天，聊到后面时不时会遇到一种情况：它开始「降智」了。
开头还好好的，问什么答什么。再往后，它开始答非所问，甚至胡说八道。第一反应是反思自己------是不是没描述清楚？prompt 写得不够好？
跟你的 prompt 没关系。是 AI 的短期记忆满了。
它能记住的东西有硬上限。前面说的话它努力记着，但聊到一定长度，最早的内容就被挤了出去。开头一丢，后面的回答自然会跑偏。
这背后是两个词在起作用：Token 和上下文窗口。不复杂，但 AI 记得住多少、花多少钱、用得爽不爽，全跟它们绑在一起。
Token：AI 的「最小阅读单位」
一个字 ≠ 一个 Token
大多数人以为 AI 是「一个字一个字」读的。不是。
AI 的最小阅读单位叫 Token。一个 Token 大约等于：
-
中文：一个汉字 ≈ 1.5-2 个 Token。比如「你好」≈ 2 个 Token。
-
英文：一个常见单词 ≈ 1 个 Token。比如 "hello world" ≈ 2 个 Token。
-
代码 ：
console.log("hello")这种一行语句 ≈ 5-6 个 Token。代码里的括号、引号、换行全是独立 Token。 -
数字和符号 ：
2026和@各算 1 个 Token。
一个最简单的经验公式：
| 内容 | 大约等于多少 Token |
|---|---|
| 1 个中文字 | ~1.5 Token |
| 1 个英文单词 | ~1 Token |
| 1 行代码 | ~5-10 Token |
| 一个不太标准的经验：1000 个中文字 | ~1500-2000 Token |
为什么不按字算
因为 AI 用的是子词分词（Subword Tokenization）。拿"人工智能"这个词举例子------AI 的词表里如果已经有"人工智能"这整个词，它就算 1 个 Token。如果词表里有"人工"和"智能"但没连着的，它就拆成 2 个 Token。
常见的词在词表里，直接成一个 Token；生僻词会被拆成更小的片段。
这意味着什么？同样的意思，用常见词表达更省 Token。 "我很快乐" 比 "余心甚悦" 消耗更少 Token。对 AI 来说，大白话比古文省钱------不仅好理解，还少占地方。
上下文窗口：AI 的「短期记忆硬盘」
一个比喻
想象 AI 是一台摄像机，它的上下文窗口就是在录的一卷磁带。你每说一句话，磁带就往后录一段。AI 每次回答你时，都会重放整卷磁带来理解当前的对话。磁带录满了，最早录的东西就被自动覆盖------AI 忘掉了开头。
上下文窗口的大小，就是这卷磁带能录多长。
不同模型的「记忆容量」
| 模型 | 上下文窗口 | 大约等于 |
|---|---|---|
| Claude 3.5 Sonnet | 200K Token | 约 15 万个中文字，或一整本《活着》 |
| GPT-4o | 128K Token | 约 10 万个中文字 |
| Gemini 2.0 | 1M Token | 约 75 万个中文字，或一整部《三体》 |
| DeepSeek V4 Pro / Flash | 1M Token | 约 75 万个中文字 |
| Kimi K3（月之暗面） | 1M Token | 约 75 万个中文字 |
| 通义千问 Qwen3.7-Max | 1M Token | 约 75 万个中文字 |
| 智谱 GLM-5.2 | 1M Token | 约 75 万个中文字 |
15 万个中文字是什么概念？一本余华的《活着》大约 12 万字。也就是说，你跟 Claude 聊的前后对话加起来，差不多可以塞一整本《活着》进去------AI 都能「记住」。
而如果你用的是 DeepSeek V4、Kimi K3、Qwen3.7-Max 或 GLM-5.2 这些国产新模型，上下文窗口到了 100 万 Token------大约 75 万个中文字，够塞一整部《三体》。实际上，2026 年国产模型已经全面标配 1M 上下文窗口了。这对平常阅读长文档、分析代码仓库、做长对话来说，是个实打实的体验提升。
但注意，这只是理论上限。实际体验中，你把一部长篇小说整本丢进去，AI 可能对中间部分的信息抓取没那么准------就像你通宵读完一本厚书、第二天让你回忆第 137 页第 3 段写了啥，你也未必能精准复述。
上下文窗口里装的东西
不是只有你打的字------上下文窗口装的是整场对话的全部内容：
| 内容 | 占不占窗口？ |
|---|---|
| 你输入的每一句话 | ✅ 占 |
| AI 输出的每一句话 | ✅ 占 |
| AI 读取的每个文件内容 | ✅ 占 |
| 搜索结果、日志输出 | ✅ 占（而且是大量占） |
| 系统提示词（AI 的行为规则） | ✅ 占（通常几十 KB） |
| SubAgent 返回的结论 | ✅ 占（但中间过程不占------这就是 SubAgent 的价值） |
一句话：你让 AI 读一个 5000 行的日志文件，这 5000 行全塞进了上下文窗口。这也是为什么「让 AI 跑测试」这件事经常让对话变慢变笨------几千行错误日志一下子挤满了上下文窗口。
上下文污染：当「记忆」被垃圾填满
上面说的「日志刷屏」问题，学名叫上下文污染。
你本来让 AI 帮你改一个 Bug。你说了问题，AI 开始读代码------正常。然后 AI 跑了个测试------哗啦啦输出 300 行编译错误。你又让它搜了下相关 Issue------又是 15 条讨论记录。此时上下文窗口已经塞满。你再问「所以刚才那个 Bug 怎么修？」------AI 可能已经不记得一开始你描述的问题了。
你的原始问题信息，在上下文窗口中已经被后来涌入的日志和搜索结果挤到了很远的位置。AI 虽然还能「看到」开头，但就像人翻一份 50 页的文档------最前面几页的内容，注意力覆盖不到了。
该派 SubAgent 的时候就派出去------把会刷屏的脏活隔离在外面，别让它淹了主对话。
Token 的另一层身份：计价单位
如果你只免费用 AI 聊天，Token 跟你关系不大。但如果你开始大量使用 AI ，或者开发 AI 应用，Token 就是你的账单：
API 计费是按 Token 算的
各厂商都是按「每 1M Token」（100 万 Token）计价。大模型（如 Claude Opus）单价贵，小模型（如 Claude Haiku）单价便宜。
一个直观对比：
| 模型 | 输入价格（每 1M Token） | 《活着》输入费 |
|---|---|---|
| Claude Haiku | ≈ ¥7 | ≈ ¥1.3 |
| Claude Sonnet | ≈ ¥22 | ≈ ¥4.0 |
| Claude Opus | ≈ ¥110 | ≈ ¥20 |
| GPT-4o | ≈ ¥36 | ≈ ¥6.5 |
| DeepSeek V4-Flash | ¥1 | ¥0.18 |
| DeepSeek V4-Pro | ¥3 | ¥0.54 |
| 通义千问 Qwen3.7-Flash | ≈ ¥0.7 | ≈ ¥0.13 |
| 智谱 GLM-5.2 | ¥8 | ¥1.44 |
| Kimi K3 | ¥20 | ¥3.6 |
价格浮动，以各厂商官网为准。这里只给量级感受。
不只是输入------输出也要钱
大多数模型的输出 Token 比输入 Token 贵。比如 Claude Sonnet 输入约 ¥22/1M Token、输出约 ¥110/1M Token------输出是输入的 5 倍。DeepSeek V4-Pro 输入 ¥3/1M、输出 ¥6/1M，也是输出更贵，但绝对值低了一个数量级。同样是「让 AI 写一篇 5000 字长文」，用 DeepSeek 的费用不到 Claude Sonnet 的 1/15。
另外提一嘴，DeepSeek V4 今年 7 月刚搞了峰谷定价------北京时间上午 9-12 点、下午 2-6 点是高峰期，API 价格翻倍，V4-Pro 输入涨到 ¥6/1M；其余时间平价。算是个有意思的省钱细节：如果只是日常批量跑任务，错开高峰期就行。
省 Token 的几个思路
提问之前，先想：AI 真需要知道这个吗？很多人习惯把整份文件贴过去，其实 AI 只需要其中一小段。对话短而精，Token 自然就省下来了。
另外一个容易被忽略的事：不同的活，用不同档位的模型。 同一个任务用 Haiku 替代 Opus，费用可能差 15 倍。有团队从月费一万七降到六千多，全靠把模型匹配到合适的任务：
| 任务类型 | 海外模型 | 国内模型 | 理由 |
|---|---|---|---|
| 读文件、搜代码 | Haiku | DeepSeek V4-Flash / Qwen3.7-Flash | 便宜够用，没必要上大模型 |
| 代码审查、重构 | Sonnet | DeepSeek V4-Pro / Kimi K3 | 性价比最佳 |
| 架构决策、安全审计 | Opus | DeepSeek V4-Pro（思考模式）/ Kimi K3 | 分析深，值得花时间 |
| 写文档、写注释 | Haiku | Qwen3.7-Flash / DeepSeek V4-Flash | 机械性强，便宜最关键 |
这里有必要单独说一下国内模型的性价比。DeepSeek V4-Flash 的 API 单价跟 Claude Opus 差了超过 100 倍------用 Opus 读一整本《活着》要花 ¥20，用 DeepSeek V4-Flash 只花 1 毛 8。Qwen3.7-Flash 更便宜，不到 1 毛 3。
换句话说，如果你的 AI 工具底层接的是国内模型（比如 WorkBuddy 接的就是腾讯混元 + DeepSeek），Token 开销这件事你几乎不用操心------国内模型的定价策略跟海外不在一个量级。你真正需要关心的是上下文窗口别被垃圾塞满，而不是账单。
还有两个习惯值得养成。第一，一次性让 AI 做 10 件事，比拆成 10 次各做 1 件事更贵------前者的上下文窗口被 10 个任务的信息同时占据，后者每次只装一个任务的上下文。第二，跑测试、翻日志、查资料这些会产生大量 Token 消耗的活，派给 SubAgent 干。中间过程锁在 SubAgent 的上下文里，主对话只收一句结论。
上下文窗口的「边缘递减效应」
即使上下文窗口大到 1M，也有一个现象值得注意：AI 对窗口中间偏后的信息抓取最准，对窗口开头和结尾的注意力会下降------这叫「Lost in the Middle」效应。窗口越大，这个效应越明显。
所以，你期望 AI 记住的关键信息，写在指令的末尾比写在开头更有效。如果一次性塞了大量文档让 AI 回答，把最重要的那份放在最后面。别在开头用大段背景介绍埋住关键信息。
上下文工程：主动设计 AI 的「视野」
前面讲了很多「怎么省」「怎么防污染」，本质上都在干同一件事------管好往上下文窗口里塞什么。 这件事有个正式的名字，叫上下文工程（Context Engineering）。
它跟 Prompt 工程有什么区别？
Prompt 工程关心的是「话怎么说」------措辞、格式、示例、角色设定。上下文工程站高一层，关心的是「哪些东西应该出现在 AI 的视野里」。
一张表说清楚：
| Prompt 工程 | 上下文工程 | |
|---|---|---|
| 管什么 | 你说的那句话 | AI 能「看到」的全部内容 |
| 粒度 | 单次提问 | 整场对话 + 所有注入的信息 |
| 典型问题 | 「怎么写 prompt 效果更好」 | 「这段代码应该让 AI 读到吗？读到第几行就够了？」 |
| 工具 | Few-shot 示例、思维链 | Skills、SubAgent、MCP、RAG、记忆管理 |
一个 Prompt 工程师纠结的是「怎么让 AI 输出 JSON」。一个上下文工程师纠结的是「在输出 JSON 之前，AI 的上下文里有没有塞着 5000 行无关日志」。
两者不冲突。上下文工程管大边界，Prompt 工程管小细节。
上下文工程在管什么？
上下文窗口里装的每一样东西，都是上下文工程的管辖范围：
系统提示词。 这是最底层的东西，定义了 AI 的行为边界和角色。写进 CLAUDE.md 的规则、Skills 的 SKILL.md 指令、SubAgent 的 frontmatter，本质上都在往系统提示词里塞内容。上下文工程的第一课：系统提示词越精炼，留给真正任务的窗口就越大。
对话历史。 AI 每回答一轮，都会把之前全部对话重读一遍。聊到 30 轮的时候，AI 的上下文里堆着 29 轮问答、中间读过的文件和搜索结果。上下文工程的原则：长任务及时收尾、新开话题、把中间试错过程放到 SubAgent 里。
注入的知识。 RAG（检索增强生成）本质也是上下文工程------从知识库里捞出最相关的几段文档，塞进上下文窗口让 AI 参考。捞出 3 段有用的代码当然好，捞出 50 页全塞进去就是在浪费窗口。
工具调用结果。 你让 AI 读了一个目录，返回 200 行文件名------这 200 行全进了上下文。你让 AI 搜了 5 次 StackOverflow------5 次搜索结果全在窗口里。每一个工具调用的返回值，都是上下文工程的决策点：这次调用真的有必要吗？返回结果要不要截断？要不要让 SubAgent 来搜、只返回摘要？
三个硬原则
回头看一眼，其实前面写过的所有技巧，都收敛到这三条：
第一，进来的东西，每一行都要交租金。 上下文窗口的每一寸空间都在占用 AI 的注意力。放进去的内容必须值得它占的那个位置。怀疑某段内容有没有用？删掉。
第二，结构比内容更重要。 AI 读一堆零散信息和读一段有层级结构的信息，理解深度差很多。系统提示词按「角色→规则→流程→格式」排好；代码审查用「严重→警告→建议」分级汇报；长文档分段加小标题------这些都是上下文工程。
第三，该隔离的就隔离，别让主对话看到。 跑测试、翻日志、大范围搜索------这些活会产生海量中间数据，SubAgent 干完只交一句结论。主对话从头到尾只看到结果，看不到过程。这就是上下文工程的「信息过滤」。
一句话
上下文工程，就是你主动设计 AI 能看到什么、看不到什么、先看什么、后看什么。
Token 是砖，上下文窗口是房子，上下文工程是装修。砖好、房子大，但如果装修是往里面乱堆东西，这房子也住不舒服。
Token、上下文窗口、上下文工程、Skills、SubAgent、MCP------一图全串起来
前几篇文章讲了 Skills、SubAgent、MCP，这篇文章讲了 Token、上下文窗口，以及上下文工程。六个概念摆在一起，关系大概是这样的：
| 概念 | 一句话 | 管什么 |
|---|---|---|
| Token | AI 的最小阅读单位 | 最基本的计量单位------一切由此计 |
| 上下文窗口 | AI 的短期记忆容量 | Token 的上限------装满了就忘 |
| 上下文工程 | 主动设计 AI 的「视野」 | 管什么进、什么不进、什么先看、什么后看 |
| Skills | 标准化操作流程 | 把重复劳动写成模板，省 Token |
| SubAgent | 专项小弟 | 把脏活隔离在外，护 Token |
| MCP | 外部工具接口 | 直接伸手拿数据，不用整个仓库搬进来 |
换句话说：Token 是砖，上下文窗口是房子，上下文工程是装修------主动设计这房子里放什么、怎么摆。Skills 压缩重复劳动（省砖），SubAgent 把垃圾挡在门外（护空间），MCP 让数据按需取用而不是全搬进来（减堆料）。六件事围着同一个目标转------让 AI 那点记性，只装真正值钱的东西。
收个尾
Token 不是什么神秘概念------它就是 AI 数数用的最小单位，中文一个字大概 1.5 个 Token，英文一个词 1 个。AI 记性好不好、聊天贵不贵，根上都是它在算账。
上下文窗口就是 AI 当下能记住多少东西的上限。超了，老的就被挤掉。现在主流国产模型都标配 100 万 Token 的窗口，听起来很大，但几轮带日志的对话跑下来，该满还是满。
上下文工程，就是把上面这些事串起来的那根线。它不是某个工具或配置项，而是一种意识------每次往 AI 面前放东西，先问一句：这东西值得占它那点记忆空间吗？
前几篇文章聊的 Skills、SubAgent、MCP，本质上都是上下文工程的工具------用对了，AI 记住的都是精华；用错了，窗口里全是噪音。