用过 Claude Code 的朋友应该都有过这种体验上午还在同一个项目里聊得热火朝天你让它记住了目录结构、代码风格、常用命令下午重新打开一个终端会话它一脸茫然地看着你。默认情况下 Claude 的每个会话都是互相隔离的所有对话就像速写纸关掉窗口就等同于擦掉黑板。刚开始我还能靠写 CLAUDE.md 硬撑但项目一多、上下文一长这种人肉记忆根本扛不住。于是我去翻了社区里讨论度挺高的 claude-mem——一个专门给 Claude 加长期记忆的开源工具。这篇文章我就从实际使用者的角度聊聊它到底帮你记住了什么底层是怎么存的接入要几步日常怎么用最顺手以及我踩过的一些坑。1. 先说说我为什么给 Claude 套上一层记忆皮肤1.1 原生会话的秒忘属性比你想的更麻烦Claude 这类大模型本质上是一个无状态函数你发给它一段上下文它基于这段上下文生成回复。它没有真正意义上的长期记忆只有当前窗口里还能看见的文字。这就带来两个很实际的麻烦。第一新会话要重新交代背景。你昨天花了二十分钟跟它梳理模块依赖关系今天新开一个会话它完全不记得。你得重新把项目背景、技术栈、已经确定的技术方案再讲一遍甚至讲得比上次更细。第二上下文窗口是有上限的。就算你在同一个长会话里聊到一定长度之后前面的内容会被截断。我做一次大型重构的时候经常遇到刚跟 Claude 确认过这个模块不要再动了后面要整体抽出结果上下文一满它反而开始建议我改这个模块因为它已经看不见之前的约定了。这种感觉就像你请了个很聪明的临时工他每天都精神饱满但每天上班都是第一天。正常情况下你需要靠文档、靠聊天记录、靠自己脑子里的记忆去给他交接班。项目小的时候还行项目一多这种交接成本高到让人烦躁。1.2 claude-mem 的定位不是插件是交接班日志claude-mem 的思路很简单既然大模型自己记不住那就别让它记把记忆放到外部去。它是一个运行在本地、通过 MCP 协议跟 Claude Code 通信的工具。MCP 你可能听说过就是让 Claude 能调用外部工具和数据的标准协议。claude-mem 以 MCP 服务器的身份接入把自己包装成一组记忆工具Claude 在对话中需要用到记忆时就会去调用这些工具。它做的不是把每一句聊天记录都原封不动地存下来而是定期从对话中提炼出值得长期记住的信息项目约定、用户偏好、关键技术决策、常用命令、踩过的坑然后写入本地的 SQLite 数据库。下次新会话启动时Claude 可以主动从记忆库里检索相关条目把旧记忆拉回到当前上下文里。我用一个类比来理解它Claude 是每天新来的临时代班员工claude-mem 是上一班员工留下的交接日志。日志不是把所有废话都写上去而是挑重点哪些事情定了、哪些事情不能碰、这个客户有什么忌讳。第二天上班的人扫一眼日志就能快速进入状态。1.3 和常规的让 Claude 记住方案对比我一开始也没直接上 claude-mem而是先试过各种土办法。这里把几种常见方案放在一起比较大家可以根据自己的情况选。方案优点缺点项目内 CLAUDE.mdClaude Code 原生支持简单直接静态内容不会随对话自动更新内容全靠人工维护自己写脚本存 TXT/JSON灵活想存什么存什么没有检索和提炼能力存进去就是死文本上下文注入不可控claude-mem自动提炼 语义搜索 本地 SQLite 存储多一层 MCP 依赖需要显式配置自动记录可能产生噪音CLAUDE.md 我到现在还在用但它适合放不会变的东西比如项目背景、目录说明。真正会变的东西比如今天确定的一个约定、昨天踩的一个坑靠手动往 CLAUDE.md 里写太不现实。claude-mem 的价值就是把会变的信息变成自动更新的交接日志。2. 从记录到回忆claude-mem 的记忆链路是怎么设计的2.1 会话捕获它到底在听什么在使用 claude-mem 之前我一直以为它需要我在对话里喊一声记住才干活。用完才发现它的核心能力之一是主动扫描 Claude Code 本地的会话日志文件。Claude Code 在运行时会把你和它的对话写入本地日志目录通常是~/.claude/projects/下按项目分类的 JSONL 文件。claude-mem 会去读这些文件找到最近发生的对话然后分析里面有没有值得沉淀的信息。这意味着我不用刻意维护记忆只要正常跟 Claude 聊天claude-mem 就能在后台做信息收割。这个设计很聪明。如果记忆工具只靠用户主动触发很多人用两天就会忘记用最后记忆库一片空白。主动扫描会话日志让记忆的采集自动化程度高了很多。对隐私敏感的人可能会觉得有点被监听的感觉这一点我在后面会专门讲这里先按下不表。2.2 记忆提取不是存聊天记录而是榨汁直接存聊天记录是最懒但最蠢的做法。一条五万字的对话塞进数据库检索时要么搜不准要么把大量无关内容捞出来污染上下文。claude-mem 的做法是先让大模型对对话做一轮提炼把冗长的讨论压成几条精简记忆。举个例子。我在对话里跟 Claude 说以后所有数据库迁移脚本都统一放在 db/migrations 目录下命名用迁移工具生成的时间戳别再用 date 命令手动生成文件名。如果直接把这句话存进去检索时相关性还行但也存了很多无用细节。claude-mem 提炼后的记忆大概会变成项目约定数据库迁移脚本统一存放于 db/migrations命名遵循迁移工具的版本号前缀不手动生成文件名。内容更紧凑语义更明确也能跟其他记忆区分开。同样如果我在对话里说我这个项目部署到服务器后总是莫名其妙重启后来发现是内存配太小了它可能提炼成一条教训部署注意项目容易出现内存不足导致重启部署时需提高 Node 内存上限。这类项目级教训在后续会话里非常有用相当于给未来的 Claude 打了一针预防针。2.3 落地 SQLite一条记忆是怎么存下来的提炼出来的记忆会被写入 SQLite 数据库。选择 SQLite 而不是 MySQL、PostgreSQL,理由很直接它就是一个本地文件零运维备份拷贝都很方便也不需要额外起一个数据库服务。每条记忆存储的内容我理解下来大致包括几个部分记忆正文、记忆类型比如项目约定、用户偏好、事实、经验教训、创建时间和更新时间、来源会话、所属项目。此外它还会为每条记忆生成向量表示用来做语义搜索。也就是说它不光是关键词匹配还能按意思相近来检索。比如你搜部署内存问题它也能把之前那条服务器重启的记忆捞出来因为两者语义相关。这个设计对我来说最大的好处是单文件可移植。我换电脑时只需要把数据库文件拷过去之前的记忆就全跟着走了。配合网盘同步甚至能做到多设备共享记忆当然同步冲突的问题我在后面也会提到。3. 十分钟接入MCP 配置、环境变量与首次验证3.1 前提条件接入 claude-mem 之前我先确认自己的环境满足两个条件一是已经安装并正常使用 Claude Code二是本机有 Node.js 运行环境因为 claude-mem 本身是一个 Node 工具。Node 版本建议用 18 以上太老的版本跑起来会报各种奇怪的问题。我安装时用的是 npm 全局安装命令很简单npm install -g claude-mem装完之后不需要手动去启动它而是通过 MCP 配置让 Claude Code 在需要时拉起这个服务器。这里我遇到一个小问题不同版本的 Claude Code 配置 MCP 的方式略有差异有的用命令行注册有的直接改配置文件。我用的方式是命令注册一条命令就能完成claude mcp add claude-mem -- npx -y claude-mem如果你们当前的版本不支持命令行注册也可以手动在项目的.mcp.json或者全局的~/.claude.json里加配置。手动配置长这样{ mcpServers: { claude-mem: { command: npx, args: [-y, claude-mem] } } }注意具体的配置字段和版本有关如果你安装的版本跟我不一样最稳妥的做法是去项目 README 里复制官方给出的一段配置不要凭记忆手打。我在这一步卡了十分钟就是因为自己拼了一个环境变量名进去结果 claude-mem 压根没读取到。3.2 第一次验证从你好到你记住了我配置好 MCP 之后在 Claude Code 里重新打开一个会话输入斜杠命令/mcp确认claude-mem显示为 connected。这一步能看到服务器是否被正常拉起。然后我做了第一个测试直接用自然语言跟它说请记住我是这个项目的主要维护者日常使用 pnpm 作为包管理器不使用 npm 和 yarn。说这句话的时候Claude 会调用 claude-mem 提供的记忆工具把这条件写入数据库。为了验证真的存进去了我又开了一个全新会话问它关于我的项目偏好你知道什么它回了一句我记得你是项目主要维护者倾向使用 pnpm 管理依赖。那一刻我确实有点惊喜因为这是跨会话的记忆上一个对话里根本没有这条信息。如果你在/mcp看到连接正常但 Claude 不会自动调用记忆工具可以先手动触发一次记住操作让 Claude 感知到这个工具的存在。很多初次接入的人在这步卡住其实不是没接上而是 Claude 在普通对话里不会主动去想起用记忆工具需要你先给它一个信号。3.3 数据文件放哪路径管理和备份思路默认情况下claude-mem 会把数据库放在用户目录下的某个隐藏文件夹里比如~/.claude-mem/或者类似路径按项目拆分文件。我建议你不要频繁改动默认路径但一定要纳入备份体系。我现在的习惯是把整个 claude-mem 数据目录加入本地定时备份如果用的是网盘同步也可以把目录放到同步文件夹里。但这里有个隐患SQLite 数据库文件在多端同步时如果两台设备同时写入很容易出现数据库文件已锁定或者副本冲突。我目前的做法是主力开发机是本机数据库其他设备只读不同步写这样能避免大部分冲突问题。4. 日常使用让 Claude 会记、能查、也能忘4.1 触发记忆写入的三种姿势接入之后我发现写入记忆不只是被动扫描这一条路按使用习惯可以分成三种姿势。被动方式就是前面说的claude-mem 自动扫描会话日志从对话中提取记忆。这个方式适合聊着聊着聊出了重要信息的场景不需要特意打断对话节奏。但它的缺点是噪音偏多可能把不重要的内容也提炼进去。主动方式是在对话里明确下达指令这些指令会被 Claude 翻译成对记忆工具的调用。比如你可以说记住这个项目部署用 Docker端口映射规则是 8080 映射到容器内 80。请把刚才确定的接口命名规范存入记忆。以后提到这个模块的时候记得提醒我它存在技术债。这种方式最可控我强烈建议重要信息都用主动方式写入。被动扫描是兜底主动写入才是主菜。还有一种姿势是对话中自然触发。比如你说这次别再像上次那样用 Webpack 了直接上 Vite。如果 claude-mem 足够聪明它会从上下文里判断出项目已弃用 Webpack 转向 Vite值得记录。这种方式我不指望它每次都抓得准但偶尔会有惊喜。4.2 检索让旧记忆自然浮现检索是 claude-mem 最核心的使用场景。在新会话里如果你想继续之前的工作我最常用的开场白是我昨天让你重构了一下用户模块的权限逻辑今天想继续先把相关记忆找出来。Claude 会去检索记忆库把之前讨论过的技术方案、已确定的代码结构、当时的结论拉回来然后告诉你根据记忆你昨天确定了以下要点……。这个能力在我切换终端、切换设备、甚至隔了两天继续处理同一件事时都非常有用。它省掉的不只是重新交代背景的时间更避免了来回拉扯。之前没有记忆时我可能要花四五个来回让 Claude 重新理解上下文现在基本上一句话就接上了。如果你发现 Claude 没有自动检索可以更直白地提示它请使用记忆搜索功能查找关于 xx 的信息。它就会去调用检索工具。我建议在日常提示词里养成习惯比如说先回忆一下之前的决策再开始干活这样 Claude 会更自觉地使用记忆。4.3 更新与删除记忆也会写错记忆不是只进不退的claude-mem 也支持修改和删除。如果之前存的记忆过时了比如说你曾经告诉它用 Webpack 构建但后来项目迁移到了 Vite那就要主动纠正。在对话里直接说之前记录的关于项目使用 Webpack 那条记忆已经过时了改成 Vite。Claude 会调用更新工具把旧记忆替换掉。我一开始没太在意更新这个动作结果出现了很尴尬的情况项目明明已经迁移到 Vite 了Claude 还在按记忆里的 Webpack 配置给我出方案。频繁使用下来我慢慢总结出一个经验每次项目技术栈发生变化时第一件事就是去更新相关记忆不然它比没有记忆更坑。删除也是一样。当你发现记忆库里有明显错误、重复、或者非常敏感的内容时直接说删除关于 xx 的记忆或者把最近那条约 xx 的记录忘掉。claude-mem 里对应的工具会处理掉记录。删除不掉的特殊情况我遇到过比如数据库文件损坏或记录已经成了孤儿数据这种情况直接手动编辑 SQLite 文件反而是最快的方案。4.4 在提示词里约定记忆策略我强烈建议在项目的 CLAUDE.md 或系统提示词里加一小段记忆使用约定。举个例子我会在 CLAUDE.md 里写## 记忆使用规范 - 在开始任何任务前先检索本项目的记忆库了解历史决策和约定。 - 当用户给出重要项目信息时主动用记住操作写入记忆。 - 检索记忆时只返回与当前任务最相关的内容最多 5 条避免上下文堆砌。 - 如果发现记忆内容与用户当前说法矛盾优先以用户当前说法为准并提示更新记忆。这一段提示词能把 claude-mem 从被动工具变成主动工作习惯。不加这段的话Claude 只会在你明确喊它的时候才用记忆加上之后它会在任务启动时自动检索这才是最舒服的使用状态。5. 我连续用了一周踩过的坑和调优心得5.1 上下文污染记忆太多了反而坏事我最初使用 claude-mem 时被它的自动扫描能力惊艳到了于是放开让它记。结果第三天就出问题了每次新会话启动Claude 会检索出一大堆记忆塞进上下文真正跟当前任务相关的可能只有两三条其他全是边角料。这很像一个实习生第一天上班把交接日志从头到尾读了一遍结果重要信息没抓住无关信息倒是背得滚瓜烂熟。上下文是有限的塞进大量无关记忆会挤占 Claude 处理真实任务的注意力。我的解决办法有三个。第一在检索时明确限制条数比如提示词里写最多返回 3 条记忆。第二主动清理噪音记忆把明显不重要的记录删掉。第三减少自动提炼的频度不重要的会话不需要每条都存。记忆的核心价值是少而精不是大而全。5.2 多设备同步的 SQLite 写冲突如前面提到的我把 claude-mem 的数据目录放到了网盘同步文件夹里想在办公室和家里两台机器之间共享记忆。理想很丰满现实很骨感。有一次我在办公室写了一条记忆还没等网盘同步完成又在家里的机器上启动 Claude 会话结果 claude-mem 报错提示数据库被锁。后来我查了一些资料才明白SQLite 在多个进程同时写同一个文件时会出现锁竞争。网盘同步还会引入时间差可能导致文件版本冲突。现在我改成了单写多读策略只在主力开发机上允许 claude-mem 写入其他设备通过同步拿到只读副本如果需要写入我会先确认主力机已经关闭相关会话。如果你有类似场景建议参考这个思路或者干脆不要做多设备同步。记忆丢失的代价远大于少在另一台设备上调用记忆。5.3 隐私与敏感信息问题必须认真对待claude-mem 把对话信息提炼后存在本地这个本地既可以是安全垫也可能是隐患。如果你在对话里提到过 API 密钥、数据库密码、客户个人信息这些内容一旦被写进记忆库就意味着它们会以明文形式存在 SQLite 文件里。我不止一次看到有人把生产环境的密钥写进了记忆然后在分享备份或提交数据目录时把密钥一起传出去了。我的建议是涉及敏感信息的项目直接关闭自动提炼只手动记录非敏感事项。对于密钥这类东西不要记进记忆。如果你确实需要 Claude 记住某个服务的地址也请把密钥放在环境变量或专门的密钥管理工具里记忆里只写密钥通过环境变量读取。定期做记忆审计也是个好习惯我每周会翻一次记忆库把过期、无用、尤其是有敏感内容的数据清理掉。5.4 提炼和检索带来的额外成本claude-mem 的自动提炼需要调用大模型来做信息压缩这意味着它会产生额外的 token 消耗。如果你用的是 Claude Code 的 API 计费模式运行一天下来你会发现记忆相关的 token 消耗占了不小比例。一开始我没太在意后来查看账单时吓了一跳。把提炼频率降低是最直接的省钱方式。可以只在重要的会话结束后手动触发一次提炼而不是每轮对话都让它在后台跑。此外如果 claude-mem 支持配置采用更轻量的小模型来做提炼和检索我会优先选小模型让主力大模型关心理清逻辑而不是花在重复压缩文本上。5.5 什么时候应该关掉它用了两周之后我的结论是 claude-mem 并不是在所有场景下都适合开启。对于临时的一次性对话、涉密项目、高度机密的代码我会选择在项目配置中关闭它。反而是那些长期维护、需要多次会话接力的大项目特别适合开启记忆功能。我还发现与其让 claude-mem 自动记所有会话不如把它跟项目阶段绑定。项目刚起步时信息变化快我今天定的方案明天就推翻这种时候记住太多反而碍事。等项目进入稳定期再开启自动提炼记忆的价值才会真正显现出来。这些坑踩完之后我现在的用法其实收敛了很多全局记忆保留给长期个人偏好项目记忆只在项目进入稳定期后才开自动提炼平时都是手动记住/忘掉。最大的感受是claude-mem 并不能让 Claude 变聪明但它确实把我从每次开会都要重新自我介绍的循环里拉出来了。如果你也经常在多会话间切换着处理同一批代码非常值得给它半天时间试一下。