企业官网建设流程全解析

1. 为什么「本地 AI 记忆」值得认真做一次

先把概念说清楚。所谓本地 AI 记忆，指的是把 AI 对话过程中产生的上下文、偏好、事实、决策记录等，以结构化或半结构化的形式，持久化保存在用户自己的设备或私有环境里，而不是全部丢给云端模型服务商。它要解决的核心问题很朴素：今天跟 AI 聊过的东西，明天它还记得；换一个客户端，记忆还能跟着走；敏感信息不出本机。

我接触这个方向，最初是因为自己用 AI 写代码和整理资料，反复遇到同一个尴尬——每次开新会话，都要重新交代项目背景、技术栈、命名习惯、目录结构。一次两次还行，次数多了就烦。后来我尝试用本地文件做简单的上下文注入，再后来接触到MCP（Model Context Protocol）这类协议，才意识到「记忆」不该是某个 App 的私有功能，而应该是一层可被多个工具复用的基础设施。

这个项目适合谁来参考？三类人。第一类是有产品想法但缺工程落地能力的独立开发者，你需要一个技术合伙人把记忆层做扎实；第二类是有后端或客户端经验、想切入 AI 工具链的工程师，本地记忆是一个很好的练手场景；第三类是已经在做 AI 应用、被上下文管理折磨过的团队，想看看别人怎么拆这个问题。下面我会把「找技术合伙人」和「把本地 AI 记忆做出来」这两件事揉在一起讲，因为这两件事在早期是分不开的。

2. 项目整体设计与思路拆解

2.1 先想清楚「记忆」到底存什么

很多人一上来就说要做向量数据库，我觉得这是把手段当成了目标。记忆系统真正要回答的是：哪些信息值得长期保留，哪些只是当前会话的临时状态。我的划分方式是三层。

第一层是会话内上下文，就是当前这轮对话的临时信息，会话结束就可以丢。第二层是用户偏好与事实，比如「我习惯用 Python 而不是 Node」「我的项目根目录在 D 盘某个路径」「我讨厌冗长的解释」。这类信息需要跨会话保留，而且更新频率低。第三层是项目级知识，比如某个代码库的架构决策、某份文档的结论、某次调试的根因。这类信息量大、结构复杂，需要检索。

把这三层分开之后，存储选型就清晰了。会话内上下文放内存；偏好与事实放本地结构化存储，SQLite 就够；项目级知识才需要向量检索或全文检索。我见过不少项目一上来就全量向量化，结果偏好这种短文本被切得七零八落，检索出来全是噪声。

2.2 为什么选 MCP 作为对外接口

MCP这两年被讨论得很多，从编辑器插件到逆向工具、从数据库到地图服务，都在往这个协议上靠。它本质上是给 AI 客户端和外部能力之间定了一套标准通信方式。对本地记忆来说，选 MCP 的最大好处是解耦：记忆层只负责存和取，具体是哪个客户端来调用、调用后怎么展示，不归它管。

我试过两种做法。一种是把记忆逻辑直接写进某个客户端的插件里，快是快，但换客户端就得重写。另一种是把记忆做成独立的 MCP 服务，客户端通过标准协议连接。后者前期麻烦一点，但一旦跑通，任何支持 MCP 的客户端都能接进来。这也是我建议技术合伙人优先做的事——先把协议层定下来，别急着做 UI。

2.3 技术合伙人的分工边界怎么划

找技术合伙人，最怕的是「两个人都在做同一件事」或者「谁都不愿意碰脏活」。我的建议是按数据流分工，而不是按「前端后端」这种粗粒度分。一个人负责写入链路：怎么从对话里抽取值得记的信息、怎么去重、怎么落库。另一个人负责读取链路：怎么根据当前问题召回相关记忆、怎么排序、怎么注入回上下文。

这样分的好处是接口清晰，写入方只需要保证「存进去的东西是干净的」，读取方只需要保证「取出来的东西是相关的」。中间用一层明确的数据结构隔开，谁改都不影响对方。如果只有两个人，产品定义和对外沟通可以由发起人兼着，但写入和读取这两条链路最好各有一个明确负责人。

3. 核心细节解析与实操要点

3.1 记忆写入：抽取比存储难得多

