记忆与个性化架构 (Memory System)

R — 原文 (Reading)

Claude Web: userMemories 注入 + memory_user_edits tool + 选择性应用规则 + 静默归因 + 边界示例 Claude Code: File-based persistent memory with typed memories (user, feedback, project, reference) + MEMORY.md index Claude Opus 4.7: "NEVER reference sensitive memories in unrelated contexts" + bad example (proactively mentioning deceased pet) GPT-4o/GPT-4.5: bio tool for persistence + sensitive data prohibition FlintK12: Pedagogical memory (interests, preferences, grade level) + mandatory create_memory call Gemini CLI: save_memory tool + GEMINI.md files for project context

I — 方法论骨架 (Interpretation)

记忆系统的核心设计模式围绕"生命周期管理"和"边界控制"两个轴展开：

记忆生命周期 (CRUL 模型):

1. Create (创建): 决定何时创建记忆。FlintK12 采用"强制创建"策略（mandatory create_memory call），确保关键教学信息不被遗漏。Claude Web 采用"选择性创建"——只在用户明确表达偏好时创建。
2. Retrieve (检索): 在每轮对话开始时，将相关记忆注入 context window。关键设计决策是"注入多少"和"注入什么"——全部注入会消耗上下文窗口，选择性注入需要相关性判断。
3. Apply (应用): 静默地应用记忆内容来调整回复，而不在回复中显式引用。Claude Opus 4.7 的反面教材极为重要：如果用户曾提到宠物去世，AI 不应在无关对话中主动提及。
4. Update (更新): 允许用户编辑或删除已存储的记忆。Claude Web 的 memory_user_edits 工具和 Claude Code 的 typed memory 系统都支持这一能力。

类型化记忆 (Typed Memory): Claude Code 将记忆分为四类：user（用户偏好）、feedback（交互反馈）、project（项目上下文）、reference（参考文档）。不同类型有不同的存储策略、检索优先级和应用规则。

边界控制: 记忆系统最大的风险不是"记不住"，而是"在不该记住的时候记住了"或"在不该引用的时候引用了"。

A1 — 案例分析 (Past Application)

案例 1: Claude Web 的静默记忆应用

• 问题: 如何让 AI 利用用户记忆但不让对话变得尴尬或侵犯隐私？
• 设计模式的使用: Claude Web 实现了"静默归因"策略——记忆被注入 context 后，AI 在回复中不应透露"根据我的记忆"或"我记得你说过"等表述。配合边界示例（如"不要在无关上下文中提及用户已故宠物"），确保记忆应用既有效又不突兀。
• 结论: 记忆系统的用户体验质量取决于"隐性应用"而非"显性提及"。

案例 2: Claude Code 的文件型持久记忆

• 问题: 编程 agent 如何在长项目中保持上下文连贯性？
• 设计模式的使用: 采用文件型持久记忆，将记忆存储为 typed 文件（user/feedback/project/reference），并使用 MEMORY.md 作为索引文件。每次会话开始时通过读取 MEMORY.md 恢复项目上下文。这种方式比数据库存储更透明、更可编辑、更易于版本控制。
• 结论: 在专业工具场景中，记忆的透明性和可编辑性比自动化程度更重要。

案例 3: FlintK12 的教学记忆强制创建

• 问题: AI 如何在有限的对话轮次中积累足够的学生画像以实现个性化教学？
• 设计模式的使用: 实现 mandatory create_memory call——在每次教学交互中，AI 必须调用记忆创建工具记录学生的兴趣、理解水平和学习偏好。Pedagogical memory 存储兴趣、偏好、年级等信息，用于后续教学内容的个性化适配。
• 结论: 在高价值场景中（教育效果直接取决于个性化程度），强制创建记忆优于等待显式触发。

A2 — 触发场景 (Future Trigger) ★

用户会在什么情境下需要这个 skill?

1. AI 需要跨会话记住用户偏好、历史或上下文
2. 产品需要"个性化"体验但不确定如何实现记忆架构
3. 记忆内容可能包含敏感信息，需要设计访问控制
4. AI 在回复中暴露了不该暴露的记忆内容
5. 需要决定记忆的存储方式（文件、数据库、向量存储）

