6.4 上下文窗口：你的"实时流量套餐"

理解上下文窗口

AI 模型的上下文窗口（Context Window），是它在单次对话中能"记住"的最大信息量。它不是硬盘，不是长期记忆——它是模型的短期工作记忆。

这个容量不是无限的。就像你的手机同时打开太多 App 就会卡顿、后台程序被强制关闭一样，AI 模型也有自己的"内存上限"。当信息量超过这个上限时，最早的信息就会被丢弃——模型会"忘记"之前说过什么。

这不是模型变笨了，而是它的短期记忆装不下了。

主流模型的上下文窗口对比

不同模型的上下文窗口大小差异巨大，直接决定了它们适合做什么类型的任务：

第一梯队：超长上下文（1M Token 以上）

这些模型可以"读完整本书"再和你讨论。

• Gemini 1.5 Pro / 2.0 Pro：1M~2M Token。可以一次处理《三体》三部曲的全部内容。适用于需要理解超长文档的场景——分析整个代码库、研究整本学术专著。
• Gemini 2.5 Pro：最高 1M Token。
• DeepSeek-V3 / DeepSeek-R1：1M Token。国产模型的突破，上下文能力与 Gemini 看齐。

第二梯队：长上下文（200K Token）

这些模型可以一次处理一本 300 页左右的书。

• Claude 3.5 Sonnet / Claude 4 Sonnet / Claude 4 Opus：200K Token。
• GPT-4 Turbo / GPT-4o：128K Token。
• Qwen 2.5（通义千问）：128K~1M Token（不同版本）。

第三梯队：中等上下文（32K~100K Token）

• GPT-4（早期版本）：8K~32K Token。
• Claude 3 Haiku：48K Token。
• Mistral Large：32K Token。

第四梯队：短上下文（4K~16K Token）

• GPT-3.5：4K Token（大约二三千个汉字）。
• 早期开源模型（Llama 2、Falcon 等）：2K~8K Token。

200K Token 到底能装多少内容？以中文为例：1 个汉字大约消耗 1~2 个 Token。200K Token 约等于 10 万~15 万个汉字，相当于一本 300 页的书。看起来很大对吧？但在编程场景中，这个容量消耗得比你想象中快得多。

上下文里的"乘客"：一个出租车比喻

想象一辆出租车。上下文窗口是出租车，Token 是乘客。每次你和 AI 对话，都会有乘客上车，而且——关键点——乘客一旦上车，就不下车。

让我们看看这辆车里都有哪些乘客：

乘客 1：系统提示词（常驻乘客）

你给 AI 设定的角色和规则——比如"你是一个资深 Python 开发者，请用简洁的代码风格回答"。这位乘客一上车就坐在副驾驶座上，全程不离开。系统提示词越复杂，这位乘客的"体型"就越大。

在主流 AI 产品中：

• Claude Code / Cursor / Windsurf 等 IDE 内置 AI：系统提示词通常包含大量预置规则，可能占用 1K~10K Token。
• ChatGPT / Claude 网页版：系统提示词相对简短。

乘客 2：你的问题——输入 Token（每站上车的新乘客）

每轮对话你写的话。有时候只是一句简短的"改一下颜色"，有时候是一大段代码加上需求描述。每个问题都是新上车的乘客。

乘客 3：AI 的回答——输出 Token（和输入乘客坐在一起）

AI 给你的回复。有时候是一个简短的确认，有时候是几百行代码。输入乘客和输出乘客一起占据座位，不会消失。

乘客 4：代码文件或文档（体积很大的乘客）

你贴给 AI 的项目文件——一个 500 行的 Python 文件，一个完整的 JSON 配置文件，一段长长的日志输出。这些乘客体型巨大，一上车就占好几排座位。

随着对话进行，车上的乘客越来越多。到了某个时刻，座位满了——也就是说，累积的 Token 达到了上下文窗口的上限。这时候会发生什么？

最早上下车的乘客（最早讨论的内容）会被挤下车。

想象一辆满载的出租车。新乘客要上车，最早上车的乘客——即使他还需要在某个地方下车——也得下车腾位置。这就是"模型失忆"的本质。

真实场景中的上下文消耗

让我们算一笔实际的账。假设你使用 Claude（200K 上下文窗口）做一个功能开发：

第 1 轮对话：

• 系统提示词：约 2K Token（预设的角色和规则）
• 你的需求描述（包含贴入的代码文件）：约 15K Token（2 个相关文件）
• AI 的回答：约 3K Token（代码和解释）
• 累计：约 20K Token——还很宽裕。

第 5 轮对话：

• 系统提示词：2K Token
• 前 5 轮累积的问答：约 100K Token
• 新贴入的文件：15K Token
• 最新问题和回答：10K Token
• 累计：约 127K Token——已使用约 63%。

第 10 轮对话：

• 前 10 轮累积：约 180K Token
• 新贴入的文件：20K Token
• 最新问答：8K Token
• 累计：约 208K Token——超过了 200K 上限。

在第 10 轮左右，最早的需求描述、前几轮的约定、最开始的代码版本，都被挤出了上下文窗口。AI 已经"不记得"最初的要求了。

这就是为什么在复杂的编程任务中，你会感觉到 AI 的质量在对话后期明显下降——不是 AI 变笨了，是它的"记性"变差了。

上下文窗口满了的预警信号

当上下文窗口接近上限时，你会观察到这些迹象，越往后越严重：

阶段一：轻微遗忘（窗口使用约 60%~70%）

• AI 对早期讨论的细节开始含糊其辞。
• 需要你重复之前说过的某些信息。
• 生成的代码中偶尔遗漏了早期约定的命名规范。

阶段二：明显失忆（窗口使用约 80%~90%）