存储本身没有技术含量，难的是判断什么值得记。我的做法是给每条候选记忆打两个分：重要性和稳定性。重要性看它是否影响后续决策，稳定性看它是否会频繁变化。

举个例子，「我今天想用 Rust 写这个模块」重要性中等、稳定性低，可能明天就变了，这种只适合放会话内。「这个项目统一用 4 空格缩进」重要性中等、稳定性高，值得长期保留。「用户对某个技术方案有明确偏好」重要性和稳定性都高，必须记。

实操上，我建议先用规则做一轮过滤，再让模型做一轮判断。规则过滤负责砍掉明显无意义的寒暄和重复内容，模型判断负责处理语义层面的取舍。这里有个坑：不要让模型直接决定「存或不存」，而是让它输出一个分数和理由，由代码根据阈值决定。这样阈值可以调，模型换了也不影响整体逻辑。

注意：写入链路一定要做去重。我踩过的坑是同一句偏好被反复记录，检索时全是重复项，把真正有用的信息挤下去了。去重可以用文本相似度，也可以用「同一主体+同一属性」的键值覆盖。

3.2 记忆读取：召回质量决定体验上限

读取链路的核心是召回和排序。召回负责「别漏」，排序负责「别乱」。召回阶段我一般同时走两条路：一条是关键词或全文检索，负责精确匹配；一条是向量检索，负责语义相近。两条路的结果合并后再排序。

排序不能只看相似度。我的经验是加三个权重：时间衰减（越新的记忆权重越高）、访问频率（被召回过的记忆说明有用）、来源可信度（用户明确说的比模型推断的可信）。这三个权重怎么调，没有标准答案，得靠实际使用慢慢磨。我一般先给一个保守的初始值，然后观察召回结果里有多少是「明显不相关」的，据此调整。

还有一个细节：注入回上下文的记忆不能太多。模型的上下文窗口是有限的，塞太多反而稀释了当前问题的信息。我的做法是设一个 token 预算，比如最多占上下文的 20%，超了就按排序砍掉尾部。

3.3 本地存储选型：别过度设计

存储这块我见过太多过度设计的案例。有人一上来就上分布式向量库，结果单机跑都费劲。对绝大多数本地记忆场景，我的推荐是：

SQLite 被低估得很厉害。它支持全文检索扩展，单机性能足够，而且数据就是一个文件，用户备份、迁移都方便。向量库我倾向于选能嵌入进程的，不要选需要单独起服务的，否则用户装个记忆功能还得先跑一个后台进程，体验很差。

3.4 隐私边界要在设计阶段就划好

本地记忆最大的卖点就是隐私，但如果设计不当，隐私就是一句空话。我的原则是：默认不出本机，出本机必须显式授权。具体来说，记忆的存储、检索、注入都在本地完成；只有当用户主动选择把某段记忆同步到别处时，才涉及网络传输，而且要有明确的确认步骤。

还有一个容易被忽略的点：记忆里可能混入敏感信息。比如用户随口提到的密钥、路径、内部代号。写入链路应该有一层敏感信息检测，命中就标记为「不参与跨设备同步」或者直接拒绝存储。这层检测不需要很复杂，正则加关键词表就能覆盖大部分情况。

4. 实操过程与核心环节实现

4.1 从零搭一个最小可用的记忆服务

我建议第一版不要追求功能完整，先跑通「写入-存储-召回-注入」这条最小闭环。下面是我实际用过的一个搭建顺序。

第一步，定义记忆的数据结构。我用的是一个简单的表结构，核心字段包括：唯一 ID、内容、类型（偏好/事实/知识）、创建时间、最后访问时间、访问次数、重要性分数、稳定性分数、来源。这个结构不复杂，但覆盖了后续排序需要的所有信息。

第二步，实现写入接口。输入是一段对话文本，输出是若干条结构化记忆。内部先做规则过滤，再调用模型打分，最后按阈值决定是否落库。落库前做一次去重检查。

第三步，实现召回接口。输入是当前问题，输出是排序后的记忆列表。内部并行走全文检索和向量检索，合并去重后按加权分数排序，最后按 token 预算截断。

第四步，把它包装成 MCP 服务。定义两个工具：一个用于写入，一个用于召回。客户端连接后就能调用。这一步做完，你就有了一个可以被多个客户端复用的记忆层。

