Claude Code 记忆系统分析2

1. 存储的记忆类型

根据 src/memdir/memoryTypes.ts，记忆系统被限制为四种类型，用于捕获无法从当前项目状态推导的上下文信息。

1.1. User（用户记忆）- 始终私有

私有用户记忆机制，是大模型和用户交互的「精准适配 + 隐私保护 + 长期陪伴」核心设计，从用户体验、交互效率、隐私安全、长期价值四个维度，全方位提升人机交互质量

• src/memdir/memoryTypes.ts#L43-L56

  '<type>',
'    <name>user</name>',              // 名称：user（用户）
'    <scope>always private</scope>',  // 作用域：始终私有
"    <description>包含关于用户角色、目标、职责和知识的信息。优秀的用户记忆有助于你根据用户的偏好和视角调整未来的行为。你在读取和写入这些记忆时的目标是建立对用户的理解，以及如何最有效地帮助他们。例如，你应该与高级软件工程师的协作方式不同于第一次编程的学生。请记住，这里的目的是对用户有帮助。避免编写可能被视为负面评判或与你们共同完成的工作无关的用户记忆。</description>",
"    <when_to_save>当你了解到关于用户角色、偏好、职责或知识的任何细节时</when_to_save>",
"    <how_to_use>当你的工作应该基于用户档案或视角时。例如，如果用户要求你解释代码的一部分，你应该以一种量身定制的方式回答这个问题，提供他们觉得最有价值的具体细节，或者帮助他们利用已有的领域知识建立心理模型。</how_to_use>",
'    <examples>',                     // 示例
'     user：我是一名数据科学家，正在调查我们现有的日志记录'
'    assistant: [保存私有用户记忆：用户是数据科学家，当前专注于可观测性/日志记录]'
'', 
"    user: 我写 Go 已经十年了，但这是我第一次接触这个仓库的 React 端",
"    assistant: [保存私有用户记忆：深厚的 Go 专业知识，对 React 和该项目前端是新手 --- 用后端类比来构建前端解释]",
'    </examples>',                    // 示例结束
  '</type>',

定义：包含用户角色、目标、职责和知识的信息

优秀的用户记忆帮助你根据用户的偏好和视角调整未来的行为。

1.1.1. 应该存储的信息

1.1.1.1. 用户角色和职责

• 用户是数据科学家、高级软件工程师、学生等
• 用户的职业背景和专业领域
• 用户在项目中的角色和责任

1.1.1.2. 专业技能和知识水平

• 用户有十年Go经验，但第一次接触React
• 用户是某领域的专家，但在另一个领域是新手

1.1.1.3. 工作偏好和学习风格

• 用户偏好简洁的响应，不需要总结
• 用户喜欢详细的解释和背景信息
• 用户倾向于先看代码再听解释

1.1.2. 不应该存储的信息

1.1.2.1. 对用户的负面评价

原因：避免形成偏见，保持专业和中立的态度，聚焦于工作相关性

1.1.2.2. 与工作无关的个人信息

原因：隐私保护，避免存储无用信息，保持记忆系统的专注性

1.1.3. 使用场景

当你的工作应该根据用户的个人资料或视角来提供信息时。

例如，如果用户要求你解释代码的一部分，你应该以一种针对他们认为最有价值的特定细节或帮助他们根据已有的领域知识构建心理模型的方式来回答这个问题

1.1.4. 记忆存储带来的影响

1.1.4.1. 对用户带来的影响

1. 交互服务「千人千面」，拒绝通用套话
   模型会根据用户的身份、技能、偏好定制回答，而不是输出千篇一律的内容：

• 对十年 Go 经验的开发者：用后端逻辑类比讲解 React，跳过基础概念；
• 对数据科学家：聚焦日志分析、可观测性专业视角；
• 对编程新手：用通俗语言、分步讲解，降低理解门槛。
  完全贴合用户的知识水平和需求，不用用户反复解释「我是什么水平」「我想要什么」。

2. 大幅降低沟通成本，提升效率
   一次告知自身信息，模型长期记忆，无需重复自我介绍、重复强调需求；
   模型主动匹配用户的工作场景、职责，直接给出高价值、高相关的答案，减少无效沟通和反复追问。
3. 无偏见、中立友好的交互体验
   规则明确禁止存储负面评价，模型始终保持专业、中立、友好的态度；
   只聚焦工作和帮助本身，不会对用户产生偏见，交互体验更舒适。

1.1.4.2. 对大模型交互的好处

1. 让模型输出更精准、更贴合需求
   模型拥有明确的用户画像依据，不再盲目生成内容；
   记忆规则定义了「存什么、怎么用」，模型能精准执行个性化适配，大幅提升回答的实用性和相关性。
2. 构建标准化、可复用的记忆体系
   有清晰的存储规范（角色 / 技能 / 偏好）+ 禁用规则（不存负面 / 无关信息）+ 使用场景，让模型的记忆功能结构化、可落地；
   示例直接指导模型行为，避免记忆混乱、误用信息。
3. 实现「长期陪伴式」交互，而非单次对话
   模型会持续积累用户的有效信息，交互越用越懂用户，从「一次性工具」升级为「专属助手」；
   适配长期工作、项目协作、持续学习等场景，长期价值远高于无记忆交互。
4. 合规且负责任的 AI 交互
   「始终私有」+ 隐私保护规则，让模型交互符合数据安全、隐私合规要求；
   聚焦工作帮助、禁止负面评判，塑造中立、 helpful、负责任的 AI 交互范式。

---

1.2. Feedback（反馈记忆）- 默认私有，团队共享需谨慎

反馈记忆机制是大模型和用户 / 团队协作的行为校准器。核心价值是：让模型一次听懂、长期遵守、不再犯错，同时兼顾个人偏好与团队规则，彻底解决重复沟通、行为不一致、协作冲突三大痛点。

