真正值得记住的，不是完整过程，而是未来仍然有决策价值的经验。CLAUDE.md 和 claude-mem 也应该分工明确：CLAUDE.md 管稳定规则，claude-mem 管动态经验，当前会话处理即时现场。
到了最后一篇，我们把这些原则收束成一个完整工作流。这一篇只回答一个问题：日常使用 Claude Code 时，如何真正把 claude-mem 用起来？
先检索历史
很多人使用 Claude Code 时，习惯直接下任务。
比如：
修复支付回调重复处理的问题。
或者：
帮我给订单取消接口补测试。
这当然可以，但如果项目已经使用了 claude-mem，更好的方式是先让 Claude Code 检索相关历史记忆。
比如：
开始修改支付回调前，先检索历史记忆里和支付回调、幂等、重复通知、乱序通知相关的内容，再给出修改计划。
或者：
补充订单取消测试前，先查一下长期记忆里是否有订单取消、库存释放、幂等、并发请求相关的历史缺陷和测试策略。
这个动作很重要。因为 Claude Code 如果不先查记忆，就只能基于当前代码现场工作。它可能会读文件、跑测试、分析逻辑，但未必知道这个模块过去踩过什么坑。
而真实项目里的很多风险，不是从当前代码表面就能看出来的。支付回调可能历史上出过重复通知问题，订单取消可能历史上出过库存重复释放，优惠券模块可能历史上多次出现金额叠加错误，权限接口可能曾经漏过跨租户访问。
这些经验如果不被召回，Claude Code 很可能会给出看起来正确，但不够贴近项目风险的方案。
所以，使用 claude-mem 的第一个动作，不是让它立刻改代码，而是让它先回忆。
推荐使用这样的开场模板：
在开始这个任务前，请先检索 claude-mem 中和以下关键词相关的历史记忆：
- 模块：
- 业务动作：
- 风险点：
- 测试场景：
然后基于历史记忆和当前代码，给出任务计划。
例如：
在开始这个任务前，请先检索 claude-mem 中和以下关键词相关的历史记忆：
- 模块：订单取消
- 业务动作：库存释放、状态流转
- 风险点：幂等、并发、重复请求
- 测试场景：重复取消、并发取消、已取消订单再次取消
然后基于历史记忆和当前代码，给出任务计划。
这会让 Claude Code 先获得历史线索，再进入当前现场。
记忆在这里不是答案，而是导航。它帮助 Claude Code 少走弯路，也帮助它从一开始就关注真正的风险点。
按需读取现场
检索完历史之后，下一步不是把所有相关资料都塞进上下文，而是让 Claude Code 按需探索。
这是 claude-mem 工作流里非常关键的一点。
很多人使用 AI 编程助手时，会有一种冲动：为了让模型理解得更完整，一开始就把需求文档、接口文档、目录结构、相关代码、历史日志全部贴进去。
看起来很充分，实际很容易造成上下文污染。
因为当前任务真正需要的信息，通常不是一开始就完全确定的。更合理的方式，是先给 Claude Code 一个方向，让它像工程师一样逐步定位。
推荐流程是：
先读入口文件
↓
再查调用链
↓
再打开关键实现
↓
再查看相关测试
↓
再运行最小验证
↓
最后扩大影响范围
比如修复订单取消问题，不要一开始让 Claude Code 读取整个订单模块。可以这样要求：
请先从订单取消入口开始分析，只读取和取消流程直接相关的文件。
确认调用链后，再继续查看库存释放、状态流转和相关测试。
不要一次性读取无关模块。
这种方式有两个好处。
第一，上下文更干净。Claude Code 每一步看到的信息都和当前判断有关，不容易被无关内容稀释注意力。
第二，推理更可控。你可以看到它为什么读这个文件，为什么下一步查那个函数，为什么认为某个路径是风险点。
这就是即时上下文的思想。不要让 Claude Code 试图一次性背下整个项目，让它像工程师一样，需要什么，再查什么。
claude-mem 提供历史方向，当前工具调用提供现场事实。两者结合起来，才是更稳的工作方式。
这里还有一个细节：工具输出要及时压缩。
比如测试失败时，不要让 Claude Code 把几千行日志都长期保留。应该让它提取关键信息：
请从这次测试输出中提取真正影响判断的错误信息，包括失败用例、失败断言、关键堆栈和可能原因。
不要保留完整日志。
这样可以避免当前会话被工具噪声占满，也能为后续记忆沉淀打基础。
主动固化结论
claude-mem 可以自动捕获开发过程，但最好的实践仍然是：当任务中出现关键结论时，主动让 Claude Code 固化。
什么叫关键结论？
不是我看了哪些文件，不是我运行了哪些命令，也不是我改了哪几行代码。
而是那些未来可能继续影响判断的信息。
比如：
- 根因是什么
- 哪些方向已经被排除
- 为什么选择当前修复方案
- 这个模块的核心风险是什么
- 这次补了哪些关键测试
- 后续修改时应该注意什么
这些内容应该在任务中及时沉淀，而不是等到会话结束后从一堆日志里自动猜。
例如，排查登录超时问题时，Claude Code 最终确认根因不是 Redis TTL，而是 cookie 过期时间没有同步刷新。这时可以明确要求：
请把这个结论整理成一条适合 claude-mem 长期保存的项目记忆。
重点包含：根因、排除项、影响范围、后续修改认证逻辑时的注意事项。
它应该生成类似这样的记忆：
登录超时问题曾怀疑 Redis TTL，但最终排除。
根因是 session refresh 后没有同步更新 cookie maxAge。
后续修改认证逻辑时，需要同时检查 session TTL、cookie maxAge 和前端刷新策略。
这条记忆未来就很有价值。
它不只是记录登录超时修过一次，而是告诉 Claude Code：下次遇到类似问题，应该优先关注什么，不要重复怀疑什么。
对测试开发来说，也可以在补测试后固化测试策略。
比如：
请把本次订单取消接口的测试策略整理成 claude-mem 记忆。
重点包含：历史风险、必须覆盖的场景、核心验证点。
输出可以是：
订单取消接口的核心历史风险是库存重复释放。
后续修改订单状态流转时，必须覆盖重复取消、并发取消、已取消订单再次取消。
核心验证点是库存只释放一次，订单状态不可重复流转。
这样的记忆会直接提升未来测试生成质量。
所以，claude-mem 工作流里最重要的习惯之一就是：结论出现时，立刻结构化。
不要只让 AI 继续做事。要让 AI 把值得复用的经验留下来。
结构化关闭会话
很多人使用 Claude Code 完成任务后，就直接结束会话。
这会浪费一次非常好的记忆沉淀机会。
因为任务结束时，通常已经形成了完整上下文：目标是什么，改了什么，为什么这么改，踩了哪些坑，补了哪些测试，后续有哪些风险。
这时做一次结构化总结，可以显著提高 claude-mem 的记忆质量。
推荐使用这个模板：
## Task Summary
### Goal
本次任务目标是什么。
### Files Changed
修改了哪些关键文件。
### Root Cause
如果是 Bug，根因是什么。
### Key Decisions
做了哪些关键决策，为什么这么做。
### Failed Attempts
哪些方向尝试过但被排除。
### Tests Added
补充了哪些测试，覆盖什么风险。
### Follow-up Risks
后续修改时需要注意什么。
可以直接对 Claude Code 说：
请基于本次任务生成结构化总结，用于 claude-mem 长期记忆。
不要记录流水账，重点记录根因、关键决策、失败尝试、测试策略和后续风险。
一个好的总结应该像这样：
## Task Summary
### Goal
修复订单取消后库存偶发不一致的问题。
### Files Changed
- order.service.ts：增加取消操作幂等检查。
- inventory.service.ts：确保库存释放只执行一次。
- cancel-order.spec.ts：补充重复取消和并发取消测试。
### Root Cause
订单取消接口在重复请求场景下没有稳定幂等保护，导致库存释放逻辑可能被重复触发。
### Key Decisions
使用 order_id + cancel_status 作为业务幂等判断依据，不引入额外外部锁，避免增加状态流转复杂度。
### Failed Attempts
曾考虑在库存服务中做防重，但该方案无法阻止订单状态重复流转，最终放弃。
### Tests Added
覆盖正常取消、重复取消、并发取消、已取消订单再次取消。
### Follow-up Risks
后续修改订单状态机时，必须验证库存只释放一次，订单状态不可重复流转。
这类总结非常适合进入 claude-mem。
它不是聊天记录，不是工具日志，而是一份高度压缩的项目经验。未来 Claude Code 处理订单状态、库存、取消流程时，检索到这条记忆，就能快速进入正确方向。
任务结束总结还有一个额外价值：它能帮助人自己复盘。
很多时候，我们以为自己记住了排查过程，但过几周再看，细节已经模糊。结构化总结既服务 Claude，也服务工程师。
定期维护记忆
如果只写入、不清理，任何记忆系统最后都会变成垃圾场。
claude-mem 也一样。
项目会重构，接口会废弃，测试策略会调整，历史结论会过期。过去正确的记忆，未来可能变成错误上下文。
所以，日常工作流里必须加入记忆维护。
建议按模块定期清理，例如：
请汇总 claude-mem 中和订单取消相关的长期记忆，识别其中重复、过期、冲突或低价值的内容，并给出清理建议。
也可以在重大重构后主动更新记忆：
订单模块已经完成状态机重构。
请检查历史记忆中和旧状态流转逻辑相关的内容，将过时结论标记为废弃，后续以新状态机为准。
清理时重点关注五类内容。
- 过期记忆：旧接口已经下线，但记忆仍然提示要兼容旧客户端
- 冲突记忆：一条记忆说使用 Redis 做幂等，另一条记忆说不要使用 Redis 做幂等
- 重复记忆：同一个问题被多次记录，导致检索结果冗余
- 低价值记忆：只记录看了哪些文件、跑了哪些命令，没有结论
- 敏感信息：密钥、Token、连接串、用户隐私、生产数据，都不应该长期保存
记忆维护的目标不是让 claude-mem 记得更多，而是让它记得更准。
这个原则非常重要。
没有记忆，Claude Code 会失忆。记忆太乱，Claude Code 会误判。记忆干净，Claude Code 才能变成真正有项目经验的协作者。
所以，整个 claude-mem 日常工作流可以总结成五步：
- 任务开始：先检索历史
- 任务过程中：按需读取现场
- 关键结论：主动固化记忆
- 任务结束：结构化总结
- 周期维护：清理过期噪声
这五步并不复杂，但会明显改变 Claude Code 的工作质量。
它让 Claude Code 不再只是这次会话里的聪明助手，而是逐步变成一个能积累项目经验的长期协作者。
把任务变成上下文资产
claude-mem 的价值，不是让 Claude Code 记住所有事情，而是让每一次开发、排查、测试和修复，都有机会变成未来可复用的上下文资产。
这就是使用 claude-mem 的核心心法。
不要把它当成聊天记录仓库，不要把它当成无限上下文窗口，也不要指望它自动解决所有问题。
你真正要做的是，围绕它建立一套上下文工程工作流。
任务开始时，让 Claude 先查历史。任务过程中，让 Claude 按需探索现场。出现关键结论时，让 Claude 固化经验。任务结束时，让 Claude 结构化总结。项目演进后，让 Claude 清理旧记忆。
这样，Claude Code 才会从每次重新开始，变成越用越懂项目。
最后，用一句话总结整个系列：
CLAUDE.md 让 Claude Code 遵守项目规则，claude-mem 让 Claude Code 积累项目经验，而好的工作流让这些经验真正进入下一次任务。