企业官网建设流程全解析

1. claude-mem 到底补上了哪块短板

如果你已经用 Claude Code 连续写过三周以上的项目代码，大概率碰到过这个场景：上周刚跟它确认过的目录结构和接口命名规范，换一个会话之后就完全不记得了。它不是不会写，而是没法“记得”。每个会话开始都是一张白纸，上下文窗口里写了什么它才知道什么，关掉窗口等于清空脑子。这也正是 claude-mem 这类项目出现的原因——它想给 Claude 补一个跨会话的长期记忆。

claude-mem 不是一个聊天机器人，也不是一套 prompt 模板，而是一个 MCP 记忆服务。它把每次会话里值得留下的信息抽取成结构化的记忆条目，存进 SQLite，再用语义检索的方式在下次对话时把相关内容召回。一句话总结：Claude 负责“想”，claude-mem 负责“记”。

要说清楚它补的是哪块短板，可以先看一个对比。

所以它解决的并不是“代码生成质量”的问题，而是“协作连续性”的问题。谁适合用它？如果你只是偶尔拿 Claude 问几个一次性问题，没必要上这套东西；但如果你每天都在同一个项目仓库里和 Claude 结对开发，被“反复解释同样的约定”这件事折磨过，那 claude-mem 就是值得认真试一下的工具。它本质上是在给 Claude 装一个外挂硬盘，让每次会话都能接着上一次的认知继续干活。

1.1 大模型会话最大的问题其实是“出厂即失忆”

很多人误以为 Claude Code 会在本地保存历史记录，所以它应该记得昨天聊了什么。实际上，终端里那些历史记录只是把对话文本留下来了，下一次会话开始时，模型仍然不知道这些文本存在。它只能在当前上下文窗口里看到你重新贴进去的内容。把历史记录当成记忆，就像把日记本放在桌上却从来不翻开——信息在那里，但模型读不到。

更麻烦的是，项目级知识很难每次重复表达完整。比如“后端接口字段统一驼峰”“数据库迁移脚本放在 migrations 目录”“错误码需要先注册到 constants 里”这类约定，你第一次告诉 Claude 的时候它执行得很好，但第二天新开一个会话，它就像第一天上班的新人，又开始用下划线命名。你会陷入一个死循环：解释规范、验证规范、再次解释规范。

1.2 claude-mem 的思路：用 MCP 给 Claude 外接一个记忆库

claude-mem 没有去改模型本身的参数，而是走 MCP（Model Context Protocol）这条标准通道。你可以把 MCP 理解成 Claude 的“USB 接口”，Claude 可以通过它调用外部工具，比如查数据库、读文件、执行命令。claude-mem 做的事情，是把“记忆写入”和“记忆召回”封装成几个 MCP 工具。Claude 在对话过程中如果需要回忆旧信息，就会调用这些工具去查，而不是靠猜。

这个设计的好处是：记忆库和模型解耦。模型负责判断“什么时候需要回忆”“用户这句话是不是在给记忆库补充内容”，记忆库负责存储和检索。即使未来换一个更大的模型，只要它还支持 MCP，这套记忆体系依然能用。

2. 从安装到接入 MCP：一套最小可运行的配置

实际接入的时候，最容易被卡住的不是安装，而是配置细节。我下面给的是当前主流方式，如果你的版本命令有差异，以你安装版本的 README 和claude-mem --help输出为准。

2.1 装 claude-mem 本身

我习惯用uv来装这种 Python 写的命令行工具，隔离干净，不污染系统 Python：

uv tool install claude-mem

如果你机器上没装 uv，直接用 pip 也可以：

pip install claude-mem

装完先确认一下可执行文件在不在 PATH 里，并看一眼它支持哪些子命令：

claude-mem --help

这一步很重要。不同版本暴露的命令可能不太一样，有的叫serve，有的叫--mcp，你需要知道自己手里是哪个，后面配置 MCP 时才能填对参数。

2.2 把它注册成 Claude 的 MCP 服务