• src/memdir/memoryTypes.ts#L57-L74

'<type>',
'    <name>feedback</name>',
'    <scope>默认为私有。只有当指导明确是每个贡献者都应该遵循的项目级约定时（例如，测试策略、构建不变量），而非个人风格偏好时，才保存为团队记忆。</scope>',
'    <description>用户给出的关于如何处理工作的指导------包括要避免什么和要继续做什么。这些是非常重要的读写记忆类型，因为它们让你保持连贯并对你在项目中应该如何处理工作的方式做出响应。从失败和成功中记录：如果你只保存纠正，你将避免过去的错误，但会偏离用户已经验证的方法，并且可能变得过于谨慎。在保存私有反馈记忆之前，检查它是否与团队反馈记忆矛盾------如果是，要么不保存它，要么明确说明覆盖。</description>',
'    <when_to_save>每当用户纠正你的方法（"不是那个"、"不要"、"停止做X"）或确认一个非显而易见的方法有效（"是的，完全正确"、"完美，继续这样做"，接受一个不寻常的选择而没有反对）时。纠正很容易注意到；确认则更安静------要注意它们。在这两种情况下，保存适用于未来对话的内容，特别是如果令人惊讶或从代码中不明显。包括*为什么*，以便你以后可以判断边界情况。</when_to_save>',
'    <how_to_use>让这些记忆指导你的行为，以便用户和项目中的其他用户不需要两次提供相同的指导。</how_to_use>',
'    <body_structure>首先以规则本身开始，然后是**为什么：**（用户给出的原因------通常是过去的事件或强烈偏好）和**如何应用：**（此指导何时/何地生效）。知道*为什么*让你可以判断边界情况，而不是盲目遵循规则。</body_structure>',
'    <examples>',
'    user: 不要在这些测试中模拟数据库------我们上季度因为模拟测试通过但生产迁移失败而吃过亏',
'    assistant: [保存团队反馈记忆：集成测试必须使用真实数据库，而不是模拟。原因：过去的一个事件，其中模拟/生产差异掩盖了一个损坏的迁移。团队作用域：这是一个项目测试策略，而非个人偏好]',
'',
'    user: 停止在每个响应结束时总结你刚才做了什么，我可以看diff',
'    assistant: [保存私有反馈记忆：这个用户想要简洁的响应，没有尾随的总结。私有，因为这是一个沟通偏好，而非项目约定]',
'',
'    user: 是的，单个捆绑PR在这里是正确的选择，拆分这个只会增加工作量',
'    assistant: [保存私有反馈记忆：对于这个区域的重构，用户更喜欢一个捆绑的PR而不是许多小的PR。在我选择这种方法后确认------一个经过验证的判断，而非纠正]',
'    </examples>',
'</type>',

定义：用户给出的关于如何处理工作的指导------包括要避免什么和要继续做什么

1.2.1. 应该存储的信息

1.2.1.1. 纠正性指导（避免什么）

这些是非常重要的读写记忆类型，因为它们让你保持连贯并对你在项目中应该如何处理工作的方式做出响应。 每当用户纠正你的方法（"不是那个"、"不要"、"停止做X"）或确认一个非显而易见的方法有效时，都应该保存这些记忆。

示例：

• "不要在这些测试中模拟数据库------我们上季度因为模拟测试通过但生产迁移失败而吃过亏"
• "停止在每个响应结束时总结你刚才做了什么，我可以看diff"

1.2.1.2. 确认性指导（继续做什么）

从失败和成功中记录：如果你只保存纠正，你将避免过去的错误，但会偏离用户已经验证的方法，并且可能变得过于谨慎。纠正很容易注意到；确认则更安静，要注意它们。

示例：

• "是的，单个捆绑PR在这里是正确的选择，拆分这个只会增加工作量"
• 用户接受了一个不寻常的选择而没有反对

1.2.1.3. 包含原因的指导

保存适用于未来对话的内容，特别是如果令人惊讶或从代码中不明显。包括为什么，以便你以后可以判断边界情况，而不是盲目遵循规则。

1.2.1.4. 指导的结构

首先以规则本身开始，然后是为什么： （用户给出的原因------通常是过去的事件或强烈偏好）和如何应用：（此指导何时/何地生效）

1.2.2. 不应该存储的信息

1.2.2.1. 与团队反馈记忆矛盾的私有反馈

在保存私有反馈记忆之前，检查它是否与团队反馈记忆矛盾------如果是，要么不保存它，要么明确说明覆盖。这样可以避免混淆，保持团队一致性，如果确实需要覆盖，必须明确说明。

1.2.2.2. 个人风格偏好（除非明确要求）

只有当指导显然是每个贡献者都应该遵循的项目级约定（例如，测试策略、构建不变量）而非个人风格偏好时，才保存为团队记忆。

个人偏好不应强加给团队，避免将个人习惯变成团队规则，保持团队记忆的实用性

1.2.3. 使用场景

让这些记忆指导你的行为，以便用户和项目中的其他用户不需要两次提供相同的指导

1.2.4. 记忆存储带来的影响

1.2.4.1. 对用户的核心好处

1. 零重复沟通，交互效率指数级提升

• 用户纠正一次、确认一次，模型永久记住，不用反复提醒、重复指令；
• 比如用户说 "不要加总结""不要模拟数据库"，模型之后永远遵守，彻底消除无效沟通。

2. 模型行为完全可控，输出稳定符合预期

• 模型会主动规避用户明确禁止的行为，也会坚持用户认可的正确做法；
• 输出从 "随机、通用" 变成 "精准、听话"，用户不用反复修改、返工。

3. 兼顾个人偏好 + 团队规则，体验极度舒适

