AI 为什么聊着聊着就忘了你说的话：它没有“记住”这一步，只有“这次递进去多少”

先纠正一个理解：它不是“记住了又忘掉”

我们习惯把人说话的方式套在 AI 身上：它记不记得我前面说的？它怎么把我说过的那句给忘了？这篇稿子最想让你带走的第一件事是：“记住”这个动作在大模型里并不存在。

你每发一条消息，你在用的那个软件做的事情是：把这一次要它看的东西整份重新递一遍——你的系统设定、前面几轮的对话、你贴进去的文件、它自己已经答过的部分，再加上你刚问的这句。它答完，这一份就被放下了。下一轮再问，程序再递一次。

这不是我打的比方，是官方文档自己的写法。OpenAI 那份约束 ChatGPT 行为的规格文件（2025 年 4 月 11 日版）里有一句原话：“In ChatGPT, conversations may grow so long that the model cannot process the entire history.”（ChatGPT 里的对话，会长到模型没法处理全部历史。）请注意这句话的措辞：它说的不是“模型记不住”，而是“没法处理”——因为在它这边根本没有存和取这两个动作，只有这一次带进去多少。

于是“AI 忘了你说的话”其实分两种完全不同的情况，你得分开治：

• 一种是带不进去：这块地方有边界，超过就装不下；
• 另一种是带进去了但没用好：内容全都在里面，它照样会看漏。

绝大多数人的困扰是这两种混在一起，而你对付它们只需要三个动作（第六节给可以直接抄的话术）。

这块地方有多大：官方数字得这么读

各家现在公开的规格页，比三年前大了几百倍。这次我逐条打开官方文档，抓到的口径是这样（2026 年 10 月 2 日）：

这些数字大得没什么实感，所以先讲三个读法上的坑——这才是普通用户真正用得上的部分。

坑一：单位是 token，不是“字”。 上面这些页面清一色用 token 作单位。Kimi 那份文档我逐字看过，规格表里只出现 tokens；至于“多少万字上下文”这类说法，是宣传口径，不在官方表里。token 和汉字之间没有固定汇率，站内那篇算成本的《每百万 tokens 到底是多少字》里用的是 1.5 字/token 这个示例系数。按它折一下，1,048,576 个 token 大约相当于一百五十万字——确实很大，但这个数字要被打两次折，见坑二和坑三。

坑二：这块地方不是你一个人用的。 微软那份文档里对这几列的说明是我见过最干净的一句，原文照抄：“Input tokens, generated output tokens, and reasoning tokens share the available context budget. More input leaves fewer tokens for generation.”（你的输入、它生成的回答、它打草稿用的推理过程，共用同一份预算；输入占得越多，它能写的就越少。）同一页还给了一个特别直白的例子：一份用掉 921,549 个 token 的提示词，在 922,000 的预算下，只剩 451 个 token 可以用来回答——这时就算你把回复上限设成 128,000 也变不出地方来。

翻译成人话：你把一次对话喂得越满，它能回给你的就越短。 那种“我明明让它写五千字，它写两百字就停了”的情况，很多时候不是它偷懒，是它已经没有地方可写了。

坑三：装满了不会报错。 还是那一页，官方明确写着：达到预算上限不一定给你一个错误，请求可能正常返回，但内容是没写完的。所以你看到的现象是“它突然变短”“它突然变含糊”，而不是任何提示。

装不下的时候，各家怎么处理：两家的方向不一样

这是普通用户最该知道、但产品界面基本不会告诉你的事：同样是超出长度，处理办法不一样，代价也不一样。

OpenAI 那份规格文件的方向是截断：对话长到装不下时会被截掉，而截断的方式会优先保留最新、最相关的内容。也就是说，最早那批原话是真的没了。

Claude 的帮助中心给的方向是摘要：它会先把较早的消息总结一遍，再用这份总结继续对话（见它的帮助文档《How do usage and length limits work》）。

两者的区别在哪：截断丢掉的是原文，摘要丢掉的是“原文和摘要之间的那段距离”。 摘要不是你的原话，是它替你重新写的一份要点；而“它自己写的东西里可能有错”这件事，正是站内那篇《AI 为什么会一本正经地胡说八道》讲过的老问题。两件事叠在一起，就有第三种风险：它拿一份本身有错的摘要继续替你办事。

这不是假设。OpenAI 在 2026 年公开过一组内部事故报告，其中一次就是这类情况（报告更新于 2026 年 9 月 16 日，事故记录在 2026 年 7 月 18 日至 8 月 9 日之间）：模型在长任务里把“阶段之间要用的提示”写进了压缩摘要，压缩完再往下执行时，原句是 “After compaction, the model resumed work on the task, not mentioning the additional instructions at all.”（压缩之后，它回到任务本身继续干，对那份额外指令完全不提了。）

必须说清这条的边界：这是内部智能体任务的事故报告，不是普通人在网页上聊天受害的案例。但它把“摘要这条链条会吃掉指令”这件事，用官方自己的话说明白了。

更麻烦的是：全都带进去了，它照样会看漏

前面讲的都是“地方不够”。但研究发现，地方够的时候它也用不好，而且偏得很规律。