如果你用的是 Claude Code，在项目目录或用户目录下执行类似下面的命令，把 claude-mem 注册成一个 MCP server：

claude mcp add claude-mem --env ANTHROPIC_API_KEY "$ANTHROPIC_API_KEY" -- claude-mem serve

注意这里我把ANTHROPIC_API_KEY显式传进去了。为什么？因为 claude-mem 在抽取记忆时，需要调用模型接口来理解对话内容，这个调用发生在它自己的进程里，不会自动继承 Claude Code 的登录态。就算你平时用的是 Claude 订阅账号，这一步也照样要配一个 API key，否则记忆抽取会静默失败。

如果你用的是 Claude Desktop，则是编辑 MCP 配置文件，把 claude-mem 加进mcpServers：

{ "mcpServers": { "claude-mem": { "command": "claude-mem", "args": ["serve"] } } }

如果你的版本把启动参数叫--mcp，就把args换成["--mcp"]。判断标准很简单：启动后它应该走标准输入输出和 Claude 通信，而不是起一个 HTTP 服务。

2.3 验证连通性

配置完不是直接开始用，先做一次连通性验证。在 Claude Code 里执行：

claude mcp list

正常的话应该能看到claude-mem这一项，并且状态是 connected。然后你在对话里问一句：

你现在能调用哪些 MCP 工具？

如果 Claude 能列出 claude-mem 相关的记忆工具，就说明整条链路通了。这时候你可以先手动存一条记忆测试一下：

claude-mem add "项目约定：Python 代码统一使用 4 空格缩进，禁止 Tab"

再搜一下：

claude-mem search "缩进"

能搜到刚才那条，就说明写入和召回都正常。

3. 记忆的完整生命链：提取、入库、召回、衰减

接入只是第一步，真正值得花时间理解的是记忆从生成到被使用的完整链路。这部分搞清楚了，你才知道什么该自动提取、什么该手动写、什么该定期清理。

3.1 提取：不是抓关键词，而是让模型“翻译”成记忆

claude-mem 的自动提取，不是像 grep 那样从对话里抠出几个名词，而是让一个小模型去阅读一段对话，判断哪些信息值得留到以后。比如你说了这样一段话：

这个接口的字段名别用下划线，统一改驼峰，前端那边已经定了。

如果只是抓关键词，存下来的可能是“下划线”“驼峰”“前端”，这些碎片以后根本没法用。claude-mem 的思路是把这句话“翻译”成一条可复用的记忆：

用户偏好：接口字段命名统一使用 camelCase，不使用下划线。

这个“翻译”动作非常关键。它意味着记忆库里的内容不是对话原文，而是经过提炼的、面向未来使用的断言。自动提取通常发生在会话进行中，或者会话结束后的一小段窗口期。它是异步的，不会阻塞你正常和 Claude 对话。

3.2 入库与去重：SQLite + 向量索引

提取出的记忆条目会被写入 SQLite。每条记忆大概包含这些字段：唯一 ID、记忆正文、创建时间、来源会话、所属项目、向量表示。

为什么用 SQLite？因为这是个人级工具最好的选择。单文件存储，备份就是拷一个文件，不需要额外启动 Redis 或者向量数据库。向量索引在几万条记忆的规模下也完全够用，没必要为了“看起来很专业”去引入一套分布式存储。

去重逻辑也在这层做。如果同一条记忆反复出现，比如每次会话都提到“接口返回结构统一为{ code, message, data }”，库里面不应该堆三条一模一样的记录。claude-mem 会先做相似度比对，如果接近完全重复，就更新原条目的时间戳，而不是新增。这个设计避免了记忆库被同一个事实刷屏。

3.3 召回：语义相似度决定要不要把记忆塞进上下文

召回阶段是 claude-mem 最有价值的部分。当新会话开始或者对话进入某个话题时，Claude 会带着当前的 query 去查记忆库。它不会做字符串匹配，而是把 query 也转成向量，和库里的记忆做余弦相似度计算，然后取最相关的 top K 返回。