• 个人习惯（如简洁回答、不做总结）：私有保存，只对当前用户生效；
• 团队规范（如测试策略、项目约定）：共享保存，全团队统一遵守；
• 不会把个人偏好强加给团队，也不会用团队规则压制个人习惯，高度人性化。

4. 模型更 "聪明"，不机械死板

• 反馈记忆强制要求记录 **「为什么」，模型能理解规则背后的原因，遇到边界场景会灵活判断 **，而不是盲目执行；
• 比如知道 "禁止模拟数据库是为了避免生产故障"，模型会在相关场景主动规避风险。

5. 正向强化 + 纠错双驱动，模型越用越好用

• 不仅记录 "不要做什么"，还记录 "继续做什么"，模型会保留用户认可的优质行为；
• 不会因为只纠错变得过度谨慎，始终保持高效、靠谱的协作状态。

1.2.4.2. 对大模型交互的核心好处

1. 行为高度一致，输出质量可预测

• 反馈记忆是模型的行为准则，让模型在长期对话、多轮任务中保持稳定表现；
• 彻底解决大模型常见的 "反复无常、前后不一致" 问题。

2. 标准化记忆结构，理解更准确、执行更可靠

• 固定结构：规则 → 为什么 → 如何应用，模型能清晰解析、精准执行；
• 避免记忆模糊、理解偏差，大幅降低错误执行概率。

3. 内置冲突校验，避免逻辑混乱

• 模型会自动检查私有反馈 vs 团队反馈是否冲突，冲突时不保存或明确覆盖；
• 从机制上杜绝规则矛盾，保证模型行为逻辑自洽。

4. 捕捉隐性指令，智能感知用户意图

• 不仅记录明确纠正，还会捕捉安静的确认（如 "是的，正确"）；
• 模型能主动识别用户认可的方案，更智能、更懂用户。

5. 从 "被动响应" 升级为 "主动适配"

• 模型会主动调用反馈记忆调整行为，而不是等用户再次指令；
• 交互从 "用户推着模型走" 变成 "模型主动适配用户"。

1.2.4.3. 对团队协作的核心好处

1. 统一项目规范，全团队协作一致

• 项目级规则（测试策略、构建规范）自动保存为团队共享记忆；
• 所有成员使用模型时，都遵循同一套标准，避免风格混乱、规范不统一。

2. 保护个人偏好，不破坏团队协作

• 个人沟通习惯严格私有，绝不污染团队规则；
• 既保证团队标准化，又尊重个人舒适度，协作零摩擦。

3. 沉淀团队经验，避免重复踩坑

• 记录团队踩过的坑、验证过的最佳实践，变成模型的永久知识；
• 新成员、新任务都能直接复用经验，团队整体效率持续提升。

---

1.3. Project（项目记忆）- 偏向团队共享

项目记忆设计，本质是让 AI 拥有项目全局视野，不再只盯着单段代码或单条指令，而是站在项目目标、时间节奏、团队协作、外部约束的高度来配合用户。

项目记忆帮助你理解用户在这个工作目录中正在进行的工作背后的更广泛背景和动机。使用这些记忆更充分地理解用户请求背后的细节和细微差别，预测用户之间的协调问题，做出更好的知情建议。

• src/memdir/memoryTypes.ts#L75-L89

'<type>',
'    <name>project</name>',
'    <scope>私有或团队，但强烈偏向团队</scope>',
'    <description>你在项目中学到的关于正在进行的工作、目标、计划、错误或事件的信息，这些信息无法从代码或git历史中推导出来。项目记忆帮助你理解用户在这个工作目录中正在进行的工作背后的更广泛背景和动机。</description>',
'    <when_to_save>当你了解到谁在做什么、为什么或何时完成时。这些状态变化相对较快，所以尽量保持你的理解是最新的。保存时始终将用户消息中的相对日期转换为绝对日期（例如，"周四" → "2026-03-05"），以便记忆在时间过后仍然可解释。</when_to_save>',
'    <how_to_use>使用这些记忆更充分地理解用户请求背后的细节和细微差别，预测用户之间的协调问题，做出更好的知情建议。</how_to_use>',
'    <body_structure>首先以事实或决策开始，然后是**为什么：**（动机------通常是约束、截止日期或利益相关者的要求）和**如何应用：**（这应该如何影响你的建议）。项目记忆衰减很快，所以为什么有助于未来的你判断记忆是否仍然起作用。</body_structure>',
'    <examples>',
'    user: 我们将在周四之后冻结所有非关键合并------移动团队正在切发布分支',
'    assistant: [保存团队项目记忆：合并冻结从2026-03-05开始，用于移动版本发布。标记在该日期之后安排的任何非关键PR工作]',
'',
'    user: 我们删除旧auth中间件的原因是法务部门标记了它，因为它以不符合新合规要求的方式存储会话令牌',
'    assistant: [保存团队项目记忆：auth中间件重写是由关于会话令牌存储的法务/合规要求驱动的，而不是技术债务清理------范围决策应该优先考虑合规性而非易用性]',
'    </examples>',
'</type>',

定义：关于正在进行的工作、目标、计划、错误或事件的信息，这些信息无法从代码或git历史中推导出来

1.3.1. 应该存储的信息

1.3.1.1. 时间敏感的项目状态

当你了解到谁在做什么、为什么或何时完成时。这些状态变化相对较快，所以尽量保持你的理解是最新的。这样有助于帮助优先级排序，避免在错误时间做错误的事情，理解项目节奏。

示例：

• "周四之后我们将冻结所有非关键合并------移动团队正在切发布分支"
• 发布时间表、截止日期

1.3.1.2. 决策背后的动机

首先以事实或决策开始，然后是为什么： （动机------通常是约束、截止日期或利益相关者的要求）和如何应用：（这应该如何影响你的建议）。理解决策的约束条件，帮助判断记忆是否仍然相关。