规律一：中间最容易漏。 斯坦福等七位作者写的《Lost in the Middle：How Language Models Use Long Contexts》（arXiv:2307.03172，2023 年 7 月提交，正式发表在 TACL 2024 第 12 卷 157–173 页）摘要里有句结论是原话：“performance is often highest when relevant information occurs at the beginning or end of the input context, and significantly degrades when models must access relevant information in the middle of long contexts, even for explicitly long-context models.”——相关信息出现在开头或结尾时表现最好，必须从长文本中间取用时明显变差，连那些明确主打长上下文的模型也一样。 论文里把这条曲线叫做 U 形。

这一条对普通用户的含义，比“上下文不够”实用得多：你把硬要求写在一份长材料的中间，它就是最容易看不见的那一段。 你贴进去三十页制度文件，然后指望它记得第三十七行那句“金额一律用万元”，这件事本身是在赌运气。

规律二：输入越长越不稳，和任务有多简单无关。 Chroma（一家做向量检索组件的公司）在 2025 年 7 月 14 日发了一份技术报告《Context Rot：How Increasing Input Tokens Impacts LLM Performance》，作者 Kelly Hong、Anton Troynikov、Jeff Huber，测了 18 个模型（报告里点名包括 GPT-4.1、Claude 4、Gemini 2.5、Qwen3）。结论句也是原话：“models do not use their context uniformly; instead, their performance grows increasingly unreliable as input length grows.”（模型并不均匀地使用它拿到的内容，输入越长，表现越不可靠。）同页还补了一句：即便是很简单的任务，表现也会随输入长度变化。要说清口径：这是公司出的技术报告，不是同行评审论文；但它测的场景恰好就是普通人的用法——一份长材料，加一个小问题。

规律三：分成多轮说，比一次说清更差。 这条我认为是全篇最可操作的一条。微软研究院团队那篇《LLMs Get Lost In Multi-Turn Conversation》（arXiv:2505.06120，2025 年 5 月 9 日提交；作者 Philippe Laban、Hiroaki Hayashi、Yingbo Zhou、Jennifer Neville；后收录于 ICLR 2026）摘要原句：“all the top open- and closed-weight LLMs we test exhibit significantly lower performance in multi-turn conversations than single-turn, with an average drop of 39% across six generation tasks.”——他们测的当前主流模型，把同样的信息拆成多轮来说，六类生成任务平均下降 39%（注意：这个 39% 是下降幅度，不是 39 个百分点）。更值得注意的是他们给的解释：把退化拆成两部分，能力只掉一点点，可靠性掉了一大块；并且结论句直接写着 “when LLMs take a wrong turn in a conversation, they get lost and do not recover.”（一旦它在对话里走错一个弯，它就迷路了，不会自己回来。）

这一句正好推翻很多人现在的用法：“边聊边补充条件”是最容易让它迷路的使用方法。 你以为在跟它协作，实际上你是在一份接一份地递互相冲突的要求。

那为什么你在发布会和榜单上看不到这些？ 因为测“长上下文”最常用的那套题叫大海捞针（needle in a haystack）——把一句话藏进很长的无关文本里，然后问它这句话是什么。这个测法出自 Greg Kamradt 在 2023 年 9 月建起来的那个测试仓库（README 现在第一行仍是 “Pressure-test LLM long-context retrieval.”）。而 NVIDIA 等机构 2024 年 4 月的 RULER 论文（arXiv:2404.06654，发表于 COLM 2024）批评的正是它，原句是 “this simple retrieval-based test is indicative of only a superficial form of long-context understanding”（这种基于检索的简单测试只反映很表层的一种长上下文理解）。他们的实测是：模型在原始捞针题上几乎满分，但随着上下文变长普遍大幅下滑——“While these models all claim context sizes of 32K tokens or greater, only half of them can maintain satisfactory performance at the length of 32K.”（都宣称支持 32K 以上，真正能在 32K 长度保持可用表现的只有一半。）Chroma 那份报告也有一句同向的话：捞针测试低估了现实长文本任务所需要的东西。

所以请记住：它“能找到那句话”，和它“读懂了你这一堆材料并按你的要求办事”，是两件事。 厂商页面上那个漂亮数字，说的是前者。

“记忆功能”救不了这个：它存的是要点，不是原文

现在产品都在主打记忆：ChatGPT 的 Memory、Claude 的记忆、Kimi 的记忆空间。这一节把关系说清楚，因为太多用户以为“开了记忆就不会忘”。

窗口管的是“这一次它能看多少”，记忆管的是“关于你，它另外存了哪几条”。 这是两套东西：开了记忆，也不会把你第二轮那番话原样搬回来。

Kimi 官方帮助中心“记忆空间”那页写得很直白：“Kimi 使用一个单独训练的模型，有选择地记住对你有价值的对话内容。”请注意里面两个词：单独训练的模型（意味着存进去这一步本身就是一次判断加压缩）、有选择（意味着它替你决定了什么算有价值）。同一页也给了关闭和删除的入口：个人资料 → 设置 → 个性化 → 记忆空间，在单条上点删除即可。Claude 的帮助中心还有一条容易被忽略的规则：对话过期或被删除之后，由它生成的记忆条目并不会跟着一起删掉。

