很多人第一次看到 claude-mem 这个项目名第一反应大概是这不就是给 Claude 加一个“记忆仓库”吗等真正翻代码、自己跑过一遍之后你会发现它做的事情比“记住聊天记录”要实在得多——它解决的是 Claude Code 这一类编码代理最让人抓狂的问题每开一个新会话之前聊过的技术方案、踩过的坑、定下的约定全都等于不存在。这篇文章就围绕 claude-mem 这个记忆层工具把它的设计思路、核心机制、实操过程和我自己踩过的坑完整拆一遍给打算给自己的 AI 编程流程加持久记忆的人一个可以直接照做的参考。关注 claude-mem 的主要是两类人一类是被“AI 编码搭子失忆”逼疯的独立开发者每天在多个项目间切换每次都要重新交代背景另一类是想自己动手给 Claude 定制上下文的小团队他们不满足于官方那点有限的上下文窗口想要一个能跨会话、跨项目沉淀经验的记忆系统。如果你也属于这两类人这篇内容会帮你少走不少弯路。1. 先说清楚 claude-mem 是什么1.1 一句话定义给 Claude Code 装一块长期记忆claude-mem 本质上是一个本地优先的会话记忆层它的目标不是做成一个聊天记录查看器而是充当 Claude 会话之间的“第二大脑”。你在一个会话里讨论出某个模块该用哪种设计模式下次新开一个会话它还能自动把这条结论捞出来塞进新的上下文里让 AI 接着上次的思路继续干活而不是从零开始。我自己的理解是它和官方 Anthropic 提供的记忆功能是两种路线。官方是平台级别的“记忆”走的是账号体系服务端存储你不太能控制它到底记了什么而 claude-mem 是项目级别的本地工具所有数据都以文件形式落在你自己的机器上记录什么、什么时候注入、注入多少你都能通过配置干预。对做工程的人来讲这种可观测、可控制、可备份的状态心理上更有底。这个项目直接面向的使用场景有两个一是日常用 Claude Code 写代码时跨会话保持上下文连续性二是做批量任务时比如让 AI 处理几十个文件的重构每个文件都开新会话去处理但要求每个会话都遵守同一个约束规范。没有记忆层的话这些约束就得写成长篇大论的 system prompt或者反复粘贴有了 claude-mem约束可以直接作为历史记忆被自动检索到新会话不用你反复交代。1.2 它不是“对话记录导出工具”很多人在刚接触 claude-mem 时会掉进一个思维误区觉得它的核心功能就是“把过往的对话历史整理出来给 AI 看”。如果只是这么简单那直接写个脚本把 JSONL 日志读出来拼到 prompt 里就够了根本不需要单独一个工具。claude-mem 和其他“日志拼接工具”最本质的区别在于它做了语义化的取舍。它会分析一段对话把其中真正有长期价值的信息提炼出来比如用户的技术偏好、项目架构决策、反复出现的错误类型、某些模块的实现约束然后形成一条条结构化的“记忆单元”。这个过程里面有删除、有压缩、有抽象不是把所有原文搬过来。另外一个区别是它会在会话启动之前主动做检索而不是把全部历史一股脑塞进去。也就是说它有一套相似度打分机制根据当前要处理的任务主题只挑相关性最高的那部分记忆。这样既不会撑爆上下文窗口也不会让 AI 被无关的旧信息带偏。日志导出是“全部给到”claude-mem 是“按需召回”这两者从设计目标上就不是一回事。1.3 解决了什么实际痛点我自己有一个特别典型的经历。做一个内部工具项目时上一轮会话里我花了快四十分钟和 Claude Code 敲定了一个关于异步任务队列的幂等方案包括表结构怎么设计、消费者怎么去重、失败重试的退避策略。结果第二天新开会话它完全不记得这些讨论又给我提了一个完全不同的方案。不是那个方案不好而是我很确定昨天已经往那个方向踩过坑了今天又要重新吵一遍这种感觉特别透支。这种“反复交代背景费”在多个项目并行的时候尤其明显。你不可能给每个项目写一份独立的长期 system note又不可能在每次新会话开头都粘贴一大堆之前的结论。claude-mem 的价值就在于它把散落在各个会话日志里的那些结论自动沉淀下来并且在你最需要的时候把它带回来。它适合的人群也很明确高频使用 Claude Code、经常并行推进多个项目、想让 AI 交付结果保持一致性的工程师。反过来如果你只是偶尔用一下 AI 聊天、碰不到需要长期维护的技术背景那这个工具带给你的额外负担可能会超过收益。它终究是一个需要维护、清理和调参的工具不是装上就一劳永逸的银弹。2. 项目核心设计拆解一条从记录到记忆的管线想知道 claude-mem 为什么能“记住”关键在于看它内部怎么处理数据。整体可以拆成四个阶段读日志、切记忆、做向量化、注入上下文。这一节把这四个环节逐个过一遍每个环节的取舍我都会说明为什么这么做。2.1 数据入口读取会话日志第一件事是搞到原始数据。Claude Code 在运行过程中会把每次会话的完整信息以 JSONL 格式落到本地其中大概包括消息类型、角色、内容文本、工具调用结果、时间戳这些字段。claude-mem 要做的第一步就是扫描这些会话日志把内容解析出来。这里有个细节会话日志是多行 JSONL不是纯文本所以解析时不能直接按字符串拼接。你需要分清哪个是用户消息、哪个是 AI 回复、哪个是工具执行的结果因为不同角色在不同场景下产生的信息价值完全不同。比如用户明确说“不要用 xxx 方案”这是一条高权重偏好而 AI 回复里的某个代码片段往往是过程性信息不太值得原样保留。在这个阶段工具还会做初步过滤把明显的噪音去掉。比如“继续”、“对”、“好的”这类无信息量的短消息不会有任何沉淀价值又比如某些工具报错但随后又自动恢复了这种临时性故障也不值得长期记忆。这些过滤规则如果只靠正则去匹配会很粗糙所以好的实现通常会结合消息长度、句法特征、前后文关联来判断。这一步做完得到的是一个“可以被进一步提炼的候选语料集”。2.2 记忆切分把“流水账”变成“要点”拿到原始语料之后下一步最核心把连续的对话切分成离散的记忆单元。为什么一定要切分因为对话本身是流式的一条结论往往分散在好几轮消息里。比如用户先说“我们考虑用 Redis 做限流”AI 问了一些细节用户又补充“但是单机版就行不需要集群”最后 AI 总结“那采用单机 Redis 加令牌桶”。这四轮消息连在一起才形成了一条完整的信息单看任何一句都是有缺失的。claude-mem 的做法是先用一定窗口把相关轮次聚合起来再通过提炼模型对这段聚合内容做总结抽取出一个带主题、带结论、带上下文的信息单元。这个单元的结构通常类似在什么场景下我们做了什么决定为什么这么选有什么副作用或注意点。切分粒度是个需要权衡的问题。粒度太细比如把每一轮都存下来会造成记忆碎片化检索到的是一条条残缺的信息粒度太粗比如按整个会话来存会导致单条记忆的 token 数量过大注入时很快就把上下文塞满。实践中合理的粒度是“一个完整讨论主题”作为一个单元大概对应一次持续几分钟的聚焦对话。实现时可以用时间间隔结合主题向量变化来做切分而不是单纯按条数切。2.3 向量化存储让记忆可以“被搜到”切分好的记忆单元还不能直接塞进文件里就完事因为将来要做的是语义检索——用户的新任务可能话术上跟历史记忆完全不同但语义上是同一件事。比如历史记忆写的是“订单超时关单”新任务是“处理支付后未回调的订单”这两句话没有太多共同关键词但本质上高度相关。关键词匹配在这里会失效所以必须做向量化。向量化就是把一段文字映射成一个高维度的数字向量语义相近的文本在向量空间里距离更近。claude-mem 在存储时会为每条记忆生成一个嵌入向量连同原文、元信息、时间戳、所属项目一起写入本地存储。本地存储选什么这是一个工程上的取舍。有的实现选 SQLite 加向量扩展有的实现选单独的向量数据库比如 Chroma 或 LanceDB。如果让我选我倾向本地优先、单文件、免服务的方案。理由是这类工具的核心价值是低摩擦如果跑起来还需要外挂一个数据库服务增加的不只是安装步骤还有运营成本。实测下来项目级数据量下 SQLite 的向量检索性能完全够用没必要上重武器。2.4 上下文注入把记忆送回对话最后一步是把检索到的记忆注入到当前会话中。这一步也有两种做法一种是在会话启动前通过 hook 把检索结果注入到系统提示词或者第一条用户消息里另一种是作为一个额外的上下文模块在每次对话时动态调用检索接口把结果附带进去。前一种更轻量也更容易控制。新会话启动时claude-mem 拿到当前的任务描述先做一次向量检索取回 topK 条相关记忆把它们组织成一个固定的提示块拼在 Claude Code 初始化上下文里。这样相当于在会话开始那一刻AI 就带上了之前讨论过的相关背景后面整个会话过程中的所有回复都会基于这套背景来展开。注入的内容格式很关键。不能直接把记忆原文堆在一起最好以“历史经验参考”的形式呈现并且标注每条记忆的摘要和来源时间让 AI 知道这是从历史会话中检索出来的参考信息而不是用户当下的新指令。否则模型可能混淆哪些是当前要执行的任务哪些仅仅是参考背景。这一点在做工程化时要特别注意。2.5 为什么用“语义检索”而不是“关键词过滤”这是 claude-mem 设计里一个很值得展开的地方。关键词过滤的问题再明显不过它的召回率太低而且极度依赖用户描述和历史记忆之间的字面重合。实际上做技术讨论时同一个问题在不同时间点会有完全不同的表述方式。今天聊“怎么缓存 MySQL 查询结果”明天变成“接口响应太慢怎么优化”这俩在字面上几乎没有交集但在任务目标上高度一致。如果靠关键词这条记忆就永远捞不回来。向量检索不只是解决“换个说法找不到的问题”它还能在一定程度上容忍噪声和错误拼写。因为向量表示学习的是语义空间中的位置关系个别字词的差异不会让整个向量发生剧烈偏移。这一点在中文场景里特别实用因为中文表达的同义改写比英文更灵活。踩过坑之后我的体会是对这类工具来说召回能力比精确匹配重要得多宁可捞回几条不相关的也不能让真正有价值的记忆漏掉。2.6 一条重要的取舍路径精简 token 还是保留细节做记忆层项目时必须直面一个矛盾如果记忆太精简可能丢失关键细节如果记忆太完整注入时又会占掉大量上下文空间。claude-mem 在这个问题上给的方案是分两个层级处理而不是二选一。第一层是每个记忆单元在存储时已经做过一次提炼保留的是“结论和核心理由”不是完整对话原文。第二层是注入时还会做一次动态裁剪根据当前上下文的剩余 token 空间决定到底带多少条记忆进来。这个设计很聪明它让记忆系统具备了弹性上下文宽裕的时候多带几条让 AI 有更充分的背景上下文紧张的时候少带几条优先保证当前任务的指令空间。实际用下来这种“宁可少带也要保证任务执行质量”的思路是对的因为记忆起的是辅佐作用不能喧宾夺主。3. 实操上手安装、配置、让它跑起来3.1 安装与初始化claude-mem 这类工具目前大多还处于快速迭代阶段安装方式因项目而异但通常绕不开这三条路npm 全局包、克隆仓库本地构建、或者通过安装脚本直接下载二进制。以 npm 方式为例一条命令就能装上npm install -g claude-mem装完之后先执行初始化命令这个命令负责创建配置目录、初始化存储文件并且扫描一遍本机已有的 Claude Code 会话日志。claude-mem init初始化过程会询问几个问题包括默认的嵌入模型、存储路径、要扫描的项目范围。我的建议是第一次先全部默认跑通了再慢慢调。千万别一上来就折腾复杂配置因为第一次扫描可能会花一些时间如果中途因为配置报错中断排查起来反而麻烦。先把最基本的链路跑通看到自己能搜到第一条记忆后面再优化就顺了。3.2 首次扫描历史记录初始化完成后真正把历史会话日志变成记忆库的是 scan 操作。这条命令会扫描你的历史会话目录解析内容提炼记忆单元并生成向量索引claude-mem scan --all第一次跑的时候建议盯着输出看重点关注它扫到了多少个会话、过滤掉了多少条消息、最后生成了多少条记忆。这个数字比例很能说明问题。如果会话很多但记忆寥寥可能是过滤规则太激进如果每条消息都被无脑存下来了那后面检索时噪音会非常大。基准值我自己一般是大约三分之一的会话内容能沉淀为有长期价值的记忆其余都是过程性信息。扫描完成后可以用一个简单的搜索命令来验证效果claude-mem search 数据库连接池配置这一步建议用多种不同的说法去搜同一条记忆比如换个词、换个角度看看能不能召回。如果召回结果稳定说明向量化效果好如果换一种说法就搜不到那就要检查嵌入模型的选择是否匹配你的使用场景尤其是中文场景往往要换中文友好的模型。3.3 给新会话装记忆 Hooks扫描是让旧数据变成记忆而注入是让新会话能用上这份记忆。这一步才是让 claude-mem 真正“融入工作流”的关键。在 Claude Code 里一般是配置 hooks也就是事件驱动脚本。你可以设置一个会话启动时的 hook在每次新会话创建之后、发送第一条消息之前触发 claude-mem 的注入命令。配置项大致长这样{ hooks: { SessionStart: [ { matcher: start, hooks: [ { type: command, command: claude-mem inject --context-file .claude-mem/current-task.md } ] } ] } }这里的核心逻辑是先把当前任务背景写到一个临时文件里让 claude-mem 基于这段背景做检索再把检索到的记忆作为初始化上下文注入。需要留意的是 hook 的执行上下文不一定和你的终端工作目录一致路径要用绝对路径或者基于 home 目录的展开路径这是最常踩的坑之一。3.4 关键配置项解析claude-mem 的配置集中在少数几个参数上把参数背后原理搞清楚调参会变得非常快。下面是几个最核心的配置项# 嵌入模型 claude-mem config set embedding.model text-embedding-3-small # 存储目录 claude-mem config set storage.path ~/.claude-mem # 每次注入时最多检索几条记忆 claude-mem config set retrieve.topK 5 # 相关性阈值低于该值的记忆不注入 claude-mem config set retrieve.threshold 0.65 # 是否压缩注入记忆的细节 claude-mem config set retrieve.summarize true其中topK和threshold是影响使用体验最明显的一对参数。topK 决定最多带多少条threshold 决定最低要有多相关才带。两者配合起来既能保证上下文不会被垃圾塞爆又能保证高相关的记忆一个不漏。如果当前任务的主题特别明确比如“只处理前端样式调整”但历史记忆里全是后端架构讨论检索出的相关性普遍偏低这时 threshold 应该提高避免无关记忆干扰。反过来如果是综合性重构任务背景本身就很杂那么 threshold 可以适当放宽让 AI 多接触一些不同方向的记忆。这就是为什么记忆工具不能做成一把通用标尺参数必须跟着任务类型走。4. 实操过程与核心环节实现4.1 单条记忆长什么样先看一条从实际会话里提炼出来的记忆长什么样这会帮助你理解后面所有配置的意义。假设历史上有一段关于“异步任务幂等”的讨论claude-mem 提炼出来的记忆单元可能是这样的 JSON{ id: mem_8f3a2b, project: order-scheduler, title: 订单关单异步任务幂等方案, summary: 订单超时关单采用 Redis SETNX 加任务表状态字段双重保证消费者侧通过 task_id 去重失败重试采用指数退避最多 5 次, keywords: [幂等, Redis, 关单, 重试, SETNX], decision: 采用业务表状态 Redis 锁双重机制而不是单纯依赖 Redis SETNX, reason: Redis 锁可能过期导致重复执行业务表状态可作为兜底, caution: 重试时注意退避时间要大于 Redis 锁过期时间, created_at: 2025-06-20T10:23:00Z, source_session: sess_9f2e01 }注意看它的结构不是简单存一段话而是把结论、理由、注意事项分成了不同字段。这样在注入到上下文时AI 可以很清晰地理解这只是一条经验参考而且能区分核心结论和支撑理由。特别是caution字段保存的是当时讨论中发现的边界情况这种东西在实际开发里比结论本身更值钱。如果你的实现里没有这种结构化字段只是把段落文本原样存储那注入效果会打折扣。原因是模型的注意力会被长篇文本分散而结构化字段让它能够快速锁定“关键结论”和“要小心什么”相当于给模型做了一次重点标注。4.2 注入到 Prompt 的实际效果配置好 hook 之后新会话启动时模型看到的上下文里会多出这样一段内容memories 以下是历史会话中与该任务相关的经验总结仅作背景参考 1. [订单关单异步任务幂等方案] 订单超时关单采用 Redis SETNX 加任务表状态字段双重保证消费者通过 task_id 去重。注意重试退避时间应大于 Redis 锁过期时间。(2025-06-20) 2. [排队任务消费失败处理] 消费者失败时不要立刻丢弃消息先进入本地 retry topic按 2s/8s/32s 退避。 /memories这段内容会让 AI 在后续所有回复里都带上这两个约束。实测下来最明显的变化是 AI 不再提出已经被否决的方案。以前它可能会再次建议“用 Redis 锁解决重复消费”但它现在记得这次讨论已经决定“Redis 锁 业务表双保险”所以给出的方案会直接跳到最后讨论的结论上继续优化。这不只是省了重复沟通还意味着后续每次迭代都是在一个已收敛的方向上继续而不是反复横跳。同样的效果也体现在风格一致性上。如果你平时会在对话里反复要求“日志格式用 JSON字段名用 snake_case”这些偏好一旦被沉淀成记忆新会话里不需要重新强调AI 也会自动按这个风格走。这比写 system prompt 更自然因为 spec prompt 是固定的而记忆是动态从历史中提取的更贴合项目当前状态。4.3 参数计算示例topK 和阈值怎么定参数不是拍脑袋定的要用数据说话。假设你有 800 条记忆每次新会话任务描述的嵌入向量会和这 800 条逐一计算相似度得到一个分布。你需要先跑一次搜索把所有相似度分数倒序排出来看分布情况claude-mem search 订单超时处理 --verbose --show-scores输出大致会是这样score0.91: 订单关单异步任务幂等方案 score0.84: 订单状态流转字段说明 score0.77: 超时任务扫描频率调整 score0.63: 前端订单列表刷新逻辑 score0.52: 数据库归档策略这个分布消息量很大。从 0.91 到 0.77这几条明显都是和当前任务正相关的应该注入0.63 那条已经明显偏题属于搭点边但不一定有用的0.52 以下的几乎可以断定是噪音。这种情况下threshold 设 0.7 左右是合理的topK 设 4 或 5 就够。如果你的分布整体偏低最高分才 0.6 左右那不一定是你存储的问题而是任务类型本身太冷门历史里没积累过相关内容。这时硬调低 threshold 也没什么意义拉进来的全是不相关记忆反而让 AI 分心。正确的做法是接受“目前没有可用的记忆”把精力放在积累新的历史会话上。记忆库这东西本质上需要时间发酵不是配置能替代的。4.4 多项目隔离的目录规划如果你同时在维护好几个项目记忆绝对不应该全局混在一起。不同项目的技术栈、业务背景、执行约定完全不同混在一起会导致极其荒谬的上下文污染。比如你在这边聊 Go 服务的高并发调优那边的前端项目记忆被检索出来AI 突然关注起按钮交互来整个回复都会跑偏。claude-mem 支持按项目隔离存储这是非常必要的设计。我自己的规划方式是~/.claude-mem/ ├── projects/ │ ├── order-scheduler/ │ │ ├── memories.sqlite │ │ └── config.toml │ ├── internal-tool-frontend/ │ │ ├── memories.sqlite │ │ └── config.toml │ └──>claude-mem inject --project order-scheduler这个做法的额外好处是单个项目的记忆库体积不会无限膨胀检索性能也能维持在一个稳定水平。SQLite 在单项目几千条记忆的规模下响应依然是毫秒级的完全感受不到延迟。5. 常见问题与排查实录5.1 最常见的 5 个坑这个工具看起来简单实际操作中能踩的坑不少。我把最典型的几类问题整理成表格你自己排查时对照着看现象原因快速排查解决办法hook 不起作用新会话没有任何注入内容相对路径失效或命令不存在检查绝对路径、手动执行一次注入命令一律用绝对路径并把 claude-mem 命令放到 shell PATH 里搜索能搜到但注入时没有内容相关性阈值过高全部被过滤查看注入日志中的 score 分布调低 retrieve.threshold扫描出了一堆记忆但检索结果很乱过滤规则太宽松噪音入库抽查记忆库前 20 条看有效密度调整过滤深度或删库重新扫描中文搜索效果明显差于英文默认嵌入模型中文能力弱对比不同模型召回同一问题的结果换成中文友好的 bge-m3 等本地模型会话历史目录权限受限扫不到Claude Code 运行在容器或非默认 home检查权限和目标目录是否存在在配置里指定原始日志目录头两个坑是配置型问题后三个是模型和数据质量问题。从我的经验看中文场景的模型问题最容易被低估但影响又最大。如果默认嵌入模型产出的向量在中文语义上区分度不高你会看到相似度分数普遍偏高但召回结果却一塌糊涂因为模型根本分不清哪些是真正相关、哪些只是表面接近。5.2 日志怎么看遇到问题不要瞎猜先看日志。claude-mem 一般会提供 debug 级别的日志输出你可以临时打开详细日志定位问题claude-mem scan --debug 21 | tee /tmp/claude-mem-scan.log重点看三个环节的日志解析阶段有多少条消息被读取提炼阶段生成了多少个记忆单元丢弃记录是什么注入阶段检索到了哪些候选最终命中哪些分数都是多少。这三个阶段的信息可以帮你快速定位问题到底出在数据源、提炼逻辑还是检索配置上。有一次我遇到“注入内容完全不对”的情况查日志发现注入脚本拿到的项目名是空的结果向量检索在全局范围内做了查询自然捞了一堆乱七八糟的东西。这种问题不看日志根本发现不了因为表面上一切都正常只是结果离奇。5.3 记忆混进不相关上下文记忆系统最怕的就是“无差别记忆”。你让 AI 处理一个登录页样式问题结果它强行带上上次讨论的 Kafka 分区策略这种上下文污染不仅没用还会打断思路。我测试下来这类问题的根源一般出在两条线上。第一条是原始会话日志里本来就混着大量多主题讨论提炼模型没有很好地区分主题边界导致一条记忆单元里塞了两个不相干的话题。这种情况可以通过调整提炼提示词来解决明确要求“每条记忆只保留一个核心主题”“如果一段对话包含多个主题请拆成多条记录”。第二条是检索阶段阈值设得太低尤其在冷启动阶段记忆库总量少为了凑够 topK 会把大量弱相关记录拉进来。这种情况宁可少带也不要硬凑。另外一个挑出来的经验是记忆库里应该增加一个“负面记忆”的类别。所谓负面记忆就是那些当时被明确否决的方案、明确踩过的坑。这种记忆在检索时优先级反而要更高因为防止重复犯错比提效更关键。比如某条记忆记录的是“不要用 Lua 脚本做分布式限流原因是要引入额外 Redis 运行时运维成本高”下次再聊相关问题AI 会主动避开这条弯路直接进入有效方案区。5.4 性能与内存占用优化跑了一段时间之后你可能会注意到扫描耗时会增长注入前检索虽然仍是毫秒级但扫描历史会话时越来越慢。这是因为所有历史日志都会重复解析哪怕它们已经在记忆库里了。优化的思路是给 claude-mem 加一个增量扫描机制只在每次扫描时处理新增的和发生变化的会话日志跳过已经处理过的部分。这个思路实现起来并不复杂核心是记录每个日志文件的哈希或最后修改时间。增量扫描还有一个额外好处就是大幅降低了重复提炼带来的 API 调用成本因为提炼记忆过程本身是需要调用模型的每次全量扫描都等于把历史重新压一遍。内存占用的问题主要出在批量扫描时如果一次把所有会话都读进内存做向量化几百个文件同时加载内存很容易冲高。稳妥的做法是改成逐文件处理、逐条记忆写入存储控制并发数。对一个个人使用的工具来说稳定和低资源占用比吞吐速度更重要。6. 我自己的一点经验这个项目真正让我觉得值得推荐的不是它多了多少 fancy 功能而是它把“AI 记忆”从一个抽象概念变成了一个可以本地运行、可以审计、可以手动干预的工程系统。跑了一段时间、积累了几百条有效记忆之后Claude Code 确实更像一个“跟我合作了几个月的老同事”而不是每次见面都互相重新自我介绍的新临时工。最后分享一个我特别受用的小技巧让它只记结论不记过程。一开始我图省事把整段对话原文都存进去结果检索出来的记忆又长又没重点AI 的回复也变得啰嗦。后来我改成只保存提炼后的结论、理由和注意事项效果立刻提升了一个档次。原因在于大模型读文本时重点信息密度是决定性因素。你记忆库里存的每条内容都应该像 commit message而不是像现场直播的文字稿。带着这个思路去调 claude-mem 的提炼配置你的记忆系统才会越用越顺手而不是越用越臃肿。