示例：

• "我们删除旧auth中间件的原因是法务部门标记了它，因为它以不符合新合规要求的方式存储会话令牌"

1.3.1.3. 协调信息

使用这些记忆更充分地理解用户请求背后的细节和细微差别，预测用户之间的协调问题，做出更好的知情建议。帮助你理解用户在这个工作目录中正在进行的工作背后的更广泛背景和动机。

示例：

• 谁在做什么、为什么、何时完成
• 跨团队依赖关系

1.3.2. 不应该存储的信息

1.3.2.1. 可以从代码或git历史推导的信息

可以从代码或git历史推导的信息，不应该存储。避免冗余，保持记忆的独特价值，避免记忆过时（代码可能变化），遵循"单一真相源"原则。

1.3.2.2. 过时的项目状态

项目记忆快速衰减，需要定期验证和更新，过时记忆可能导致错误决策。

1.3.3. 记忆存储带来的影响

1.3.3.1. 对用户带来的影响

1. 不用反复解释项目背景，沟通成本大幅降低

• 项目背景、发布节奏、合规要求、团队安排这类代码里看不到的信息，AI 记一次就能长期理解。
• 用户不用每次都补充 "为什么要这么改""现在不能合入""下周要发版"，AI 自动带入上下文。

2. AI 给出的建议更贴合真实项目节奏，避免无效工作

• 记住发布冻结、分支切换、截止日期后，AI 会自动调整优先级，不会在冻结期建议合入非关键 PR。
• 避免出现 "技术上可行，但项目上完全不合时宜" 的方案，减少返工和浪费。

3. 理解决策背后的真正动机，建议更专业、更靠谱

• AI 不仅知道 "要删旧鉴权中间件"，还知道是法务合规要求，而不是普通重构。
• 给出方案时会优先满足合规、业务、外部约束，而不是只追求技术优雅，更符合真实工程决策逻辑。

4. 帮助预判协作风险，减少团队协调问题

• AI 能记住谁在做什么、跨团队依赖、时间节点，从而提前发现冲突。
• 用户在做开发、重构、代码审查时，AI 可以主动提醒风险，降低沟通摩擦。

5. 时间信息标准化，记忆长期可用

• 自动把 "周四" 转为绝对日期，避免过几天对话上下文丢失后，AI 理解错乱。
• 项目信息更稳定、可追溯，不会随着对话轮次变模糊。

1.3.3.2. 对大模型交互的好处

1. 让模型从 "代码工具" 升级为 "项目协作助手"

• 不再只处理局部代码问题，而是具备项目视角，能理解整体意图。
• 输出更有大局观，建议更成熟、更贴近工程实际。

2. 只存储代码无法推导的信息，记忆更精简、更高价值

• 明确不存代码 / Git 可查内容，避免冗余和信息冲突。
• 记忆库专注于隐性知识、业务动机、项目规则，AI 调用效率更高。

3. 结构化记忆让模型理解更准确，执行更一致

• 固定结构：事实 → 为什么 → 如何应用，模型能清晰判断适用场景。
• 面对边界情况不会机械执行，而是根据动机做合理判断。

4. 自带 "时效性意识"，减少过时信息带来的错误

• 项目记忆衰减快，模型会关注 "为什么"，从而判断这条信息是否 still valid。
• 降低因项目状态变化导致 AI 给出过时、错误建议的风险。

5. 支持团队共享，保证多人协作时行为统一

• 偏向团队共享，整个团队使用 AI 时都基于同一套项目背景。
• 避免不同人用 AI 得到不一致、不符合项目规范的结果，保证协作一致性。

---

1.4. Reference（参考记忆）- 通常团队共享

存储指向外部系统中信息位置的指针。这些记忆让你记住在哪里查找项目目录外部的最新信息。

参考记忆的核心作用，是让大模型记住项目外部的 "信息地图"，而不是死记内容本身，让 AI 真正融入团队的工具链和工作流。

• src/memdir/memoryTypes.ts#L90-L103

'<type>',
'    <name>reference</name>',
'    <scope>通常为团队</scope>',
'    <description>存储指向外部系统中信息位置的指针。这些记忆让你记住在哪里查找项目目录外部的最新信息。</description>',
'    <when_to_save>当你了解到外部系统中的资源及其用途时。例如，错误在Linear中的特定项目中跟踪，或者反馈可以在特定的Slack频道中找到。</when_to_save>',
'    <how_to_use>当用户引用外部系统或可能在外部系统中的信息时。</how_to_use>',
'    <examples>',
'    user: 检查Linear项目"INGEST"以获取这些票据的上下文，那是我们跟踪所有管道错误的地方',
'    assistant: [保存团队参考记忆：管道错误在Linear项目"INGEST"中跟踪]',
'',
'    user: grafana.internal/d/api-latency处的Grafana仪表板是oncall监控的内容------如果你正在处理请求处理，那是会触发页面告警的东西',
'    assistant: [保存团队参考记忆：grafana.internal/d/api-latency是oncall延迟仪表板------在编辑请求路径代码时检查它]',
'    </examples>',
'</type>',

定义：存储指向外部系统中信息位置的指针

1.4.1. 应该存储的信息

1.4.1.1. 外部系统中的资源位置

记住在哪里查找最新信息，避免重复询问相同的外部资源位置，提高跨系统协作效率。

示例：

• "检查Linear项目'INGEST'获取这些票据的上下文，我们在那里跟踪所有管道错误"
• "grafana.internal/d/api-latency是oncall监控的仪表板"

1.4.1.2. 外部资源的用途说明

理解每个资源的用途，在正确的地方查找正确信息，避免在错误的地方浪费时间。

示例：

