项目是长期演进的，AI 会话却是短期的。一个复杂项目里的架构决策、历史 Bug、失败方案、测试策略、兼容性约束，很难全部写进当前会话。没有长期记忆，Claude Code 每次新开会话，都像重新入职：它可能很聪明，但它不知道这个项目以前踩过哪些坑，也不知道哪些路已经被证明走不通。
claude-mem 解决的正是这个问题。
但如果只把 claude-mem 理解成给 Claude Code 加一个记忆插件，其实还是低估了它。
更准确地说，claude-mem 背后真正重要的不是 Memory，而是 Context Engineering，也就是上下文工程。记忆只是手段，上下文质量才是目标。
Prompt Engineering 解决不了长期任务
过去大家谈 AI 使用技巧，最常说的是 Prompt Engineering：怎么写提示词，怎么设定角色，怎么拆解任务，怎么让模型输出更稳定，怎么让模型按照指定格式回答。
这些当然有用。
在单轮问答场景里，Prompt Engineering 很重要。比如让模型写一段文案、解释一个概念、生成一段 SQL、总结一篇文章。任务边界清楚，输入基本完整，模型只需要根据当前指令完成输出。
但 Claude Code 这类 AI Agent 面对的不是单轮任务。它要读文件、查调用链、运行命令、分析报错、修改代码、补测试，还要根据工具结果继续调整方向。任务越长，模型越不是在回答一个问题，而是在持续做工程判断。
这时候，决定任务质量的就不只是提示词怎么写，而是模型在每一步推理时，到底看到了什么信息。
Prompt Engineering 关注的是怎么说。
Context Engineering 关注的是给什么信息。
前者是表达问题，后者是信息系统问题。
在 Agent 场景里，Prompt 只是 Context 的一部分。真正的上下文还包括项目规则、历史会话、工具描述、代码文件、运行结果、错误日志、外部文档、长期记忆、当前任务状态。模型不是凭一句提示词工作，而是基于这些信息组合来判断下一步该读什么、改哪里、怎么验证。
所以，Claude Code 表现不好时，问题未必是 Prompt 写得不够好。更常见的问题是：上下文不完整、不相关、过期，或者噪声太多。
比如你让 Claude Code 修一个登录 Bug，但不给它认证流程、session 逻辑、最近改动、历史缺陷和测试约束。哪怕 Prompt 写得很漂亮，它也只能从当前文件里猜。
反过来，如果上下文足够精准，即使 Prompt 很简单，模型也可能做得很好。
这就是 Agent 时代和普通聊天时代的关键区别：Prompt 决定模型怎么听指令，Context 决定模型基于什么做判断。
上下文不是越多越好
很多人会自然认为，既然上下文很重要，那就把信息尽量多地塞给模型。项目背景塞进去，历史 Bug 塞进去，完整日志塞进去，接口文档塞进去，聊天记录也塞进去。
看起来很合理，但实际很危险。
因为上下文不是越长越好。上下文窗口再大，模型的注意力仍然是有限的。信息越多，噪声越多，关键内容越容易被稀释。
这就是所谓的 Context Rot，可以理解为上下文腐烂。
所谓上下文腐烂，不是信息消失了，而是信息虽然还在，但模型已经不再稳定使用它。
比如你在会话前面明确告诉 Claude：订单取消接口必须保证幂等，不能重复释放库存。然后你继续让它读取大量代码、日志、工具输出、历史讨论。等到真正改代码时，这条约束可能仍然在上下文窗口里，但模型未必还会牢牢记住它。
它可能补了正常取消流程，也可能补了异常参数测试，但就是漏掉重复请求和并发取消。
这不是模型完全不知道那句话，而是那句话在大量噪声中失去了足够权重。
这对 AI Agent 特别致命。
因为 Agent 的任务通常很长。它会不断读取文件，不断运行工具，不断追加输出。如果不控制上下文质量，当前窗口很快会被低价值信息填满。最后模型看起来知道很多，但真正关键的约束反而被冲淡。
所以，上下文工程的目标不是最大化输入量，而是最大化信噪比。
不是把所有东西都给模型，而是把当前任务最需要的信息给模型。
不是上下文越长越好，而是上下文越准越好。
claude-mem 的价值就在这里。它不是把历史聊天记录全部塞回 Claude Code，而是把过去会话中的高价值经验压缩成可检索的记忆，并在相关任务中按需注入。
这比简单扩大上下文窗口更重要。
最小高信号上下文
理解 claude-mem，需要抓住一个核心原则：找到最小但高信号的上下文，让模型完成任务的概率最大化。
这里有两个关键词。
第一个是最小。
最小不是越短越好，而是不要塞无关信息。一个 Bug 修复任务不需要看到整个项目历史，一个接口测试任务也不需要看到所有架构讨论。上下文应该服务于当前任务，而不是展示系统知道多少东西。
第二个是高信号。
高信号意味着这段信息对模型的判断有直接帮助。它能减少猜测，缩小搜索空间，提醒历史风险，约束错误方向，或者提供关键决策依据。
比如下面这类信息，信号就很高：
订单取消接口历史上出现过库存重复释放问题。根因是取消操作缺少幂等保护。后续修改该逻辑时，必须覆盖重复请求、并发请求、已取消订单再次取消。
它短，但价值很高。它告诉 Claude Code：这个模块的核心风险不是能不能取消订单，而是重复取消时会不会产生副作用。
再看另一种记录：
今天查看了 order.ts、inventory.ts、cancel.test.ts。运行 pnpm test 失败。后来修改了测试。
这类内容虽然也是历史，但信号很低。它没有告诉模型真正的风险、根因、决策和后续约束。未来即使检索出来，也很难帮助 Claude Code 做出更好的判断。
claude-mem 应该沉淀前一种信息，而不是后一种信息。
这也是为什么说 claude-mem 不是历史存档，而是经验压缩。
它应该把复杂开发过程压缩成未来可用的判断依据，而不是把所有过程原样保存下来。
可以把 claude-mem 的理想工作方式理解成：
- 过去的工具调用、排查过程、修复记录
- 压缩成高信号记忆
- 当前任务相关时被检索出来
- 成为 Claude Code 的决策上下文
这就是上下文工程的核心路径。
记忆的价值在于按需注入
很多人使用记忆系统时，会犯一个错误：既然记了，就想让模型每次都看到。
这会重新制造上下文污染。
长期记忆不应该默认全部进入当前会话。因为绝大多数历史记忆对当前任务并不相关。即使它们都是真的，也会变成噪声。
比如你现在让 Claude Code 修复登录超时问题，它不需要知道优惠券模块的历史缺陷，也不需要知道订单取消接口的幂等问题。即使这些记忆都很重要，也不该在这个任务里出现。
真正好的记忆系统，应该是按需召回。
当前任务和认证模块相关，就检索认证、session、token、cookie、登录超时相关记忆；当前任务和支付回调相关，就检索支付、回调、幂等、重复通知相关记忆；当前任务和测试补充相关，就检索历史缺陷、回归重点、Mock 约束相关记忆。
这就是 claude-mem 和上下文工程结合的关键点：记忆不是为了常驻上下文，而是为了在合适时机补充上下文。
这和人类工程师的工作方式很像。
一个资深工程师不会在处理登录 Bug 时，把整个公司所有历史事故都回忆一遍。他只会想起和登录、认证、session 相关的经验。需要时再去查文档、看日志、翻记录。
AI Agent 也应该如此。
所以 claude-mem 最好的使用方式，不是让 Claude Code 背下所有历史，而是让它在任务开始时先检索相关记忆。
比如：开始修改支付回调前，先检索历史记忆里和支付回调、幂等、重复通知相关的内容。
或者：补充订单取消测试前，先查看记忆里是否有这个模块的历史缺陷和回归重点。
这种用法能让 Claude Code 先获得历史线索，再决定读哪些文件、跑哪些测试、重点关注哪些风险。
记忆在这里不是答案，而是导航。
它帮助模型少走弯路，但最终仍然需要结合当前代码和测试结果验证。
从 Memory 到 Context Engineering
到这里可以看出，claude-mem 的核心并不是让 Claude 记住更多。
它真正解决的是上下文工程问题。
没有 claude-mem 时，Claude Code 的上下文主要来自当前会话、当前文件、当前工具调用和 CLAUDE.md。这些信息足够完成短任务，但很难承载项目长期经验。
有了 claude-mem 后，历史排查、架构决策、失败方案、测试策略、风险模式，都有机会被压缩成可检索记忆，在未来任务中重新进入上下文。
这会让 Claude Code 从只理解当前任务逐步变成理解项目历史。
但前提是，我们不能把 claude-mem 当成普通存档工具使用。它不是越记越好，也不是每次注入越多越好。真正关键的是三件事：
- 记忆必须高信号。它要记录决策、根因、约束、风险，而不是流水账
- 记忆必须按需检索。只有和当前任务相关的历史，才应该进入上下文
- 记忆必须接受验证。历史经验只能提供方向，不能替代当前代码、当前测试和当前事实
所以，claude-mem 的最佳实践可以总结成一句话：
用记忆保存经验，用检索控制相关性，用验证保证正确性。
这就是它和 Context Engineering 的关系。Prompt Engineering 让你更会指挥模型。Context Engineering 让模型在更正确的信息环境里工作。claude-mem 则是把项目历史变成可复用上下文的一种方式。
下一篇，我们继续聊一个更实操的问题：claude-mem 到底应该记什么，不应该记什么？