企业官网建设流程全解析

如果你和我一样，每天要跟AI助手聊几十轮，你一定经历过这个瞬间——开一个新会话，它完全不记得三十分钟前你反复强调过的技术选型和目录结构。我把这种状态叫“AI失忆”。为了一劳永逸地根治它，我折腾出了一套基于 claude-mem 的持久记忆层：让助手跨会话记住该记的，并在合适的时候主动想起来。这篇文章会把我的完整踩坑过程、架构设计思路、可复现的搭建步骤和调优经验整理出来，适合重度依赖AI写代码、做方案，或者正在琢磨“怎么给AI装长期记忆”的人参考。

1. 为什么我会在意AI的“记性”：无状态模型的真实痛点

1.1 每次会话都是一场“重新自我介绍”

我每天用AI助手辅助写代码和整理方案，最消耗耐心的不是它答错题，而是它在一个新会话里表现得像个刚入职的新员工。它不知道我们项目用的是哪门语言，不知道我的缩进风格，不知道昨天刚讨论过某个库有兼容性问题。每次都要把项目背景、依赖清单、过往决策重新复制粘贴一遍。反复几次之后你会发现，提问本身只占一分钟，但“重新介绍背景”至少占掉十分钟。

有一阵子我统计过自己在一个中型脚本项目上的会话成本：一周下来，重复粘贴项目结构说明和代码风格要求超过二十次。那些文字几乎一字不差，我却必须一次次喂给AI。人烦，token也烧得厉害。于是我开始认真思考一个问题：既然人脑都有长时记忆，为什么AI助手不能有？我们缺的不是更强的模型，而是一个让模型“记得住”的中间层。

1.2 上下文窗口不是记忆

很多人的第一反应是：把上下文窗口开大点，或者把历史聊天记录整个粘进去不就行了？说实话，我也走过这条路。把两万字的历史记录塞进提示词里，模型确实能听懂你在说什么，但代价同样明显。

首先，上下文窗口是有限的，历史记录占用的空间越多，留给当前问题和推理的空间就越少。关键是，这种“全量粘贴”本质上只是临时显存，窗口一关，下次还得重新粘。更麻烦的是，我的历史聊天里大量内容是寒暄、试探、中途翻车，这些如果一股脑全部注入，模型很容易被无关信息干扰，反而忽略真正重要的技术决策。

我用一个对比表来说明这个问题：

上下文窗口解决的是“一次性看懂”，持久记忆解决的是“跨时间还记得”，二者解决的完全不是同一个问题。

1.3 记忆层的意义不只是省token

我一开始以为做了记忆层顶多是省点token钱，用了一段时间才发现，它对工作流的改变是质变式的。编程本身是高度依赖上下文的活儿：一个决策往往是前面二十个决策的推导结果。如果没有记忆，AI每次都在一个“真空”里回答你，维度只能停留在“这个函数的语法怎么写”这个级别。一旦有了记忆，它能在回答里自然带出“你之前用的方案是A，且你确认过B方案不稳定”，这种连续性让AI从一个搜索工具变成了真正意义上的协作者。

所以，给AI做持久记忆，不是锦上添花，而是补上它天然缺失的那块短板。

2. claude-mem的架构拆解：记忆管道如何“记住”与“想起”

2.1 三层记忆：短期窗口、工作记忆、长期存档

我设计的记忆层分三层，参考的是认知心理学里感觉记忆、工作记忆和长时记忆的区分方式。最底层是短期窗口，也就是当前会话内的全部对话内容，这部分由模型自带上下文处理，不额外落库。第二层是工作记忆，指最近几次会话里产出的高质量摘要，比如某个关键决策、某个未完成的任务、某个明确的用户偏好。第三层是长期存档，指跨周跨月依然稳定的信息，例如项目技术栈、命名规范、禁止事项、长期目标。

工作记忆和长期存档看起来有点像，但我在存储上做了区分。工作记忆更新频率高，部分内容过段时间就不再有价值，比如“今天准备先修登录bug再优化查询”。长期存档则更稳定，比如“团队约定新接口统一走REST风格”。这个区分直接影响后面的过期策略和检索优先级，后面专门说。

2.2 提取机制：摘要不是复述，而是抽取

整个管道最核心也最容易被低估的一步，是会话摘要的提取。我用了一个回调机制，在会话达到暂停条件或结束边界时，把整场对话交给一个专门的摘要模型处理。重点来了：摘要不是让模型把对话变成“今天我跟AI讨论了A、B、C”这类流水账，而是强制它抽取四类信息：

