用过 Claude Code 的人十有八九都有过这样的憋屈时刻上午明明已经告诉它“这个项目统一用 pnpm锁文件别乱动”下午新开一个会话它又一脸茫然地问你要不要用 npm。你重复了三遍的代码规范、环境变量、部署流程它永远像金鱼一样七秒记忆。这不是模型不够聪明而是对话式 AI 天然缺少一条跨会话的“记忆神经”。我为了解决这个问题折腾过各种方案最后找到了 claude-mem——一个专门给 Claude 补上长期记忆的开源工具也是今天这篇博文的主角。它能自动从对话里抽取关键信息存成结构化记忆下次会话直接调用。无论你是拿 Claude Code 写代码、跑自动化脚本还是拿它做文档整理只要来回切换会话比较频繁这个工具都能帮你省掉大量重复沟通的成本。1. 为什么会做这么个工具AI 记忆的痛点在哪1.1 会话隔离是原罪所有大模型产品的底层都是“无状态”的。每次你发起对话模型看到的只是当前会话里这些上下文之前的会话、之前的项目历史它一概不知。所谓“记住”其实是靠你在对话里不断重复喂给它。这种设计在聊天场景下没问题但在真正干活的时候就成了大麻烦。尤其是 Claude Code 这种深度嵌入工作流的终端工具你可能会开十几个会话处理不同任务一个写后端接口一个做前端页面一个在排查 CI 报错。它们之间完全隔离掌握的上下文互不相通。我在实际使用中最直观的感受是项目里有些约定俗成的东西根本不在代码里只在脑子里。比如“数据库迁移脚本不能直接跑在线上环境”“测试环境要用 mock 的支付回调地址”“这个仓库存放在 monorepo 的 packages/shared 目录下”。每次开新会话我都得像念经一样重新交代一遍。更烦的是如果哪次忘了说它就可能按照最常规、最普适的做法去处理然后产出一个和项目风格完全不一致的代码。1.2 那些“说了就忘”的真实场景我举几个自己踩过的具体例子。第一个是技术栈约定。我有个项目前端用 Vue 3 的script setup写法禁用了 Options API。头一天告诉 Claude Code 之后它写得挺好第二天换个会话让它加个页面它直接给你整出export default { data() { ... } }的老写法。不怪它是它确实“不记得”了。第二个是常用命令和路径。项目里有个内部 CLI 工具路径是./scripts/dev-tool.sh启动参数很怪。这工具在会话里提到过一次但下次会话它忘了还会自作主张地建议你npx dev-tool然后你得到一个 command not found。第三个是配置文件的坑。.env.example里有个VITE_API_BASE_URL需要指向 staging 域名这种信息在团队 wiki 里写着但你没法每次都贴给 AI 看。它一旦不知道就可能生成指向 localhost 的接口代码让你的联调崩溃。1.3 claude-mem 到底解决什么问题claude-mem 的核心思路特别朴素把“记忆”从模型的临时上下文里搬出来落到本地持久化的存储里。它监听你和 Claude Code 的对话过程在合适的时机例如一轮对话结束自动提取其中有保留价值的信息整理成一条条记忆。这些记忆会存在项目本地下次会话启动时Claude Code 就会通过工具调用把它们加载回来。我用下来感觉它解决的不是“模型记性好不好”的问题而是“要不要一遍遍重复”的问题。你只需要在某个会话里说一次“这个项目用 pnpm”它就变成一条记忆。之后任何新会话都自动具备这条知识。对于日常重复性的业务开发这个价值极其明显把 AI 从“聊天机器人”变成了一个有项目记忆的“长期协作者”。2. 核心机制拆解claude-mem 是怎么记住东西的2.1 记忆的捕获从对话流里截取关键信息claude-mem 的工作方式非常依赖 Claude Code 的 hooks 机制。Claude Code 允许你在特定事件比如每次模型回复结束时触发外部脚本claude-mem 就是利用这个“Stop hook”作为触发点。每当一轮交互结束它会把当前会话的完整文本交给一个分析流程从中抽取候选记忆。这里有个关键设计它不是把整段对话原样存下来而是做“抽取式提炼”。我理解它内部有一个 Prompt 模板会要求模型以特定格式输出记忆条目。常见的抽取维度包括用户的明确偏好“不要用 npm”、项目技术决策“我们用 Vite 而不是 Webpack”、具体的工作流约定“每次发版前要跑 lint”、环境相关的事实“生产环境数据库账号存在 1Password 里”。这些维度的设定直接决定了记忆库质量的上限。你说这不就是把对话丢给模型让它总结吗没错逻辑上确实是。但它的价值在于自动化你不用手动复制、粘贴、整理它全帮你做完了。而且你可以控制触发频率不用每句话都存通常几个来回才触发一次成本和噪音都可控。2.2 记忆的存储Markdown 文件 SQLite 索引存储层是 claude-mem 另一个比较务实的设计。记忆最终会写入一个 Markdown 文件通常放在项目目录下的.claude-mem文件夹里主文件名一般是MEMORY.md。Markdown 的好处不用多说人类可读、可直接编辑、能用 git 做版本管理。你完全可以打开这个文件手工删掉某条过时的记忆或者补充一条新的。但纯文件存储有个问题——检索效率。当记忆数量涨到几百条你想快速找到“和数据库相关的那条”靠 grep 效率太低了。所以 claude-mem 同时维护了一个 SQLite 索引库对每条记忆做了分词和全文索引。查询的时候先走 SQLite 的 FTS 做全文检索再把命中的 Markdown 片段返回给 Claude。这个设计思路类似一个极简版的笔记系统文件是人能看懂的真相SQLite 是给机器用的加速索引。还有一点值得提它的记忆条目本身可能有结构化的 meta 信息比如创建时间、来源会话、标签。这些 meta 信息对后续的去重、排序、过期清理非常重要。我看它的存储结构时会觉得这不像一个随手写的玩具而是一个认真设计了数据模型的工具。2.3 整理与去重不让记忆库变成垃圾场凡是搞过知识库的人都知道收集容易整理难。claude-mem 如果只负责往 MEMORY.md 里堆内容用不了多久这个文件就变成一坨没人看得下去的废料Claude 也会被误导。所以它内置了一些记忆维护机制。一个是相似度去重。新抽取出的一条记忆会先和历史记忆做向量或文本相似度计算如果发现内容高度重叠就不会重复插入。我实际用下来这种去重对“同一件事换个说法反复出现”的情况比较有效。比如第一次你说了“使用 pnpm”第二次说“包管理器统一用 pnpm”它不会存两条。另一个是自动归档。记忆库里有些内容时效性很强比如“当前正在解决的问题是登录接口 401”这种信息过几天就没意义了。claude-mem 会通过定期总结或规则判断把这类临时性记忆压缩掉只保留那些长期稳定的事实。我以前没注意这个功能导致记忆库膨胀到几百条里面一半是过期信息。后来打开 MEMORY.md 才发现整理得越干净Claude 调用记忆时的表现越准确。3. 安装与集成把记忆装进 Claude Code3.1 安装 claude-mem 的两种方式claude-mem 的安装门槛很低。最常规的方式是直接用 Node 包管理器装因为它本身是一个 CLI 工具依赖 Node.js 运行时。你可以在全局装也可以装在某个项目里。我个人的建议是全局安装一次然后在需要启用记忆的项目里单独做初始化。命令很直白就是npm install -g claude-mem。装完跑一下claude-mem --version能输出版本号就说明环境没问题。第二种方式是跑它自带的一条初始化命令在项目目录里执行claude-mem init。这条命令会帮你生成必要的配置文件和目录结构比如.claude-mem/文件夹、一个记录夹取频率的配置文件。如果你是第一次用直接 init 比自己手动 mkdir 省事得多。初始化之后你的项目里就多了一套私有的记忆仓库。还有一点要注意claude-mem 有几个可选依赖。比如它支持的记忆提取后端可以配置成调用 Claude API也可以配置成本地的 Ollama。默认情况下它会走当前 Claude Code 所在的模型环境也就是说不额外产生 API 费用。熟悉配置之后你完全可以按自己的需求调整提取后端。3.2 与 Claude Code 的 hooks 配置安装完只是第一步真正让它跑起来的关键在于把 claude-mem 的 CLI 命令注册成 Claude Code 的 hook。Claude Code 的配置通常在项目根目录的.claude/settings.json里。你需要在这个文件里定义一个Stop事件的后置命令让 claude-mem 在每次对话停止时去执行一遍记忆提取。具体的配置片段大致长这样{ hooks: { Stop: [ { matcher: , hooks: [ { type: command, command: claude-mem capture } ] } ] } }这里的matcher留空表示所有对话都触发。这是我建议初学者先用的配置。跑一段时间你想精细化控制也可以填上特定的正则只让某些类型的对话触发记忆捕获。总之注册好 hook 之后claude-mem 才算是真正接入了你的开发流。如果漏掉这一步装了半天它也只是个空转的 CLI。配置完成后我建议你立刻做一次验证。随便开一个会话对 Claude Code 说一句“从今往后这个项目的代码风格统一使用函数式组件”然后结束对话。再去查看.claude-mem/MEMORY.md如果能看到这条信息的相关记录就说明整套链路已经通了。3.3 递归记忆与跨项目记忆的边界claude-mem 默认的记忆范围是当前项目。每个项目有自己独立的记忆文件这能有效避免“项目 A 的技术栈约定串到项目 B”的混乱。但是有些内容可能是通用的比如“我习惯用双引号不用单引号”“我写的提交信息要带 Jira 单号”。这类个人偏好如果只存在某个项目里换个项目就又忘了。我的处理方式是把 claude-mem 的记忆目录按两层来理解项目级记忆和个人级记忆。项目级记忆随着项目走跟着 git 仓库走团队成员拉下来也能共享。个人级记忆则存在你的用户目录下专门存放跨项目普适的偏好。claude-mem 在初始化的时候会让你选存储位置我建议你认真审视一下哪些内容该放哪一层。交叉使用的时候注意一点当你同时开了多级记忆Claude Code 加载记忆时会把两层内容都带进上下文。如果两层内容出现了矛盾条目模型的判断可能被干扰。所以隔一段时间清理个人记忆里的过期约定跟清理项目记忆一样重要。4. 实操记忆的查看、搜索与清理4.1 查看全部记忆清单会暴露你的习惯开箱之后很多人会好奇自己的记忆库里到底存了什么。命令很简单claude-mem --list就能把当前项目的记忆条目全部列出来。我第一次执行的时候发现它已经存了三十多条里面有几条我自己都快忘了。这其实是个很有意思的“元认知”过程你会看到自己在日常工作中反复强调什么、最在意什么。清单输出通常是分条展示的每条记忆有编号、创建时间、内容摘要。如果内容太长它只显示一个摘要不会把整个记忆体塞满终端。这条命令最大的用途是帮你快速确认“它记住了哪些东西”从而判断记忆库的质量是否正常。如果发现大量重复或无关内容就该考虑清理了。我习惯于在每周五下午跑一次claude-mem --list快速扫一遍这周积累的记忆。看到过时信息就顺手清掉看到表达混乱的就手动改。这十分钟的维护工作比后续让 Claude 带着一堆垃圾记忆干活要划算得多。4.2 按关键词搜索把记忆变成可检索的增量知识记忆库最大的优势是可检索。当你想确认“之前有没有讨论过日志格式的问题”不需要翻聊天记录直接claude-mem --search 日志格式就行。这个搜索走的是 SQLite 全文索引聊胜于 grep速度非常快。搜索结果的展示会带上记忆条目的上下文片段方便你判断哪一条才是自己要的。我发现这个搜索功能在日常开发中最实用的场景其实是“找回失散的技术决策”。比如半个月前我们讨论过为什么用tsx而不是ts-node当时没来得及记到正经文档里但我记得跟 Claude 说过几句话。这种情况下搜索引擎比文档还靠谱因为它保存的是当时对话里的原始表达包含了决策动机而不像文档那样总是一版一版地精简。搜索还有个用法你可能想不到它能把 Claude Code 从“遇到问题只会给通用答案”变成“遇到问题先查历史经验”。比如你问它“这个项目怎么跑测试”它如果搜到了记忆里“测试要用 vitest 且要带上--run参数”回答就会比那种泛泛的“运行 npm test”准确得多。4.3 删除错误记忆与手动修整没有任何工具能保证自动抽取出来的记忆百分百正确。我也遇到过它把一句玩笑话当成正经偏好存了下来比如我随口说“再也不要用 less 了”它就把“禁用 less”记录在案。这种误存如果不及时清理会影响后续所有会话的判断。删除命令是claude-mem --forget 记忆编号。先--list找到编号再执行删除两步就能完成。这个命令的作用是同时删除 SQLite 索引里的记录和 Markdown 文件里的对应条目保持两边一致。实际用下来删除很干脆不会有残留脏数据。除了删除我也经常直接手改 MEMORY.md。claude-mem 设计得比较放心的一点是它不怕你手工改甚至鼓励你手工维护——文件就是最直接的真相。你可以在文件里手写一条新记忆下次 Claude 加载时同样能读到。我觉得这种“系统自动提取 人工兜底修正”的组合是平衡效率和准确度的好方案。完全依赖自动提取是不可能高可靠的毕竟语言理解的边界太宽。4.4 记忆合并与压缩的时机记忆库维护不只有增删还有合并。比如你一开始记住的是“测试用 vitest”后来又记住了“测试命令要加 --coverage”这两条逻辑上可以合并成一条“测试用 vitest 且带覆盖率参数”。分开存倒也不会出错但会让记忆数量虚高让 Claude 在加载时看到更多琐碎条目。claude-mem 本身具备某种自动压缩机制但我并不全依赖它。我发现手动合并的效果通常更好因为你能捕捉到两条记忆之间的语义关联而自动算法往往只能识别文本相似。所以说白了这工具是你的记忆助理不是你记忆的最终决策者。压缩的时机也有讲究。我的经验是不要每天都做那样太累也不要攒到几百条再做那样清理成本巨高。合理周期是两周左右检查一次或者在你感觉 Claude 的回答“开始变啰嗦、什么旧知识都在往外翻”的时候就是该压缩了。5. 常见问题与排查实录5.1 记忆完全没有生效怎么办最常见的问题就是配置好 claude-mem 之后新开会话Claude 还是什么都不记得。我排查这种问题一般按三个顺序来。第一看 Stop hook 是不是真的注册成功了。很多人改了settings.json但格式写错导致 Claude Code 静默忽略了整个钩子配置。你可以在对话里故意问一句“你刚才从我的记忆里看到了什么”如果它说没有任何记忆大概率是 hook 没生效。第二看claude-mem capture命令是否能手动跑通。在终端直接跑一次如果命令报错那可能是全局安装路径没被 Claude Code 的 shell 环境识别到。第三确认记忆库文件是不是空。跑claude-mem --list如果列表为空说明捕获链路有断点但配置本身是通的。我遇到过一种诡异的情况hook 配置正确、命令能执行但 MEMORY.md 里还是什么都没有。后来发现是因为触发条件太苛刻我设置的 matcher 正则不匹配任何实际对话。这种问题嵌套得很深排查时最好一步步拆解先验证配置层再验证命令层最后才是验证业务层。5.2 重复记忆堆积如山另一个高频问题没用多久记忆库里出现了大量内容重复的条目。虽然 claude-mem 有去重逻辑但在某些情况下它依然会失效。比如你每次会话都重新说明一遍同样的规范每次都用了不同的措辞向量语义虽然可能接近但文本相似度的阈值没触发就会重复插入。解决办法有两个方向。一个是优化使用习惯对于长期稳定的规范与其反复在对话里说不如直接写进 MEMORY.md 文件里作为“种子记忆”。这样既减少了重复捕获的机会也让 Claude 从一开始就具备这些基础认知。另一个是定期合并清理把重复的条目手动删掉只保留信息最完整的一条。这里我要多说一句别指望任何自动去重能做到完美语言太灵活同一个意思可以有一百种表达方式。把记忆库当成你手头的一堆卡片定期归类整理才是靠谱的心智模型。5.3 多项目之间的记忆串台当你在好几个项目里都启用了 claude-mem而且把它们放在同一个全局存储位置就有可能出现串台。我实际遇到过一次A 项目里记录了“用 pnpm”B 项目的会话里它居然问我“要不要用 pnpm 装依赖”可 B 项目明明是 npm 项目。查了半天发现是两个项目共用了一套全局记忆库导致记忆鱼龙混杂。这个问题的最佳解法是在初始化时就明确区分存储位置。每个项目都应该有自己独立的.claude-mem目录。个人级偏好才放全局。另外你在切换项目时最好留意一下当前工作目录Claude Code 的 hook 触发时会读取项目根目录的配置如果目录不对命令可能作用在了错误的记忆库上。如果你已经出现串台处理也不难打开两个项目的 MEMORY.md把不属于该项目的条目删掉同时查看个人记忆库里是否有需要清理的交叉内容。这种整理工作有点像搬家时的断舍离过程麻烦但搬完之后住着舒服。5.4 模型更新后记忆格式不一致我遇到过 claude-mem 在 Claude 模型版本更新之后抽取的记忆格式偶尔会发生变化。比如以前偏好用列表形式输出事实新版本开始用一段话描述。这种不一致本身不影响使用但如果你依赖工具自动去重就可能因为格式差异导致去重失败。我的习惯是每个季度检查一次 claude-mem 的更新版本有更新就及时升级。因为这个工具还在快速迭代作者经常修格式兼容类的 bug。如果你发现升级后老记忆出现乱码、或根本读不出来别急着删文件备份一下 MEMORY.md然后重新 init 一次存储目录通常能恢复。从这些坑里走出来的经验可以总结为一句话记忆工具不是“装完就万事大吉”的它需要你花一点心思去维护格式、位置、内容边界。但这份维护成本相比每天重复向 AI 交代背景已经是极低的支出了。6. 进阶玩法与个人经验6.1 把记忆当作团队交接文档claude-mem 不知不觉间让团队协作多了一个层面。因为项目记忆存在项目目录里如果团队成员都在用 Claude Code大家共享的记忆库就变成了一份活文档。新同学上手时不用翻半天的 wikiClaude Code 自己就能从记忆里给出符合项目惯例的建议。我们团队现在有个不成文的规矩遇到复杂的项目决策会在对话里特意强调一遍结论比如“定下来生产环境用 PostgreSQL不要用 MySQL”。这种话不是为了说给 AI 听而是为了让 claude-mem 捕获变成长期的团队共识。久而久之MEMORY.md 成了另一份团队知识库它和正式文档的区别在于它保留了很多“为什么当时这么决定”的对话痕迹这个价值非常大。我强烈建议你在项目初期就把记忆库的维护习惯建立起来等积累了半年再看你会惊讶于这份资产的厚度。它就像代码注释一样平时不觉得有啥但到了交接、复盘、维护老功能的时候每一条记忆都在帮你省时间。6.2 控制记忆的颗粒度别什么事都让它记用久了你就会发现记忆库里真正有价值的信息其实占比不高。原因主要在于捕获粒度没控制好。claude-mem 的默认行为可能偏保守会尽量多记一些以免遗漏。但记太多也是有代价的——每次会话加载的记忆越多留给当前任务的有效上下文就越少。我习惯在配置里调低捕获频率并且对某些敏感或临时性内容明确不记。比如“我今天要修登录页的 bug”这种就应该让它自然消失“这个项目的登录页用的是 OAuth 2.0 授权码模式”这种才值得记住。把握这个颗粒度的核心标准是这条记忆在下一次会话里是否仍然有用如果回答是“是”才值得留住。这个原则说起来简单做起来需要一点点直觉。我的建议是先用默认配置跑一周然后复盘一下记忆库里哪些条目是“废话”再根据实际情况调整。越早形成自己的“记忆价值观”你的记忆库质量提升得越快。6.3 从 claude-mem 想到的 AI 使用哲学最后聊一点超出工具本身的想法。用 claude-mem 的时间越久我越觉得“给 AI 装记忆”这件事的本质是在重新定义人机协作的边界。过去我们觉得 AI 是个单次对话的问答器用完即走现在有了记忆它开始像一个“渐入佳境”的同事和你一起成长、积累默契。这背后也提醒我一件事AI 已经不再是“用完即抛”的玩具它正在变成真正参与项目长期建设的一份子。而给它持续投喂高质量记忆就像给新员工做入职培训前期投入是值得的。你不欠它什么但你的项目会由于它的稳定发挥而明显受益。我个人在项目里推广 claude-mem 之后最大的体会是跟 AI 沟通的心智负担明显减轻了不用再时刻想着“这句话要不要再说一遍”因为它都会记得。这才是工具给工作流带来的最本质的改善。 
长河君 · 2026/10/9 6:37:28 · 阅读 1.2k 给 Claude Code 装上长期记忆：claude-mem 原理、配置与实战
用过 Claude Code 的人十有八九都有过这样的憋屈时刻上午明明已经告诉它“这个项目统一用 pnpm锁文件别乱动”下午新开一个会话它又一脸茫然地问你要不要用 npm。你重复了三遍的代码规范、环境变量、部署流程它永远像金鱼一样七秒记忆。这不是模型不够聪明而是对话式 AI 天然缺少一条跨会话的“记忆神经”。我为了解决这个问题折腾过各种方案最后找到了 claude-mem——一个专门给 Claude 补上长期记忆的开源工具也是今天这篇博文的主角。它能自动从对话里抽取关键信息存成结构化记忆下次会话直接调用。无论你是拿 Claude Code 写代码、跑自动化脚本还是拿它做文档整理只要来回切换会话比较频繁这个工具都能帮你省掉大量重复沟通的成本。1. 为什么会做这么个工具AI 记忆的痛点在哪1.1 会话隔离是原罪所有大模型产品的底层都是“无状态”的。每次你发起对话模型看到的只是当前会话里这些上下文之前的会话、之前的项目历史它一概不知。所谓“记住”其实是靠你在对话里不断重复喂给它。这种设计在聊天场景下没问题但在真正干活的时候就成了大麻烦。尤其是 Claude Code 这种深度嵌入工作流的终端工具你可能会开十几个会话处理不同任务一个写后端接口一个做前端页面一个在排查 CI 报错。它们之间完全隔离掌握的上下文互不相通。我在实际使用中最直观的感受是项目里有些约定俗成的东西根本不在代码里只在脑子里。比如“数据库迁移脚本不能直接跑在线上环境”“测试环境要用 mock 的支付回调地址”“这个仓库存放在 monorepo 的 packages/shared 目录下”。每次开新会话我都得像念经一样重新交代一遍。更烦的是如果哪次忘了说它就可能按照最常规、最普适的做法去处理然后产出一个和项目风格完全不一致的代码。1.2 那些“说了就忘”的真实场景我举几个自己踩过的具体例子。第一个是技术栈约定。我有个项目前端用 Vue 3 的script setup写法禁用了 Options API。头一天告诉 Claude Code 之后它写得挺好第二天换个会话让它加个页面它直接给你整出export default { data() { ... } }的老写法。不怪它是它确实“不记得”了。第二个是常用命令和路径。项目里有个内部 CLI 工具路径是./scripts/dev-tool.sh启动参数很怪。这工具在会话里提到过一次但下次会话它忘了还会自作主张地建议你npx dev-tool然后你得到一个 command not found。第三个是配置文件的坑。.env.example里有个VITE_API_BASE_URL需要指向 staging 域名这种信息在团队 wiki 里写着但你没法每次都贴给 AI 看。它一旦不知道就可能生成指向 localhost 的接口代码让你的联调崩溃。1.3 claude-mem 到底解决什么问题claude-mem 的核心思路特别朴素把“记忆”从模型的临时上下文里搬出来落到本地持久化的存储里。它监听你和 Claude Code 的对话过程在合适的时机例如一轮对话结束自动提取其中有保留价值的信息整理成一条条记忆。这些记忆会存在项目本地下次会话启动时Claude Code 就会通过工具调用把它们加载回来。我用下来感觉它解决的不是“模型记性好不好”的问题而是“要不要一遍遍重复”的问题。你只需要在某个会话里说一次“这个项目用 pnpm”它就变成一条记忆。之后任何新会话都自动具备这条知识。对于日常重复性的业务开发这个价值极其明显把 AI 从“聊天机器人”变成了一个有项目记忆的“长期协作者”。2. 核心机制拆解claude-mem 是怎么记住东西的2.1 记忆的捕获从对话流里截取关键信息claude-mem 的工作方式非常依赖 Claude Code 的 hooks 机制。Claude Code 允许你在特定事件比如每次模型回复结束时触发外部脚本claude-mem 就是利用这个“Stop hook”作为触发点。每当一轮交互结束它会把当前会话的完整文本交给一个分析流程从中抽取候选记忆。这里有个关键设计它不是把整段对话原样存下来而是做“抽取式提炼”。我理解它内部有一个 Prompt 模板会要求模型以特定格式输出记忆条目。常见的抽取维度包括用户的明确偏好“不要用 npm”、项目技术决策“我们用 Vite 而不是 Webpack”、具体的工作流约定“每次发版前要跑 lint”、环境相关的事实“生产环境数据库账号存在 1Password 里”。这些维度的设定直接决定了记忆库质量的上限。你说这不就是把对话丢给模型让它总结吗没错逻辑上确实是。但它的价值在于自动化你不用手动复制、粘贴、整理它全帮你做完了。而且你可以控制触发频率不用每句话都存通常几个来回才触发一次成本和噪音都可控。2.2 记忆的存储Markdown 文件 SQLite 索引存储层是 claude-mem 另一个比较务实的设计。记忆最终会写入一个 Markdown 文件通常放在项目目录下的.claude-mem文件夹里主文件名一般是MEMORY.md。Markdown 的好处不用多说人类可读、可直接编辑、能用 git 做版本管理。你完全可以打开这个文件手工删掉某条过时的记忆或者补充一条新的。但纯文件存储有个问题——检索效率。当记忆数量涨到几百条你想快速找到“和数据库相关的那条”靠 grep 效率太低了。所以 claude-mem 同时维护了一个 SQLite 索引库对每条记忆做了分词和全文索引。查询的时候先走 SQLite 的 FTS 做全文检索再把命中的 Markdown 片段返回给 Claude。这个设计思路类似一个极简版的笔记系统文件是人能看懂的真相SQLite 是给机器用的加速索引。还有一点值得提它的记忆条目本身可能有结构化的 meta 信息比如创建时间、来源会话、标签。这些 meta 信息对后续的去重、排序、过期清理非常重要。我看它的存储结构时会觉得这不像一个随手写的玩具而是一个认真设计了数据模型的工具。2.3 整理与去重不让记忆库变成垃圾场凡是搞过知识库的人都知道收集容易整理难。claude-mem 如果只负责往 MEMORY.md 里堆内容用不了多久这个文件就变成一坨没人看得下去的废料Claude 也会被误导。所以它内置了一些记忆维护机制。一个是相似度去重。新抽取出的一条记忆会先和历史记忆做向量或文本相似度计算如果发现内容高度重叠就不会重复插入。我实际用下来这种去重对“同一件事换个说法反复出现”的情况比较有效。比如第一次你说了“使用 pnpm”第二次说“包管理器统一用 pnpm”它不会存两条。另一个是自动归档。记忆库里有些内容时效性很强比如“当前正在解决的问题是登录接口 401”这种信息过几天就没意义了。claude-mem 会通过定期总结或规则判断把这类临时性记忆压缩掉只保留那些长期稳定的事实。我以前没注意这个功能导致记忆库膨胀到几百条里面一半是过期信息。后来打开 MEMORY.md 才发现整理得越干净Claude 调用记忆时的表现越准确。3. 安装与集成把记忆装进 Claude Code3.1 安装 claude-mem 的两种方式claude-mem 的安装门槛很低。最常规的方式是直接用 Node 包管理器装因为它本身是一个 CLI 工具依赖 Node.js 运行时。你可以在全局装也可以装在某个项目里。我个人的建议是全局安装一次然后在需要启用记忆的项目里单独做初始化。命令很直白就是npm install -g claude-mem。装完跑一下claude-mem --version能输出版本号就说明环境没问题。第二种方式是跑它自带的一条初始化命令在项目目录里执行claude-mem init。这条命令会帮你生成必要的配置文件和目录结构比如.claude-mem/文件夹、一个记录夹取频率的配置文件。如果你是第一次用直接 init 比自己手动 mkdir 省事得多。初始化之后你的项目里就多了一套私有的记忆仓库。还有一点要注意claude-mem 有几个可选依赖。比如它支持的记忆提取后端可以配置成调用 Claude API也可以配置成本地的 Ollama。默认情况下它会走当前 Claude Code 所在的模型环境也就是说不额外产生 API 费用。熟悉配置之后你完全可以按自己的需求调整提取后端。3.2 与 Claude Code 的 hooks 配置安装完只是第一步真正让它跑起来的关键在于把 claude-mem 的 CLI 命令注册成 Claude Code 的 hook。Claude Code 的配置通常在项目根目录的.claude/settings.json里。你需要在这个文件里定义一个Stop事件的后置命令让 claude-mem 在每次对话停止时去执行一遍记忆提取。具体的配置片段大致长这样{ hooks: { Stop: [ { matcher: , hooks: [ { type: command, command: claude-mem capture } ] } ] } }这里的matcher留空表示所有对话都触发。这是我建议初学者先用的配置。跑一段时间你想精细化控制也可以填上特定的正则只让某些类型的对话触发记忆捕获。总之注册好 hook 之后claude-mem 才算是真正接入了你的开发流。如果漏掉这一步装了半天它也只是个空转的 CLI。配置完成后我建议你立刻做一次验证。随便开一个会话对 Claude Code 说一句“从今往后这个项目的代码风格统一使用函数式组件”然后结束对话。再去查看.claude-mem/MEMORY.md如果能看到这条信息的相关记录就说明整套链路已经通了。3.3 递归记忆与跨项目记忆的边界claude-mem 默认的记忆范围是当前项目。每个项目有自己独立的记忆文件这能有效避免“项目 A 的技术栈约定串到项目 B”的混乱。但是有些内容可能是通用的比如“我习惯用双引号不用单引号”“我写的提交信息要带 Jira 单号”。这类个人偏好如果只存在某个项目里换个项目就又忘了。我的处理方式是把 claude-mem 的记忆目录按两层来理解项目级记忆和个人级记忆。项目级记忆随着项目走跟着 git 仓库走团队成员拉下来也能共享。个人级记忆则存在你的用户目录下专门存放跨项目普适的偏好。claude-mem 在初始化的时候会让你选存储位置我建议你认真审视一下哪些内容该放哪一层。交叉使用的时候注意一点当你同时开了多级记忆Claude Code 加载记忆时会把两层内容都带进上下文。如果两层内容出现了矛盾条目模型的判断可能被干扰。所以隔一段时间清理个人记忆里的过期约定跟清理项目记忆一样重要。4. 实操记忆的查看、搜索与清理4.1 查看全部记忆清单会暴露你的习惯开箱之后很多人会好奇自己的记忆库里到底存了什么。命令很简单claude-mem --list就能把当前项目的记忆条目全部列出来。我第一次执行的时候发现它已经存了三十多条里面有几条我自己都快忘了。这其实是个很有意思的“元认知”过程你会看到自己在日常工作中反复强调什么、最在意什么。清单输出通常是分条展示的每条记忆有编号、创建时间、内容摘要。如果内容太长它只显示一个摘要不会把整个记忆体塞满终端。这条命令最大的用途是帮你快速确认“它记住了哪些东西”从而判断记忆库的质量是否正常。如果发现大量重复或无关内容就该考虑清理了。我习惯于在每周五下午跑一次claude-mem --list快速扫一遍这周积累的记忆。看到过时信息就顺手清掉看到表达混乱的就手动改。这十分钟的维护工作比后续让 Claude 带着一堆垃圾记忆干活要划算得多。4.2 按关键词搜索把记忆变成可检索的增量知识记忆库最大的优势是可检索。当你想确认“之前有没有讨论过日志格式的问题”不需要翻聊天记录直接claude-mem --search 日志格式就行。这个搜索走的是 SQLite 全文索引聊胜于 grep速度非常快。搜索结果的展示会带上记忆条目的上下文片段方便你判断哪一条才是自己要的。我发现这个搜索功能在日常开发中最实用的场景其实是“找回失散的技术决策”。比如半个月前我们讨论过为什么用tsx而不是ts-node当时没来得及记到正经文档里但我记得跟 Claude 说过几句话。这种情况下搜索引擎比文档还靠谱因为它保存的是当时对话里的原始表达包含了决策动机而不像文档那样总是一版一版地精简。搜索还有个用法你可能想不到它能把 Claude Code 从“遇到问题只会给通用答案”变成“遇到问题先查历史经验”。比如你问它“这个项目怎么跑测试”它如果搜到了记忆里“测试要用 vitest 且要带上--run参数”回答就会比那种泛泛的“运行 npm test”准确得多。4.3 删除错误记忆与手动修整没有任何工具能保证自动抽取出来的记忆百分百正确。我也遇到过它把一句玩笑话当成正经偏好存了下来比如我随口说“再也不要用 less 了”它就把“禁用 less”记录在案。这种误存如果不及时清理会影响后续所有会话的判断。删除命令是claude-mem --forget 记忆编号。先--list找到编号再执行删除两步就能完成。这个命令的作用是同时删除 SQLite 索引里的记录和 Markdown 文件里的对应条目保持两边一致。实际用下来删除很干脆不会有残留脏数据。除了删除我也经常直接手改 MEMORY.md。claude-mem 设计得比较放心的一点是它不怕你手工改甚至鼓励你手工维护——文件就是最直接的真相。你可以在文件里手写一条新记忆下次 Claude 加载时同样能读到。我觉得这种“系统自动提取 人工兜底修正”的组合是平衡效率和准确度的好方案。完全依赖自动提取是不可能高可靠的毕竟语言理解的边界太宽。4.4 记忆合并与压缩的时机记忆库维护不只有增删还有合并。比如你一开始记住的是“测试用 vitest”后来又记住了“测试命令要加 --coverage”这两条逻辑上可以合并成一条“测试用 vitest 且带覆盖率参数”。分开存倒也不会出错但会让记忆数量虚高让 Claude 在加载时看到更多琐碎条目。claude-mem 本身具备某种自动压缩机制但我并不全依赖它。我发现手动合并的效果通常更好因为你能捕捉到两条记忆之间的语义关联而自动算法往往只能识别文本相似。所以说白了这工具是你的记忆助理不是你记忆的最终决策者。压缩的时机也有讲究。我的经验是不要每天都做那样太累也不要攒到几百条再做那样清理成本巨高。合理周期是两周左右检查一次或者在你感觉 Claude 的回答“开始变啰嗦、什么旧知识都在往外翻”的时候就是该压缩了。5. 常见问题与排查实录5.1 记忆完全没有生效怎么办最常见的问题就是配置好 claude-mem 之后新开会话Claude 还是什么都不记得。我排查这种问题一般按三个顺序来。第一看 Stop hook 是不是真的注册成功了。很多人改了settings.json但格式写错导致 Claude Code 静默忽略了整个钩子配置。你可以在对话里故意问一句“你刚才从我的记忆里看到了什么”如果它说没有任何记忆大概率是 hook 没生效。第二看claude-mem capture命令是否能手动跑通。在终端直接跑一次如果命令报错那可能是全局安装路径没被 Claude Code 的 shell 环境识别到。第三确认记忆库文件是不是空。跑claude-mem --list如果列表为空说明捕获链路有断点但配置本身是通的。我遇到过一种诡异的情况hook 配置正确、命令能执行但 MEMORY.md 里还是什么都没有。后来发现是因为触发条件太苛刻我设置的 matcher 正则不匹配任何实际对话。这种问题嵌套得很深排查时最好一步步拆解先验证配置层再验证命令层最后才是验证业务层。5.2 重复记忆堆积如山另一个高频问题没用多久记忆库里出现了大量内容重复的条目。虽然 claude-mem 有去重逻辑但在某些情况下它依然会失效。比如你每次会话都重新说明一遍同样的规范每次都用了不同的措辞向量语义虽然可能接近但文本相似度的阈值没触发就会重复插入。解决办法有两个方向。一个是优化使用习惯对于长期稳定的规范与其反复在对话里说不如直接写进 MEMORY.md 文件里作为“种子记忆”。这样既减少了重复捕获的机会也让 Claude 从一开始就具备这些基础认知。另一个是定期合并清理把重复的条目手动删掉只保留信息最完整的一条。这里我要多说一句别指望任何自动去重能做到完美语言太灵活同一个意思可以有一百种表达方式。把记忆库当成你手头的一堆卡片定期归类整理才是靠谱的心智模型。5.3 多项目之间的记忆串台当你在好几个项目里都启用了 claude-mem而且把它们放在同一个全局存储位置就有可能出现串台。我实际遇到过一次A 项目里记录了“用 pnpm”B 项目的会话里它居然问我“要不要用 pnpm 装依赖”可 B 项目明明是 npm 项目。查了半天发现是两个项目共用了一套全局记忆库导致记忆鱼龙混杂。这个问题的最佳解法是在初始化时就明确区分存储位置。每个项目都应该有自己独立的.claude-mem目录。个人级偏好才放全局。另外你在切换项目时最好留意一下当前工作目录Claude Code 的 hook 触发时会读取项目根目录的配置如果目录不对命令可能作用在了错误的记忆库上。如果你已经出现串台处理也不难打开两个项目的 MEMORY.md把不属于该项目的条目删掉同时查看个人记忆库里是否有需要清理的交叉内容。这种整理工作有点像搬家时的断舍离过程麻烦但搬完之后住着舒服。5.4 模型更新后记忆格式不一致我遇到过 claude-mem 在 Claude 模型版本更新之后抽取的记忆格式偶尔会发生变化。比如以前偏好用列表形式输出事实新版本开始用一段话描述。这种不一致本身不影响使用但如果你依赖工具自动去重就可能因为格式差异导致去重失败。我的习惯是每个季度检查一次 claude-mem 的更新版本有更新就及时升级。因为这个工具还在快速迭代作者经常修格式兼容类的 bug。如果你发现升级后老记忆出现乱码、或根本读不出来别急着删文件备份一下 MEMORY.md然后重新 init 一次存储目录通常能恢复。从这些坑里走出来的经验可以总结为一句话记忆工具不是“装完就万事大吉”的它需要你花一点心思去维护格式、位置、内容边界。但这份维护成本相比每天重复向 AI 交代背景已经是极低的支出了。6. 进阶玩法与个人经验6.1 把记忆当作团队交接文档claude-mem 不知不觉间让团队协作多了一个层面。因为项目记忆存在项目目录里如果团队成员都在用 Claude Code大家共享的记忆库就变成了一份活文档。新同学上手时不用翻半天的 wikiClaude Code 自己就能从记忆里给出符合项目惯例的建议。我们团队现在有个不成文的规矩遇到复杂的项目决策会在对话里特意强调一遍结论比如“定下来生产环境用 PostgreSQL不要用 MySQL”。这种话不是为了说给 AI 听而是为了让 claude-mem 捕获变成长期的团队共识。久而久之MEMORY.md 成了另一份团队知识库它和正式文档的区别在于它保留了很多“为什么当时这么决定”的对话痕迹这个价值非常大。我强烈建议你在项目初期就把记忆库的维护习惯建立起来等积累了半年再看你会惊讶于这份资产的厚度。它就像代码注释一样平时不觉得有啥但到了交接、复盘、维护老功能的时候每一条记忆都在帮你省时间。6.2 控制记忆的颗粒度别什么事都让它记用久了你就会发现记忆库里真正有价值的信息其实占比不高。原因主要在于捕获粒度没控制好。claude-mem 的默认行为可能偏保守会尽量多记一些以免遗漏。但记太多也是有代价的——每次会话加载的记忆越多留给当前任务的有效上下文就越少。我习惯在配置里调低捕获频率并且对某些敏感或临时性内容明确不记。比如“我今天要修登录页的 bug”这种就应该让它自然消失“这个项目的登录页用的是 OAuth 2.0 授权码模式”这种才值得记住。把握这个颗粒度的核心标准是这条记忆在下一次会话里是否仍然有用如果回答是“是”才值得留住。这个原则说起来简单做起来需要一点点直觉。我的建议是先用默认配置跑一周然后复盘一下记忆库里哪些条目是“废话”再根据实际情况调整。越早形成自己的“记忆价值观”你的记忆库质量提升得越快。6.3 从 claude-mem 想到的 AI 使用哲学最后聊一点超出工具本身的想法。用 claude-mem 的时间越久我越觉得“给 AI 装记忆”这件事的本质是在重新定义人机协作的边界。过去我们觉得 AI 是个单次对话的问答器用完即走现在有了记忆它开始像一个“渐入佳境”的同事和你一起成长、积累默契。这背后也提醒我一件事AI 已经不再是“用完即抛”的玩具它正在变成真正参与项目长期建设的一份子。而给它持续投喂高质量记忆就像给新员工做入职培训前期投入是值得的。你不欠它什么但你的项目会由于它的稳定发挥而明显受益。我个人在项目里推广 claude-mem 之后最大的体会是跟 AI 沟通的心智负担明显减轻了不用再时刻想着“这句话要不要再说一遍”因为它都会记得。这才是工具给工作流带来的最本质的改善。