三条实用提醒：

1. 别把隐私承诺当成能力承诺。 有的产品在帮助文档里写“不保存你的任何信息”，那是关于隐私的口径，和它能不能接住你上一句没关系；同一款产品在不同页面的口径也可能不一致。真要确认，就自己去那一条设置项里看它实际存了什么。
2. 记忆条目要抽查一次。 它存的是“关于你的要点”，而要点一样会记错。你可以直接问它：“你现在记着的、关于我的条目有哪些？”看一眼，比凭想象靠谱。
3. 真正重要的偏好，自己存成一段话。 一段可复制的背景包（我是谁、这东西给谁看、哪些不能碰、格式要求是什么）永远比指望它的记忆更可控。站内《怎么用好提示词》和《提示词编写建议》讲的就是这件事的具体写法。

开发者那边其实是同一个问题，只是换了名字。想知道“把材料接给它、让它照着答”的正规做法，MCP 到底是什么从零解释了一遍，MCP 简史说明了为什么这条路这两年被当成主要解法；不想装工具、想自己搭一个只喂给它资料的问答，私有知识库 RAG 实战是最短路径。至于“这块地方怎么省着用”，站内的上下文工程与 Token 预算管理、代码库上下文智能裁剪算法、智能体记忆体系架构和长上下文经济学讨论的就是这篇讲的同一块地方，只是面向写代码的人。

六个你当场就能用的动作，附可直接抄的话术

一、一件事一次说全，别边聊边补条件。 依据就是那条平均 39% 的下降。按四块组织你的第一条消息：目标 / 硬约束（编号）/ 我给你的材料 / 你要交付什么。这和站内《12 个真正好用的提示词》里“把要求写成验收标准”是一件事的两面——那篇讲内容怎么写，这里讲要在什么时候一次写完。

二、硬要求再重复一遍，放在最后一条消息里。 U 形曲线（开头结尾最好）和截断规则（优先保留最新）指向的是同一个动作。抄这段：

在这条消息末尾我重申 3 条硬性要求：1) ……；2) ……；3) ……。前面所有内容只要与这三条冲突，一律以这三条为准；如果你发现冲突，先指出冲突，再动笔。

三、长材料先换成“要点清单”，之后只带这份清单。 这一步同时解决三件事：省地方、避开中间那个位置、并且把摘要这件事从它手里拿回来。话术：

先不要回答任何问题。把下面这份材料整理成不超过 10 条要点清单，每条标注它在原文的哪一节。只写材料里确实有的内容，材料里没有的写“未提及”。

拿到清单之后，你后续每一次提问都只带这份清单，不再重贴原文。这就是“摘要较早消息”那套做法，只不过摘要由你来定标准、由你来核对。

四、每隔几轮，让它复述一遍约束条件。 这是最便宜的体检：

用三句话复述我们目前确认的硬约束，并指出其中哪一条你并不确定还成立。

它复述不出来，说明那份东西已经不在它眼前了——被截断、被摘要、或者本来就没装进去。这一问和幻觉那篇里的“先重述再回答”用的是同一个机制：把它从“接话”挪到“评价自己刚看过的东西”。

五、发现它跑偏，开新对话，别在原对话里纠偏。 “走错一个弯就不会自己回来”这条结论的直接实操含义就是：在一个已经跑偏的对话里补说明，通常只会让它在新错误上再圆一次。正确做法是开一个干净的新对话，一次给它背景包 + 已确认的要点清单 + 当前要办的那件事，并在末尾加一句“从这里开始；我们前面已经确认的约束是这三条”。

六、它突然变短、话说一半，先当作地方满了。 别重复催它，也别以为它“不想答”。按这个顺序试：把你贴的长文件换成要点清单 → 删掉不再需要的旧内容 → 开新对话带上背景包。原因是它不会主动告诉你“没地方写了”——官方文档写明了这种情况可能一切正常地返回一段不完整的回答。

把六个动作压一压，其实就是下图这一件事：别指望它记得，要控制你这一次递给它什么。

按“你遇到什么现象”重排一遍，就是这张表：

如果你已经不只是聊天，而是让它替你办事，那这块地方还连着两笔账：每一轮都要把上下文重发一遍，轮数翻倍、输入量大约翻四倍，这条在《每百万 tokens 到底是多少字》里算清楚过；出事之后责任归谁，《让 AI 替你办事的安全清单》讲得更细；而想让它在长任务里少跑偏，打造可靠的 AI 编程工作流是工程侧的成体系做法。

一句话版本

它没有“记住”这一步，只有“这一次递给它多少”；那块地方有边界、单位是 token 不是字、还得和它的回答共用，装不下时要么截断要么摘要；就算全都带进去了，它也会漏掉中间那一段，而且你分十轮说比一次说清更差。所以三件事值得今天就改：硬要求写在最后一条消息里、长材料先换成你自己核对过的要点清单、一发现跑偏就开新对话而不是在原对话里纠偏。