• 用户偏好：例如“不喜欢过度设计”“优先用标准库”
• 技术决策：例如“选定用SQLite做存储，不引入外部数据库服务”
• 问题与解法：例如“遇到编码问题，通过强制UTF-8解决”
• 未完成任务：例如“下一步要跑性能压测”

为了拿到可靠的摘要，我写了严格的结构化提示词。一个我踩过的坑是：第一次我图省事，直接说“总结这段对话”，结果模型给的摘要里有一半是废话，什么“用户表示理解”“AI提供了帮助”。后来我把抽取目标固定为四类，每条输出限制在一两句话内，并明确禁止出现寒暄类信息，质量立刻上来了。

2.3 存储与向量化：SQLite做底座，向量做检索

摘要和关键事实生成之后，写入本地SQLite数据库，同时为每条记录生成一个嵌入向量。向量化这一步是为了后续“想起”时有索引可以找。我用的是轻量级嵌入模型，把每条记忆文本转成固定维度的向量，存在向量字段里。检索的实质是余弦相似度计算，新会话开头把用户当前的第一句话也转成向量，然后和已有记忆做相似度排序，取top-K条注入系统提示。

选择SQLite而不是重型数据库，是因为记忆层本质是单机本地工具，数据量级撑死了几万条，SQLite完全够用，部署起来还零成本。向量检索则借助SQLite的向量扩展完成，不用额外搭向量数据库服务。这套组合让我在整个记忆管道里不用依赖任何外部网络服务，所有东西都在本地跑。

2.4 注入方式：既要“想起来”，也不能“刷存在感”

检索出记忆之后，怎么注入也很有讲究。我是把“已知记忆”统一追加在系统提示的末尾，并用明确的分隔标签包起来。注入的开头固定写“以下是与当前问题相关的历史记忆，请参考但不要机械复述”，这个限定句非常关键。没有它，模型有时候会直接把记忆内容原样念出来，回答显得非常傻。加上之后，模型会把记忆当作内部参考，自然融入自己的推理过程。

我测试过的注入条数上限是五条。超过五条，模型的判断力会明显下降，它搞不清哪条更重要。所以检索阶段宁可漏掉几条，也不要贪多。

3. 从安装到首条记忆落库：一套可复现的搭建过程

3.1 环境准备：依赖与版本

先说环境。我建议直接用Python 3.10以上版本，省得处理旧版本的类型标注兼容问题。核心依赖就三块：SQLite向量扩展、嵌入模型库、以及claude-mem本身的命令行工具。直接看安装示例：

# 推荐用虚拟环境隔离 python -m venv .venv source .venv/bin/activate # 安装核心包 pip install claude-mem sqlite-vec sentence-transformers

这里我要特别提一句：安装完之后建议验证一下SQLite扩展是否真的加载成功。我第一次装的时候没验证，跑了一个小时发现检索一直报“unknown function”，最后查出来是扩展虽然装了，但maria对不上版本。验证扩展是否可用就一行命令：

python -c "import sqlite_vec; print(sqlite_vec.loadable_path())"

看到输出路径就是好的，否则先去解决依赖版本问题。

3.2 初始化配置：记忆库路径和模型选择

claude-mem 初始化的时候会生成一个配置文件，主要字段如下：

memory: sqlite_path: ~/.claude-mem/memory.db embed_model: BAAI/bge-small-zh-v1.5 similarity_threshold: 0.5 max_injections: 5 ttl_days: 90

重点说一下两个参数。embed_model选小而快的中文嵌入模型就好，不用追求最大最强的那个，因为记忆检索的质量瓶颈往往不在模型精度，而在摘要质量和阈值设定。similarity_threshold是检索时的最低相似度门槛，我反复试下来0.5左右最平衡，低于0.4会出现大量无关记忆混进来，高于0.6又会漏掉那些“表面措辞不同但语义一致”的记忆。这两个经验值是我跑了很多轮测试才定下来的。

3.3 手工写入一条记忆并验证落库

配置好之后，最直观的验证方式是手工往里写一条记忆。我用的是命令行工具提供的写入口：

claude-mem add --content "用户明确表示在新项目中不引入重量级ORM，优先使用轻量查询构造器" claude-mem list --limit 5

