企业官网建设流程全解析

1. 从零认识 claude-mem：它到底在解决什么问题

第一次看到 claude-mem 这个名字，很多人会以为它又是一个套壳的对话客户端。其实不是。claude-mem 的核心定位，是给 AI 编程助手补上一块它天生缺失的能力——跨会话的长期记忆。你可以把它理解成给一个每次上班都会失忆的同事，配了一本随身携带、自动更新的工作笔记。

我最初接触这个方向，是因为一个很现实的痛点：用 AI 助手写代码时，每次新开一个会话，它就像换了个人。上一轮我们刚敲定的目录结构、命名规范、某个模块为什么不用某个库，它全忘了。你得反复把背景重新讲一遍，讲得多了，人比写代码还累。claude-mem 想做的，就是把这层“重复交代背景”的成本压下去，让助手在下次对话时能自动想起之前发生过什么。

它适合谁？三类人最该关注。第一类是重度依赖 AI 助手做日常开发的人，每天要开十几个会话，上下文反复丢失；第二类是团队里负责搭建内部工具链的人，想把 AI 助手的记忆能力沉淀成团队资产；第三类是对 AI 记忆机制本身好奇、想自己动手改一改的技术爱好者。哪怕你只是想搞清楚“AI 记忆到底是怎么存的”，这套东西也值得拆开看看。

需要先说明一点：claude-mem 这类工具的具体实现细节，不同版本差异很大，官方文档也未必写得全。下面我讲的架构、参数、步骤，一部分来自公开资料的合理推断，一部分来自我自己搭类似系统时踩出来的经验。凡是推断的部分我都会点明，你照着做的时候以自己实际环境为准。

2. 整体设计思路：为什么记忆不能只靠“塞进上下文”

2.1 上下文窗口不是记忆，是草稿纸

很多人对 AI 记忆有个误解，觉得只要把历史对话全塞进上下文窗口，就等于有了记忆。这个思路在小规模下能跑，但很快就会撞墙。上下文窗口再大也是有限的，而且它是线性成本——你塞进去的每一个字，每次推理都要重新算一遍。会话一长，响应变慢、费用飙升，还容易把真正重要的信息淹没在噪音里。

claude-mem 的设计思路恰恰相反：它不追求把所有东西都留在上下文里，而是把记忆外置成一个可检索的存储层。对话过程中，它把值得记住的内容抽取出来，压缩、结构化，存到本地或指定的存储里；下次需要的时候，再按相关性把最相关的几条捞回来，拼进当前上下文。这就像人脑的工作方式——你不会记住今天说过的每一句话，但你会记住“这个项目的数据库用的是哪个”“上次那个 bug 是怎么修的”。

2.2 记忆分层：短期、长期、项目级

我在实际搭建时，把记忆分成了三层，这个分层思路和 claude-mem 的常见实践基本一致：

• 短期记忆：当前会话内的临时上下文，会话结束就丢，不落盘。
• 长期记忆：跨会话保留的事实性信息，比如“用户偏好用 TypeScript”“这个仓库用 pnpm 而不是 npm”。
• 项目级记忆：绑定到具体项目目录的上下文，比如“这个模块的入口在 src/index.ts”“测试命令是 pnpm test”。

为什么要分三层？因为它们的生命周期和检索范围完全不同。短期记忆追求快，长期记忆追求稳，项目级记忆追求准。如果混在一起存，检索时就会互相干扰——你问一个项目相关的问题，结果捞出来一堆跟当前项目无关的全局偏好，反而添乱。

2.3 为什么选择“抽取 + 检索”而不是“全量回放”

这里有个关键取舍。全量回放实现简单，但代价是上下文膨胀和检索精度下降。抽取 + 检索实现复杂，但换来的是可控的上下文占用和更高的相关性。claude-mem 走的是后一条路，这也是它比“手动复制粘贴历史”高明的地方。

