Memory 记忆系统

AI「失忆」是使用 AI 编程工具时最让人头疼的问题之一。每次开始新会话，AI 就不记得之前的项目上下文、你偏好的代码风格、之前谈过的架构决策。Qoder 的 Memory 系统专门解决这个问题。

记忆的价值不只是"备忘"——它是你和 AI 之间不断积累的共同语境。使用越久，AI 越了解你的偏好、你的项目结构、你踩过的坑，新会话的"预热时间"越来越短。

但记忆有一把双刃剑：存的越多，越需要治理。100 条精心维护的记忆比 1000 条杂乱的记忆有用得多。Skill 也是如此——20 个精心维护的 Skill 比 100 个过时的 Skill 有用得多。

---

使用篇 —— 与记忆交互

1. 如何与记忆对话

记忆操作的接口只有一种：自然语言对话。你不需要打开任何管理界面。

主动存入

你不需要手动决定"存什么、怎么存"。最高效的方式是让 AI 来建议和创建记忆。

方式一：让 AI 主动总结对话中的关键信息

在讨论完一个重要话题后，直接说：

刚才讨论的架构决策，你觉得哪些值得记住？请帮我创建记忆。

AI 会自行判断哪些信息有价值、归属哪个类别，然后压缩提炼后存储。它比你更清楚自己需要记住什么。

方式二：让 AI 根据代码/规范变化更新记忆

当项目代码或规则发生变化时：

我刚更新了编码规范，请扫描 Rule 文件的变化，自动更新相关记忆。

AI 会对比新旧规范，识别需要创建或更新的记忆点，自动完成治理。

方式三：在日常对话中自然沉淀

AI 会在对话中判断哪些信息值得记住——当你解决了一个踩坑问题、确认了一个架构选型、约定了一种编码方式时，直接告诉 AI：

这个经验很重要，请更新记忆。

按需查询

需要 AI 回忆已有经验时：

搜索你的记忆，找出关于 FFmpeg 调试的经验

记忆中有没有关于 EmbeddedAgent 的架构决策？

全景查看

定期查看 AI 记得什么：

你现在的全局记忆保存了哪些信息，请列出来

AI 会返回按类别整理的清单，这张截图就是一个真实项目的"常见坑点"类别展开后的样子——你能看到每一条记忆的标题和内容摘要，一目了然。这是做"记忆审计"的基础。

2. 记忆的类别

Qoder 的记忆按类别组织。一个实际项目（21 个模块、52 条记忆）的分类如下：

类别	数量	存什么
常见坑点	11	踩坑记录：PowerShell 多行提交、FFmpeg -y 参数
项目介绍	13	架构说明、模块职责、废弃模块标记
技能经验	7	可复用的标准化操作流程
环境配置	6	工具路径和目录结构
重要决策	3	架构选型理由
其他配置类	5	构建、依赖、IDE、Git 提交规范

---

案例篇 —— 一个改变前端开发方式的记忆

3. ui-ux-pro-max：用记忆补齐 AI 的设计短板

如果你用 AI 写过前端页面，一定有过这样的体验：生成的界面能用，但怎么看都像"AI 风格"——布局呆板、配色奇怪、字体不协调。这不是模型的能力问题，而是AI 缺乏设计领域的知识沉淀。

ui-ux-pro-max 就是解决这个问题的。它是 GitHub 上最受欢迎的 AI 编程设计 Skill，拥有 88,700+ stars。它的工作方式非常简单：把一套完整的设计系统注入到 AI 的上下文中。

它存了什么

ui-ux-pro-max 本质就是一个精心设计的记忆包 + 指令包，包含了：

类型	数量	作用
UI 风格	67+	Glassmorphism、Neumorphism、Brutalism、Bento Grid 等
配色方案	96+	按行业分类（SaaS、电商、教育、金融等）
字体搭配	56+	成套的标题/正文/等宽字体组合
UX 最佳实践	98+	表单设计、导航布局、响应式策略

当 AI 需要生成前端界面时，它会从这些记忆中找到匹配的设计模式，直接应用到生成的代码中。结果是：不再需要你在 prompt 里写"好看一点"，AI 自己就知道什么叫好看。

它是怎么工作的

传统方式：用户写 prompt "设计一个好看的登录页面，用玻璃拟态风格"
              ↓
        依赖 AI 的训练数据中是否有足够的玻璃拟态案例
              ↓
        结果随机，大部分时候是"能用但不精致"

