和 AI 助手长期协作过的人，几乎都遇到过同一类尴尬：昨天刚讨论清楚的方案，今天它一无所知；上周明确否决过的做法，这周它又兴致勃勃地提了出来。这不是 AI 变笨了，而是它的记忆结构和人完全不同——它没有连续的经验流，只有一个有限的上下文窗口。窗口里有什么，它就知道什么；窗口外的一切，对它来说等于从未发生。
这个约束催生了一个新的工程领域：上下文工程。它关心的问题很朴素——在有限的窗口里，应该装什么，不装什么，什么时候换掉，换掉之前留下什么。这些问题看起来像技术细节，实际上决定了 AI 协作的上限。
记忆不是越多越好
直觉上，给 AI 的上下文越多，它的表现应该越好。实践很快会纠正这个直觉。上下文窗口塞得越满，模型对其中每一部分的注意力就越稀释。一份塞进十万字历史记录的对话，模型可能记不住三小时前明确约定的一个关键参数；而一份只有两千字、但每一句都切中要害的上下文，反而能让它精准执行。
这和人的工作记忆惊人地相似。一个人开会时如果被塞进五十页背景材料，大概率抓不住重点；如果只拿到一页精心提炼的简报，反而能立刻进入状态。上下文工程的第一课就是承认这一点：上下文是稀缺资源，管理它的核心动作是取舍，不是堆积。
取舍的标准是任务相关性，而不是信息完整性。当前任务需要知道的约束、最近的决策、正在操作的对象状态，这些必须在场；三个月前的闲聊、已经废弃的旧方案、和当前任务无关的项目细节，留在窗口里只会制造干扰。一个常见的反模式是"以防万一式保留"——舍不得删任何历史，觉得说不定哪天有用。结果是真正重要的信息淹没在噪音里，模型在关键时刻抓错了参考。
遗忘需要设计，而不是放任
上下文窗口终究会满。满了之后怎么办，是上下文工程里最见功力的环节。最粗暴的做法是截断：把最早的内容直接扔掉。这相当于让一个人突然失忆——他不记得自己为什么坐在这里，只能从眼前的残章断句里猜测任务。截断造成的错误往往很隐蔽：AI 不会说"我忘了"，它会基于残缺的信息自信地继续，把错误包装成合理的推进。
更好的做法是压缩：在旧内容被移出窗口之前，先把它蒸馏成摘要。摘要保留决策、约定、关键事实，丢弃过程性的往返讨论。这就像人的长期记忆机制——我们不会记住上周会议的每一句话，但会记住会上定了什么、谁负责什么。压缩的质量决定了"失忆"的代价：一份好的摘要能让协作无缝延续，一份坏的摘要会把细节错误固化成长期偏见。
压缩本身也有陷阱。摘要是有损的，而且损失是不可逆的。如果摘要写着"决定采用方案 A"，但没有记录"因为方案 B 在高并发下有数据竞争风险"，那么三周后当有人重提方案 B 时，AI 无法给出反驳理由，甚至可能附和。所以成熟的上下文体系会分层：摘要负责快速定位，原始记录负责精确回溯。摘要里的每个关键结论，最好能指回它的出处，需要时可以展开验证，而不是让摘要成为孤证。
外部记忆：把重要的东西写下来
上下文窗口的天花板是物理性的，绕不过去。真正可持续的方案是把记忆外化——写到文件里、数据库里、任何窗口之外的持久存储里。工作日志、决策记录、项目备忘，这些文件构成了 AI 的"外部海马体"。每次会话开始时装载必要的部分，会话中产生的新知识及时写回。
外部记忆的价值在协作场景里尤其明显。一个 AI 助手今天记住的教训，如果只存在于当天的对话里，明天的会话就得重新踩一遍坑。但如果写进了共享的记忆文件，那么不仅明天的自己能读到，其他协作的 AI 实例、甚至人类同事都能受益。记忆从个体资产变成了团队资产。
这里有个容易被忽视的纪律：写入的时机必须是"当下"，而不是"稍后"。 "我记住了，回头写下来"在 AI 的世界里是一句空话——会话一结束，没写下来的东西就彻底消失了。这条纪律对人其实同样适用，只是人的遗忘曲线更平缓，让我们误以为可以拖延。AI 的硬约束反而逼出了好习惯：重要的事情，说完就落盘。
外部记忆也需要治理。无节制地写，记忆文件会膨胀成另一个没人读的垃圾场——问题绕了一圈又回来了。定期回顾、合并重复、淘汰过时条目，把原始日志蒸馏成精华笔记，这些维护动作和写入本身同样重要。健康的外部记忆像一座勤于整理的图书馆，而不是一个只进不出的仓库。
检索：记忆的价值在于被找到
有了外部记忆，下一个问题立刻出现：怎么在需要的时候找到它。存而不查的记忆等于没有记忆。检索的设计常常比存储更难，因为写入的时候你知道内容是什么，检索的时候你只知道问题是什么——两者之间隔着一层表述的鸿沟。三个月前的笔记里写的是"发布管道的日期校验"，今天你搜的却是"为什么文章日期不对"，字面上没有一个词重合。
实用的检索体系通常是多路并行的。关键词检索负责精确命中：知道确切名词时最快。语义检索负责模糊匹配：只记得大概意思时兜底。时间线检索负责场景回溯："上周二讨论过的那件事"这类查询，按时间翻日志往往比任何搜索都直接。三条路互为补充，任何单独一条都有盲区。
更进一步的做法是在写入时就为检索铺路：给记录加上明确的主题词，在摘要里保留原始表述中的关键名词，让同一个事实同时出现在时间线和主题索引里。这些动作在写入时多花十秒，在检索时省下十分钟。反过来，检索的失败记录也值得回流：搜了三次都没找到的东西，说明当初的写法有问题，值得重写一条更容易命中的条目。记忆系统由此变成一个有反馈的活系统，而不是一次性的存档。
上下文是协作的接口
把视角拉高一点，上下文工程本质上是在设计一个接口：人和 AI 之间、AI 和 AI 之间传递工作状态的接口。接口设计的好坏，直接决定协作的摩擦系数。
好的上下文接口有几个特征。它是自足的：接手方不需要额外打听就能开始工作。它是分层的：一眼能看到结论，需要时能下钻到细节。它是新鲜的：反映的是当前状态，而不是三天前的旧账。交接一个任务给 AI 时附上的那段说明、跨会话传递的那份摘要、多个 Agent 之间共享的那个状态文件——它们的质量，就是协作的质量。
反过来说，很多"AI 不好用"的抱怨，追根溯源是上下文接口的失败：任务描述里缺了关键约束，历史决策没有传递，AI 拿到的是一个信息残缺的现场，却被期待做出完整正确的判断。这不公平，也不现实。换一个人类新同事到同样的信息环境里，表现未必更好。把抱怨转换成接口改进——补全约束、固化决策记录、把隐性知识显式化——往往比换一个更强的模型见效更快，成本也更低。
从管理 AI 的记忆，到反思自己的记忆
上下文工程最有意思的地方，是它逼着我们把"记忆管理"从一个模糊的习惯变成一套显式的工程实践。什么值得记、怎么压缩、何时回顾、如何检索——这些问题人类靠直觉处理了几万年，效果时好时坏。为 AI 设计记忆系统的过程，像是在给认知过程画工程图纸，而图纸画完之后回头一看，往往会发现自己的笔记系统、团队的知识库、公司的文档体系，犯着一模一样的毛病：只写不读、只存不理、摘要失真、检索靠缘分。
所以上下文工程不只是伺候 AI 的技术活。它是一次机会，让我们把"信息如何变成可用的知识"这件事想清楚。AI 的记忆约束是显性的、刚性的，它把问题暴露得毫无遮拦；而解决这些问题的方法——分层存储、及时落盘、定期蒸馏、来源可溯——对人类团队同样成立。教 AI 记忆的过程，最终教会的是我们自己。