夜雨聆风
为什么你的AI助手越用越蠢?
作者：数字李逍遥
你有没有这种感觉？
刚装好一个AI助手，头几天用起来特别顺手——它记得你的项目结构，理解你的编码风格，甚至能预判你想做什么。
但用了一个月之后，它开始犯低级错误：忘记你之前定下的规范，重复问你已经回答过的问题，甚至开始”幻觉”出一些根本不存在的文件路径。
这不是错觉。这是”上下文腐烂”（Context Rot）。
简单来说，上下文腐烂是指AI助手的记忆随时间累积而逐渐”腐烂”的过程。
当你和AI进行多轮对话时，它的”记忆”来自两件事：
当前对话窗口——只保留在本轮对话里
外部记忆文件——比如MEMORY.md、skills文件、笔记系统
问题在于，随着时间推移，这些记忆会变得：
冗余：过时的调试修复还留在文件里，但对应代码早就删了
矛盾：新的规范和旧的惯例打架，AI不知道该听谁的
丢失：重要约束被埋在大量文本的”中间 40-60%”，被新信息覆盖了
一位开发者曾形象地描述：用了30多轮之后，他的Claude Code里充满了”矛盾的笔记、过时的修复、相对路径引用错误”。
大语言模型（LLM）的上下文窗口就像一张纸。纸的容量有限，放多了就放不下新东西。
当这张”纸”被填满时，模型会优先保留最近的对话，而把早期的内容”挤”出去。就像你记不住上周开会说的细节一样，AI也记不住一个月前你们定的规范。
这带来了一个悖论：
你用得越久，AI应该越懂你。但实际上，它反而越容易忘记重要的事。
解决这个问题的核心思路是：不要让AI自己管理记忆，而是给它建造一个结构化的外部记忆系统。
目前主流的方案是三层记忆架构：
载体：MEMORY.md（≤150行）
这是AI每次”醒来”时第一个读取的文件，相当于它的”出厂设置”。
热记忆只放最核心的信息：
– 用户是谁、怎么称呼
– 核心工作流程
– 最重要的规范和禁忌
关键原则：保持精简。 超过150行，AI读取的负担就会抵消记忆的价值。
载体：每日/专题笔记
这一层存放更详细的信息，但按时间或主题组织。AI可以根据需要查询，不需要每次都读取。
比如：
– memory/2026-03-28.md——记录昨天的项目进展
– projects/韵达监控/spec.md——某个具体项目的详细规范
载体：归档、沉睡记忆
这一层存放不常用但不能丢的信息。比如：
– 半年前的会议结论
– 已经废弃的技术方案
– 早期的版本记录
AI不需要每次都读这些，但当用户提到时，它知道去哪里找。
现在很多AI工具都有”记忆”功能，但大多数停留在第二层暖记忆——把对话历史存下来，下次接着聊。
这种方案有两个问题：
查询效率低：暖记忆里的内容没有结构化，AI要找特定信息只能”翻箱倒柜”
没有淘汰机制：旧记忆只增不减，积累到一定程度就变成了”记忆沼泽”
真正的第三层记忆，需要两个关键能力：
定期提炼（Distillation）：从大量日常记录中提取精华，形成结构化的知识
智能检索（Retrieval）：让AI在需要时能快速找到相关信息，而不是把所有东西都塞进上下文
对照这个框架，大多数人的AI助手”记忆”是这样的：
| 层级 | 常见现状 | 问题 |
|---|---|---|
| 热记忆 | MEMORY.md有，但内容膨胀 | 超过150行，读取变成负担 |
| 暖记忆 | 零散的笔记和文档 | 没有结构，散落在各处 |
| 冷存储 | 基本没有 | 旧信息要么丢失，要么堆积 |
结果就是：AI助手在短期内表现尚可，但随着时间推移，它的”智商”在悄然下降。
几个典型信号：
它开始重复问你同样的问题
你发现它用了过时的方案，而你们早就换了
新会话和旧会话的行为差异很大
每次开始新对话都要重新”调教”一遍
如果你有以上症状，说明你的AI记忆系统需要升级了。
AI助手的”记忆问题”不是技术缺陷，而是一个设计问题。
给AI一个好的记忆架构，就像给人类建立好的笔记系统一样——不是为了记住更多，而是为了在需要时能快速找到真正重要的东西。
三层记忆的核心逻辑很简单：热记忆是”永远不忘的常识”，暖记忆是”按需查询的图书馆”，冷存储是”以防万一的仓库”。
把这三层理清楚了，你的AI助手就不会再越用越蠢。
你用AI助手遇到过”记忆失灵”的情况吗？
欢迎在评论区分享