之前我写过一篇关于 让 Claude 记住项目 的文章。

当时我的想法很简单：

AI 会忘记，那就让它记下来。

于是每次完成一个重要任务之后，就把一些关键信息写进 Memory。

刚开始的时候，这个方法确实很好用。

但用了一段时间之后，我发现了一个新的问题。

Memory 开始变多了。

而且不仅仅是变多。

它开始重复。

我发现 Memory 里出现了很多“重复劳动”

比如一个项目需要修改数据库。

第一次，我让 AI 处理了 SQL Server 的相关问题。

于是 Memory 记录：

项目使用 SQL Server。

后来又遇到了类似问题。

AI 再次完成任务之后，又产生了一条类似的记忆：

这个项目的数据库是 SQL Server，需要注意……

再后来，又来了一次。

于是 Memory 里面可能已经存在好几条类似的信息。

它们看起来都没有错。

但问题是：

这些信息本质上描述的是同一件事情。

随着时间越来越久，Memory 就很容易变成：

一份记录着“我过去做过什么”的流水账。

而不是一份真正能够帮助 AI 工作的知识库。

Memory 最大的问题，不是太少，而是太杂

我以前一直觉得：

AI 记得越多，应该越聪明。

但实际使用下来，我开始怀疑这件事情。

因为人的记忆也是一样。

如果让你记住过去几年发生的所有事情，你未必会因此变得更聪明。

相反，你真正需要的是：

把重要的事情留下，把重复的事情合并，把已经失效的事情删除。

AI 也是如此。

如果 Memory 里面存在大量：

重复信息
过期信息
临时信息
已经解决的问题
相似但不完全一致的信息
不同时间产生的不同解决方案

那么 AI 在调用这些信息的时候，就可能遇到一个问题：

到底应该相信哪一条？

这也是我开始担心 AI “记得太多”之后反而产生幻觉的原因之一。

当然，Memory 过多并不意味着一定会产生幻觉。

但它确实会增加上下文噪音。

而上下文越混乱，AI 判断错误的可能性自然也会增加。

那么，Memory 应该怎么办？

我的想法是：

不要让 Memory 承担所有事情。

Memory 和 Skill，其实可以承担完全不同的职责。

我现在更倾向于这样理解：

Memory 负责记录“发生过什么”。
Skill 负责记录“以后应该怎么做”。

这两个东西看起来很像，但实际上差别非常大。

Memory：记录事实

例如：

2026 年 8 月 21 日，我在 Windows 上部署了 DeepSeek Harness。

这属于 Memory。

它记录的是一个事实。

再比如：

这个项目使用 SQL Server。

也是 Memory。

它告诉 AI：

“这个项目是什么样的。”

Skill：记录方法

但是，如果我解决了一个问题：

SQL Server 中某类 URL 需要替换 Base URL。

与其以后每次都重新记录：

今天修改了某个 URL……

不如把真正有价值的东西沉淀下来：

SQL Server URL 替换规范
修改接口 Base URL 时，只替换指定的 Base URL 部分，不修改后面的 Path、QueryString 和参数。

这就更像 Skill。

它不是在告诉 AI：

“我过去做过这件事情。”

而是在告诉 AI：

“以后遇到这种事情，你应该这样做。”

这两者的价值完全不同。

我甚至觉得可以把 AI 的知识分成三层

如果继续往下思考，我觉得一个比较合理的结构应该是：

                AI 知识
                   │
        ┌──────────┴──────────┐
        │                     │
      Memory                Skill
        │                     │
   发生过什么              应该怎么做
        │                     │
   项目事实 / 历史        方法 / 规范 / 流程
        │                     │
        └──────────┬──────────┘
                   │
                Context
                   │
              当前任务需要什么

而真正重要的是最后一步：

不要把所有东西都塞给 AI。

而是根据当前任务，只加载真正相关的 Skill 和 Memory。

例如我现在问 AI：

“帮我修改这个项目的 SQL。”

AI 不需要知道：

我三个月前曾经修改过哪个 SQL。

它真正需要知道的是：

这个项目使用什么数据库
数据库有什么特殊约定
这个项目有哪些 SQL 规范
当前这个问题有没有相关 Skill
有没有必须遵守的规则

这些才是真正有价值的上下文。

所以我开始重新思考 Memory

以前我的思路是：

做完事情 → 写 Memory

现在我觉得这个流程可能应该变成：

做完事情 → 判断是否值得沉淀 → 提炼 → 合并 → 形成 Skill

也就是说：

不是所有事情都值得记忆。

更不是所有事情都值得永久保存。

比如：

“今天修改了一个按钮的颜色。”

这种事情，可能根本不值得进入 Memory。

但如果发现：

“这个项目所有按钮都必须使用统一的设计规范。”

那就值得沉淀。

因为它对未来仍然有价值。

Memory 更像日志，Skill 更像经验

这是我目前比较喜欢的一个比喻。

Memory 更像 Git Commit。

它告诉你：

某一天发生了什么变化。

而 Skill 更像项目规范或者 README。

它告诉你：

如果以后再遇到这种情况，应该怎么做。

Git 可以有几百、几千个 Commit。

但你不会希望 AI 每次修改代码之前，把所有 Commit 全部读一遍。

同样：

Memory 可以很多，但真正进入工作上下文的知识应该很少。

这也让我重新理解了“AI 记忆”

以前我认为：

AI 的记忆越丰富越好。

现在我反而觉得：

AI 真正需要的不是更多记忆，而是更好的记忆。

甚至可以进一步说：

Memory 的终点，不应该是无限增长。

而应该是：

历史记录
   ↓
筛选
   ↓
去重
   ↓
总结
   ↓
提炼经验
   ↓
Skill
   ↓
删除无价值 Memory

这其实和人类学习非常像。

我们并不会把每天发生的每一件事情都记住。

真正留下来的，往往是：

经验。

所以，我现在更期待一种新的 AI 工作方式

未来的 AI Coding Agent，可能不应该只有一个巨大的 Memory。

而应该拥有：

Memory
↓
记录事实

Skill
↓
记录经验

Project Rules
↓
记录项目规范

Context
↓
根据当前任务动态选择

这样 AI 才不会因为“记得太多”，反而被过去的信息束缚。

最后

我并不是认为 Memory 没有价值。

恰恰相反。

Memory 非常重要。

只是我越来越觉得：

Memory 是原材料，而 Skill 才是经过加工之后真正有价值的知识。

以前我希望 AI：

什么都记住。

现在我更希望它：

记住重要的，忘掉无关的，并且把重复的经验沉淀成真正可复用的能力。

也许这才是 AI Memory 下一阶段真正值得解决的问题。

不是让 AI 拥有越来越大的记忆，而是让 AI 学会整理自己的记忆。

Memory 越多，AI 反而越容易犯错：我开始考虑把 Memory 升级成 Skill