具体来说，抽取环节要做的事是：判断一段对话里哪些内容值得记。不是所有内容都值得记——“好的”“收到”这种废话记了就是污染。真正值得记的是决策、约定、事实、偏好、待办。检索环节则要在需要时，用当前问题去匹配这些记忆，按相关度排序，取前 N 条注入上下文。这个 N 很关键，取太少漏信息，取太多又回到上下文膨胀的老路。

3. 核心机制拆解：记忆是怎么被存进去又捞出来的

3.1 记忆的写入：抽取、压缩、结构化

写入是整条链路里最容易被低估的一环。很多人以为写入就是“把对话存下来”，其实真正难的是判断存什么。我试过几种策略，最后发现最稳的是“规则 + 模型”双管齐下。

规则层负责兜底：凡是包含“记住”“以后都”“不要用”“约定”这类关键词的句子，直接标记为候选记忆。模型层负责精筛：把候选内容丢给模型，让它判断这条是不是真的值得长期保留，并压缩成一句话。比如原始对话是“我们讨论了半天，最后决定这个项目还是用 PostgreSQL，因为要支持复杂查询，MySQL 在这个场景下不太够用”，压缩后可能就变成“项目数据库选型：PostgreSQL，理由是需要复杂查询支持”。

结构化这一步决定了后续检索好不好用。我一般会给每条记忆打上几个字段：

注意：type 字段别设太多，超过五六个分类，模型判断时就开始乱标。我一开始设了十几种，结果检索时按类型过滤反而更不准，后来砍到四类才稳定。

3.2 记忆的检索：相关性排序的三个维度

检索环节的核心问题是：当前这个问题，该捞哪几条记忆出来。我实测下来，单靠向量相似度不够，得三个维度一起看。

第一个维度是语义相似度，也就是用嵌入向量算当前问题和记忆内容的接近程度。这是基础，但光靠它会出问题——有些记忆语义上不相关，但场景上必须带上。比如你问“这个函数怎么改”，语义上跟“项目用 pnpm”没关系，但如果你要跑测试验证改动，这条记忆就有用。

第二个维度是作用范围匹配。当前会话如果绑定在某个项目目录下，那项目级记忆的权重就该拉高，全局记忆权重降低。这个逻辑很直观：你在改 A 项目，B 项目的记忆再相似也不该优先。

第三个维度是时效性。越新的记忆权重越高，但衰减不能太陡。我一般用半衰期的方式，比如 30 天前的记忆权重打七折，90 天前的打四折。这样既照顾了新信息，也不会把老约定直接丢掉。

三个维度加权求和之后排序，取前 N 条。N 我一般设 5 到 8 条，具体看记忆的平均长度。如果每条记忆压缩得好、就一两句话，可以取到 8 条；如果偏长，就压到 5 条以内。

3.3 记忆的更新与冲突处理

这块是最容易出坑的地方。同一个事实，不同时间可能被写成不同版本。比如你三个月前说“这个项目用 npm”，上个月改成了“改用 pnpm”，如果两条都留着，检索时可能把旧的捞出来，助手就会给你错误的建议。

我的处理方式是同 scope 同 type 下做去重和覆盖。写入新记忆时，先检索同范围内语义高度相似的旧记忆，如果相似度超过阈值（我一般设 0.85），就用新的覆盖旧的，而不是并存。覆盖时保留一个历史版本字段，方便回溯，但检索时只取最新那条。

提示：覆盖阈值别设太低。设到 0.7 的时候，我遇到过“用 PostgreSQL”和“用 MySQL”被误判为相似然后互相覆盖的惨案。0.85 到 0.9 之间比较稳。

4. 实操落地：从零搭一套可用的记忆系统

4.1 环境准备与依赖选择

先说环境。这套东西对运行环境要求不高，一台普通的开发机就够。核心依赖就三样：一个能跑模型的运行时、一个存记忆的存储层、一个做向量检索的组件。

