AI 模型的上下文窗口（Context Window），是它在单次对话中能"记住"的最大信息量。它不是硬盘，不是长期记忆——它是模型的短期工作记忆。
这个容量不是无限的。就像你的手机同时打开太多 App 就会卡顿、后台程序被强制关闭一样，AI 模型也有自己的"内存上限"。当信息量超过这个上限时，最早的信息就会被丢弃——模型会"忘记"之前说过什么。
这不是模型变笨了，而是它的短期记忆装不下了。
不同模型的上下文窗口大小差异巨大，直接决定了它们适合做什么类型的任务：
第一梯队：超长上下文（1M Token 以上）
这些模型可以"读完整本书"再和你讨论。
第二梯队：长上下文（200K Token）
这些模型可以一次处理一本 300 页左右的书。
第三梯队：中等上下文（32K~100K Token）
第四梯队：短上下文（4K~16K Token）
200K Token 到底能装多少内容？以中文为例：1 个汉字大约消耗 1~2 个 Token。200K Token 约等于 10 万~15 万个汉字，相当于一本 300 页的书。看起来很大对吧？但在编程场景中，这个容量消耗得比你想象中快得多。
想象一辆出租车。上下文窗口是出租车，Token 是乘客。每次你和 AI 对话，都会有乘客上车，而且——关键点——乘客一旦上车，就不下车。
让我们看看这辆车里都有哪些乘客：
乘客 1：系统提示词（常驻乘客）
你给 AI 设定的角色和规则——比如"你是一个资深 Python 开发者，请用简洁的代码风格回答"。这位乘客一上车就坐在副驾驶座上，全程不离开。系统提示词越复杂，这位乘客的"体型"就越大。
在主流 AI 产品中：
乘客 2：你的问题——输入 Token（每站上车的新乘客）
每轮对话你写的话。有时候只是一句简短的"改一下颜色"，有时候是一大段代码加上需求描述。每个问题都是新上车的乘客。
乘客 3：AI 的回答——输出 Token（和输入乘客坐在一起）
AI 给你的回复。有时候是一个简短的确认，有时候是几百行代码。输入乘客和输出乘客一起占据座位，不会消失。
乘客 4：代码文件或文档（体积很大的乘客）
你贴给 AI 的项目文件——一个 500 行的 Python 文件，一个完整的 JSON 配置文件，一段长长的日志输出。这些乘客体型巨大，一上车就占好几排座位。
随着对话进行，车上的乘客越来越多。到了某个时刻，座位满了——也就是说，累积的 Token 达到了上下文窗口的上限。这时候会发生什么？
最早上下车的乘客（最早讨论的内容）会被挤下车。
想象一辆满载的出租车。新乘客要上车，最早上车的乘客——即使他还需要在某个地方下车——也得下车腾位置。这就是"模型失忆"的本质。
让我们算一笔实际的账。假设你使用 Claude（200K 上下文窗口）做一个功能开发：
第 1 轮对话：
第 5 轮对话：
第 10 轮对话：
在第 10 轮左右，最早的需求描述、前几轮的约定、最开始的代码版本，都被挤出了上下文窗口。AI 已经"不记得"最初的要求了。
这就是为什么在复杂的编程任务中，你会感觉到 AI 的质量在对话后期明显下降——不是 AI 变笨了，是它的"记性"变差了。
当上下文窗口接近上限时，你会观察到这些迹象，越往后越严重：
阶段一：轻微遗忘（窗口使用约 60%~70%）
阶段二：明显失忆（窗口使用约 80%~90%）
阶段三：严重混乱（窗口使用超过 95%）
遇到这些情况，不要责怪 AI——检查你的对话历史长度。如果对话已经持续了很多轮，或者贴过很多大段代码，大概率就是上下文窗口的问题。
既然上下文窗口是有限的，你需要主动管理它。下面是一套从入门到高级的管理策略：
初级技巧：定期做"上下文压缩"
当对话变长时，让 AI 把已经确认的内容总结成一段话，然后开启一个新对话。
具体操作：
这样你保留了关键信息，但丢弃了历史对话中多余的内容——那些"试试这个""不行再试试那个"的试错过程。消耗的 Token 从 100K 降到 2K。
中级技巧：贴代码时只贴相关部分
很多人的习惯是整个文件复制粘贴。但 AI 和人类一样——给它太多无关的信息，它反而更难找到重点。
优化的做法：
高级技巧：一次只做一件事
单一职责原则不仅适用于代码设计，也适用于 AI 对话。在每个对话中聚焦于一个功能或一个问题。完成后再开启新对话处理下一个任务。
反例：在一个对话中同时讨论"用户登录功能""数据导出功能""邮件通知功能"——三个功能交替讨论，上下文里塞满了各种代码文件，AI 很容易混淆。
正例：
这样每个对话的上下文窗口只承载它需要的信息，信息密度高，AI 理解准确。
专家技巧：建立项目知识库
如果你在做的是一个长期项目（几周甚至几个月），不能每次都依赖 AI 的短期记忆。你需要一个外部知识库：
这相当于你给 AI 做了一个"便携硬盘"——每次启动新对话时，先把必要的信息"加载"进去，然后才开始工作。
不同模型有不同大小的上下文窗口，有经验的开发者会有意识地选择模型：
超长上下文任务（需要理解大量背景信息）
中等长度任务（有上下文但不太长）
短小精悍的任务（不需要太多上下文）
不是所有任务都需要最长的上下文。为一个简单问题开启一个 200K 上下文对话——就像开一辆大巴车去超市买菜——当然可以，但没必要，而且成本更高。
上下文管理的另一个维度是成本。回顾我们在 06-03 中讨论的：输入 Token 也是要花钱的。
假设你使用按 Token 计费的 API：
随着对话延长，每轮对话的成本在递增。 不是因为输入变多了（虽然那也是一部分），而是因为你每次都在为累积的历史上下文付费——即使那些历史信息已经不再相关。
所以，管理上下文就是管理成本。保持对话精简，定期压缩和重启，你的效率会提升，成本会下降。
类比一下：
在 Vibe Coding 的实践中，上下文管理是和提示词工程同等重要的技能。一个不会管理上下文的开发者，就像开着一辆越来越堵的车，速度越来越慢，油耗越来越高。
打开你最长的一次 AI 对话记录（或者找一个有很多轮对话的场景），做一次"上下文审计"：
1. 数一下对话大概进行了多少轮。
2. 估算每轮对话的 Token 消耗（可以用在线计数器估算，或者粗略估算：一个汉字 ≈ 1.5 Token，一段代码每行 ≈ 10~20 Token）。
3. 计算总消耗量，判断是否接近或超过了模型的上下文窗口上限。
4. 然后问 AI：
"请评估一下当前这个对话的 Token 消耗情况。上下文窗口中哪些信息是关键的、哪些是可以去掉的？如果要开启新对话来继续这个任务，我应该在新对话的提示词里保留哪些背景信息？"
做完这个练习，你会对自己日常的 Token 消耗有直观的认识，也会更自觉地管理上下文。