• AI 忘记了你几轮前让它记住的某个关键约束。
• 给出与之前相矛盾的建议。
• 开始依赖近期对话中的信息，忽略早期的上下文。

阶段三：严重混乱（窗口使用超过 95%）

• AI 对早期讨论的内容完全答非所问。
• 在同一段回复中出现前后矛盾。
• 代码质量明显下降，出现低级错误。

遇到这些情况，不要责怪 AI——检查你的对话历史长度。如果对话已经持续了很多轮，或者贴过很多大段代码，大概率就是上下文窗口的问题。

管理上下文的实战技巧

既然上下文窗口是有限的，你需要主动管理它。下面是一套从入门到高级的管理策略：

初级技巧：定期做"上下文压缩"

当对话变长时，让 AI 把已经确认的内容总结成一段话，然后开启一个新对话。

具体操作：

1. 在当前对话中，对 AI 说："请把我们已确认的需求、约束条件、技术决策、代码架构整理成一份 500 字以内的摘要。"
2. 复制这份摘要。
3. 开启新对话。
4. 把摘要作为系统提示词粘贴进去。
5. 继续工作。

这样你保留了关键信息，但丢弃了历史对话中多余的内容——那些"试试这个""不行再试试那个"的试错过程。消耗的 Token 从 100K 降到 2K。

中级技巧：贴代码时只贴相关部分

很多人的习惯是整个文件复制粘贴。但 AI 和人类一样——给它太多无关的信息，它反而更难找到重点。

优化的做法：

• 只贴相关的函数或模块。如果你需要 AI 理解全局结构，可以贴一个简短的架构说明。
• 使用"这是我项目中 utils.py 文件的 get_data() 函数，它的输入输出是 X，我需要它支持 Y 功能。相关代码如下：[代码片段]"。
• 如果你用的是 AI 原生的 IDE 工具（如 Claude Code、Cursor），它们会自动管理上下文——你知道代码在项目中，AI 知道在哪里找。不需要把整个项目塞进对话。

高级技巧：一次只做一件事

单一职责原则不仅适用于代码设计，也适用于 AI 对话。在每个对话中聚焦于一个功能或一个问题。完成后再开启新对话处理下一个任务。

反例：在一个对话中同时讨论"用户登录功能""数据导出功能""邮件通知功能"——三个功能交替讨论，上下文里塞满了各种代码文件，AI 很容易混淆。

正例：

• 对话 A："实现用户登录功能，技术栈 X，约束条件 Y。"
• 对话 B（使用对话 A 的产出作为输入）："在登录功能基础上，实现数据导出功能。"
• 对话 C（同样基于前序产出）："实现邮件通知功能。"

这样每个对话的上下文窗口只承载它需要的信息，信息密度高，AI 理解准确。

专家技巧：建立项目知识库

如果你在做的是一个长期项目（几周甚至几个月），不能每次都依赖 AI 的短期记忆。你需要一个外部知识库：

• 维护一份项目的 README.md 或 ARCHITECTURE.md，记录技术选型、架构决策、代码规范。
• 每次开启新对话时，先把这份文档贴给 AI 作为上下文基础。
• 当项目发生变化时，更新这份文档。

这相当于你给 AI 做了一个"便携硬盘"——每次启动新对话时，先把必要的信息"加载"进去，然后才开始工作。

多模型策略：为不同任务选不同的"车厢大小"

不同模型有不同大小的上下文窗口，有经验的开发者会有意识地选择模型：

超长上下文任务（需要理解大量背景信息）

• 选 Gemini 2.5 Pro（1M Token）或 DeepSeek-R1（1M Token）。
• 场景：分析整个代码库的架构、审查超长文档、理解大型项目的全部上下文。

中等长度任务（有上下文但不太长）

• 选 Claude 4 Sonnet（200K Token）或 GPT-4o（128K Token）。
• 场景：大多数日常编程任务、功能开发、代码审查。

短小精悍的任务（不需要太多上下文）

• 选 Claude 3.5 Haiku 或 GPT-4o mini。
• 场景：简单的代码生成、格式化、转换任务。
• 优势：速度快、成本低。

不是所有任务都需要最长的上下文。为一个简单问题开启一个 200K 上下文对话——就像开一辆大巴车去超市买菜——当然可以，但没必要，而且成本更高。

管理与成本

上下文管理的另一个维度是成本。回顾我们在 06-03 中讨论的：输入 Token 也是要花钱的。

假设你使用按 Token 计费的 API：

• 每轮对话的提示词包含 10K Token（固定）+ 累积的对话历史。
• 第 1 轮累计：10K（输入）+ 2K（输出），成本约 0.06 元。
• 第 10 轮累计：10K + 18K（历史输出）+ 10K（新的输入）≈ 38K 输入 Token，成本约 0.23 元。
• 第 20 轮累计：10K + 38K（历史输出）+ 10K（新的输入）≈ 58K 输入 Token，成本约 0.35 元。

随着对话延长，每轮对话的成本在递增。 不是因为输入变多了（虽然那也是一部分），而是因为你每次都在为累积的历史上下文付费——即使那些历史信息已经不再相关。

所以，管理上下文就是管理成本。保持对话精简，定期压缩和重启，你的效率会提升，成本会下降。

类比一下：

• 不做上下文管理 = 开一辆大巴车在城市里穿梭，不管去多远都带着全部乘客。
• 做上下文管理 = 每次只派出需要的车型，乘客到了站就下车，定期清理车厢。

在 Vibe Coding 的实践中，上下文管理是和提示词工程同等重要的技能。一个不会管理上下文的开发者，就像开着一辆越来越堵的车，速度越来越慢，油耗越来越高。