举个例子。你在新会话里说：

帮我加一个订单查询接口。

这句话和“项目约定：接口字段命名统一驼峰”在字面上没有任何重叠，但在语义上非常相关，因为都是关于接口设计的。向量检索能跨词面找到这层关系，这是普通全文搜索做不到的。

召回之后，这些记忆会被注入到当前上下文里，作为 Claude 的辅助背景。它不需要你重新把规范敲一遍，模型看到的就是“这个项目已经有这些约定，请遵守”。

3.4 衰减与清理：记忆不是只增不减

记忆库最大的风险是会膨胀。你用了三个月之后，库里可能有几千条记忆，其中一半已经过期。如果每轮对话都把几千条记忆全塞进上下文，上下文窗口会被撑爆，而且大量无关记忆反而会干扰模型判断。

所以 claude-mem 一定会有清理机制。常见做法是：限制召回条数、设置相似度阈值、支持按项目维度删除、支持手动删除单条。我的习惯是每周做一次“记忆盘点”，把过期的、被推翻的、或者已经明显错误的条目清掉。记忆库不是越大越好，而是越准越好。

4. 三组真实对话：看它怎么改变协作方式

只讲原理太抽象，我实际用下来，记忆库主要在三种场景里产生了质变。

4.1 项目规范的自动续接

第一次会话里，我跟 Claude 说清楚了这个项目的约束：

所有 API 路由都写在routes/目录下，每个资源一个文件，不要都堆在app.py里。

Claude 当场照做，这段对话同时被 claude-mem 提取成记忆。第二天我新开一个会话，直接说：

给用户模块加一个修改头像的路由。

Claude 没有问“路由文件在哪里”，而是直接打开routes/user.py开始改。这就是记忆最舒服的用法：你不需要每次复述，它自己知道项目已经形成的规矩。

4.2 个人偏好的跨会话继承

除了项目规范，个人偏好也很容易被记住。比如我调试前端时不喜欢 console.log 打满屏，更倾向于在关键节点用debugger断点。这个偏好我只说过一次，之后所有会话里，Claude 给的调试代码都自动带着debugger语句。

这类偏好在原生会话里几乎不可能被记住，因为你每次都要重新描述。有了记忆库之后，模型相当于知道“这个用户喜欢什么样的交付物”，它会主动调整输出风格，而不只是执行字面指令。

4.3 模糊诉求也能命中旧任务

最有意思的一次，是隔了快两个星期，我跟 Claude 说：

上次聊的那个性能问题，我决定按你的方案重构，现在开始吧。

如果换成原生会话，这句话基本无效，因为“上次聊的那个”在上下文里没有对应物。但 claude-mem 会把这个模糊诉求转成向量去库里面找，找到一条和“性能”“重构”相关的旧记忆。Claude 把记忆里的重构方案列出来跟我确认，然后直接开工。

这种“模糊指代”能命中，是因为语义检索天然支持近义表达。你不用记住当初是怎么描述的，只要大概印象还在，它就能帮你把上下文捞回来。

5. 我踩过的坑和对配置的最终调优

工具好用，但配置不当也会翻车。下面这几个坑我是真金白银踩出来的，写在这里帮你提前避掉。

5.1 抽取模型选大了，账单和延迟一起涨

claude-mem 的自动提取需要调用模型接口，这里有一个默认模型配置。我一开始偷懒，用了能力很强的大模型来做抽取，结果一场上午的密集开发下来，我的 API 账单肉眼可见地涨了。更难受的是延迟：每次抽取都要等一两秒，如果对话节奏快，体验会明显变卡。

后来我把抽取模型换成了更便宜的轻量模型，效果几乎没有下降。为什么？因为“从对话里提炼可复用的断言”这件事，本身对推理能力要求不高，它需要的是稳定和快，而不是创造力。建议你在配置里显式指定抽取模型，不要用默认值扛着。如果找不到配置项，至少关注一下环境变量里有没有CLAUDE_MEM_EXTRACTION_MODEL这类设置。

