claude-mem 什么值得记

AI 大模型的记忆有两个核心的要点。第一，Claude Code 需要长期记忆。因为会话是短期的，项目是长期的。没有长期记忆，Claude Code 每次新开会话，都像重新接触项目。第二，claude-mem 的核心不是记忆本身，而是上下文工程。它的目标不是让 Claude 记住更多，而是让 Claude 在当前任务中看到更高信噪比的上下文。

下面我们将面临更实操的问题：claude-mem 到底应该记什么，不应该记什么？

这是使用 claude-mem 时最容易被低估的问题。很多人以为，装上记忆插件之后，只要让它自动记录就行。但长期记忆不是越多越好。记得太少，Claude Code 还是会失忆；记得太多，记忆库又会变成垃圾场。

真正的关键不是要不要记，而是什么值得记。

长期记忆不是聊天记录

很多人第一次使用 claude-mem，会自然地把它当成聊天记录存档工具。这个理解很容易导致错误用法。聊天记录追求完整，长期记忆追求有用，这两者不是一回事。

如果把所有历史对话、工具输出、命令结果、日志堆栈都保存下来，表面上看信息很完整，但对 Claude Code 后续工作未必有帮助。因为未来任务真正需要的，通常不是完整过程，而是过程背后的结论。

比如下面这种记录，信息量看起来不少：

查看了 auth.ts、session.ts、middleware.ts。
运行 pnpm test 失败。
修改了 session refresh 逻辑。
又运行了一次测试。
最后通过。

这确实是历史，但它不是高价值记忆。因为它没有告诉 Claude Code：问题根因是什么，哪些方向被排除了，后续修改时应该注意什么。

更好的记忆应该是这样：

登录超时问题的根因不是 token 生成逻辑，而是 session refresh 后没有同步更新 cookie maxAge。后续修改认证逻辑时，需要同时检查 session TTL、cookie maxAge 和前端刷新策略。

这条记忆更短，但价值更高。它能直接影响未来判断。

所以，claude-mem 不应该保存发生了什么的流水账，而应该沉淀以后怎么判断的经验。

一句话：聊天记录面向回放，长期记忆面向决策。

值得记住的六类信息

判断一条信息是否值得进入 claude-mem，可以看它未来是否会影响 Claude Code 的决策。如果未来相关任务中还会用到，它就值得被记住；如果只是一次性过程，它就不该长期占位。

我建议优先沉淀六类信息。

第一类是架构决策。比如某个模块为什么这样拆分，为什么没有引入某个中间件，为什么某个接口必须保留旧参数，为什么某个服务不能直接依赖另一个服务。这些信息通常不会在代码里完整体现，但会深刻影响后续修改。

示例：用户权限模块没有直接依赖组织架构服务，是为了避免权限校验链路引入远程调用。后续修改权限判断逻辑时，应优先使用本地缓存的组织关系快照。

第二类是历史 Bug。历史 Bug 是非常高价值的记忆。因为真实缺陷往往代表真实风险。一个模块曾经在哪里出过问题，后续就应该重点关注哪里。

示例：订单取消接口历史上出现过库存重复释放问题，根因是取消操作缺少幂等保护。后续修改订单状态流转时，必须覆盖重复取消、并发取消、已取消订单再次取消。

第三类是失败尝试。很多失败方案非常值得记。因为它能防止 Claude Code 未来重复走同一条路。尤其是那些看起来合理，但实际不可行的方案。

示例：支付回调曾尝试通过请求时间戳去重，但由于第三方网关存在重试延迟，时间戳不能作为可靠幂等依据。后续应继续使用 callback_id + order_id 做幂等键。

第四类是测试策略。测试策略是测试开发场景中最值得沉淀的内容。它包括必测场景、回归范围、Mock 规则、数据构造约束和历史高风险路径。

示例：优惠券金额计算修改后，必须回归满减券、折扣券、会员价、退款重算、活动叠加五类场景。历史缺陷主要集中在活动叠加和退款重算。

第五类是团队约定。团队约定适合分两层管理。稳定、强约束的规则应该写进 CLAUDE.md；动态形成的经验性约定，可以进入 claude-mem。

示例：当前项目中，涉及外部支付网关的测试不允许真实调用第三方环境，必须使用本地 mock server。历史上真实调用测试环境曾导致回调状态污染。

第六类是长期约束。长期约束包括兼容性要求、性能红线、安全要求、外部依赖限制、灰度发布限制等。这些信息很容易被当前代码掩盖，但对修改方案非常关键。

示例：订单详情接口必须兼容旧版移动端，不能删除 legacy_status 字段。即使新版本前端已经不使用，该字段仍被部分旧客户端依赖。

这六类信息有一个共同点：它们不是简单描述过去，而是会影响未来任务。这就是判断标准。

必须避免记住的内容

有些信息不仅不值得记，甚至必须主动避免进入长期记忆。

第一类是临时日志。比如某一次运行测试的完整输出、一次接口调用的临时报错、一次构建失败的详细堆栈。这些信息通常只对当前任务有用，长期保存价值很低。临时日志可以在当前会话中使用，但不应该长期沉淀。

