Token 和上下文窗口——AI 记性的秘密

📅 2026/7/22 11:30:21
Token 和上下文窗口——AI 记性的秘密
多数人以为 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 概念配图一个最简单的经验公式内容 大约等于多少 Token1 个中文字 ~1.5 Token1 个英文单词 ~1 Token1 行代码 ~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 的行为规则 ✅ 占通常几十 KBSubAgent 返回的结论 ✅ 占但中间过程不占——这就是 SubAgent 的价值一句话你让 AI 读一个 5000 行的日志文件这 5000 行全塞进了上下文窗口。这也是为什么「让 AI 跑测试」这件事经常让对话变慢变笨——几千行错误日志一下子挤满了上下文窗口。服务器与数据——上下文污染配图上下文污染当「记忆」被垃圾填满上面说的「日志刷屏」问题学名叫上下文污染。你本来让 AI 帮你改一个 Bug。你说了问题AI 开始读代码——正常。然后 AI 跑了个测试——哗啦啦输出 300 行编译错误。你又让它搜了下相关 Issue——又是 15 条讨论记录。此时上下文窗口已经塞满。你再问「所以刚才那个 Bug 怎么修」——AI 可能已经不记得一开始你描述的问题了。你的原始问题信息在上下文窗口中已经被后来涌入的日志和搜索结果挤到了很远的位置。AI 虽然还能「看到」开头但就像人翻一份 50 页的文档——最前面几页的内容注意力覆盖不到了。该派 SubAgent 的时候就派出去——把会刷屏的脏活隔离在外面别让它淹了主对话。数据分析——Token 计价配图Token 的另一层身份计价单位如果你只免费用 AI 聊天Token 跟你关系不大。但如果你开始大量使用 AI或者开发 AI 应用Token 就是你的账单API 计费是按 Token 算的各厂商都是按「每 1M Token」100 万 Token计价。大模型如 Claude Opus单价贵小模型如 Claude Haiku单价便宜。一个直观对比模型 输入价格每 1M Token 《活着》输入费Claude Haiku ≈ ¥7 ≈ ¥1.3Claude Sonnet ≈ ¥22 ≈ ¥4.0Claude Opus ≈ ¥110 ≈ ¥20GPT-4o ≈ ¥36 ≈ ¥6.5DeepSeek V4-Flash ¥1 ¥0.18DeepSeek V4-Pro ¥3 ¥0.54通义千问 Qwen3.7-Flash ≈ ¥0.7 ≈ ¥0.13智谱 GLM-5.2 ¥8 ¥1.44Kimi 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 配图省 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 接的就是腾讯混元 DeepSeekToken 开销这件事你几乎不用操心——国内模型的定价策略跟海外不在一个量级。你真正需要关心的是上下文窗口别被垃圾塞满而不是账单。还有两个习惯值得养成。第一一次性让 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 标准化操作流程 把重复劳动写成模板省 TokenSubAgent 专项小弟 把脏活隔离在外护 TokenMCP 外部工具接口 直接伸手拿数据不用整个仓库搬进来换句话说Token 是砖上下文窗口是房子上下文工程是装修——主动设计这房子里放什么、怎么摆。Skills 压缩重复劳动省砖SubAgent 把垃圾挡在门外护空间MCP 让数据按需取用而不是全搬进来减堆料。六件事围着同一个目标转——让 AI 那点记性只装真正值钱的东西。收个尾Token 不是什么神秘概念——它就是 AI 数数用的最小单位中文一个字大概 1.5 个 Token英文一个词 1 个。AI 记性好不好、聊天贵不贵根上都是它在算账。上下文窗口就是 AI 当下能记住多少东西的上限。超了老的就被挤掉。现在主流国产模型都标配 100 万 Token 的窗口听起来很大但几轮带日志的对话跑下来该满还是满。