存储层我推荐先用 SQLite 起步，别一上来就上向量数据库。原因很简单：数据量小的时候，SQLite 加一个向量扩展完全够用，部署零成本，调试也方便。等记忆条数上万了，再考虑迁移到专门的向量库。我见过太多人一上来就搭一套重型基础设施，结果卡在配置上，业务逻辑一行没写。

向量检索组件，如果不想引入额外依赖，可以用模型自带的嵌入接口，把向量存成二进制，检索时在内存里算余弦相似度。记忆条数在几千以内，这个方案完全能扛。超过这个量级再考虑专门的索引结构。

4.2 记忆写入的完整流程

写入流程我拆成五步，每一步都有它的必要性：

1. 会话内容采集：把当前会话的对话内容按轮次收集起来。注意别把系统提示词也收进去，那是噪音。
2. 候选筛选：用规则先过一遍，把包含决策、约定、偏好、待办信号的句子挑出来。这一步能砍掉八成以上的无关内容。
3. 模型压缩：把候选内容批量丢给模型，让它输出结构化的记忆条目。批量处理比逐条处理省很多调用次数。
4. 冲突检测：拿新条目去检索已有记忆，判断是新增还是覆盖。
5. 落盘：写入存储，同时更新索引。

这里有个实操细节：批量压缩时，一次别塞太多。我试过一次塞 50 条候选，结果模型开始偷懒，后面的条目压缩质量明显下降。后来改成一次 10 到 15 条，质量就稳了。多调用几次的成本，远比记忆质量差带来的返工低。

4.3 记忆检索的注入策略

检索出来的记忆，怎么注入当前上下文，也有讲究。直接拼在系统提示词后面是最简单的做法，但效果一般。我试过几种注入方式，最后固定成“分区注入”：

• 项目级记忆放在最前面，因为最相关。
• 全局偏好放在中间，作为约束条件。
• 时效性高的记忆单独标一个“最近约定”区块，提醒助手优先遵守。

注入时还要控制总长度。我一般限制在 500 到 800 个 token 之间。超了就按相关度砍，砍到符合为止。这个上限不是拍脑袋定的——太短了信息不够，太长了又会挤占正常对话的空间，实测 500 到 800 是个比较舒服的区间。

4.4 一个最小可运行示例

下面这段是伪代码，展示核心逻辑，不是能直接跑的完整程序，你按自己环境补全依赖：

# 记忆写入的核心逻辑（伪代码） def write_memory(session_content, scope): candidates = rule_filter(session_content) # 规则筛选 memories = [] for batch in chunk(candidates, 12): # 分批压缩 memories.extend(model_compress(batch)) for mem in memories: mem.scope = scope existing = search_similar(mem, scope) # 冲突检测 if existing and existing.similarity > 0.85: overwrite(existing, mem) # 覆盖旧记忆 else: save(mem) # 新增 rebuild_index() # 记忆检索的核心逻辑（伪代码） def retrieve_memory(query, scope, top_n=6): scored = [] for mem in load_all(scope): score = (0.6 * semantic_sim(query, mem) + 0.25 * scope_match(scope, mem) + 0.15 * time_decay(mem.timestamp)) scored.append((score, mem)) scored.sort(reverse=True) return [m for _, m in scored[:top_n]]

权重 0.6 / 0.25 / 0.15 是我调了几轮之后比较满意的配比。语义相似度占大头，但没到压倒性，给范围和时效留了调整空间。你可以根据自己的使用习惯微调，比如你更看重项目上下文，就把 scope_match 的权重往上提。

5. 常见问题与排查技巧实录

5.1 记忆污染：为什么助手开始胡说八道

这是最常见的问题。表现是助手突然引用了一条你根本没印象的“约定”，或者把两个项目的配置搞混了。根因通常是记忆写入时没做范围隔离，全局记忆和项目记忆混在一起存了。

