目录1 四种类型速览2 user用户画像2.1 一句话理解2.2 详细说明2.3 何时保存2.4 如何使用2.5 注意事项2.6 示例2.7 实践3 feedback反馈偏好3.1 一句话理解3.2 详细说明3.3 何时保存3.4 文件的推荐结构3.5 示例3.6 实践4 project项目上下文4.1 一句话理解4.2 详细说明4.3 何时保存4.4 关键规则4.5 body_structure4.6 示例5 reference外部参考指针5.1 一句话理解5.2 详细说明5.3 何时保存5.4 如何使用5.5 示例6 四类记忆对比总结7 什么不该存为记忆8 记忆文件的格式8.1 示例一条 feedback 记忆8.2 user-roleClaude Code自动记忆系统四种记忆类型详解 —— 小白也能看懂Claude Code中自动记忆系统将记忆严格限定为4 种类型形成一个封闭的分类体系。每种类型有明确的“何时保存”和“如何使用”规则。核心原则只有无法从代码/git 推导出来的信息才值得存为记忆。代码模式、架构、git 历史、文件结构……这些通过 grep/git/CLAUDE.md 就能查到不应存为记忆。1 四种类型速览通过Claude Code源码src/memdir/memoryTypes.ts 可以清楚的知道Claude Code 的记忆系统将记忆分为四类这套分类体系解决了“谁有资格被记住”的问题。我们用下图来展示四个分类┌──────────────────────────────────────────────────────────────────┐ │ 记忆四分类 │ │ │ │ user feedback project reference │ │ ┌──────┐ ┌──────┐ ┌──────┐ ┌──────┐ │ │ │ │ │ │ │ │ │ │ │ │ │ 用户 │ │ 反馈 │ │ 项目 │ │ 参考 │ │ │ │ 画像 │ │ 偏好 │ │ 上下文│ │ 指针 │ │ │ └──────┘ └──────┘ └──────┘ └──────┘ │ │ │ │ 你是谁 怎么做 为什么做 去哪找 │ │ 身份/角色 行为准则 背景/动机 外部资源 │ └──────────────────────────────────────────────────────────────────┘~/.claude/ └── projects/ └── sanitized-git-root/ # Git 仓库根路径的 sanitized 版本 └── memory/ # getAutoMemPath() 返回值 ├── MEMORY.md # 索引文件入口文件上限 200 行 / 25KB ├── user_role.md # 记忆文件以下为示例 ├── feedback_testing.md ├── project_deadline.md ├── reference_dashboard.md ├── logs/ # KAIROS 助手模式的每日日志 │ └── YYYY/ │ └── MM/ │ └── YYYY-MM-DD.md ├── team/ # 团队记忆需 TEAMMEM feature tengu_herring_clock GrowthBook 开关 │ └── MEMORY.md └── .consolidate-lock # autoDream 整合锁2 user用户画像2.1 一句话理解记录你是谁——用户的身份、角色、技能水平、知识背景。2.2 详细说明这类记忆帮 AI调整沟通方式。同样是解释一段代码对资深工程师和对刚入门的学生回答方式完全不同。2.3 何时保存当了解到用户的以下信息时角色和职位技能水平和经验知识领域擅长什么、不熟悉什么工作职责和关注点2.4 如何使用当回答问题时根据用户画像调整回答的深度、角度和侧重点。例如资深后端 → 用后端类比解释前端概念数据科学家 → 突出数据/日志相关的内容学生 → 更耐心、更详细、更多背景解释2.5 注意事项不要存负面评价或与工作无关的个人信息目标是更好地帮助用户不是评判用户2.6 示例用户说AI 记住什么“我是一名数据科学家正在调查我们的日志系统”user_data_scientist.md→ 用户是数据科学家当前关注可观测性/日志“我写了十年 Go但这是我第一次碰这个项目的 React 部分”user_go_expert.md→ Go 资深React 新手 → 用后端概念类比解释前端“我对 Rust 还不太熟边做边学”user_learning_rust.md→ 正在学 Rust → 解释要详细给出学习资源2.7 实践例如我们打开一个工程输入如下内容我是一名intersystems iris语言工程师对ts代码不太熟悉。此时Claude Code就会根据其内部机制判断是否要写入memory执行完成之后会在记忆文件夹中创建了一个叫做user_role.md的文件。3 feedback反馈偏好3.1 一句话理解记录怎么做——用户教你的行为准则既包括纠正也包括肯定。3.2 详细说明这是最重要的记忆类型。用户给你的每一条反馈——不管是批评还是表扬——都应该记住。关键不仅要记录失败纠正也要记录成功认可。如果只记录纠正你会越来越保守记录认可则帮你锁定用户喜欢的做法。3.3 何时保存触发场景示例用户纠正做法“别这样”、“不要”、“停止做 X”用户认可做法“对就是这样”、“完美继续这样做”用户接受一个不寻常的选择没有质疑默认通过纠正好识别认可容易被忽略——要特别注意捕捉。3.4 文件的推荐结构规则本身 **Why:** 用户给出这条规则的原因知道原因才能判断边界情况 **How to apply:** 何时/何处应用这条规则3.5 示例用户说AI 记住什么“测试里别 mock 数据库上次 mock 测试过了但生产迁移失败了”集成测试必须用真实数据库。原因mock 与生产环境差异曾导致迁移失败“别再每条回复末尾总结你干了什么我看 diff 就知道了”用户要简洁回复不要末尾总结。原因用户会自己看 diff“对这次打包成一个 PR 是正确的拆开就是无意义的 churn”此类重构用户倾向于一个 PR。原因已验证拆分无价值3.6 实践例如第一次在让Claude Code帮我绘制.drawio格式的流程图时绘制完成之后打开之后报错提示非绘图文件。对话告诉他此次输出的文件打开报错提示非绘图文件。修复Claude Code自动帮我修复然后总结了2条原因。肯定他让他记住此次的修复问题。之后Claude Code便会在记忆文件夹中创建了feedback_drawio_xml_rules.md文件。4 project项目上下文4.1 一句话理解记录为什么做——代码之外的动机、约束、截止日期、决策背景。4.2 详细说明代码告诉你做了什么但很少告诉你为什么。为什么用这个方案而不是另一个这个功能的截止日期是什么谁在推动这件事出于什么原因有没有合并冻结/发布窗口这些信息对做出正确决策至关重要但代码里找不到。4.3 何时保存当了解到以下信息时谁在做什么、为什么要做、何时完成项目的 deadline 和里程碑决策背后的非技术原因合规、法律、业务组织层面的约束团队分工、发布节奏4.4 关键规则必须把相对日期转成绝对日期“周四开始合并冻结” → 记成 “2026-05-18 开始合并冻结”而不是 “周四”因为几周后你再看这条记忆周四就没有意义了。4.5 body_structure事实或决策 **Why:** 动机约束、截止日期、需求方 **How to apply:** 这条信息如何影响你的建议4.6 示例用户说AI 记住什么“周四之后冻结所有非紧急合并移动端要切发布分支了”合并冻结 2026-05-18 开始。标记该日期之后的非关键 PR“我们在重写认证中间件因为法务说旧版存 session token 的方式不合规”认证重写是合规驱动的不是技术债清理。方案选择应优先合规“这个任务不急优先级低于用户那边反馈的 bug 修复”当前阶段 bug 修复优先级高于功能开发5 reference外部参考指针5.1 一句话理解记录去哪找——外部系统中的资源位置而不是内容本身。5.2 详细说明这类记忆不存内容本身只存资源的坐标。因为外部系统的内容随时在变过时风险高存一个指针去源头查才是正确的。5.3 何时保存当了解到以下信息时bug 在哪个系统里跟踪Linear、Jira、GitHub Issues监控面板在哪里Grafana、Datadog文档在哪里Confluence、Notion、Google Docs团队沟通渠道Slack 频道、邮件组5.4 如何使用当用户提到某个系统或话题时先查 reference 记忆找到对应的外部资源位置。5.5 示例用户说AI 记住什么“查 Linear 项目 INGEST那里跟踪所有 pipeline bug”管线 bug 跟踪在 Linear 项目 “INGEST”“grafana.internal/d/api-latency 是 oncall 盯的看板改请求相关代码时注意别把延迟搞上去”oncall 延迟看板在 grafana.internal/d/api-latency改请求路径代码时要关注“部署文档在 notion.so/xxx-deploy-guide”部署文档在 Notionnotion.so/xxx-deploy-guide6 四类记忆对比总结维度userfeedbackprojectreference核心问题你是谁你要我怎么做为什么做这个相关信息在哪内容性质身份/能力描述行为规则/偏好背景/动机/约束外部资源坐标时效性基本稳定较稳定变化快容易过时取决于外部系统触发频率低一次性中持续积累中随项目推进低易被忽略—认可比纠正更易漏相对日期忘转绝对—7 什么不该存为记忆核心原则即使面对明确的保存请求也应主动追问用户“其中哪些信息是出乎意料或非显而易见的”仅保留具备高信息熵的核心内容。以下五类信息通常无需额外记忆代码架构与文件路径此类信息可通过grep或glob等工具在代码库中直接检索获取。版本控制与变更记录Git 历史记录及代码归属谁修改了什么应以git log和git blame的查询结果为准保持单一事实来源。调试方案与修复记录代码中的实际修复及 Commit Message 已包含完整的上下文无需重复记录“修 bug 菜谱”。CLAUDE.md 既有内容项目根目录的CLAUDE.md中已明确记载的规则严禁重复记忆。临时任务与瞬时状态进行中的工作细节、临时状态及当前对话的短期上下文不具备长期记忆价值。8 记忆文件的格式每条记忆存为独立的.md文件使用 YAML frontmatter--- name: {{记忆名称短横线连接}} description: {{一句话描述——用于未来判断是否相关所以要具体}} type: user / feedback / project / reference --- {{记忆正文}} - feedback/project 类型建议包含 **Why:** 和 **How to apply:** 段落8.1 示例一条 feedback 记忆--- name: concise-responses description: User prefers terse responses without trailing summaries type: feedback --- Rule: Keep responses short and skip end-of-turn summaries. **Why:** The user reads diffs directly and finds summaries redundant. **How to apply:** After completing edits or changes, state the result in one sentence. No bullet-point recaps unless specifically requested.8.2 user-role--- name: user-role description: 用户是 InterSystems IRIS 语言工程师对 TypeScript 代码不太熟悉 metadata: node_type: memory type: user originSessionId: 998bb0b8-182a-4fc6-ac33-0e037bf3696e --- 用户是一名 InterSystems IRIS数据库/互操作性平台语言工程师主要使用 ObjectScript 和 IRIS 相关技术栈。对 TypeScript 代码不太熟悉在解释 TS 代码、架构模式、类型系统等内容时需要更多的上下文说明和类比。秋堂主· 倚楼听风雨淡看江湖路