4.2 关键参数的计算与选择

排序分数怎么算，我给一个我实际用过的公式，你可以作为起点：

score = w1 * 相似度 + w2 * 时间衰减 + w3 * 访问频率 + w4 * 重要性

其中时间衰减我用的是指数衰减，半衰期设成 30 天。也就是说一条 30 天前的记忆，时间权重降到一半。访问频率做对数压缩，避免高频记忆一家独大。四个权重我初始设成 0.5、0.2、0.15、0.15，然后根据实际召回效果微调。

token 预算这块，我一般按当前模型上下文窗口的 15% 到 20% 来设。假设窗口是 128k，那记忆注入控制在 20k 以内。这个数字不是死的，如果当前问题很依赖历史，可以临时调高。

提示：参数一定要做成可配置的，而且要有日志记录每次召回用了哪些记忆、分数是多少。没有日志，调参就是盲猜。

4.3 一次真实的调试记录

我印象比较深的一次问题是：召回结果里总是出现大量「用户说过你好」这类无意义记忆。排查后发现是写入链路的规则过滤太宽松，把寒暄也当成候选了。修复方式是在规则层加一个「最小信息量」判断，比如内容长度低于阈值、且不含实体或偏好词的，直接丢弃。

另一次问题是召回延迟高。查下来是向量检索和全文检索串行执行，改成并行后延迟降了一半多。还有一次是记忆越存越多，检索越来越慢，后来加了定期归档，把超过一定时间且从未被召回的记忆移到冷存储，热库只保留活跃记忆。

这些问题的共同点是：都不是算法问题，而是工程细节问题。这也是为什么我说技术合伙人要能沉下心做脏活，光有想法不够。

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

5.1 记忆系统常见问题速查

5.2 找技术合伙人的几个实操建议

第一，先合作一个小任务再谈合伙。比如让对方用一周时间做一个记忆写入的原型，你来看代码质量和沟通效率。比聊十次理想都管用。

第二，把「不做什么」写清楚。早期最容易失控的是范围蔓延，今天想加多模态，明天想加团队协作。我的建议是明确写下第一版不做的功能清单，双方签字画押。

第三，股权和分工要匹配。如果对方是全职投入、负责核心链路，那和技术顾问是两回事。这块我不展开，但一定要在开始前谈清楚，别用「先做出来再说」糊弄过去。

第四，接受对方的技术判断。你提需求，他定实现。如果每个技术选型你都要插手，那不如自己学。找合伙人的意义就是补上你不擅长的那块。

5.3 几个我踩过的坑

坑一：过早追求「智能」。我一开始想让模型自动决定记什么，结果噪声太多。后来改成规则加模型打分，可控性好了很多。能确定性解决的，别交给模型。

坑二：忽略冷启动。新用户没有历史记忆，召回为空，体验和普通对话没区别。后来我加了一个「引导式记忆」，在首次使用时主动问几个问题，快速建立初始记忆。

坑三：没做记忆的可视化。用户不知道系统记了什么，就不信任它。后来加了一个简单的记忆列表页面，用户可以查看、编辑、删除。信任感一下就上来了。

坑四：把记忆和对话历史混为一谈。对话历史是流水账，记忆是提炼后的结论。两者存储和检索策略完全不同，混在一起会互相干扰。

6. 这个方向后续还能怎么扩展

把最小闭环跑通之后，扩展方向其实很多。我列几个我觉得有价值的。

一是记忆的跨设备同步。本地优先不等于永远单机，用户换设备时希望记忆能跟着走。这里的关键是端到端加密，同步的是密文，密钥在用户手里。

二是记忆的共享与协作。团队场景下，某些项目知识应该被多人共享。这需要引入权限模型，区分个人记忆和团队记忆。

三是记忆的生命周期管理。什么记忆该遗忘，什么该强化，这本身是个值得研究的问题。我倾向于让用户有最终控制权，系统只提供建议。

四是和更多工具的集成。MCP 生态在快速扩张，从编辑器到数据库工具都在接入。记忆层作为基础设施，接入的工具越多，价值越大。

如果你正在找技术合伙人做这件事，我的建议是先把最小闭环做出来，用真实使用数据说话，再谈扩张。想法不值钱，跑通的闭环才值钱。