上周一我打开 Claude Code准备接着做支付模块的重构。前一天我明明已经和它把方案聊得很透了项目统一用 pnpm、测试框架是 vitest、支付回调在src/modules/payment/callback.ts、重构时不要动 stripe SDK 的版本。结果新的会话一上来它先客客气气地问我“这个项目是用 npm 还是 pnpm测试用 jest 可以吗”那一瞬间我真想把屏幕合上。这就是 Claude Code 这类终端产物目前最尴尬的短板在单次会话里它是近乎完美的结对编程对象但一旦会话关闭它对你的项目就只剩“路人记忆”。而 claude-mem 这个开源工具想填的坑恰好就是这个——它通过非常克制的机制把“会话结束后的经验”自动沉淀成“下个会话开头的记忆”让我不用再花十分钟跟 AI 科普自己的项目。这篇文章我会基于自己这段时间的实测来写不搞 PPT 式介绍。包括它的工作原理、安装接入、真实效果、踩过的坑以及和CLAUDE.md、--resume这些官方方案之间到底怎么配合。如果你也是 Claude Code 的重度用户对“每次新开会话 AI 就失忆”感到烦躁这篇应该能帮你少走不少弯路。1. 金鱼记忆的代价Claude Code 为什么“出了会话就不认识你”1.1 你大概率经历过的失忆场景Claude Code 本身的能力毋庸置疑尤其在单会话里连续改十几个文件、跑测试、修 bug 这种长链路任务上它表现得很像一位耐心的同事。但问题恰恰出在“会话”这个边界上。我遇到过三种高频失忆场景跨天续工。昨天下午刚讨论完的方案第二天早上新开会话它完全不记得。你说“继续昨天的重构”它只能靠读代码猜猜错方向的话返工成本比重新聊一遍还高。跨项目切换。手头同时维护三四个仓库每个项目的包管理器、测试工具、代码风格都不一样。Claude Code 默认不感知这些差异经常用 A 项目的习惯去改 B 项目的代码。重复犯错。今天刚纠正过“不要在 service 层直接操作数据库”明天新会话又写出一模一样的代码。你只能再纠正一遍然后祈祷它这次记住——但基本记不住。网上有人调侃这是“金鱼记忆”本质上是因为 Claude Code 每个会话的上下文窗口都是独立初始化的。它没有“长期记忆”这个概念除非你把信息放进CLAUDE.md或者手动通过--resume把历史会话的上下文重新拉起来。1.2 官方方案为什么不够用Anthropic 其实给过几个官方路径我挨个试过各有各的别扭。--resume和--continue这类参数本质是把之前的会话日志原封不动地塞回上下文窗口。好处是“无缝续聊”坏处是它把记忆和原始对话日志画了等号。一个跑了三小时的会话日志可能有几十万 token你想要的是“结论”但它回放的是“全过程”。而且这种原始日志只能用于同一段会话的延续换个新任务、新仓库照样归零。CLAUDE.md则是另一套思路在每个项目里放一份静态说明文件告诉 AI 这个项目的约定、结构、命令。它适合写“永远成立”的东西比如构建命令、目录规范、不要做什么。但问题在于它需要手动维护。我自己深有体会新项目头两周还会认真更新CLAUDE.md后面忙起来就忘了。等到项目里有一堆过时说明、甚至和现状冲突时AI 照着它做反而比没有它更让人血压升高。所以我的结论很简单官方方案解决的是“会话怎么恢复”而真正缺失的是“项目经验怎么沉淀”。这正是 claude-mem 切入的位置。1.3 claude-mem 想解决的是“沉淀”这件事claude-mem 是一套基于 Claude Code 官方 hook 机制实现的外部记忆工具发行在 Python 生态里用pipx或uv tool安装。它不修改 Claude Code 本体也不劫持对话而是作为“旁路观察者”存在会话进行时记录关键信息会话结束后提炼成结构化记忆下一次会话开始时主动把相关记忆注入到上下文里。它和CLAUDE.md最大的区别是不需要我动手写。它自己能从对话里判断什么东西值得记、什么东西只是临时闲聊。它和--resume最大的区别是它沉淀的是“结论”而不是“日志”所以在成本上要经济得多。我第一次感受到它的价值不是某个瞬间的“惊艳”而是一种“终于对了”的踏实感——周五下班前我跟 AI 说“下周一继续改这个模块”周一一上班它真的知道我们在改哪个模块、怎么改的、改到哪一步了。2. 它凭什么能记住hook 机制 摘要提取 向量召回2.1 Claude Code 的 hook 体系是外部工具接进来的钥匙Claude Code 从很早期开始就支持 hooks简单说就是在整个会话生命周期中的某些时间点触发你配置的外部脚本脚本可以读取上下文、执行命令、把输出返回给 Claude Code。常见的事件类型包括用户提交 prompt 时UserPromptSubmit、工具被调用前后PreToolUse、PostToolUse、会话结束Stop/SessionStart等等。claude-mem 的思路很直接在SessionStart时初始化会话状态在UserPromptSubmit时注入记忆在PostToolUse或Stop时沉淀记忆。装好之后你的settings.json里会出现一节 hooks 配置指向 claude-mem 提供的几个子命令。它不是一个常驻进程而是一堆会在特定时机被 Claude Code 自动拉起的 CLI 脚本每个都干特定的事。我一开始担心“用 hook 做记忆注入会不会拖慢每次对话”实测下来它的注入逻辑不是每个 prompt 都跑而是倾向于在合适时机插入比如会话开头的第一个 prompt。即便每次都跑本地脚本加检索的开销也就是几百毫秒级别远没有模型推理耗时明显。2.2 写入流程从“对话噪音”里提炼出“值得记忆的东西”claude-mem 真正核心的部分是“提炼”。它不会把一整段对话原封不动存进数据库那样和--resume就没区别了。它的默认做法是在会话告一段落时调用一次 LLM把当前会话的上下文摘要输入进去问它“这段会话里有哪些信息值得长期记住”。什么样的东西算“值得记住”从我的使用经验来看大概能归纳成几类用户偏好比如“这个项目里作者更喜欢用ruff而不是black”。技术决策比如“支付模块决定用 Stripe 的 webhook 事件驱动不改 SDK 版本”。项目事实比如“测试目录是tests/CI 脚本在.github/workflows/ci.yml”。进度状态比如“用户重构到一半callback.ts已经改成异步但refund流程还没动”。这套“提问式提炼”的设计让我觉得它很聪明。因为对话日志本身就是大量噪音夹杂少量信号人工都很难快速总结如果靠简单的关键词抽取效果会非常差。claude-mem 把“总结”这件事委托给 LLM等于是在保留语义理解能力的同时把存储体积压缩到了极小。2.3 读取流程每次开局先“想”起和当前事项最相关的记忆到了下一次新会话claude-mem 会做一次“回忆”操作。它读取当前项目目录结合你正在处理的内容去记忆库里做一次相似度检索把最相关的几条记忆取出来拼成一段精炼的“记忆上下文”注入到 Claude Code 的 prompt 前面。它不是把记忆库里所有东西都灌进去——那样成本太高而且信息多了反而干扰模型。它更像一种“按需唤醒”你在改支付模块它就把支付相关的决策翻出来你在写测试它就把测试约定翻出来。这个检索用的是向量相似度。每条记忆在写入时都会生成向量表示存进索引里检索时把当前项目路径或者用户 prompt 也转成向量然后找出最相近的 top-k 条。我自己理解这套机制时打了个比方它像一个人的“长期工作记忆”——不是把所有日记本都摊开而是你刚坐下提了一句“今天继续改支付”它就凭着这句话联想到支付模块相关的几页笔记摆在桌面上。桌面只放这几页其他全在抽屉里。抽屉就是 SQLite 数据库和向量索引。2.4 落地存储SQLite 向量轻量但够用claude-mem 默认把所有记忆数据放在用户目录下的一个独立文件夹里不同机器上位置略有差异核心是 SQLite 数据库加向量索引文件。这样做有几个好处单个用户的数据量很小日常对话级的使用撑不起多大的库不依赖网络服务属于本地优先备份和迁移也很直白直接拷贝目录就行。它在权限设计上也踩了我想过的点默认只读取它自己的存储目录不主动扫描整个文件系统更不会偷偷读你的代码库。所以如果你对隐私比较敏感第一件该做的事就是确认它写入了哪些路径、有没有跟云端服务通信。3. 从零到一接入 claude-mem我的安装路径和首次验证3.1 安装前要准备的几件事如果你也想试建议先确认系统里有 Python 3.10 以上环境。我自己用的是 macOS 国内开发者常用的一整套终端环境安装过程没什么特殊之处。另外因为它的一部分“提炼”能力要调 LLM 接口所以你得有一个可用的模型 API 配置——支持 Anthropic 自家模型也支持 OpenAI 兼容接口甚至能配到本地 Ollama 上。这里有个容易踩的坑很多人以为装了 claude-mem 之后它自带模型免费就能跑。不对。它本质是个“壳”核心的记忆提炼还是要借助模型能力。不过好消息是它对模型大小没那么挑剔我用过好几档配置体验差异主要集中在“总结得精不精炼”上不至于完全不能用。3.2 安装和初始化安装过程非常短。两条命令的功夫uv tool install claude-mem claude-mem initinit会帮你做两件事生成默认配置文件同时把 hook 配置写入 Claude Code 的settings.json。如果你只想针对某个项目启用可以在项目根目录下执行这样 hook 会落到项目的.claude/settings.json如果想全局生效就放到用户全局配置里。我个人的建议是新手期先项目级启用搞懂后再全局启用避免一上来就在所有项目里注入记忆互相污染。初始化完成后它会在启动时自动创建记忆库目录。这个时间点你可以打开settings.json瞧瞧里面应该多了几个 hooks 条目分别指向 claude-mem 的 session-start、prompt-submit、stop 之类的处理器。3.3 让第一条记忆诞生的验证实验装完之后怎么验证它真的在干活我的做法是做一个“有意识”的实验新开一个 Claude Code 会话故意说一些明确的约定和决策。比如“以后这个项目所有数据库操作都走 repository 层不要在 controller 里直接写 SQL”。正常干一轮活让会话自然结束或者主动退出。再过几分钟去看记忆库目录确认文件已经被创建和更新。再开一个新会话随便说一句“继续之前的工作”然后观察 Claude Code 开头是不是多了一段“记忆上下文”里面包含上一步那个约定。我第一次验证的时候第二条会话确实冒出来一句类似“该项目的长期记忆数据库操作必须通过 repository 层”的提示当场就有点小激动。这种“自动写入 自动召回”的闭环一旦跑通后面的使用就顺了。3.4 hook 不生效时的排查思路如果验证发现它没反应不要慌大概率是以下几个原因settings.json写错了位置。Claude Code 的 hook 我印象里按“项目级优先于用户级”的规则合并如果你两处都配了要确认是不是项目级配置覆盖了全局配置。Python 环境对不上。用uv tool安装后在PATH里能找到claude-mem但 Claude Code 触发的 hook 脚本可能用的是另一个 shell 环境找不到命令。最简单的排错是先在终端手动跑一遍 hook 对应的命令看有没有报错。模型 API 没配好。第一次提炼时如果请求失败它通常会静默跳过而不是打断你开会话。别指望它弹窗报错主动去日志里看才能发现问题。我见过不少人卡在第三步因为 Claude Code 的settings.json里 hook 配置很灵活一不小心就容易写串。如果你对 JSON 结构没有十足把握claude-mem init生成的版本是最稳的后面尽量手动编辑增量项别整体重写。4. 接入之后它到底记住了哪些“真正值钱”的东西4.1 项目约定和技术栈偏好是最立竿见影的我用 claude-mem 大概两周后感受最明显的是“重复科普”少了很多。拿一个实际例子我手头有个 Python 项目早期我明确说过“用 uv 管依赖、用 ruff 做 lint、测试用 pytest不要用 pip 和 black”。这条约定进了记忆库。之后不管我隔几天再去动这个项目新会话里的 Claude Code 都能在开头读到这条写代码的时候会自动切换到对应工具不用我再强调一遍。这种效果非常像给团队新同事发的“前三天必读”文档只不过这次是 AI 自己在维护这份文档。而且它是通过观察我的真实对话主动提炼的不是我手动记录的所以我忘写文档的问题也被绕过去了。4.2 架构决策与迁移进度是长线会话最需要的锚点比工具偏好更重要的是架构层面的决策。你想想一个项目做三个月期间会做几十个有得有失的技术选型为什么用这个方案而不用那个、哪个模块准备拆掉、哪块的兼容性不能动。这些决策如果只存在某个历史会话的日志里下次基本等于不存在。claude-mem 能把这类决策单独沉淀成条目。我就遇到过一次三个礼拜后我在另一个分支上想重写一个模块正犹豫要不要换掉当时那个有点笨拙的实现结果 Claude Code 在记忆上下文里提到了“当初决定保留这个实现是为了兼容旧客户端”我立刻打消了重构念头。这种“想起当初为什么这么做”的能力比单纯记住工具命令要值钱得多。4.3 搜索旧记忆等于给自己配了一个“项目笔记本”除了自动注入claude-mem 还提供了手动查询的能力。比如我经常会问它“我们之前讨论过关于缓存方案的结论是什么”或者“我们在某个会话里决定过不采用 ORM 吗”它会去记忆库里做检索然后返回相关条目。这个能力让我觉得它不只是“备忘录”更是“索引”。它把散落在不同时间段、不同项目里的决策串成了一张可以随时查的网。对多项目并行的人来说这种“快速翻旧账”的能力非常省心不用再一个个翻历史会话也不用靠CLAUDE.md里那点干巴巴的文字猜测。当然它不可能是完美的。我后面会说它有哪些边界——它记不住“进行中的待办清单”它也不理解“复杂而微妙的人类权衡”它只擅长记录“明确说出口的话”。但工具能做好这一点已经超过我预期了。5. 不是神话claude-mem 的成本、误记忆和隐私边界5.1 成本怎么算不是工具本身贵是“提炼”要吃 tokenclaude-mem 本身免费开源但这不代表零成本。每次会话结束做记忆提炼本质上是调一次 LLM我按自己比较忙的一天做过粗略估算一天大概开七八个会话每个会话结束时做一次上下文摘要。按主流的模型价格算一次摘要的 token 消耗可能在几千到一万 token 上下一天下来不到一块钱一个月也就是十几块的量级。对个人开发者来说基本不敏感但对重度使用者来说这笔账值得心里有数。另外每次会话开始注入的记忆也会占用一部分 prompt token。如果注入不善会把长上下文喂得更满。我自己一般会控制记忆注入条数宁可少注入几条最相关的也不要一次性塞一堆边角料。这里的关键词是“克制”。5.2 记忆污染它会固执地把错事记一辈子claude-mem 最让我头大的问题是“错误记忆的惯性”。它有段时间记住了“这个项目已经迁移到 pydantic v2”但实际情况是迁移只做了一半模型层还没改完。结果我在另一个分支上做新功能它上来就按“已经迁移完”的前提写代码报错之后我花了好久才反应过来问题是它记忆里的前提错了。这类问题很难靠工具本身解决因为它无法判断“用户随口说的”和“用户深思熟虑后确定的”之间的区别。我的应对办法是碰到明显可疑的记忆时直接在 prompt 里纠正它并强调“不要遵循这条记忆”过一段时间把记忆库里过时或者错误的条目删掉。claude-mem 提供了查看和删除记忆的手段但需要你自己养成“定期清理”的习惯否则错误条目就会像滚雪球一样越滚越大。5.3 隐私边界代码和决策到底去了哪记忆提炼要调 API这意味着你的对话内容以及被提炼出来的项目决策会经过模型提供方的服务器。如果你写的是闭源商业项目或者带敏感信息的代码这个点一定要想清楚。我自己的处理方式是分两层个人玩具项目和开源项目随便用云端模型省心公司内部或者有保密要求的代码把记忆提炼的模型指向本地 Ollama或者干脆不开 claude-mem。你可以在 claude-mem 的配置文件里指定 provider不必全局绑死一个。安全性不是这家工具的问题而是“任何外部记忆工具”都要面临的共同边界。6. 该不该用它和 CLAUDE.md、--resume、MCP 知识库的横向选择6.1 一条简单的对比有人问我 claude-mem 是不是能完全替代CLAUDE.md和--resume我的答案是不能也不该那么用。下面是我做的一张对比表方案自动化程度记忆形态跨会话可用性维护成本适合场景CLAUDE.md手动静态规则每次都生效高必须勤维护项目固定规范、新人引导--resume手动指定原始对话日志仅限同一会话低一个任务中途没做完当天接着整claude-mem自动提炼后的结论跨所有会话低偶尔清理让 AI 长期积累项目经验MCP 知识库/图谱服务半自动实体关系/文档跨会话中复杂项目知识管理、多人协作能看出来CLAUDE.md的强项在于“规则性”、--resume的强项在于“延续性”、claude-mem的强项在于“积累性”。三者本质上解决不同阶段的问题进场的时候靠规则中场的时候靠日志长期靠记忆。6.2 我自己实际用的组合方式现在的标准流程是这样的项目根目录放一份精简的CLAUDE.md只写“雷打不动”的规范比如目录结构、构建命令、禁止事项。日常工作全部开着 claude-mem让它自动沉淀会话经验。如果某个任务因为被打断而需要当天继续用--resume续上下文。每隔一两周翻一遍 claude-mem 的记忆库删掉过时的修正错误的。这套组合用下来比任何单一路径都舒服。CLAUDE.md承担“宪法”的角色claude-mem 承担“日记”的角色--resume承担“临时便签”的角色。各管一摊互不干扰。7. 进阶玩法把 claude-mem 从“个人助手”变成“团队记忆库”7.1 共享记忆库让新同事的 AI 也“认识”这个项目claude-mem 的存储是本地目录但这个特性也意味着你可以把它做成团队共享。做法不复杂把记忆库目录放到一个团队都能访问的同步目录里然后把 claude-mem 的 store 路径指过去。这样你在会话里沉淀的决策同组其他人新开会话时也能读到。但我得提醒一句SQLite 在多人同时写入的场景下可能会出问题。我的建议是不要“实时共享”而是每天收工前手动同步一次。团队小、节奏慢的时候这样最省心。真正要做成多人实时协作还是得考虑更复杂的后端方案个人工具级别的产品不会自动适配那种场景。7.2 用 Git 提交信息喂养记忆有过一个我觉得很值得尝试的玩法把 Git 提交记录作为记忆来源。具体做法很简单写个钩子脚本在每次 commit 或 merge 之后把 commit message 喂给 claude-mem 做一次提炼。Commit message 本身就是高度浓缩的“发生了什么”很适合变成记忆条目。我试过的效果是AI 对项目“最近发生了什么”的感知变得很敏锐。它知道“前天刚把用户模块的数据库层迁移到 repository 模式”所以在新会话里提到这块代码时它会基于最新状态去理解而不是基于几个月前的旧结构。7.3 记忆卫生定期 review 比追求“记得多”更重要随着使用时间拉长记忆库一定会膨胀。我踩过一个很明显的坑初期舍不得删任何东西结果记忆里充满了细碎无用的条目比如“用户今天不想用某个颜色”这种一次性偏好。这些噪音反向干扰注入效果。后来我养成了每周 review 一次的习惯把明显过时或没营养的条目清掉。另外值得注意claude-mem 的记忆注入会有条数上限如果不做清理新项目里最相关的记忆可能会因为历史噪音太多而排不上号。记忆这个东西不是越多越好而是越对越好——这一点在人和 AI 身上都一样。最后再分享一个小感受。刚开始用 claude-mem 那几天我并不觉得它有多神甚至觉得它记录的内容有点“普通”。但用了一个多月后有一天我在一个搁置了三周的项目里重新开会话Claude Code 开口就提到了三周前我们确定的技术选型我没有解释任何背景直接进入了开发状态。那一刻我意识到claude-mem 这类工具真正改变的不是“AI 的记忆力”而是我作为开发者的协作方式——以前我是那个每次都要重新介绍项目的人现在 AI 变成了那个真正“记得我们怎么走到这一步”的同事。如果你也烦透了“每次开会话都像第一次见面”的体验给它一个周末的时间你大概率会愿意把它留在工作流里。 
长河君 · 2026/10/9 11:20:07 · 阅读 1.2k claude-mem实测：让Claude Code告别金鱼记忆，自动沉淀项目经验
上周一我打开 Claude Code准备接着做支付模块的重构。前一天我明明已经和它把方案聊得很透了项目统一用 pnpm、测试框架是 vitest、支付回调在src/modules/payment/callback.ts、重构时不要动 stripe SDK 的版本。结果新的会话一上来它先客客气气地问我“这个项目是用 npm 还是 pnpm测试用 jest 可以吗”那一瞬间我真想把屏幕合上。这就是 Claude Code 这类终端产物目前最尴尬的短板在单次会话里它是近乎完美的结对编程对象但一旦会话关闭它对你的项目就只剩“路人记忆”。而 claude-mem 这个开源工具想填的坑恰好就是这个——它通过非常克制的机制把“会话结束后的经验”自动沉淀成“下个会话开头的记忆”让我不用再花十分钟跟 AI 科普自己的项目。这篇文章我会基于自己这段时间的实测来写不搞 PPT 式介绍。包括它的工作原理、安装接入、真实效果、踩过的坑以及和CLAUDE.md、--resume这些官方方案之间到底怎么配合。如果你也是 Claude Code 的重度用户对“每次新开会话 AI 就失忆”感到烦躁这篇应该能帮你少走不少弯路。1. 金鱼记忆的代价Claude Code 为什么“出了会话就不认识你”1.1 你大概率经历过的失忆场景Claude Code 本身的能力毋庸置疑尤其在单会话里连续改十几个文件、跑测试、修 bug 这种长链路任务上它表现得很像一位耐心的同事。但问题恰恰出在“会话”这个边界上。我遇到过三种高频失忆场景跨天续工。昨天下午刚讨论完的方案第二天早上新开会话它完全不记得。你说“继续昨天的重构”它只能靠读代码猜猜错方向的话返工成本比重新聊一遍还高。跨项目切换。手头同时维护三四个仓库每个项目的包管理器、测试工具、代码风格都不一样。Claude Code 默认不感知这些差异经常用 A 项目的习惯去改 B 项目的代码。重复犯错。今天刚纠正过“不要在 service 层直接操作数据库”明天新会话又写出一模一样的代码。你只能再纠正一遍然后祈祷它这次记住——但基本记不住。网上有人调侃这是“金鱼记忆”本质上是因为 Claude Code 每个会话的上下文窗口都是独立初始化的。它没有“长期记忆”这个概念除非你把信息放进CLAUDE.md或者手动通过--resume把历史会话的上下文重新拉起来。1.2 官方方案为什么不够用Anthropic 其实给过几个官方路径我挨个试过各有各的别扭。--resume和--continue这类参数本质是把之前的会话日志原封不动地塞回上下文窗口。好处是“无缝续聊”坏处是它把记忆和原始对话日志画了等号。一个跑了三小时的会话日志可能有几十万 token你想要的是“结论”但它回放的是“全过程”。而且这种原始日志只能用于同一段会话的延续换个新任务、新仓库照样归零。CLAUDE.md则是另一套思路在每个项目里放一份静态说明文件告诉 AI 这个项目的约定、结构、命令。它适合写“永远成立”的东西比如构建命令、目录规范、不要做什么。但问题在于它需要手动维护。我自己深有体会新项目头两周还会认真更新CLAUDE.md后面忙起来就忘了。等到项目里有一堆过时说明、甚至和现状冲突时AI 照着它做反而比没有它更让人血压升高。所以我的结论很简单官方方案解决的是“会话怎么恢复”而真正缺失的是“项目经验怎么沉淀”。这正是 claude-mem 切入的位置。1.3 claude-mem 想解决的是“沉淀”这件事claude-mem 是一套基于 Claude Code 官方 hook 机制实现的外部记忆工具发行在 Python 生态里用pipx或uv tool安装。它不修改 Claude Code 本体也不劫持对话而是作为“旁路观察者”存在会话进行时记录关键信息会话结束后提炼成结构化记忆下一次会话开始时主动把相关记忆注入到上下文里。它和CLAUDE.md最大的区别是不需要我动手写。它自己能从对话里判断什么东西值得记、什么东西只是临时闲聊。它和--resume最大的区别是它沉淀的是“结论”而不是“日志”所以在成本上要经济得多。我第一次感受到它的价值不是某个瞬间的“惊艳”而是一种“终于对了”的踏实感——周五下班前我跟 AI 说“下周一继续改这个模块”周一一上班它真的知道我们在改哪个模块、怎么改的、改到哪一步了。2. 它凭什么能记住hook 机制 摘要提取 向量召回2.1 Claude Code 的 hook 体系是外部工具接进来的钥匙Claude Code 从很早期开始就支持 hooks简单说就是在整个会话生命周期中的某些时间点触发你配置的外部脚本脚本可以读取上下文、执行命令、把输出返回给 Claude Code。常见的事件类型包括用户提交 prompt 时UserPromptSubmit、工具被调用前后PreToolUse、PostToolUse、会话结束Stop/SessionStart等等。claude-mem 的思路很直接在SessionStart时初始化会话状态在UserPromptSubmit时注入记忆在PostToolUse或Stop时沉淀记忆。装好之后你的settings.json里会出现一节 hooks 配置指向 claude-mem 提供的几个子命令。它不是一个常驻进程而是一堆会在特定时机被 Claude Code 自动拉起的 CLI 脚本每个都干特定的事。我一开始担心“用 hook 做记忆注入会不会拖慢每次对话”实测下来它的注入逻辑不是每个 prompt 都跑而是倾向于在合适时机插入比如会话开头的第一个 prompt。即便每次都跑本地脚本加检索的开销也就是几百毫秒级别远没有模型推理耗时明显。2.2 写入流程从“对话噪音”里提炼出“值得记忆的东西”claude-mem 真正核心的部分是“提炼”。它不会把一整段对话原封不动存进数据库那样和--resume就没区别了。它的默认做法是在会话告一段落时调用一次 LLM把当前会话的上下文摘要输入进去问它“这段会话里有哪些信息值得长期记住”。什么样的东西算“值得记住”从我的使用经验来看大概能归纳成几类用户偏好比如“这个项目里作者更喜欢用ruff而不是black”。技术决策比如“支付模块决定用 Stripe 的 webhook 事件驱动不改 SDK 版本”。项目事实比如“测试目录是tests/CI 脚本在.github/workflows/ci.yml”。进度状态比如“用户重构到一半callback.ts已经改成异步但refund流程还没动”。这套“提问式提炼”的设计让我觉得它很聪明。因为对话日志本身就是大量噪音夹杂少量信号人工都很难快速总结如果靠简单的关键词抽取效果会非常差。claude-mem 把“总结”这件事委托给 LLM等于是在保留语义理解能力的同时把存储体积压缩到了极小。2.3 读取流程每次开局先“想”起和当前事项最相关的记忆到了下一次新会话claude-mem 会做一次“回忆”操作。它读取当前项目目录结合你正在处理的内容去记忆库里做一次相似度检索把最相关的几条记忆取出来拼成一段精炼的“记忆上下文”注入到 Claude Code 的 prompt 前面。它不是把记忆库里所有东西都灌进去——那样成本太高而且信息多了反而干扰模型。它更像一种“按需唤醒”你在改支付模块它就把支付相关的决策翻出来你在写测试它就把测试约定翻出来。这个检索用的是向量相似度。每条记忆在写入时都会生成向量表示存进索引里检索时把当前项目路径或者用户 prompt 也转成向量然后找出最相近的 top-k 条。我自己理解这套机制时打了个比方它像一个人的“长期工作记忆”——不是把所有日记本都摊开而是你刚坐下提了一句“今天继续改支付”它就凭着这句话联想到支付模块相关的几页笔记摆在桌面上。桌面只放这几页其他全在抽屉里。抽屉就是 SQLite 数据库和向量索引。2.4 落地存储SQLite 向量轻量但够用claude-mem 默认把所有记忆数据放在用户目录下的一个独立文件夹里不同机器上位置略有差异核心是 SQLite 数据库加向量索引文件。这样做有几个好处单个用户的数据量很小日常对话级的使用撑不起多大的库不依赖网络服务属于本地优先备份和迁移也很直白直接拷贝目录就行。它在权限设计上也踩了我想过的点默认只读取它自己的存储目录不主动扫描整个文件系统更不会偷偷读你的代码库。所以如果你对隐私比较敏感第一件该做的事就是确认它写入了哪些路径、有没有跟云端服务通信。3. 从零到一接入 claude-mem我的安装路径和首次验证3.1 安装前要准备的几件事如果你也想试建议先确认系统里有 Python 3.10 以上环境。我自己用的是 macOS 国内开发者常用的一整套终端环境安装过程没什么特殊之处。另外因为它的一部分“提炼”能力要调 LLM 接口所以你得有一个可用的模型 API 配置——支持 Anthropic 自家模型也支持 OpenAI 兼容接口甚至能配到本地 Ollama 上。这里有个容易踩的坑很多人以为装了 claude-mem 之后它自带模型免费就能跑。不对。它本质是个“壳”核心的记忆提炼还是要借助模型能力。不过好消息是它对模型大小没那么挑剔我用过好几档配置体验差异主要集中在“总结得精不精炼”上不至于完全不能用。3.2 安装和初始化安装过程非常短。两条命令的功夫uv tool install claude-mem claude-mem initinit会帮你做两件事生成默认配置文件同时把 hook 配置写入 Claude Code 的settings.json。如果你只想针对某个项目启用可以在项目根目录下执行这样 hook 会落到项目的.claude/settings.json如果想全局生效就放到用户全局配置里。我个人的建议是新手期先项目级启用搞懂后再全局启用避免一上来就在所有项目里注入记忆互相污染。初始化完成后它会在启动时自动创建记忆库目录。这个时间点你可以打开settings.json瞧瞧里面应该多了几个 hooks 条目分别指向 claude-mem 的 session-start、prompt-submit、stop 之类的处理器。3.3 让第一条记忆诞生的验证实验装完之后怎么验证它真的在干活我的做法是做一个“有意识”的实验新开一个 Claude Code 会话故意说一些明确的约定和决策。比如“以后这个项目所有数据库操作都走 repository 层不要在 controller 里直接写 SQL”。正常干一轮活让会话自然结束或者主动退出。再过几分钟去看记忆库目录确认文件已经被创建和更新。再开一个新会话随便说一句“继续之前的工作”然后观察 Claude Code 开头是不是多了一段“记忆上下文”里面包含上一步那个约定。我第一次验证的时候第二条会话确实冒出来一句类似“该项目的长期记忆数据库操作必须通过 repository 层”的提示当场就有点小激动。这种“自动写入 自动召回”的闭环一旦跑通后面的使用就顺了。3.4 hook 不生效时的排查思路如果验证发现它没反应不要慌大概率是以下几个原因settings.json写错了位置。Claude Code 的 hook 我印象里按“项目级优先于用户级”的规则合并如果你两处都配了要确认是不是项目级配置覆盖了全局配置。Python 环境对不上。用uv tool安装后在PATH里能找到claude-mem但 Claude Code 触发的 hook 脚本可能用的是另一个 shell 环境找不到命令。最简单的排错是先在终端手动跑一遍 hook 对应的命令看有没有报错。模型 API 没配好。第一次提炼时如果请求失败它通常会静默跳过而不是打断你开会话。别指望它弹窗报错主动去日志里看才能发现问题。我见过不少人卡在第三步因为 Claude Code 的settings.json里 hook 配置很灵活一不小心就容易写串。如果你对 JSON 结构没有十足把握claude-mem init生成的版本是最稳的后面尽量手动编辑增量项别整体重写。4. 接入之后它到底记住了哪些“真正值钱”的东西4.1 项目约定和技术栈偏好是最立竿见影的我用 claude-mem 大概两周后感受最明显的是“重复科普”少了很多。拿一个实际例子我手头有个 Python 项目早期我明确说过“用 uv 管依赖、用 ruff 做 lint、测试用 pytest不要用 pip 和 black”。这条约定进了记忆库。之后不管我隔几天再去动这个项目新会话里的 Claude Code 都能在开头读到这条写代码的时候会自动切换到对应工具不用我再强调一遍。这种效果非常像给团队新同事发的“前三天必读”文档只不过这次是 AI 自己在维护这份文档。而且它是通过观察我的真实对话主动提炼的不是我手动记录的所以我忘写文档的问题也被绕过去了。4.2 架构决策与迁移进度是长线会话最需要的锚点比工具偏好更重要的是架构层面的决策。你想想一个项目做三个月期间会做几十个有得有失的技术选型为什么用这个方案而不用那个、哪个模块准备拆掉、哪块的兼容性不能动。这些决策如果只存在某个历史会话的日志里下次基本等于不存在。claude-mem 能把这类决策单独沉淀成条目。我就遇到过一次三个礼拜后我在另一个分支上想重写一个模块正犹豫要不要换掉当时那个有点笨拙的实现结果 Claude Code 在记忆上下文里提到了“当初决定保留这个实现是为了兼容旧客户端”我立刻打消了重构念头。这种“想起当初为什么这么做”的能力比单纯记住工具命令要值钱得多。4.3 搜索旧记忆等于给自己配了一个“项目笔记本”除了自动注入claude-mem 还提供了手动查询的能力。比如我经常会问它“我们之前讨论过关于缓存方案的结论是什么”或者“我们在某个会话里决定过不采用 ORM 吗”它会去记忆库里做检索然后返回相关条目。这个能力让我觉得它不只是“备忘录”更是“索引”。它把散落在不同时间段、不同项目里的决策串成了一张可以随时查的网。对多项目并行的人来说这种“快速翻旧账”的能力非常省心不用再一个个翻历史会话也不用靠CLAUDE.md里那点干巴巴的文字猜测。当然它不可能是完美的。我后面会说它有哪些边界——它记不住“进行中的待办清单”它也不理解“复杂而微妙的人类权衡”它只擅长记录“明确说出口的话”。但工具能做好这一点已经超过我预期了。5. 不是神话claude-mem 的成本、误记忆和隐私边界5.1 成本怎么算不是工具本身贵是“提炼”要吃 tokenclaude-mem 本身免费开源但这不代表零成本。每次会话结束做记忆提炼本质上是调一次 LLM我按自己比较忙的一天做过粗略估算一天大概开七八个会话每个会话结束时做一次上下文摘要。按主流的模型价格算一次摘要的 token 消耗可能在几千到一万 token 上下一天下来不到一块钱一个月也就是十几块的量级。对个人开发者来说基本不敏感但对重度使用者来说这笔账值得心里有数。另外每次会话开始注入的记忆也会占用一部分 prompt token。如果注入不善会把长上下文喂得更满。我自己一般会控制记忆注入条数宁可少注入几条最相关的也不要一次性塞一堆边角料。这里的关键词是“克制”。5.2 记忆污染它会固执地把错事记一辈子claude-mem 最让我头大的问题是“错误记忆的惯性”。它有段时间记住了“这个项目已经迁移到 pydantic v2”但实际情况是迁移只做了一半模型层还没改完。结果我在另一个分支上做新功能它上来就按“已经迁移完”的前提写代码报错之后我花了好久才反应过来问题是它记忆里的前提错了。这类问题很难靠工具本身解决因为它无法判断“用户随口说的”和“用户深思熟虑后确定的”之间的区别。我的应对办法是碰到明显可疑的记忆时直接在 prompt 里纠正它并强调“不要遵循这条记忆”过一段时间把记忆库里过时或者错误的条目删掉。claude-mem 提供了查看和删除记忆的手段但需要你自己养成“定期清理”的习惯否则错误条目就会像滚雪球一样越滚越大。5.3 隐私边界代码和决策到底去了哪记忆提炼要调 API这意味着你的对话内容以及被提炼出来的项目决策会经过模型提供方的服务器。如果你写的是闭源商业项目或者带敏感信息的代码这个点一定要想清楚。我自己的处理方式是分两层个人玩具项目和开源项目随便用云端模型省心公司内部或者有保密要求的代码把记忆提炼的模型指向本地 Ollama或者干脆不开 claude-mem。你可以在 claude-mem 的配置文件里指定 provider不必全局绑死一个。安全性不是这家工具的问题而是“任何外部记忆工具”都要面临的共同边界。6. 该不该用它和 CLAUDE.md、--resume、MCP 知识库的横向选择6.1 一条简单的对比有人问我 claude-mem 是不是能完全替代CLAUDE.md和--resume我的答案是不能也不该那么用。下面是我做的一张对比表方案自动化程度记忆形态跨会话可用性维护成本适合场景CLAUDE.md手动静态规则每次都生效高必须勤维护项目固定规范、新人引导--resume手动指定原始对话日志仅限同一会话低一个任务中途没做完当天接着整claude-mem自动提炼后的结论跨所有会话低偶尔清理让 AI 长期积累项目经验MCP 知识库/图谱服务半自动实体关系/文档跨会话中复杂项目知识管理、多人协作能看出来CLAUDE.md的强项在于“规则性”、--resume的强项在于“延续性”、claude-mem的强项在于“积累性”。三者本质上解决不同阶段的问题进场的时候靠规则中场的时候靠日志长期靠记忆。6.2 我自己实际用的组合方式现在的标准流程是这样的项目根目录放一份精简的CLAUDE.md只写“雷打不动”的规范比如目录结构、构建命令、禁止事项。日常工作全部开着 claude-mem让它自动沉淀会话经验。如果某个任务因为被打断而需要当天继续用--resume续上下文。每隔一两周翻一遍 claude-mem 的记忆库删掉过时的修正错误的。这套组合用下来比任何单一路径都舒服。CLAUDE.md承担“宪法”的角色claude-mem 承担“日记”的角色--resume承担“临时便签”的角色。各管一摊互不干扰。7. 进阶玩法把 claude-mem 从“个人助手”变成“团队记忆库”7.1 共享记忆库让新同事的 AI 也“认识”这个项目claude-mem 的存储是本地目录但这个特性也意味着你可以把它做成团队共享。做法不复杂把记忆库目录放到一个团队都能访问的同步目录里然后把 claude-mem 的 store 路径指过去。这样你在会话里沉淀的决策同组其他人新开会话时也能读到。但我得提醒一句SQLite 在多人同时写入的场景下可能会出问题。我的建议是不要“实时共享”而是每天收工前手动同步一次。团队小、节奏慢的时候这样最省心。真正要做成多人实时协作还是得考虑更复杂的后端方案个人工具级别的产品不会自动适配那种场景。7.2 用 Git 提交信息喂养记忆有过一个我觉得很值得尝试的玩法把 Git 提交记录作为记忆来源。具体做法很简单写个钩子脚本在每次 commit 或 merge 之后把 commit message 喂给 claude-mem 做一次提炼。Commit message 本身就是高度浓缩的“发生了什么”很适合变成记忆条目。我试过的效果是AI 对项目“最近发生了什么”的感知变得很敏锐。它知道“前天刚把用户模块的数据库层迁移到 repository 模式”所以在新会话里提到这块代码时它会基于最新状态去理解而不是基于几个月前的旧结构。7.3 记忆卫生定期 review 比追求“记得多”更重要随着使用时间拉长记忆库一定会膨胀。我踩过一个很明显的坑初期舍不得删任何东西结果记忆里充满了细碎无用的条目比如“用户今天不想用某个颜色”这种一次性偏好。这些噪音反向干扰注入效果。后来我养成了每周 review 一次的习惯把明显过时或没营养的条目清掉。另外值得注意claude-mem 的记忆注入会有条数上限如果不做清理新项目里最相关的记忆可能会因为历史噪音太多而排不上号。记忆这个东西不是越多越好而是越对越好——这一点在人和 AI 身上都一样。最后再分享一个小感受。刚开始用 claude-mem 那几天我并不觉得它有多神甚至觉得它记录的内容有点“普通”。但用了一个多月后有一天我在一个搁置了三周的项目里重新开会话Claude Code 开口就提到了三周前我们确定的技术选型我没有解释任何背景直接进入了开发状态。那一刻我意识到claude-mem 这类工具真正改变的不是“AI 的记忆力”而是我作为开发者的协作方式——以前我是那个每次都要重新介绍项目的人现在 AI 变成了那个真正“记得我们怎么走到这一步”的同事。如果你也烦透了“每次开会话都像第一次见面”的体验给它一个周末的时间你大概率会愿意把它留在工作流里。