有 ui-ux-pro-max 的记忆：
        用户写 prompt "帮我创建一个登录页面"
              ↓
        AI 从记忆中找到 67+ 种 UI 风格的知识
              ↓
        AI 主动选择最匹配的风格（如 Glassmorphism）
              ↓
        自动应用该风格的色值、圆角、阴影、字体规范
              ↓
        结果：专业级别的 UI，不用额外描述

这个案例的启示

ui-ux-pro-max 展示了 Memory 系统的真正价值：它不只是用来记忆"项目架构"和"踩坑记录"的，更是用来给 AI 注入专业领域知识的。

传统路径	记忆驱动路径
你描述细节 → AI 按文字还原	你描述意图 → AI 从记忆中匹配最佳方案
每次都要重复说"用玻璃拟态"	一次存入，每次自动应用
依赖 AI 训练数据中的偶遇知识	主动注入经过验证的专业知识

这就是为什么我们说「最好的标准，是让人不需要记住标准」——ui-ux-pro-max 把"设计标准"变成了 AI 的记忆，你只需要告诉 AI 你的意图。

---

治理篇 —— 记忆与 Skill 的健康管理

4. 记忆的压缩与过期治理

Qoder 在存入记忆时会做自动压缩——一段长篇讨论被提炼为摘要。这个过程不可逆，查询时看到的是要点而非细节。

压缩的最大副作用：过期的记忆不会自动消失。 今天约定"函数不超过 30 行"，下个月改成 50 行，旧记忆还在。AI 同时读到两条冲突的记忆，不知道该遵循哪个。

发现问题时直接说：

那条"函数不超过30行"的记忆已经过时了，现在统一是50行，请删除旧的记忆

我的 Rule 已经更新了编码规范，请搜索你的记忆，删除所有与当前 Rule 冲突的旧记忆

一个真实案例： Growth 项目重构了接口命名——从 IXxxProvider 改为 IXxxService。新规范写进了 Rule，但记忆里还存着旧的规范。AI 每次生成时，Rule 说用 Service，记忆说用 Provider，陷入矛盾。一句话"请更新记忆"就解决了。

5. Skill 治理：不要让技能成为负担

Skill 和 Memory 面临同一个问题：积累越多，管理成本越高。当团队热情高涨地创建了大量 Skill 后，会不可避免地遇到三个问题：

上下文膨胀

每个 Skill 都需要在 AGENTS.md 中注册索引。100 个 Skill，即使每个只写一行描述，AGENTS.md 也要多出 100 行。每次对话都要加载这些内容，即使你只是想写一个简单的函数。

这就像每次出门前都要读完整个宜家目录——哪怕你只想买一个螺丝刀。

发现困难

100 个 Skill，用户能记住的不超过 20 个。大部分 Skill 静静躺在目录里，没人知道它们存在，更没人用。创造了却没人用，比不创造更浪费——你投入了维护成本，却没有得到收益。

Memory 也一样——当记忆条目超过 200 条时，AI 在检索时也会"挑花眼"，相关记忆被淹没在噪声中。

路由准确率下降

大模型在选择 Skill 时，需要从 AGENTS.md 的索引列表中匹配当前任务。候选越多，选错或犹豫的概率就越高。实践中我们发现，当 Skill 超过 30 个时，模型自动路由的准确率就开始明显下降。

Memory 的语义检索虽然不会"路由错误"，但噪声记忆会拉低检索结果的精确度——模型找到 10 条相关记忆，其中可能只有 3 条是真正有用的。

6. 共同的治理原则

Memory 和 Skill 的治理遵循同一套原则：

原则	Memory	Skill
准入标准	只有确实重要、不记就会忘的信息才存入	只有每周至少出现一次的任务才值得创建
定期检查	每季度让 AI 审计一次，删除过时条目	每季度审视一次，废弃零使用的 Skill
精而不多	100 条精心维护的记忆 > 1000 条杂乱的	20 个活跃的 Skill > 100 个无人问津的
去重合并	同类信息合并为一条，避免碎片化	功能重叠的 Skill 合并，避免选择困难

操作上，治理不需要你手动翻列表，一句话就能完成：

请审计我的记忆，是否有和当前代码不匹配的过时条目？

请检查我的 Skill 列表，过去三个月没使用过的标记为废弃。

---

知识篇 —— 理解记忆系统

7. 三种记忆架构路线

业内对"如何管理 AI 记忆"有三种完全不同的设计路线。看懂这三条路线，你就知道 Qoder 的 Memory 设计为什么是今天这个样子。