第二类是大段工具输出。Claude Code 在工作中会产生大量工具调用结果。比如 grep 结果、文件片段、测试输出、命令返回。这些内容如果原样进入记忆，会迅速污染记忆库。真正值得保留的是工具输出背后的结论，而不是工具输出本身。

第三类是无结论探索。比如看了几个文件，但还没确定原因，尝试了一个方向，但还需要继续分析。这类状态如果没有形成明确结论，通常不适合长期保存。否则后续检索出来，只会增加不确定性。

第四类是过期方案。项目会演进，接口会废弃，架构会重构，测试策略会调整，历史结论也会过期。过去正确的方案，未来可能已经失效。尤其是重构、迁移、接口废弃之后，旧记忆如果不清理，会严重误导 Claude Code。

第五类是敏感信息。包括密钥、Token、数据库连接串、生产账号、客户数据、用户隐私、内部临时凭证等。任何这类内容都不应该进入长期记忆。记忆系统一旦持久化，就必须按长期资产对待，不能把它当成临时草稿。

第六类是错误判断。排查过程中经常会出现阶段性误判，比如一开始怀疑数据库，后来发现是缓存；一开始怀疑后端，后来发现是前端重复请求。最终结论可以保存，但中间误判不能以事实的形式进入记忆。

例如，不应该保存：

登录超时问题是 Redis TTL 导致的。

如果最终已经排除 Redis，更好的记忆是：

登录超时问题曾怀疑 Redis TTL，但最终排除。根因是 session refresh 后 cookie maxAge 未同步更新。

这类表达既保留了排除项，又不会制造错误事实。

好的记忆应该怎么写

claude-mem 虽然可以自动捕获和压缩，但我们仍然应该主动引导它形成更好的记忆。

一条好的记忆，通常应该包含四个要素：背景、结论、影响、后续建议。

比如：背景是订单取消接口历史上出现过库存重复释放；结论是根因在于取消操作缺少幂等保护；影响是后续任何订单状态流转修改都可能影响库存一致性；建议是必须覆盖重复取消、并发取消、已取消订单再次取消。

这比单纯写订单取消出过 Bug 要有用得多。

也可以用更紧凑的自然语言写法：

订单取消接口历史上出现过库存重复释放问题，根因是取消操作缺少幂等保护。后续修改订单状态流转时，必须覆盖重复取消、并发取消、已取消订单再次取消，重点验证库存只释放一次。

对测试开发来说，推荐使用风险 + 场景 + 验证点的格式。

例如：优惠券模块的主要历史风险是活动叠加金额计算错误。后续修改价格计算逻辑时，必须覆盖满减券、折扣券、会员价、退款重算和多活动叠加。验证重点是最终支付金额、优惠明细、退款金额是否一致。

这种记忆非常适合未来生成测试用例。它不仅告诉 Claude Code 要测什么，还告诉它为什么测、重点验证什么。

好的记忆应该避免三种写法。

第一种是流水账：今天看了 order.ts，改了 cancel.ts，跑了测试。

第二种是空泛总结：订单模块比较复杂，后续要小心。

第三种是没有边界的规则：所有接口都要重点测试并发。

这些内容要么信息密度低，要么不可执行，要么范围太大，都会降低记忆质量。真正好的记忆应该具体、可检索、可执行。

记忆也需要定期清理

长期记忆不是一次写入后就永远正确。项目会变化，接口会废弃，架构会重构，测试策略会调整，历史结论也会过期。

所以 claude-mem 的最佳实践里，必须包含记忆清理。否则，记忆系统很容易从项目经验库变成历史垃圾场。

清理时重点关注几类内容。

第一，已经废弃的架构方案。比如项目已经从 session 迁移到 token，但记忆里还保留大量旧 session 逻辑。

第二，已经失效的接口约束。比如旧客户端已经下线，但记忆里仍然提示必须兼容旧字段。

第三，临时 workaround。很多临时方案在当时合理，但长期存在会误导后续设计。

第四，重复记忆。同一个问题被多次记录，可能导致检索结果冗余，降低信噪比。

第五，互相冲突的记忆。如果记忆里同时存在使用 Redis 做幂等和不要使用 Redis 做幂等，Claude Code 很可能被错误上下文干扰。

可以在重大重构后主动让 Claude Code 清理记忆。例如：认证模块已经从 session 机制迁移到 token refresh 机制。请检查历史记忆中和旧 session 续期相关的内容，将过时结论标记为废弃，后续以 token refresh 机制为准。

也可以按模块定期整理：请汇总当前和订单取消相关的长期记忆，找出重复、过期、冲突的内容，并给出清理建议。

长期记忆系统的质量，不只取决于写入，也取决于删除。

没有记忆，Claude Code 会失忆。记忆太乱，Claude Code 会误判。高质量记忆，才会让 Claude Code 真正变成项目协作者。

所以这一篇的核心结论很简单：

claude-mem 不应该记住所有历史，它应该记住未来仍然有决策价值的经验。

下一篇，我们继续聊一个非常实际的问题：CLAUDE.md 和 claude-mem 到底应该怎么分工？