list命令能直接看到刚刚写入的记录。写完之后建议去SQLite底层确认一下向量字段确实生成了，这一步能排除“只存了文本没算向量”的隐患。我一般是这么查的：

sqlite3 ~/.claude-mem/memory.db "select id, substr(embedding, 1, 8), content from memory order by id desc limit 1;"

如果embedding字段输出不是一串乱码或NULL，说明向量化成功。如果看到NULL，多半是嵌入模型没有正确加载，回到上一步去查模型依赖。

3.4 与会话工具的对接：让助手“主动想起”

记忆库本身只是个仓库，关键是接入真实的会话工作流。现在我用的方式是：在会话工具的配置里，把 claude-mem 注册为记忆提供方，并在会话开始前自动执行一次检索。大致的流程是：用户输入第一句话 → 提取文本 → 计算向量 → 检索topK → 拼接到系统提示末尾 → 模型开始正常回答。

这个流程里有一个容易忽略的细节：检索用的“当前文本”不能是空的，也不能是单纯的“你好”这种寒暄。我遇到过一次因为开场白太短、检索全落在低相关记忆上，结果AI一本正经地乱回忆。解决办法很粗暴：设置一个最短检索长度，用户开场词少于五个字时直接跳过检索，让会话自然开始。

对接完成之后，你应该能观察到第一次“回忆成功”：你提一个具体项目问题，AI的回答里带出了你几周前的一个决策。那一刻你会觉得整套搭建过程都值了。

4. 实测中遇到的四个翻车现场与修复思路

4.1 记忆碎片过多导致检索结果全是噪音

第一次真正启用 claude-mem 跑项目时，我想的是“存得越多越聪明”，于是把每轮对话都拆成记忆条写入。结果第二天新会话检索回来的top5，三条是“用户说好的我明白了”“AI提供了代码示例”这类纯流程废话，真正有价值的选型讨论反而排在后面。检索结果全是噪音，注入等于没注入。

我查了当时的存储记录，发现问题出在“什么东西该进记忆”这个口子上完全没把关。修复方式我给记忆加了一个kind字段，分三类：decision、task、fact。检索的时候只查询这三类，寒暄和过程性对话从一开始就被过滤掉，只在置信度很高时才作为辅助参考。修复之后，检索结果的噪音率直接降了八成以上。

4.2 摘要时机太早：半句话就被“截图”了

有次我在会话里刚打出一半指令，还没说完话，因为网络断了，会话被强制保存，摘要提取器立刻跑了一遍，结果把一句半截话当成完整决策存进了记忆库。更麻烦的是，这条错误记忆还带上了“用户确定”这类词，后面两天一直被检索出来反复干扰回答。

排查下来，发现根因是触发条件太激进。我原本设为“对话停止15秒后执行摘要”，但一次断网重连就直接踩中了。修复方案是改成双条件触发：既要求对话静默超过三分钟，也要求会话主题变更或主动结束。如果只是短暂停顿，不会误触发。同时我在摘要提取器里加了一个保护规则：任何以动词开头但没有宾语的不完整语句，一律不落库。

4.3 敏感信息落库风险：一次尴尬的排查

这是我最想提醒你注意的一次翻车。某天我在调试一个接口鉴权问题，直接把一个服务密钥粘进对话里测试，结果摘要提取器判定这是“技术决策”，给写进长期存档了。第二天清理记忆时看到那条记录，后背一阵发凉：如果这个库被人读走，等于密钥直接泄露。

我当时的修复动作分两步。第一，立即把那条记忆手工删掉，并全库扫描了一遍关键词。第二，在写入链路里加了一个本地脱敏过滤器，规则很简单：先扫内容里是否有疑似密钥、Token、AK/SK形式的字符串，有就直接拒绝写入，不做任何例外。另外我开启了“内容检查模式”，对新写入的记忆做二次扫描。经验是：记忆系统的脱敏必须前置，不能指望事后清理，因为检索注入时模型会把记忆内容原样纳入推理，敏感信息一旦进入记忆库，它就是系统提示的一部分了。

注意：任何接入记忆层的会话工具，都要在写入前对内容做敏感信息检测，把“可能包含密钥、口令、个人隐私”的内容挡在记忆库之外。

4.4 模型回滚导致的向量维度不匹配

第四个坑是模型版本变动引起的。有一次我把嵌入模型从一个版本换成另一个不同维度的模型，忘了重建历史索引，结果检索时直接报向量维度不一致的异常，整个记忆层瘫了一下午。特征很明显：历史记忆还在库里，但相似度计算全部失败，新会话注入的记忆永远为空。

