为什么 ChatGPT 会遗忘你之前说过的话
窗口是有边界的，而你看不见它
每个模型都有最大上下文限制。长对话最终会超出这一限制，此时必须舍弃一些内容——早期的对话轮次会被丢弃或压缩，以便容纳最近的内容。
界面并不会向你展示这一点。对话中没有一条线来标记模型的视野从哪里开始。因此，在你看来，消息明明就在那里却被忽略了；而在模型看来，它根本不存在。这种不对称正是该问题的核心体验，也是为什么解决办法似乎总是“更坚定地重复你刚才说的话”。
即使在窗口内部，位置也至关重要
这是大多数人不知道的部分，它能更好地解释那些对话显然仍未超出窗口限制的情况。
这一发现来自论文 Lost in the Middle: How Language Models Use Long Contexts (Liu 等人，TACL 2023)。他们测试了多文档问答和键值检索，同时改变相关信息的位置，并指出：“当相关信息出现在输入上下文的开头或结尾时，性能通常最高；而当模型必须访问长上下文中间的相关信息时，性能会显著下降，即使对于专门设计为长上下文的模型也是如此。”
将这一点映射到聊天中。你的初始设置指令在开头——好位置。你最新的消息在结尾——好位置。而你在 90 条消息中的第 30 条添加的限制条件则处于中间，这是输入中最薄弱的位置。这并不是因为你的表达不清晰，它只是随着时间的推移被推到了尴尬的位置。
实际有效容量小于宣传的数值
第二个效应是，宣称的上下文大小是一个上限，而不是实际的工作容量。
RULER: What's the Real Context Size of Your Long-Context Language Models? (Hsieh 等人，2024) 构建了一个合成基准，超越了简单的“大海捞针”检索，引入了多跳追踪和聚合，并评估了 17 个长上下文模型。他们的结论是：尽管在基础检索测试中获得了近乎完美的分数，“但随着上下文长度的增加，几乎所有模型都表现出巨大的性能下降”，虽然这些模型都声称支持 32K 个 token 或更多，但“只有一半的模型能在 32K 的长度下保持令人满意的性能。”
该评估来自 2024 年，具体的模型此后已被替代，因此请将其视为确立了问题的形态，而非当前的排行榜。这种形态依然存在：规格表上的数字描述的是能装下什么，而不是模型能用好什么——而且需要跨分散片段进行推理的任务，比仅检索单一事实的任务更早发生退化。
没有任何提示告诉你什么被丢弃了
加剧这一问题的因素是“无声”。当早期的对话轮次被修剪或压缩时，你不会收到任何通知。撰写关于长 Agent 会话文章的从业者从工具端描述了同样的情况：会话早期的指令并没有被忽略，只是模型无法再可靠地触及它。
因此，你无法区分“它没有遵守限制条件”和“限制条件已不在其视野中”，而这两者需要截然相反的应对方式。前者需要更清晰的指令；后者则需要重构对话——此时无论你如何强调都无济于事。
人们尝试过的解决方法
重复指令。 立即见效，但无法告诉你原因。它还会使对话膨胀，从而加速下一次失效的到来。这是大多数人所陷入的死循环。
将所有关键内容放在第一条消息中。 确实很聪明——开头是一个强势位置。这在对话增长到开头被修剪之前一直有效，但对于你在第 40 条消息时才发现的限制条件毫无帮助。
开启新对话。 最可靠的单一举措，也是经验丰富的用户经常这么做的原因。代价是你也会丢弃所有有用的信息，因此你是在用一个退化的对话换取一个空白的对话。
让它在继续之前进行总结。 一种实用的技巧：让它重新陈述限制条件，然后根据靠近上下文末尾的总结继续工作。有效但有损——你正在进行压缩，而丢弃什么是由模型决定的。
针对固定部分使用自定义指令（Custom Instructions）。 这一方法被低估了，因为这些指令在每次请求时都会重新提供，而不是存在于对话记录中。这个区块很小，所以它只能容纳你少数几条常规规则，而不是当前任务的具体细节。值得妥善使用——这与设置了但未生效的指令不同，后者是另一个问题。
重新上传文档。 很常见，而且它在对抗同样的趋势：在对话中途上传的文件脱离上下文，正是从文件视角看到的相同机制。
注意所有这些临时解决方案的共同点：它们都是在管理一个被用作存储介质的对话记录。
解决方案：停止将对话用作存储
结构性的错误在于将对话视为记录。对话是一个工作台——适合思考，不适合保留，而且在长度增加时会变得极差。一旦你的需求仅以消息形式存在，它们就会受到位置效应、修剪和压缩的影响，而这些你都无法察觉。
因此，请将需求移出对话。将限制条件、规范、Schema 和决策保存在助手可以读取的存储中，让每次对话都保持简短且可丢弃。简短的对话没有可以让人迷失的“中间地带”。
这是最真实的机制，有必要准确说明它能做什么和不能做什么：记忆层并不能延伸上下文窗口，也不能解决长输入中的注意力问题。 没有任何工具能做到这一点。它改变的是你不再需要冗长的对话，因为持久化的材料是被检索出来的，而不是被重复陈述的——这样你就可以在模型可靠的区间内工作，而不是去费力管理它们不可靠的区间。
MemoryLake 就是为此设计的记忆层——将你的文档、限制条件和决策保存在一个存储中，可通过 API 被 ChatGPT 读取，也可直接被支持 MCP 的工具（如 Claude 和 Codex）读取。全新的聊天，相同的知识，无需 90 条消息的冗长对话。
步骤 1：创建 API 密钥
生成密钥并在大约 30 秒内发出你的第一次请求。将其保存在你的环境变量或机密管理器中，而不是粘贴到聊天窗口中。
步骤 2：上传你的第一批记忆
放入你目前需要反复解释的文档、图像和文件：规范、限制条件、风格指南、Schema、决策。尽可能上传源文件而不是摘要——你正试图摆脱那种一切都是对其他内容的压缩的工作流。
步骤 3：连接你的 AI 和 Agent
让 Claude、Codex、OpenClaw 和其他 AI Agent 通过 MCP 或 API 访问记忆。ChatGPT 没有 MCP 客户端，因此请通过 API 检索你所需的内容，并将其注入到提示词、自定义 GPT 的指令或调用模型的整个工作流中。支持 MCP 的工具则可以直接读取相同的存储。
这在实践中改变了什么
第一个区别是你的对话变短了，这就是全部的胜利所在。十个各自从相同检索上下文中开始的简短对话，胜过一个在中间发生退化的 90 条消息的冗长对话——这不仅是因为它们更整洁，而是因为简短的输入才是模型真正发挥性能的地方。
第二个区别是，“它是遗忘了还是违背了指令？”这个问题变得可以解答。当限制条件随请求一同提供，而不是留在 30 条消息之前时，未遵守指令就是真正的未遵守，你可以针对实际发生的情况做出应对。
第三个区别是，重新开始不再需要付出任何代价。目前，开启新聊天意味着重新解释；这就是为什么人们会把对话推到远超可靠性的极限。当知识可以被检索时，新聊天就是无成本的——而不断地重新解释不再是获得干净上下文的代价。
而且它与内置记忆相辅相成，而不是相互冲突。保存的记忆可以专注于它所擅长的领域——一两页稳定的偏好，而不会因为你把它当作文件柜使用而填满。
长对话的最佳实践
将对话长度视为你消耗的资源
提前决定一个工作对话大致应该达到多长，并在超过该长度时开启一个新对话。大多数人之所以远远超出可靠性极限，是因为另一种选择是重新解释。解决重新解释的问题，这一切就会变得简单。
将关键限制条件放在结尾，而不仅仅是开头
位置既可以对你有利，也可以对你不利。如果某项内容必须在下一个回答中生效，请在你发送的消息中重新陈述它——输入的末尾是一个强势位置。这就是重复有效的原因，而有意识地针对两三个重要事项进行重复，要好过被动地对所有内容进行重复。
在你选择的边界处有目的地进行总结
当对话变长时，要求明确重新陈述需求，进行检查、纠正，然后以此作为开场白开启新聊天。你是在自己进行有审核的压缩，而不是让无形的修剪替你做选择。
绝不要让决策仅存在于对话记录中
如果某件事下周依然适用，它应该存在于文档或存储中，而不是存在于第 40 条消息中。这是预防这一整类问题的唯一习惯，也是让对话可以被安全放弃的原因。
在怀疑模型之前，先怀疑位置
当指令不再被遵守时，在重写它之前，先检查它在对话中的位置。在长对话早期确立的内容处于输入中最薄弱的位置，正确的应对方式是重构，而不是重新措辞。
结论
ChatGPT 会遗忘你在同一对话前期说过的话，是因为长输入被处理得不均匀。长上下文中间的信息被利用的可靠性，低于开头或结尾的信息——这就是 Lost in the Middle 的发现，即使对于专门为长上下文构建的模型也是如此。而且，实际可用容量远低于宣传的数值，这正是 RULER 所证实的，当时声称支持 32K 的模型中有一半无法在 32K 的长度下坚持住。你的限制条件并没有被忽略；到第 90 条消息时，它正处于超出模型良好处理范围的输入中最糟糕的位置。
这意味着解决方案并不是某种提示词技巧。停止将对话记录作为你的记录：将持久化的材料保存在助手可以读取的存储中，保持对话简短，并自由地开启新对话。你最终将在模型可靠的范围内工作，而不是去提高在它们不可靠的范围内管理它们的能力。