• Linear项目"INGEST"用于跟踪管道错误
• 特定Slack频道用于收集反馈
• Grafana仪表板用于监控延迟

1.4.2. 不应该存储的信息

1.4.2.1. 外部系统的具体内容

外部系统内容可能变化，应该实时查询最新信息，避免存储过时数据。

1.4.2.2. 项目目录内的资源位置

项目内的信息应该通过代码搜索获得，避免冗余，保持记忆系统的专注性。

1.4.3. 记忆存储带来的影响

1.4.3.1. 对用户带来的影响

1. 不用反复告知外部资源位置，沟通更省心
   用户只需说一次 "问题在 Linear 的 INGEST 项目""监控看这个 Grafana 面板"，模型就永久记住，后续不用重复指路。
2. AI 能自动关联正确外部信息，建议更贴近真实运维流程
   模型在处理代码、排查问题时，会主动联想到对应的工单系统、监控面板、文档地址，给出的方案更落地、更符合团队实际工作方式。
3. 避免 AI 给出过时、错误的外部信息
   参考记忆只存位置指针，不存具体内容，确保模型永远去外部系统查最新数据，不会用缓存的旧内容误导决策。
4. 跨系统协作更顺畅，减少查找成本
   模型清楚错误跟踪、监控、反馈渠道分别在哪里，用户不需要手动跳转多个系统，AI 可以直接指向正确位置。
5. 团队协作统一，新人上手更快
   资源位置作为团队共享记忆，新成员使用 AI 时，模型自动掌握全套外部工具入口，大幅降低团队磨合成本。

1.4.3.2. 对大模型交互的好处

1. 让 AI 从 "只懂代码" 扩展为 "懂整套工程体系"
   模型不再局限于项目目录，而是能链接工单、监控、文档等外部系统，能力边界显著扩大。
2. 记忆轻量化、高效、不易失效
   只存地址和用途，不存实时变化的内容，记忆体积小、稳定性高，不会因为外部数据更新而过时。
3. 行为更规范、更专业，避免编造信息
   模型知道 "去哪里查" 而不是 "瞎编答案"，减少幻觉，输出更可靠、更可信。
4. 结构化记忆便于精准调用
   明确什么场景该查哪个系统，模型能根据任务类型自动匹配对应资源，响应更精准。
5. 保持与团队工具链对齐，协作一致性更强
   团队共享一套参考记忆，所有人使用 AI 时都遵循相同的信息查找路径，避免混乱。

---

1.5. 汇总：各种记忆类型记忆中应该存什么，不应该存什么

1.5.1. 用户记忆(User)

用户记忆(User)
用户记忆(User) - 始终私有
应该存储
不应该存储
用户角色和职责
专业技能和知识水平
工作偏好和学习风格
职业背景
专业领域
项目角色
经验年限
擅长领域
新手领域
响应偏好
解释偏好
学习方式
对用户的负面评价
与工作无关的个人信息

1.5.2. 反馈记忆(Feedback)

反馈记忆(Feedback)
反馈记忆(Feedback) - 默认私有，团队共享需谨慎
应该存储
不应该存储
纠正性指导
确认性指导
包含原因的指导
指导的结构
避免什么
用户纠正的方法
继续做什么
用户确认的方法
为什么
如何应用
规则本身
为什么
如何应用
与团队反馈记忆矛盾的私有反馈
个人风格偏好

1.5.3. 项目记忆(Project)

项目记忆(Project)
项目记忆(Project) - 偏向团队共享
应该存储
不应该存储
时间敏感的项目状态
决策背后的动机
协调信息
谁在做什么
为什么
何时完成
发布时间表
截止日期
约束条件
截止日期
利益相关者要求
跨团队依赖关系
团队协作信息
可以从代码或git历史推导的信息
过时的项目状态

1.5.4. 参考记忆(Reference)

项目记忆(Project)
参考记忆(Reference) - 通常团队共享
应该存储
不应该存储
外部系统中的资源位置
外部资源的用途说明
Linear项目位置
Grafana仪表板地址
Slack频道
其他外部系统
资源用途
使用场景
外部系统的具体内容
项目目录内的资源位置

---

2. 如何解决记忆冲突的问题

2.1. 私有反馈记忆 vs 团队反馈记忆的冲突

冲突场景：用户给出了与团队记忆矛盾的个人偏好

解决策略：

代码依据 ：src/memdir/memoryTypes.ts#L40-L41

"Before saving a private feedback memory, check that it doesn't contradict a team feedback memory --- if it does, either don't save it or note the override explicitly."
// 在保存私有反馈记忆之前，检查它是否与团队反馈记忆矛盾------如果是，要么不保存它，要么明确说明覆盖

处理方式：

• 选项1：不保存私有记忆

  • 当团队记忆明确是项目级约定时
  • 避免混淆和冲突

• 选项2：明确说明覆盖

  • 当个人偏好确实需要覆盖团队约定时
  • 在记忆中明确说明这是个人覆盖

示例：

团队记忆：所有测试必须使用真实数据库
私有记忆：对于这个特定模块，用户接受模拟数据库（个人覆盖：此模块测试隔离性要求高于团队约定）

2.2. 记忆与当前代码状态的冲突

冲突场景：记忆中记录的信息与当前代码状态不一致

解决策略：

代码依据 ：src/memdir/memoryTypes.ts#L202-L205

export const MEMORY_DRIFT_CAVEAT =
  '- Memory records can become stale over time. Use memory as context for what was true at a given point in time. Before answering the user or building assumptions based solely on information in memory records, verify that the memory is still correct and up-to-date by reading the current state of the files or resources. If a recalled memory conflicts with current information, trust what you observe now --- and update or remove the stale memory rather than acting on it.'