OpenViking：图书馆编目（最精细）

字节跳动旗下 Coze 的开源记忆系统。把记忆分为 8 个类别（用户画像、偏好、实体、事件、案例、模式、工具、技能），用 LLM 自动提取和分类，配合去重和合并机制。每个类别有不同的合并策略——PROFILE 始终合并、CASES 禁止合并。

适合：长生命周期、知识密集项目。

MAF（Microsoft Agent Framework）：搜索引擎（最灵活）

微软的 AI Agent 框架，不分类，所有记忆以 flat 的 vector embedding 存储在 VectorStore 中，检索靠语义相似度 + 四维过滤（应用/Agent/用户/会话）。靠 Compaction 系统（5 种压缩策略）管理膨胀。

适合：需要模糊发现、不需要精确分类的场景。

Hermes：两个笔记本（最简单）

Agent 只维护两个文件：USER.md（用户画像）和 MEMORY.md（Agent 笔记），条目用 § 分隔。所有内容全量注入到上下文。

适合：快速原型、个人实验。

三条路线的核心取舍

精确性（分类）         ←  →  灵活性（embedding）
     │                           │
  OpenViking ───────────────── MAF
  (8类+去重+合并)          (flat vector)
     │
  Hermes
  (2类文件)

8. 记忆在 Agent 中的处理方式

理解记忆架构后，还有一个关键问题：当 Agent 执行任务时，记忆是如何被加载和使用的？ 这决定了你在实际操作中应该如何对待记忆。

加载时机

记忆不是在每次对话时全部加载的。如果每次都将全部记忆注入上下文，几轮对话后上下文窗口就会耗尽。Qoder 的处理方式是按需检索：

用户提出需求
    ↓
Agent 解析需求，提取关键词
    ↓
Agent 向记忆系统发起语义检索
    ↓
记忆系统返回 Top-K 相关条目（通常 5-10 条）
    ↓
Agent 将检索结果注入当前上下文
    ↓
Agent 执行任务（同时参考记忆 + Rule + AGENTS.md）

检索与排序

记忆检索的核心机制是语义相似度匹配。Agent 把当前问题转化为向量，与记忆库中的所有条目进行相似度计算，返回最相关的若干条。

这意味着：

• 越具体的记忆越容易被召回——模糊的描述在匹配时得分低
• 越近期的记忆没有额外加分——语义匹配只看"像不像"，不看"新不新"
• 重复的记忆不会自动去重——两条内容相似的记忆都会被召回，占用上下文空间

记忆与上下文的融合

检索到的记忆不是简单拼接到上下文末尾。Agent 在融合记忆时会做几件事：

1. 去重过滤：如果多条记忆内容相似，只保留一条
2. 冲突检测：如果记忆与当前 Rule 或 AGENTS.md 矛盾，以 Rule 为准
3. 优先级排序：AGENTS.md > Rule > Memory（约束力越强的越优先）
4. 压缩合并：相关记忆合并为一段摘要，减少 token 占用

这个融合过程是 Agent 自己完成的，你不需要干预。但理解这个过程，你就明白为什么记忆不能替代 Rule——在冲突时，记忆永远被 Rule 覆盖。

9. 这对你使用 Qoder Memory 的启发

理解以上原理后，你就明白：

• 为什么记忆需要治理——因为没有自动过期机制，也没有自动去重
• 为什么记忆不能替代 Rule——因为记忆在融合时会被 Rule 覆盖
• 为什么精而不多——因为检索是语义匹配，噪声越多，精确度越低
• 为什么你不需要关心"怎么存"——因为 Agent 会自动完成压缩、分类和融合

场景	用什么
必须遵守的编码规范	Rule（强制）
踩坑记录、架构决策理由	Memory（辅助）
用户个人偏好	Memory（PROFILE 类）
工具的标准化调用方式	Memory + Skill 组合
大规模知识库	MCP 或 RepoWiki

---

写在最后

记忆系统的设计路线没有对错，只有适不适合。OpenViking 的精细编目适合长生命周期项目，MAF 的扁平向量适合需要灵活发现的知识体，Hermes 的两个文件适合快速原型。

Qoder 选择了中间路线——用自然语言作为记忆操作的统一接口，让 AI 自动完成分类和压缩。你只需要记住一句话：重要的东西主动告诉 AI 存下来，过时的东西主动让 AI 删掉。

配合本章讲的治理原则——精而不多、定期审计、去重合并——你的记忆库会随着使用时间增长变得越来越精准，而不是越来越混乱。