根因是SQLite向量扩展对索引和查询的维度有严格一致性要求。修复方案分两步：第一步是回滚嵌入模型配置，恢复原有维度；第二步是写一个小脚本，遍历历史记忆重新生成向量并更新索引。之后再换模型时，我会在配置里记录“模型版本号”，检索前自动校验当前模型和历史索引的维度是否一致，不一致就触发全量重建。这个校验逻辑看上去很基础，但能避免一整个下午的排查时间。

5. 记忆系统的调优经验：检索阈值、过期策略与持续维护

5.1 相似度阈值怎么调：不只看分数，还要看场景

关于阈值，我在前面已经给了0.5这个默认值，但它不是僵死的。实际调优时，我会把检索结果往“类目”上分：如果是在写代码的具体节点上提问，阈值往0.55调，只找精确相关的技术决策；如果是在做方案头脑风暴，阈值往0.45调，让更宽泛的背景记忆也能参与进来。一个完整的调优做法是先跑一周，统计每天被注入的记忆条数，以及“AI主动提及历史记忆的次数”，据此微调阈值。我发现如果AI每天完全想不起历史，多半是阈值偏高；如果回答里频繁出现历史线索，有时候反而不是坏事。

5.2 过期策略别贪复杂：三个月归档加重点打标就够了

我在记忆库的过期策略上走过弯路。最开始设计了TTL、热冷分层、相似记忆自动合并，听起来很完善，结果维护成本极高，还引入了两个莫名其妙的bug。后来我把整套逻辑简化成两条规则：第一条，普通记忆默认存活90天，到期后自动归档到单独的备份表，不再参与检索；第二条，每条记忆创建时可以选择“重要”标签，打上标签的永久保留，不受过期影响。这个方案运行了一个月没有出过问题。

具体怎么区分哪些记忆值得打标签？我在摘要提权阶段就埋了一个字段，让摘要模型判断“这条信息是否影响未来决策”，只有它判定为“影响未来”的内容才会打上重要标签。说白了，我们要的是弹簧：该回收的回收，该长期服从的长期服从，不要试图让系统记住一切。

5.3 日常巡检技巧：每周看一眼，别等崩了再查

最后说说日常维护。我会每周花五分钟做一次三查：查记忆总量、查重复度、查失效情况。查总量直接看数据库记录数，查重复度用一个小脚本对相似记忆做聚类，重复率高于20%就说明提取口径可能太宽松。还有一个实用技巧是定期清理“同一句话换几个说法”的记忆，这类冗余会稀释检索精度，宁可砍掉也不要留。

我日常巡检最常用的一条查询是：

select kind, count(*) from memory where created_at > datetime('now', '-7 days') group by kind;

如果task类占比过高，说明最近工作强度大但有效决策少；如果decision类突然暴涨，我会检查是不是把“对话中的普通偏好”误判成了技术决策。巡检的过程不需要很复杂，但一定要有规律，等系统彻底崩了再回头看，代价高得多。

5.4 从个人工具到项目协作的扩展建议

如果你只是给个人使用，上面的配置已经足够了。但如果你打算让记忆层服务于一个项目团队，我有两个额外建议。第一，记忆库不要放在个人目录，改放到项目的共享存储位置，并且用SQLite的WAL模式支持并发读取。第二，写入记忆时加一个“作者”标签，方便追溯这条记忆是谁在什么场景下写的。我实测下来，多人共享时最大的问题不是存储，而是“记忆优先级”冲突：A同事觉得重要的信息，B同事可能觉得是噪音。打上作者和场景标签之后，检索时可以按当前使用者过滤优先级，冲突明显减少。

到现在，claude-mem 这套记忆层我已经稳定跑了将近两个月。我最满意的一次表现是：在新项目第三周的新会话里，我随口问了一句“现在的迁移方案要不要优化”，AI 主动提起了第二周时我强调过的“不要在迁移途中换底层库”这条决策。那一刻你能明显感觉到，它不再是“失忆工具”，而是一个真的在跟着你走一段路、记得住你每个重要抉择的搭档。如果你也受够了反复解释项目背景、反复强调同一件事，真心建议照着这篇的思路亲手搭一套记忆层——它需要的准备工作不多，但带来的连续性体验，是单纯换个大模型根本无法替代的。