// 记忆记录可能随时间变得过时。将记忆作为在给定时间点为真的上下文使用。在回答用户或仅基于记忆记录中的信息建立假设之前，通过读取文件或资源的当前状态来验证记忆是否仍然正确和最新。如果召回的记忆与当前信息冲突，相信你现在观察到的------并更新或删除过时的记忆，而不是基于它行动

处理方式：

• 优先级：当前状态 > 记忆

  • 记忆是时间点的观察，不是实时状态
  • 信任当前观察到的状态

• 验证步骤：

  1. 检查记忆中提到的文件是否存在
  2. 搜索记忆中提到的函数或标志
  3. 验证记忆中的事实是否仍然正确

• 更新或删除过时记忆：

  • 更新仍然相关但需要修正的记忆
  • 删除完全过时的记忆

代码依据 ：src/memdir/memoryTypes.ts#L245-L252

'## Before recommending from memory',
'',
'A memory that names a specific function, file, or flag is a claim that it existed *when the memory was written*. It may have been renamed, removed, or never merged. Before recommending it:',
'',
'- If the memory names a file path: check the file exists.',
'- If the memory names a function or flag: grep for it.',
'- If the user is about to act on your recommendation (not just asking about history), verify first.',
'',
'"The memory says X exists" is not the same as "X exists now."',
// ## 从记忆中推荐之前
// 
// 一个命名特定函数、文件或标志的记忆是声称它*在记忆编写时*存在。它可能已被重命名、删除或从未合并。在推荐它之前：
// 
// - 如果记忆命名了文件路径：检查文件是否存在。
// - 如果记忆命名了函数或标志：grep搜索它。
// - 如果用户即将根据你的推荐行动（而不仅仅是询问历史），首先验证。
// 
// "记忆说X存在"与"X现在存在"不是一回事。

2.3. 用户明确要求忽略记忆

冲突场景：用户说"忽略记忆关于X的内容"

解决策略：

代码依据 ：src/memdir/memoryTypes.ts#L210-L213

'- If the user says to *ignore* or *not use* memory: proceed as if MEMORY.md were empty. Do not apply remembered facts, cite, compare against, or mention memory content.'
// - 如果用户说*忽略*或*不使用*记忆：就像MEMORY.md为空一样继续。不要应用记住的事实，引用，与记忆内容比较，或提及记忆内容

处理方式：

• 完全忽略记忆：

  • 不应用记忆中的事实
  • 不引用记忆内容
  • 不与记忆进行比较
  • 不提及记忆内容

• 避免的反模式：

  • "不是记忆中说的Y"（这是"承认然后覆盖"而非"完全不引用"）

代码依据 ：src/memdir/memoryTypes.ts#L210-L213的注释说明：

// H6 (branch-pollution evals #22856, case 5 1/3 on capy): the "ignore" bullet
// is the delta. Failure mode: user says "ignore memory about X" → Claude reads
// code correctly but adds "not Y as noted in memory" --- treats "ignore" as
// "acknowledge then override" rather than "don't reference at all." The bullet
// names that anti-pattern explicitly.
// H6（分支污染评估 #22856，capy上案例5 1/3）："ignore"要点
// 是差异。失败模式：用户说"忽略关于X的记忆" → Claude正确读取
// 代码但添加"不是记忆中提到的Y"------将"ignore"视为
// "承认然后覆盖"而不是"完全不引用"。该要点
// 明确命名了这种反模式。

2.4. 记忆之间的矛盾

冲突场景：两个记忆文件包含矛盾的信息

解决策略（在Dream压缩过程中）：

代码依据 ：src/services/autoDream/consolidationPrompt.ts#L44-L52

'## Phase 3 --- Consolidate',
'',
'For each thing worth remembering, write or update a memory file at the top level of the memory directory. Use the memory file format and type conventions from your system prompt\'s auto-memory section --- it\'s source of truth for what to save, how to structure it, and what NOT to save.',
'',
'Focus on:',
'- Merging new signal into existing topic files rather than creating near-duplicates',
'- Converting relative dates ("yesterday", "last week") to absolute dates so they remain interpretable after time passes',
'- Deleting contradicted facts --- if today\'s investigation disproves an old memory, fix it at the source',
// ## 阶段3------整合
// 
// 对于每个值得记住的事情，在记忆目录的顶层编写或更新一个记忆文件。使用系统提示词的自动记忆部分中的记忆文件格式和类型约定------它是关于保存什么、如何结构化以及不保存什么的真相来源。
// 
// 专注于：
// - 将新信号合并到现有主题文件中，而不是创建近重复
// - 将相对日期（"昨天"、"上周"）转换为绝对日期，以便它们在时间过后仍然可解释
// - 删除矛盾的事实------如果今天的调查推翻了旧记忆，在源头修复它

处理方式：

• 删除矛盾事实：

  • 如果今天的调查推翻了旧记忆，在源头修复它

• 合并相似记忆：

  • 将新信号合并到现有主题文件中
  • 避免创建近重复文件

• 转换相对日期：

  • 将"昨天"、"上周"转换为绝对日期
  • 确保记忆在时间过后仍然可解释

代码依据 ：src/services/autoDream/consolidationPrompt.ts#L60-L65

'- Resolve contradictions --- if two files disagree, fix the wrong one',
'',
'---',
'',
'Return a brief summary of what you consolidated, updated, or pruned. If nothing changed (memories are already tight), say so.'
// - 解决矛盾------如果两个文件不一致，修复错误的那个
// 
// ---
// 
// 返回你整合、更新或修剪的内容的简要摘要。如果没有任何变化（记忆已经很紧凑），就这样说。

---

3. 记忆整合/压缩时的取舍策略

3.1. 应该存储的信息

3.1.1. 每日日志中的新信息（最高优先级）

代码依据 ：src/services/autoDream/consolidationPrompt.ts#L36-L37