排查思路：先看被引用的那条记忆的 scope 字段。如果是 global 但内容明显是项目相关的，那就是写入时 scope 标错了。修复方式是给写入逻辑加一道校验——凡是内容里出现具体路径、具体命令的，强制标成 project 级。

我踩过最坑的一次，是早期版本没做 scope 隔离，结果 A 项目的测试命令被 B 项目检索到了，助手一直让我跑一个不存在的脚本。后来加了 scope 强校验才解决。

5.2 检索不准：明明存了却捞不出来

另一种常见情况是记忆确实存进去了，但检索时捞不出来。原因通常有三个：一是嵌入模型和检索时用的模型不一致，向量空间对不上；二是记忆压缩得太狠，关键信息丢了；三是相似度阈值设太高，把该捞的过滤掉了。

排查顺序建议从阈值开始，先把阈值调低看能不能捞出来，能捞出来说明是阈值问题；捞不出来再检查嵌入模型是否一致；都排除了再回头看压缩质量。我一般会留一个调试接口，输入一个问题，直接打印出 top 10 的候选记忆和它们的分数，这样排查起来一目了然。

5.3 性能问题：会话越长越卡

记忆系统本身不该成为性能瓶颈。如果发现会话越长越卡，八成是检索时全量扫描了。记忆条数上千之后，每次检索都遍历全部算相似度，延迟会明显上升。

解决办法是加一层粗筛。先用关键词或简单的倒排索引把候选范围缩小到几十条，再在这几十条里算向量相似度。这样即使记忆上万条，单次检索也能控制在毫秒级。我实测下来，加了粗筛之后，检索延迟从几百毫秒降到了十几毫秒。

5.4 常见问题速查表

提示：这张表建议打印出来贴在显示器边上。我调试记忆系统那阵子，一半以上的时间都花在这五类问题上，有张速查表能省很多来回试错的时间。

6. 进阶玩法：让记忆系统真正长在你身上

6.1 记忆的主动整理与衰减

记忆不是存得越多越好。存到一定量之后，需要主动整理。我的做法是每周跑一次整理任务：把长期没被检索到的记忆标记为冷记忆，冷记忆超过一定时间就归档或删除。同时把语义高度重复的记忆合并，减少冗余。

衰减策略也要配合。我一般给记忆设一个“最后命中时间”，检索时如果一条记忆很久没被命中，权重就持续下降。这样系统会自然地把注意力集中在常用的记忆上，冷门记忆慢慢沉底，但不至于直接丢失。

6.2 多项目场景下的记忆隔离

如果你同时维护多个项目，记忆隔离就特别重要。我的做法是按项目目录的哈希值做命名空间，每个项目一套独立的记忆库，全局偏好单独存一份共享库。检索时先查项目库，再查共享库，合并排序。

这样做的额外好处是，项目库可以随项目一起备份和迁移。你把项目目录拷到另一台机器，记忆也跟着走，换环境不用重新交代背景。这一点对经常换开发机的人来说特别实用。

6.3 记忆的可解释性：让助手告诉你它记得什么

最后一个我觉得很有价值的点，是给记忆系统加一个“查看记忆”的入口。用户可以随时问助手“你记得关于这个项目的什么”，助手就把当前项目相关的记忆列出来。这不仅能帮你确认记忆有没有存对，还能在记忆出错时快速定位。

我自己的用法是，每次开始一个新会话，先让助手复述一遍它记得的项目约定。如果复述得对，说明记忆检索正常；如果复述错了或者漏了，就当场修正，修正的内容又会写回记忆库。这样用下来，记忆库会越来越贴合你的实际习惯，助手也越来越像“记得住事”的老搭档。

这套东西搭起来不算轻松，但一旦跑顺，日常开发的体验提升是实打实的。我现在的习惯是，凡是需要反复交代的背景，第一次讲完就让它进记忆库，后面再也不用重复。省下来的时间，够多写好几个模块了。