5.2 不要忽略记忆污染：坏条目的杀伤力比没有记忆更大

记忆库最大的风险不是记不住，而是记住了错误的东西。有一次我在读一个开源仓库时，里面某个 README 写着“本模块命名方式统一使用单字母变量”。Claude 把它当成一种“合理约定”存进了项目记忆里。结果后面很长一段时间，它生成的代码全是a、b、c这种变量名，我排查了半天才发现是记忆库在“带偏”。

从那以后我养成两个习惯。第一，涉及代码风格的记忆，我会更倾向手动添加，而不是完全依赖自动提取。第二，定期翻看记忆列表，发现可疑条目直接删。英文里管这个问题叫 memory poisoning，中文可以理解成“记忆投毒”。对于会自动从对话里提取信息的系统，这个问题尤其需要警惕。你在和 Claude 对话时提到的任何描述性语句，都有可能变成一条长期记忆，所以要时不时检查它到底记住了什么。

5.3 多项目隔离：一份全局记忆库会让项目互相串味

claude-mem 默认可能会把所有记忆放在同一个库里，这在只有一个项目时没问题，但如果你同时维护两三个项目，就会出事。A 项目的“变量命名用极小缩写”约定，会被 B 项目检索到，然后 B 项目里就出现了一批风格诡异的代码。

解决方案是隔离。我现在的做法是给每个项目单独指定一个数据库路径，相当于每个项目一个独立的记忆分区。可以是环境变量，也可以是在对应项目的 MCP 配置里指定不同的存储路径。这样每个项目的记忆库只服务对应的项目，互不干扰。

注意：私有代码和敏感信息不要随便让自动抽取进程读到。claude-mem 会把对话片段送去模型接口做提取，这意味着这些内容会离开你的本地环境。如果你在处理机密代码，建议先关闭自动提取，只用手动方式写入脱敏后的记忆条目。

另外，SQLite 数据库文件默认放在用户目录下，里面是明文存储。如果机器是多人共用的，建议把记忆目录权限收紧：

chmod 700 ~/.claude-mem

6. 把记忆库当成可维护的资料库

用了一段时间之后，我更愿意把 claude-mem 看成“一个需要维护的资料库”，而不是“一个自动运行的黑盒”。自动提取能省事，但长期质量一定依赖人工盘点。

6.1 每周花十分钟盘点记忆

我每周五会花十分钟左右，把本周新增的记忆过一遍。重点看三件事：有没有已经失效的旧约定？有没有存错的偏好？有没有某条记忆被反复触发但每次都没实际用处？该删就删，该改就改。记忆库维护得越勤，Claude 在对话里的表现就越稳定。

6.2 给记忆加标签和手动补充

自动提取适合记录“显而易见”的约定，但有些东西最好手动补。比如项目的长期规划、接下来几周的目标、某些技术选型背后的原因。这类记忆更偏“语义背景”，光靠自动提取很难提炼好。我现在会在每个关键节点手动写几条“锚点记忆”，让 Claude 在后续所有相关会话里都能看到全局视角。

手动补充的另一个好处是你能保证质量。你亲手写下来的记忆，一定是你真正想让 Claude 长期遵从的内容，而不是它从某个角落自动捞出来的噪音。

6.3 我现在实际用的工作流

如果你准备上手，我推荐的最小配置是：装好 claude-mem，配好 API key，先让它跑一个项目，观察一个星期，然后花半个小时翻看它积累了哪些记忆。接下来再按实际情况决定要不要换抽取模型、要不要多项目隔离、要不要关掉自动提取改全手动。

我自己的最终配置是：抽取模型用轻量型号，SQLite 按项目分库，每周固定盘点，代码风格类约束尽量手动写。这样跑下来，Claude 在跨会话协作上的表现提升非常明显，那种“昨天刚说过今天又忘了”的挫败感基本消失了。记忆这件事，模型本身做不了，但我们可以用工具帮它补上。