上下文窗口：有限台面上的摆放之道

模型一次能「看见」的内容总量，就是上下文窗口，以 token 计。系统提示、对话历史、参考资料、你的问题——全都摆在这同一张台面上，共同消耗额度。 台面尺寸因模型而异，从十几万到百万级 token 不等，但无论多大都有三推论： 装不下就得取舍：塞入的资料越多，留给历史和问题的空间越少，费用也线性上涨； 「支持超长上下文」不等于「塞得越满越好」——下一个知识点会讲为什么； 报错「超出上下文长度」时，最先该删的是冗余历史，其次是无关资料。 用餐桌做比喻：上下文窗口就像一张吃火锅的桌子。锅底调料（系统提示）、已点的菜（历史对话）、新端上来的菜（参考资料）、你正在夹的菜（当前问题）——全都要摆在同一张桌上。桌子大小因模型而异，但无论多大的桌子： 摆满了就得撤一些旧菜（删历史或资料） 菜越多吃得越慢（响应变慢、费用上涨） 放在桌子中间的菜最容易被忽略（中段丢失效应）

实测多个模型都会呈现同一个规律：对上下文开头和结尾的信息利用率最高，埋在中段的内容随总长度增加逐渐「失焦」——不是完全看不见，而是容易被忽略、被概括、被张冠李戴。 实操摆放策略： 最重要的约束放开头（系统提示位置）或结尾（紧贴问题的位置）； 大块参考资料放中间，但要接受它们的利用率打折； 指望模型从五十页资料正中间挖出一个小数字的任务，拆成多次问，或者先把范围缩小再问。 这不是模型偷懒，是注意力机制在超长序列上的固有特性，短期不会消失。

聊得够久，一些产品会自动压缩早期对话来腾地方——把旧消息摘要成几句话。省空间的代价是：被压掉的字句永久丢失，而丢失的经常正是最早定下的规矩。 这就是「前说后忘」的技术根源：不是模型健忘，是它已经看不见那段原文了。 应对办法很朴素： 长会话定期重申关键约束（「再次强调：输出不超过 200 字，不要编造数字」）； 话题切换时，果断开新会话，把必要背景重新贴一遍——新会话的干净窗口，胜过老会话的臃肿记忆。

「让 AI 记住我」的产品能力，实现方式基本都是三步： 提取：从对话里识别值得保存的信息（你的称呼、偏好、项目背景）； 存储：写进一个独立于对话的数据库； 注入：下次对话开始时，检索相关条目拼进上下文。 它带来的代价也要心里有数： 记忆会过时——三个月前的职位信息今天还在生效； 记忆会冲突——新旧条目打架时模型听谁的不可控； 记忆有隐私——里面存着你说过的话，产品必须有查看和删除入口才算合格。 使用任何「记忆功能」前，先找到那个入口，看看它到底记了你什么。