1. 这个工具到底解决什么问题Claude 的“金鱼脑”困境用过 Claude 做正经项目的人大概率都撞过同一堵墙明明是同一个主题你上周刚跟它对齐过的技术选型、写码风格、命名规范这周新开会话它一概不知。你得像第一次见面一样把背景、约束、偏好重新灌一遍。如果只是闲聊倒无所谓可一旦涉及长期维护的代码库、持续更新的写作项目、跨周的调研任务这种“零记忆”状态会把人逼疯。claude-mem就是冲着这个痛点来的。它不是一个独立聊天客户端而是一个轻量级记忆增强层跑在你本地专门给 Claude CodeAnthropic 官方的终端编程助手挂载“长期记忆”。它会把你在会话里明确交代的偏好、关键事实、项目上下文、常用命令、代码规范等自动抽取、整理、存进本地数据库并在后续会话开始时自动注入给 Claude。说人话你不需要再跟 Claude 进行“自我介绍十连问”了它自己记得。我体验下来的直观感受是它把 Claude 从一个“每次开机都失忆的外包员工”变成了一个“带工作笔记的资深同事”。不是那种玄学层面的“更像人”而是实打实减少重复沟通、避免反复踩同一个坑。这篇东西我会从项目思路、安装、原理、实际用法、坑点排查一直讲到自定义扩展全程基于我的实际使用记录涉及到版本、命令的地方会标注清楚方便你对照。适合的读者很明确已经在用 Claude Code 干活、每天开七八个会话、感觉上下文窗口不够用或重复说明太多的人。如果你只是偶尔问答一下用不上它但只要你拿 Claude 做连续性工作这东西基本属于刚需。2. 项目思路拆解为什么“上下文工程”胜过“更大窗口”2.1 记忆和长上下文的本质区别可能有人会问Claude 不是有 200K 上下文吗不够塞吗问题是塞进去不等于记得。你每天产生的工作对话、中间结果、试错过程绝大部分是噪音。把这堆噪音全塞给模型一来费 token二来模型注意力被稀释反而更容易忽略重要信息。更关键的是随着时间推移历史会话越来越多你不可能总是把“上个月定的接口规范”前置到新会话里——这不是上下文窗口大小的问题是信息组织和检索的问题。claude-mem的思路是不跟上下文窗口杠而是做“外挂记忆”。它把该长期记住的内容从会话噪音里提出来结构化地存好需要的时候才精准投喂。你可以把它理解成给 Claude 配了个备查档案柜而不是把所有文件都摊在桌面上。2.2 它抓取什么、不抓取什么拿到工具之后我重点观察了它的行为。它的核心动作不是“记录所有对话”而是从对话里抽取“值得跨会话保留的信息”。这一点非常关键直接决定了记忆系统的质量。它主要抓四类东西用户明确表达的偏好“我习惯用 2 空格缩进”“接口返回统一封装成 {code, data, msg}”项目背景事实“这个服务跑在 k8s命名空间是 app-prod”“数据库主库到从库同步延迟约 200ms”决策记录“之前因为 XXX 问题决定弃用方案 A 改用方案 B”常用术语和定义“POD 在这里指平台对象描述不是 Kubernetes Pod”。它不会抓的是一次性的计算过程、临时调试输出、视觉描述等明显没长期价值的内容。我在日志里观察过它的抽取结果整体上判断标准是合理的——虽然它不是百分之百完美偶尔也会漏掉一些我认为该记的东西但整体方向非常对。比起“全记”这种“挑着记”反而更接近人的记忆习惯记关键结论不记过程噪音。2.3 为什么选 SQLite 文件注入的方案我还专门扒过它的存储实现。claude-mem没有引入外部数据库服务直接用 SQLite 存在本地默认路径在~/.claude-mem/memory.db。这个设计很聪明不需要用户去装 PostgreSQL、开启 Redis零运维负担本地存储意味着隐私边界清晰资料不出机器单文件数据库方便备份、迁移、重置读取速度对于“注入几条记忆到上下文”这种场景完全够用。注入方式也不是什么玄学就是在 Claude Code 的会话初始化脚本里把相关记忆拼接成一段文本作为系统指令的一部分放进上下文。我看了它的源码实现本质上是读取 session 文件的内容过滤出钩子hook触发的事件然后做抽取、汇总、注入。整个链条没有调用额外模型 API纯本地文件和少量逻辑所以成本极低也没有延迟感。3. 安装与配置从零到跑通的完整流程3.1 安装前置条件你需要先确保本机满足这几个前提Node.js 16 或更高版本建议上 18实测 16 也能跑但 18 更稳已经安装 Claude Code并且claude命令能在终端直接运行MacOS / Linux 环境Windows 用户可以通过 WSL2 使用原生 PowerShell 我没试通建议别折腾。claude-mem本身是一个 npm 包安装命令很简单一条拉完npm install -g claude-mem装完后确认一下版本claude-mem --version如果没报错说明 CLI 部分已经就位。但光有 CLI 还不够因为要让 Claude 在每次会话里自动调用claude-mem还需要在 Claude Code 的配置文件里挂几个钩子hooks。3.2 配置 Claude Code 钩子Claude Code 的配置文件在~/.claude/settings.json你要做的是在hooks字段下面追加几个事件回调。我的配置大概长这样{ hooks: { PreToolUse: [ { matcher: Bash(.*claude-mem.*), hooks: [ { type: command, command: claude-mem track \$CLAUDE_PROJECT_DIR\ } ] } ], SessionStart: [ { hooks: [ { type: command, command: claude-mem summarize \$CLAUDE_PROJECT_DIR\ } ] } ], Stop: [ { hooks: [ { type: command, command: claude-mem summarize \$CLAUDE_PROJECT_DIR\ } ] } ] } }这里解释一下每个钩子的作用PreToolUse段匹配所有出现claude-mem的 Bash 命令执行claude-mem track。这其实就是监听你手动调用claude-mem的动作一旦调用就把当前会话标记为“可被记忆跟踪”。SessionStart段每次 Claude Code 新会话启动时自动执行claude-mem summarize。这个命令读取最近的记忆上下文然后把相关记忆写入一个临时文件再通过 Claude Code 的 CLAUDE.md 机制注入给新会话。这一步是“记忆回放”的核心。Stop段每次会话正常结束时做一次汇总收尾确保本轮的要点被固化下来。注意$CLAUDE_PROJECT_DIR是 Claude Code 注入的环境变量表示当前项目目录。用变量传参是为了让不同项目之间的记忆天然隔离——这一点很重要后面我会专门讲项目隔离的坑。配置好之后重启 Claude Code 让配置生效。然后你可以在新会话里先试一句请说明你从记忆文件中读取到了什么内容如果配置成功Claude 会列出一些来自历史的偏好记忆。我这边第一次跑通的时候它准确说出了“作者偏好使用 pnpm 而非 npm”这种细节我确实在三天前某个会话里提过一句。当时有点惊到感觉像是给它装了个外接大脑。3.3 项目级记忆与全局记忆的取舍claude-mem默认按项目目录隔离记忆。这个设计非常明智——你不会希望在写 React 项目的时候被 Python 项目的约定污染。但同时我也发现有些记忆其实是跨项目的比如你的通用写作风格、对代码注释的语言偏好、常用的 git 提交命名规范。它支持通过--scope参数来区分project表示项目级global表示全局级。举个例子claude-mem add 我习惯使用 Conventional Commits 规范 --scopeglobal这样这条记忆就会在任意项目里生效。而某项目特有的“跳过测试目录 t/ 的 lint”这种就老老实实只留在项目记忆里。我的建议是通用习惯、个人的工具偏好、沟通风格这类放全局技术选型、业务背景、架构决策、代码规范这类放项目。两者搭配使用既能保证跨项目的一致性又不会让记忆相互干扰。这个划分逻辑很像你平时给同事写交接文档时哪些内容放“个人说明”哪些放“项目文档”。4. 记忆系统的工作原理一次请求背后的完整链路4.1 Conversation 文件与增量分析要理解它的底层逻辑得先明白 Claude Code 的会话数据是怎么存的。Claude Code 每次对话都会在~/.claude/projects/项目名/目录下生成.jsonl文件一行一条记录会话里的用户消息、助手回复、工具调用结果等。claude-mem就是读取这些 jsonl 文件然后做增量分析。“增量”体现在哪它维护了一个processed_upto指针记录上次分析到某文件的哪一行。下次触发分析时只读新增的那部分行避免每次全量扫描。这大大降低了重复开销也让记忆更新变得实时。我实测在一个中等规模会话里触发一次summarize从读取到更新入库耗时通常不到 500 毫秒几乎无感。增量抽取的过程大致是解析每个 jsonl 条目的类型过滤掉只有图片、只有工具结果的条目对文本类条目做一个轻量判断筛掉明显属于中间步骤的内容把剩余文本做分块chunk处理每块 800~1200 字符方便后续匹配对每个分块提取关键短语用规则加简单分类的方式识别出偏好、事实、命令等类型将结果写入 SQLite带上去重标记和时间戳。这里不依赖大模型 API纯本地规则抽取这既是优点也是局限。优点是快、零成本、隐私安全缺点是提取质量不如大模型语义分析的那种精细度。不过实测下来对于“偏好类”“固定事实类”内容它的规则引擎效果出奇地好可能因为这些内容往往带有明显的句式特征比如“我喜欢”“我通常”“记住”等。4.2 记忆摘要和注入回放机制说回claude-mem summarize命令它的执行链路是这样的读取该项目的全部记忆条目按时间衰减计算相关度最近使用的记忆权重更高从全部记忆里筛选出“当前最值得回放”的前 N 条默认 30 条可通过--max-context-items调整把筛选结果拼成一段结构化的文本写入CLAUDE.md的自动生成区域。CLAUDE.md是 Claude Code 的“项目笔记”文件位置一般在项目根目录。Claude Code 在每次会话开始时会自动读取这个文件的内容将其作为系统提示语的一部分。claude-mem就是借这个机制把自己整理好的记忆“塞进”Claude 的眼前。我扒了下生成的CLAUDE.md结构大概是这样# 自动记忆上下文 ## 最近项目状态 - 项目名my-blog - 技术栈Astro TailwindCSS - 当前主要在改 /src/layouts/BaseLayout.astro 的响应式样式 ## 用户偏好 - 使用 pnpm不用 npm - 提交信息遵循 Conventional Commits - 组件注释用中文代码注释用英文 ## 关键决策 - 图片统一走 /public/images不用外部图床 - 主题色使用 CSS 变量待切换暗色模式 ## 待办事项 - 文章列表页分页逻辑还没做这个格式很清楚Claude 一眼就能读懂。而且因为写在CLAUDE.md里你完全可以手动编辑它加内容这些手动内容会与自动记忆共存。我经常在里面加一些临时备忘双方互不干扰很好用。4.3 为什么“只注入摘要”而不是“注入全部记忆”一个自然而然的问题为什么不把全部记忆都塞给 Claude答案一是 token 预算二是注意力失焦。想象一下如果库里积累了一千条记忆全部注入上下文且不说 token 成本爆炸Claude 在处理当前任务时会被大量无关历史干扰。claude-mem的解决方式是通过“相关性排序 截断”。它的排序参考了几个信号记忆条目被引用的频率引用越多说明越重要最近一次更新时间最近越近越可能相关是否匹配当前项目的关键词从$CLAUDE_PROJECT_DIR提取。最终只有得分最高的 30 条会被注入。我在使用中确实感受到了这种“克制”带来的好处——Claude 不会像背课文一样把所有历史细节都倒给你而是只提供当下的决策上下文。换句话说它在“记忆力”和“专注力”之间取了平衡点。你可能还会关心那些没被注入的记忆是不是等于没用不是。它们仍然存在 SQLite 里在你明确通过claude-mem search 接口规范这样的命令搜索时可以随时被翻出来。这是“外挂记忆”和“工作记忆”的配合默认只给 Claude 带一页翻开的笔记但更多笔记就在抽屉里想查随时抽。5. 实操演示用 30 分钟搭建一个带记忆的 Claude 工作流5.1 场景准备我选择了一个小项目做实验光说不练假把式。我拿自己的一个实际项目做测试一个基于 Hugo 的静态博客里面有几十篇文章最近正在重构导航栏。为了模拟真实使用场景我人为在里面“忘记”告诉 Claude 项目的关键偏好然后观察它能否通过记忆找回。项目目录大概是这样my-hugo-blog/ ├── content/ │ ├── posts/ │ └── about.md ├── layouts/ │ ├── index.html │ └── partials/ │ └── nav.html ├── assets/ │ └── css/ ├── config.toml └── CLAUDE.md - 工具自动生成5.2 从零开始安装、配置到首次对话第一步安装并验证npm i -g claude-mem claude-mem --version # 输出0.x.x第二步配置 hooks配置文件略和上面一致然后重启终端确保 Claude Code 能读取到新的 settings.json。这点容易踩坑——如果你已经在运行 Claude Code修改 settings.json 后并不会热生效必须完全退出会话重开。第三步给这个项目写两条初始记忆模拟“用户历史上提过但当前会话不存在”的信息claude-mem add 博客使用 Hugo 框架文章源文件为 Markdown。 claude-mem add 导航栏目前结构首页、关于、归档暂无分类页。 --scopeproject然后启动 Claude Code输入一个压根没在当前会话里交代过的需求帮我检查导航栏代码顺便看看“归档”链接指向哪里。因为它通过SessionStart钩子已经把记忆注入了CLAUDE.md所以哪怕这是一个全新会话Claude 也知道这是 Hugo 项目、知道导航栏包含哪些项。实际输出的回答里直接引用了layouts/partials/nav.html路径还说“按照项目的 Hugo 约定归档链接应该指向/archives/”。这些信息我压根没在本次会话提过说明记忆注入确实生效了。5.3 会话过程中的记忆自动追记光有初始记忆还不够很多关键信息是在聊天过程中临时冒出来的。比如我让 Claude 把导航栏的“归档”改成“作品”并随口说了一句“顺便把站点标题改成『荒岛上的代码』”。这两个需求第二个并没有直接对应某个命令而是一个“偏好级”信息。会话结束后Stop钩子自动调用summarize。我再查看记忆库claude-mem list输出里多了一条站点标题改为「荒岛上的代码」。这个追记得相当聪明它判断出这是一个跨会话有效的偏好设置不是临时修改。更有意思的是下一次会话我直接说“把标题再换一个风格”Claude 记得原来的标题是「荒岛上的代码」并且主动问我“是想围绕这个意象继续发挥还是完全换赛道”这说明它不光是机械存储还把这个偏好用上了。5.4 手动搜索把“抽屉里的记忆”翻出来有时候你要找一条记忆但这条记忆不够“当前相关”没有被注入摘要。没关系用claude-mem search直接在库里检索claude-mem search 导航分类输出会列出包含关键词的记忆条目以及命中时间。这个命令适合一种场景你跟 Claude 聊着聊着突然觉得“它是不是忘了我们之前讨论过的某件事”于是主动搜索然后直接把结果贴给它。另外还有个命令是claude-mem stats能看当前库的规模claude-mem stats它显示总条目数、项目数、最近更新频率等信息用来判断记忆库有没有失控增长。我追踪了几天发现平均每个项目每天会新增 5~15 条记忆属于正常范围。5.5 工作流串起来的完整视角整套配置完以后你实际面对的是一个闭环SessionStart昨天沉淀的记忆自动注入新会话对话过程中产生的关键事实和偏好被临时记录Stop会话结束时把新信息正式入库下一次SessionStart更新的记忆再次注入。循环往复Claude 的记忆会随着使用次数越来越“懂你”。它不是一次性把内存条插满而是像人一样一点点积累工作默契。这种渐进式增强正是这个工具最迷人的地方。6. 常见坑点与排查实录我踩过的问题提前帮你避掉6.1 为什么没有生成 CLAUDE.md很多人在配置完 hooks 后发现项目根目录根本没有CLAUDE.md记忆注入自然也没生效。这个问题我第一次也遇到了排查过程如下先手动执行一次claude-mem summarize $CLAUDE_PROJECT_DIR看有没有报错。实际上$CLAUDE_PROJECT_DIR在终端里不会被展开所以我在手动执行时直接写了实际路径。如果报错提到“project dir not found”说明环境变量没传对。在 Claude Code 的 hook 配置里$CLAUDE_PROJECT_DIR是可以直接用的占位符但前提是你的 Claude Code 版本足够新0.5.0 以上。老版本没有这个变量。如果你是 mac 用户还要注意~/.claude/settings.json的文件路径有没有写对。Claude Code 的配置目录可能因安装方式不同而有差异我见过有的人是~/.claude有的人是项目下的.claude。解决方案把 hooks 里的命令改成直接指定项目路径不推荐因为写死路径不方便多项目或者更稳妥地把summarize的调用时机放到项目根目录执行。在 Claude Code 启动的前置命令里可以用pwd获取当前目录传给claude-mem。{ hooks: { SessionStart: [ { hooks: [ { type: command, command: pwd | xargs claude-mem summarize } ] } ] } }我实际用的就是这个方案绕开了环境变量版本问题稳定运行至今。6.2 记忆重复、陈旧与“幻觉记忆”问题用了一周之后我发现库里有几条明显重复的记忆比如“先 pnpm install 再跑 dev server”这种偏好被记了三条。为什么会重复因为不同会话里提到类似表述时规则引擎无法完全判定语义等价去重只做了文本层面的精确匹配。问题的直接后果是注入摘要的时候三条重复表达会占掉两个名额还容易给 Claude 造成困扰虽然不影响大方向但确实浪费 token。我的处理办法是定期清理claude-mem prune --dry-runprune命令会识别并删除重复条目--dry-run先看会删哪些心里有数再真删。我也建议每隔一两周手动检查一遍claude-mem list把过时的、已经失效的记忆手动删除claude-mem remove entry_id陈旧记忆更隐蔽。比如某项目曾经从 REST API 切换到了 GraphQL但旧记忆里还留着“接口请求走 REST”。如果这条记忆没有被新记忆覆盖万一被注入到新会话Claude 可能基于错误前提给建议。我踩过真坑有次它给我写的 fetch 代码还是.json解析老接口就是因为记忆库里残留了一条旧 API 约定。所以我的教训是出现重大架构变化时主动把相关旧记忆删掉。你可以用search定位然后批量删除不要依赖工具自动清理。工具的自动化能帮你处理简单重复但真正的语义级“忘掉不该记的”还是得人眼把关。6.3 多项目记忆串味与隐私保护记忆按项目目录隔离后理论上互不干扰。但有一种情况会串味你用了全局作用域--scopeglobal存了某项目专属偏好。例如我在全局里存过“数据库连接串指向本地 laptop”后来在另一个项目会话里Claude 也把这个连接串当成了上下文。虽然没造成事故但明显不合适。建议严格遵守项目专属信息一律用--scopeproject默认也是 project只有通用个人习惯才用 global。另外每次添加全局记忆前先想一下“我在另一个完全不相关的项目里希望它知道这件事吗”隐私方面所有记忆都存在本地 SQLite不上传任何云端。这是它的优点。但我也提醒一下如果你的电脑里有多用户默认的~/.claude-mem目录权限是当前用户可读写其他用户是不可读的。如果你想更保险可以目录加一层加密用 macOS FileVault 或 Linux 的加密目录毕竟记忆比普通聊天记录更能还原你的工作习惯和决策模式。6.4 hooks 死循环与性能拖累有个比较隐蔽的问题如果你在PreToolUse里监听所有 Bash且匹配规则写得过宽松可能会出现死循环。比如claude-mem track命令本身内部可能会触发 hook 事件然后再次匹配、再次执行。我遇到过一次终端里刷了十几行claude-mem的输出Claude Code 直接卡住了几秒。排查思路是看日志。claude-mem的日志在~/.claude-mem/logs/下面滚动查看最新日志如果发现同一命令重复执行就是 hook 匹配写得太宽了。我的解决方式是收紧 matcher把触发条件限定为matcher: Bash\\(.*claude-mem track.*\\)只匹配带有明确参数的命令行避免 hook 自我触发。性能方面claude-mem本身很快但SessionStart时如果记忆库特别大几千条summarize可能要花 1~2 秒。注意这 1~2 秒发生在会话初始化阶段不会影响打字交互。如果实在觉得慢可以用--max-context-items 15把注入量改小或者定期prune控制库规模。6.5 删除、备份与迁移的完整指引你可能需要把记忆从一台电脑迁到另一台或者重装系统前做备份。不要把~/.claude-mem直接删了才想起没备份。最稳妥的方式是cp ~/.claude-mem/memory.db ~/memory_backup.db恢复也很简单放回原路径就行。如果目录不存在先创建mkdir -p ~/.claude-mem cp ~/memory_backup.db ~/.claude-mem/memory.db还有更灵活的方式claude-mem export可以导出 JSON 格式适合做内容级迁移或自己写脚本处理claude-mem export memories.json导入就用claude-mem import memories.json。这个功能我还没在换机场景用过但看源码实现是稳妥的。如果你跨设备协作建议把memory.db放到云盘同步目录或者干脆纳入 git 仓库用私有 repo 托管注意别泄露敏感信息。7. 进阶玩法让记忆系统贴合自己的使用习惯7.1 自定义记忆条目结构从“散装笔记”到“卡片化”默认情况下claude-mem add存的是自由文本。用了一阵子我发现如果所有记忆都只是一句句话后续 Claude 在注入时会失去结构化优势。比如你希望它记住数据库连接信息那就不能散着写“数据库密码是 XXX”而应该用结构化一点的形式claude-mem add 数据库配置hostlocalhost, port5432, dbnameblog, useradmin, passwordxxx --tagsdb,config用--tags打上标签后续检索时可以按标签过滤claude-mem list --tagsdb这个功能很适合维护一组固定的“配置型记忆”。我目前的做法是把项目里的固定不变量如端口号、测试账号、CI 流程入口全部用标签归档这样即使它们没有被注入新会话也能通过一条简单的搜索指令快速找回。7.2 把记忆导出成文本自己用其他模型再加工claude-mem export导出的 JSON 可以做很多事。我自己写了个小脚本每周自动导出记忆库然后用本地大模型做一次“记忆质量周报”让它找出哪些记忆明显过时、哪些重复、哪些表述不清。相当于多了一道 AI 巡检。这个想法完全基于一个事实记忆库是你的第二个大脑对它定期做“复盘”非常值钱。示例脚本Python可以这样写import json from collections import Counter with open(memories.json) as f: memories json.load(f) # 按项目统计记忆数量 counter Counter(m[project] for m in memories[items]) for project, count in counter.most_common(): print(f{project}: {count} 条)这不算什么复杂工程但能让你直观看到记忆分布——你会在哪些项目上产生最多“值得记”的信息某种意义上也是工作重心分布的一种映射。7.3 多Agent协作下的记忆共享策略如果你和我一样同时用 Claude Code 处理多个角色有时是写代码的有时是审代码的有时是写文档的你会发现用不同角色跑同一项目时需要的记忆侧重点不同。claude-mem目前没有原生角色隔离但我发现可以利用全局记忆配合“前缀”来实现轻量隔离。例如在全局记忆里存两条“写代码模式偏好简洁实现、少依赖、命名用 camelCase。”“写文档模式偏好详尽的示例、段落前加摘要、用中文写作。”因为CLAUDE.md注入时是全量注入的两条都会生效但在实际对话里Claude 会根据你当前的任务语境选择更适用的那条。这个方案不算完美但胜在简单不用改工具。如果你的需求更复杂可以 fork 一份改造成“记忆域domain”模式把记忆按role字段过滤后注入——我在源码里看到插件体系预留了扩展位理论上可行。7.4 自定义 Prompt控制记忆注入的语气与格式默认claude-mem生成的摘要段落是固定的“项目名 用户偏好 关键决策”结构。想要改变格式可以从源码入手——这是开源项目的好处。src/prompts.ts里面有模板你可以修改后编译把记忆输出成更适合自己习惯的形态。比如我把默认模板改成了一种“假设你是刚接手项目的同事以下是交接笔记”的引导语。这样 Claude 在读取记忆时会主动代入“新成员熟悉项目”的模式而不是把记忆当作必须严格执行的规则。这个变化在处理一些模糊性偏好时特别有用因为 Claude 会更倾向于“参照历史偏好 结合当下情况”而不至于死板。改完源码后重新编译npm run build其实不用重新安装直接用 build 之后的dist目录运行node dist/index.js也可以。但如果你用的是全局安装的 npm 包最好重新npm link一下让claude-mem命令指向本地 build 产物。8. 这套方案还能怎么演从增强记忆到构建个人上下文claude-mem到现在已经不只是个给 Claude 用的记忆工具了。我越用越觉得它真正提供的是一个“个人上下文的本地基础设施”。你在这个项目里沉淀的每一个偏好、每一个决策、每一个项目事实其实都是在构建一份可迁移的“数字工作记忆”。哪怕是换一个模型比如未来用其他 AI 工具只要这些记忆还在迁移成本就很低。从这个角度看我建议使用者在记录时稍微“通用化”一点不要把每一条记忆都写得绑定死 Claude 的指令格式。比如“提交信息遵循 Conventional Commits”这种就足够通用“记住用 claude-mem log 查看日志”这种绑定工具的就没什么长期价值。记录的本质是“这个世界是什么样、我希望怎么工作”而不是“那个 AI 应该执行什么命令”。最后再分享一个我一直在用的小技巧每周抽五分钟claude-mem export导出全量记忆然后删掉记忆库重建再只导入那些“你希望永远被记住的”条目。这个过程很像定期整理工作笔记——它筛选掉的不是数据而是噪音。整理完你会明显感觉到Claude 在新会话里的反应更干净了因为它只记住了真正值得记的东西。这个习惯我坚持了三周效果非常好你可以试试。