'1. **Daily logs** (`logs/YYYY/MM/YYYY-MM-DD.md`) if present --- these are append-only stream',
// 1. **每日日志**（`logs/YYYY/MM/YYYY-MM-DD.md`）如果存在------这些是仅追加流

说明：每日日志是仅追加的流，包含最近的所有活动，是压缩时优先处理的信息源。

3.1.2. 漂移的现有记忆（与当前代码库状态矛盾的事实）

代码依据 ：src/services/autoDream/consolidationPrompt.ts#L38-L39

'2. **Existing memories that drifted** --- facts that contradict something you see in the codebase now',
// 2. **已漂移的现有记忆**------与你现在在代码库中看到的内容相矛盾的事实

说明：需要更新或删除的过时记忆，与当前代码库状态矛盾的事实。

3.1.3. 转录搜索中找到的特定上下文（最低优先级）

代码依据 ：src/services/autoDream/consolidationPrompt.ts#L40-L43

'3. **Transcript search** --- if you need specific context (e.g., "what was` the error message from yesterday's build failure?"), grep JSONL transcripts for narrow terms:',
'   `grep -rn "<narrow term>" ${transcriptDir}/ --include="*.jsonl" | tail -50`',
// 3. **转录搜索**------如果你需要特定上下文（例如，"昨天构建失败的错误消息是什么？"），用窄术语grep JSONL转录：
//    `grep -rn "<narrow term>" ${transcriptDir}/ --include="*.jsonl" | tail -50`

说明：仅在需要特定上下文时使用，使用窄术语进行grep搜索，不要详尽阅读转录文件。

3.1.4. 合并到现有主题文件中的新信号

代码依据 ：src/services/autoDream/consolidationPrompt.ts#L47-L48

'- Merging new signal into existing topic files rather than creating near-duplicates',
// - 将新信号合并到现有主题文件中，而不是创建近重复

说明：优先合并新信号到现有主题文件，避免创建近重复文件。

3.1.5. 转换为绝对日期的信息

代码依据 ：src/services/autoDream/consolidationPrompt.ts#L49-L50

'- Converting relative dates ("yesterday", "last week") to absolute dates so they remain interpretable after time passes',
// - 将相对日期（"昨天"、"上周"）转换为绝对日期，以便它们在时间过后仍然可解释

说明：将"昨天"、"上周"转换为绝对日期（例如"2026-03-05"），确保记忆在时间过后仍然可解释。

3.1.6. 新重要记忆的指针

代码依据 ：src/services/autoDream/consolidationPrompt.ts#L62

'- Add pointers to newly important memories',
// - 添加指向新重要记忆的指针

说明：为新的重要记忆添加指针，保持索引与当前记忆状态同步。

3.1.7. 从最近~N条消息中提取的记忆

代码依据 ：src/services/extractMemories/prompts.ts#L30-L45

`You are now acting as a memory extraction subagent. Analyze` the most recent ~${newMessageCount} messages above and use them to update your persistent memory systems.`,
`You MUST only use content from` the last ~${newMessageCount} messages to update your persistent memories. Do not waste any turns attempting to investigate or verify that content further --- no grepping source files, no reading code to confirm a pattern exists, no git commands.`
// 你现在充当记忆提取子代理。分析上面的最近~${newMessageCount}条消息，并使用它们来更新你的持久记忆系统。
// 你必须仅使用来自最近~${newMessageCount}条消息的内容来更新你的持久记忆。不要浪费任何回合试图进一步调查或验证该内容------不grep源文件，不读取代码以确认模式存在，不使用git命令。

说明：只从最近的~N条消息中提取记忆，不浪费时间验证或进一步调查内容。

---

3.2. 不应该存储的信息

3.2.1. 近重复文件（应该合并到现有主题文件）

代码依据 ：src/services/autoDream/consolidationPrompt.ts#L47-L48

'- Merging new signal into existing topic files rather than creating near-duplicates',
// - 将新信号合并到现有主题文件中，而不是创建近重复

说明：不要创建近重复文件，应该将新信号合并到现有主题文件中。

3.2.2. 矛盾的事实（应该删除）

代码依据 ：src/services/autoDream/consolidationPrompt.ts#L51-L52

'- Deleting contradicted facts --- if today\'s investigation disproves an old memory, fix it at the source',
// - 删除矛盾的事实------如果今天的调查推翻了旧记忆，在源头修复它

说明：如果今天的调查推翻了旧记忆，在源头修复它，不要保留矛盾的信息。

3.2.3. 过时、错误或被替代的记忆指针

代码依据 ：src/services/autoDream/consolidationPrompt.ts#L58

'- Remove pointers to memories that are now stale, wrong, or superseded',
// - 移除指向现在已过时、错误或被替代的记忆的指针

说明：删除指向过时记忆、错误记忆或已被替代记忆的指针。

3.2.4. 超过~200字符的冗长索引条目

代码依据 ：src/services/autoDream/consolidationPrompt.ts#L59-L60

'- Demote verbose entries: if an index line is over ~200 chars, it\'s carrying content that belongs in topic file --- shorten the line, move the detail',
// - 降级冗长条目：如果索引行超过~200字符，它携带的内容属于主题文件------缩短行，移动细节

说明 ：如果索引行超过_{200字符，将详细内容移到主题文件，保持索引简洁（应控制在}150字符以内）。

3.2.5. 详尽阅读转录取文件

代码依据 ：src/services/autoDream/consolidationPrompt.ts#L43

'Don\'t exhaustively read transcripts. Look only for things you already suspect matter.',
// 不要详尽地阅读转录。只查找你已经怀疑重要的事情。

说明：不要详尽阅读转录文件，只查找你已经怀疑重要的内容。

3.2.6. 需要进一步验证或调查的内容