语言信号

• "AI 需要记住用户的偏好"
• "跨会话保持上下文"
• "用户说'记住这个'时该怎么处理"
• "记忆中包含敏感信息"
• "如何设计个性化推荐"

与相邻 skill 的区分

• 与 persona-design 的区别: persona-design 定义"AI 是谁"（静态身份），memory-system 定义"AI 知道用户什么"（动态信息）。身份不变，记忆不断积累。
• 与 safety-guardrails 的区别: safety-guardrails 约束 AI 的行为边界，memory-system 中敏感记忆的处理需要 safety-guardrails 的支持，但记忆系统本身是数据管理而非行为约束。
• 与 personality-system 的区别: personality-system 定义可切换的风格叠加层，memory-system 存储用户的风格偏好（如"用户喜欢简洁回复"），这些偏好可以触发特定人格变体的选择。

E — 可执行步骤 (Execution)

1. 步骤 1: 定义记忆类型体系

   • 识别产品需要记忆的信息类别：用户偏好、交互历史、项目上下文、领域知识等
   • 为每个类别定义创建触发条件、存储格式和过期策略
   • 完成标准: 每种记忆类型有明确的边界定义，不同类型之间不重叠

2. 步骤 2: 设计创建机制

   • 确定创建策略：强制创建（FlintK12 模式，适合高价值场景）或选择性创建（Claude Web 模式，适合通用场景）
   • 定义创建触发器：显式触发（"记住这个"）+ 隐式触发（检测到偏好表达）
   • 完成标准: 创建机制在 95% 的情况下能正确判断是否需要创建记忆

3. 步骤 3: 实现静默应用规则

   • 编写核心应用规则：记忆内容应隐性影响回复，不应显式引用
   • 编写反面教材：列出不应在回复中出现的行为（如"根据我的记忆"、"我记得你之前说过"）
   • 完成标准: 用户在对话中感受不到"被记忆"的不适感，但能体验到个性化的便利

4. 步骤 4: 设计边界控制

   • 定义敏感记忆类别（健康、财务、家庭变故等）并制定特殊处理规则
   • 实现跨上下文隔离：Claude Opus 4.7 的规则"绝不在无关上下文中引用敏感记忆"
   • 设计记忆编辑/删除机制，允许用户查看和管理已存储的记忆
   • 完成标准: 敏感记忆不会被错误引用，用户有完全的记忆控制权

5. 步骤 5: 选择存储策略

   • 文件型存储（Claude Code 的 MEMORY.md）：适合专业工具，透明可编辑
   • 结构化存储（Claude Web 的 userMemories）：适合消费产品，高性能检索
   • 向量存储：适合大规模知识和语义检索场景
   • 完成标准: 存储策略与产品的记忆规模、检索需求和用户期望一致

B — 边界 (Boundary) ★

不要在以下情况使用此 skill

• AI 产品不需要任何跨会话持久化（纯一次性对话）
• 记忆需求实际上可以通过简单的 system prompt 配置解决（如"始终用中文回复"）
• 试图用记忆系统替代知识库或 RAG（记忆是用户相关的个性化数据，不是通用知识）
• 没有设计记忆删除/编辑机制就上线记忆功能（这会严重损害用户信任）

常见失败模式

• 记忆过度引用: AI 在回复中频繁使用"根据我的记忆"等表述，让用户感到被监视。应严格执行静默应用规则。
• 敏感记忆泄露: 在无关对话中主动提及用户的敏感信息。Claude Opus 4.7 明确指出这是严重错误——如果用户提到宠物去世，AI 不应在后续关于"周末计划"的对话中说"考虑到你的宠物刚去世..."。
• 记忆膨胀: 创建过多低价值记忆（如"用户使用了感叹号"），导致记忆存储膨胀且检索效率下降。应设置严格的创建门槛。
• 记忆冲突: 存储了相互矛盾的记忆（如用户在不同时间表达了不同偏好），没有设计冲突解决策略。应采用"最新优先"或"显式覆盖"策略。
• 忽略记忆透明性: 用户不知道 AI 记住了什么、无法查看或删除记忆。应提供记忆管理界面。