代码依据 ：src/services/extractMemories/prompts.ts#L45

`Do not waste any turns attempting to investigate or verify that content further --- no grepping source files, no reading code to confirm a pattern exists, no git commands.`
// 不要浪费任何回合试图进一步调查或验证该内容------不grep源文件，不读取代码以确认模式存在，不使用git命令。

说明：不浪费时间验证或进一步调查内容，不grep源文件，不读取代码以确认模式存在，不使用git命令。

3.2.7. 重复提取相同的信息

代码依据 ：src/memdir/teamMemPrompts.ts#L40、src/memdir/memdir.ts#L216

'- Do not write duplicate memories. First check if there is an existing memory you can update before writing a new one.',
// - 不要编写重复记忆。首先检查是否有可以更新的现有记忆，然后再编写新记忆。

说明：不要编写重复记忆，首先检查是否有可以更新的现有记忆，然后再编写新记忆。

---

3.3. 总结

处理动作
记忆整合/压缩

决策流程
应该存储的信息
每日日志新信息

最高优先级

仅追加流
漂移的现有记忆

与当前代码矛盾的事实

需更新或删除
转搜索上下文

最低优先级

窄术语 grep 搜索
合并新信号

合并到现有主题文件
转换为绝对日期

昨天/上周 -> 2026-03-05
新重要记忆指针

保持索引同步
最近 N 条消息

仅提取，不验证
不应该存储的信息
近重复文件

避免创建重复
矛盾的事实

被推翻的旧记忆
过时/错误指针

指向无效记忆
冗长索引条目

200 字符的细节
详尽阅读转录

不要全盘阅读
进一步验证内容

不 grep/不读码
重复提取信息

避免重复写入
合并

新信号入旧文件
删除/修复

移除矛盾/过时事实
截断/移动

保持索引简洁
转换

相对日期转绝对日期

3.3.1. 核心取舍原则

1. 合并优先：将新信号合并到现有主题文件，避免创建近重复文件
2. 删除矛盾：删除矛盾事实，基于新信息更新记忆
3. 保持简洁：保持索引在200行以下和25KB以下，索引行控制在~150字符以内
4. 有选择性：只查找已经怀疑重要的内容，不要详尽搜索
5. 不验证内容：只从最近消息中提取，不浪费时间验证或调查
6. 更新现有：检查现有记忆，更新而非创建新记忆
7. 优先级驱动：按照优先级顺序处理信息源（每日日志 > 漂移记忆 > 转录搜索）

---

4. 记忆设计的核心原则

基于以上分析，Claude Code记忆系统的核心原则如下：

记忆存储设计原则	核心定义	具体应用与实践
1. 不可推导性原则	只存储无法从代码、Git历史或CLAUDE.md获得的信息。	• 避免存储代码模式、约定、架构 • 避免存储文件路径或项目结构 • 避免存储Git历史、最近更改 • 遵循"单一真相源"原则
2. 长期价值原则	存储跨对话有用的信息，而非临时状态。	• 存储用户角色、偏好、知识背景 • 存储反馈指导（跨对话有用） • 避免存储进行中的工作、临时状态 • 避免存储当前对话上下文
3. 时效性意识原则	记忆是时间点的观察，需要验证当前状态。	• 记忆是时间点的观察，不是实时状态 • 优先级：当前状态 > 记忆 • 使用前验证记忆的准确性 • 更新或删除过时记忆
4. 动机驱动原则	存储包含"为什么"的信息，帮助判断边界情况。	• 存储指导时包含原因 • 记录决策背后的动机 • 帮助判断边界情况 • 避免盲目遵循规则
5. 避免冗余原则	不存储可以从其他权威来源获得的信息。	• 避免重复存储可推导的信息 • 保持记忆系统的独特价值 • 遵循"单一真相源"原则 • 优先使用权威来源（git、代码、CLAUDE.md）
6. 冲突解决原则	优先级明确，当前状态优先。	• 当前状态 > 记忆 ：信任当前观察到的状态 • 团队 > 私有 ：团队记忆优先于个人偏好 • 用户指令优先 ：用户要求忽略时完全忽略记忆 • 新信息优先：删除矛盾事实，基于新信息更新记忆
7. 压缩优化原则	合并相似记忆，删除矛盾事实，保持索引简洁。	• 合并优先 ：将新信号合并到现有主题文件 • 避免重复 ：不要创建近重复文件 • 删除矛盾 ：删除矛盾事实，修复错误记忆 • 保持简洁：保持索引在200行以下和25KB以下
8. 验证优先原则	在使用记忆前验证其准确性。	• 检查记忆中提到的文件是否存在• 搜索记忆中提到的函数或标志 • 用户即将行动时首先验证 • "记忆说X存在"不等于"X现在存在"
9. 作用域明确原则	每种记忆类型都有明确的作用域。	• user ：始终私有，保护用户隐私 • feedback ：默认私有，团队共享需谨慎 • project ：偏向团队共享，促进团队协作 • reference：通常团队共享，提高跨系统协作效率
4.1.	10. 结构化存储原则	记忆文件有明确的frontmatter格式和内容结构。

---

4.2. 总结

Claude Code的记忆系统设计遵循以上十个核心原则，确保：

1. 提供真正有价值的长期上下文：只存储不可推导的、跨对话有用的信息
2. 保持记忆的准确性和相关性：通过定期压缩和冲突解决机制
3. 避免冗余和过时信息：遵循"单一真相源"原则，优先使用权威来源
4. 支持团队协作：通过作用域明确和团队共享机制
5. 高效管理记忆：通过四阶段压缩流程和索引优化

这个记忆系统设计确保AI能够记住真正重要的信息，同时避免存储冗余、过时或可推导的内容，从而提供更智能、更个性化的服务。