企业官网建设流程全解析

1. 这个项目到底在做什么：从「本地 AI 记忆」说起

先把话说直白一点：所谓「本地 AI 记忆」，就是让 AI 记住你、记住你们之间的对话、记住你的偏好和习惯，而且这些记忆数据存在你自己的设备上，而不是躺在某家公司的服务器里。你换一个对话窗口、换一个模型、甚至换一个工具，它依然能认出你、接着上次的话题往下聊。这件事听起来简单，做起来却是一整套系统工程。

我最早接触这个方向，是因为自己用 AI 写代码、写方案、做资料整理，每次开新会话都要重新交代背景，烦得不行。后来试过把历史对话导出成文本，手动喂给模型，结果上下文一长就崩，检索也不准。再后来接触到MCP（Model Context Protocol）这套思路，才意识到「记忆」不该是往提示词里硬塞，而应该是一个独立的、可检索、可管理的本地数据层。标题里提到的HyperMarrow，从命名和社区讨论来看，大概率就是围绕「本地记忆存储 + 检索 + 注入」这条链路做的一套方案或框架。

那这个项目适合谁？我认为有三类人值得认真看：第一类是想做个人 AI 助手、但不想把隐私交出去的独立开发者；第二类是想找技术合伙人、把想法落地的产品型创业者；第三类是对 MCP 生态感兴趣、想找一个具体场景练手的技术人。如果你属于其中任何一类，下面这些内容应该能帮你少走不少弯路。

需要先说明的是，标题本身是一个「求建议」的提问，所以这篇东西不会给你一个标准答案，而是把我理解的技术拆解、合伙人匹配、落地路径、踩坑经验摊开来讲。很多细节是基于常见工程实践的合理补全，不是官方文档，你按自己的实际情况取舍。

2. 技术合伙人这件事，先想清楚你要的是哪种人

2.1 先分清「技术合伙人」和「外包」的边界

很多人一上来就说要找技术合伙人，其实心里想的是「找个便宜的程序员帮我把东西做出来」。这两者差别巨大。外包是你定义需求、他交付代码、钱货两清；技术合伙人是你们共同承担风险、共同定义产品、共同面对不确定性。本地 AI 记忆这个方向，最大的不确定性在于：产品形态还没定型。你今天觉得应该做成一个桌面应用，明天可能发现做成一个 MCP 服务更合理。这种反复横跳，外包受不了，合伙人才能扛。

所以你在找人之前，先问自己三个问题：第一，我能不能把「为什么做这件事」讲清楚，而不只是「做什么功能」；第二，我愿不愿意让出足够比例的股份，而不是只给一点辛苦费；第三，我能不能接受技术伙伴对产品方向提出反对意见。这三个问题有一个答不上来，你找的就不是合伙人，是员工。

2.2 本地 AI 记忆项目需要哪些技术能力

这个方向的技术栈其实挺杂的，我把它拆成几块，你可以对照着看自己缺什么、要找什么样的人。

从这张表能看出来，记忆抽取与压缩和隐私加密是最难外包的两块，因为它们直接决定产品的核心体验和信任基础。如果你自己不懂这两块，那你的技术合伙人必须至少精通其中一块，另一块可以慢慢补。至于 MCP 对接和桌面工程，属于「有经验就能做」的范畴，找对人就行。

2.3 去哪里找，怎么判断靠不靠谱

渠道上，我个人的经验是：技术社区 > 开源项目贡献者 > 熟人推荐 > 招聘平台。原因很简单，本地 AI 记忆这个方向偏极客，真正感兴趣的人往往已经在某个开源项目里折腾类似的东西了。你可以去翻一翻和 MCP、向量检索、本地模型相关的开源仓库，看谁的提交质量高、issue 回复认真，这种人比简历上写「精通 AI」的靠谱得多。

判断靠不靠谱，我一般看三点：第一，他有没有自己动手做过一个完整的小东西，哪怕很粗糙；第二，他能不能用大白话把「向量检索为什么比关键词检索更适合记忆」讲明白；第三，他对「数据存在本地」这件事有没有自己的坚持。第三点特别重要，如果一个人对这个产品的隐私价值无感，他做出来的东西大概率会偷偷把数据传到云端。

提示：第一次合作不要直接谈股份，先一起做一个小原型，比如「把最近 100 条对话存进本地库并能按语义检索出来」。两周内能跑通，再谈 deeper 的合作。

3. 核心技术拆解：本地 AI 记忆到底怎么实现

3.1 记忆的分层：不是所有东西都值得记

很多人做记忆系统的第一个误区，就是「什么都记」。结果记忆库越来越大，检索越来越慢，注入到模型里的内容越来越杂，效果反而变差。我的做法是把记忆分成三层：

• 短期记忆：当前会话的上下文，通常就是对话历史，不需要持久化，会话结束就丢。
• 中期记忆：最近几天或几周内发生的事，比如「用户昨天在做一个 Python 项目」，需要持久化，但可以定期压缩。
• 长期记忆：稳定的偏好、身份信息、重要事实，比如「用户偏好用中文回答」「用户是后端工程师」，这些要长期保留，且优先级最高。

分层的意义在于，检索的时候可以按优先级和时效性加权。短期记忆直接进上下文，中期记忆按相关性检索，长期记忆则几乎每次都带上。这样既控制了 token 消耗，又保证了关键信息不丢。

3.2 记忆的抽取：从对话里「捞」出有用的东西

抽取是整套系统里最考验功力的环节。简单做法是用规则，比如检测到「我喜欢」「我习惯」「记住」这类词就触发抽取。但规则太死，容易漏也容易误判。更稳的做法是用一个小模型做抽取，给它一个固定的提示词模板，让它输出结构化的 JSON。

我常用的抽取模板大概长这样：

{ "type": "preference | fact | event | task", "content": "用户偏好用中文回答", "confidence": 0.92, "source": "conversation_id_123", "timestamp": "2025-01-01T10:00:00Z" }

这里有几个细节值得注意。confidence字段很重要，低置信度的记忆可以先存着但不主动注入，等后续对话验证后再提升权重。source字段用于溯源，万一记忆出错，你能知道它是从哪句话里抽出来的。timestamp用于时效性加权，越新的记忆权重越高。

抽取的时机也有讲究。我试过实时抽取和会话结束批量抽取两种方案。实时抽取响应快，但会打断对话流；批量抽取对用户体验更友好，但需要处理会话中断的情况。最后我选了「实时轻量抽取 + 会话结束深度抽取」的混合方案，轻量抽取只抓高置信度的偏好和事实，深度抽取做更全面的整理和去重。

3.3 存储与检索：向量库不是唯一答案

一提到记忆存储，很多人第一反应就是向量数据库。向量检索确实适合语义相似度匹配，但它不是万能的。我的实际经验是：向量检索 + 关键词检索 + 结构化过滤三者结合，效果最好。

向量检索负责「意思相近」，比如用户说「我不爱吃辣」，向量能匹配到「用户偏好清淡饮食」。关键词检索负责「精确命中」，比如用户提到某个具体的项目名、人名。结构化过滤负责「范围限定」，比如只检索最近 30 天的记忆，或者只检索某个类型的记忆。

存储选型上，个人项目我推荐 SQLite + 向量扩展（比如 sqlite-vec），轻量、单文件、好备份。如果数据量大，可以考虑 LanceDB 或 Chroma 这类嵌入式向量库。不建议一上来就上 Postgres + pgvector，除非你确定要做多用户服务，否则运维成本不划算。

检索的排序策略也很关键。我一般用加权公式：

score = 0.5 * 语义相似度 + 0.3 * 时效性权重 + 0.2 * 类型优先级

这个权重不是拍脑袋定的，是调出来的。语义相似度占大头，因为相关性最重要；时效性权重保证新记忆优先；类型优先级让长期偏好比临时事件更容易被选中。你可以根据自己的场景调整，但建议先从这个比例开始试。

3.4 MCP 的角色：让记忆成为可插拔的能力

MCP 这套协议的价值，在于它把「记忆」从某个具体应用里解耦出来，变成一个独立的服务。任何支持 MCP 的客户端，都能通过标准接口读写记忆。这意味着你不需要为每个 AI 工具单独做适配，只要它们支持 MCP，就能共享同一份本地记忆。

实现一个 MCP 记忆服务，核心是暴露几个工具方法：memory_write、memory_search、memory_delete、memory_list。客户端调用这些方法，服务端负责实际的存储和检索。协议本身是 JSON-RPC 风格的，实现起来不算复杂，但要注意错误处理和超时控制。

注意：MCP 服务跑在本地，意味着它和客户端在同一台机器上。如果你的客户端是浏览器，那还需要一个本地桥接层，因为浏览器不能直接起本地进程。这是很多人第一次做 MCP 时容易忽略的点。

4. 实操路径：从零到能用的最小闭环

4.1 第一步：搭一个能存能查的本地库

先别想太复杂，目标就是「把一段文本存进去，能按语义查出来」。我用 Python 举例，依赖就两个：sqlite-vec和sentence-transformers。

import sqlite3 import sqlite_vec from sentence_transformers import SentenceTransformer model = SentenceTransformer('all-MiniLM-L6-v2') db = sqlite3.connect('memory.db') db.enable_load_extension(True) sqlite_vec.load(db) db.execute('CREATE VIRTUAL TABLE IF NOT EXISTS memories USING vec0(embedding float[384])') db.execute('CREATE TABLE IF NOT EXISTS memory_meta (id INTEGER PRIMARY KEY, content TEXT, type TEXT, ts INTEGER)') def add_memory(content, mem_type='fact'): emb = model.encode(content).tolist() cur = db.execute('INSERT INTO memory_meta (content, type, ts) VALUES (?, ?, strftime("%s","now"))', (content, mem_type)) db.execute('INSERT INTO memories (rowid, embedding) VALUES (?, ?)', (cur.lastrowid, emb)) db.commit() def search_memory(query, top_k=5): emb = model.encode(query).tolist() rows = db.execute('SELECT rowid, distance FROM memories WHERE embedding MATCH ? ORDER BY distance LIMIT ?', (emb, top_k)).fetchall() return [(r[0], r[1]) for r in rows]

这段代码跑通，你就有了最核心的存储和检索能力。模型选all-MiniLM-L6-v2是因为它小、快、够用，384 维的向量在个人场景下完全够。如果你追求更好的中文效果，可以换成bge-small-zh之类的模型，但维度会变，建表时要对应改。

4.2 第二步：把对话接进来，自动抽取记忆

有了库，下一步是让记忆自动产生。我一般写一个抽取函数，输入是一段对话，输出是若干条结构化记忆。

EXTRACT_PROMPT = """从下面的对话中提取值得长期记住的信息。 只提取偏好、事实、重要事件，不要提取寒暄和临时内容。 输出 JSON 数组，每项包含 type、content、confidence 三个字段。 对话： {dialogue} """ def extract_memories(dialogue, llm_call): resp = llm_call(EXTRACT_PROMPT.format(dialogue=dialogue)) items = parse_json(resp) for item in items: if item['confidence'] > 0.7: add_memory(item['content'], item['type'])

这里的llm_call可以是本地模型，也可以是云端 API。如果你坚持全本地，可以用 Ollama 跑一个小模型，比如 qwen2.5:3b，抽取任务对模型能力要求不高，小模型够用。置信度阈值 0.7 是我试出来的经验值，太低会引入噪音，太高会漏掉有用信息。

4.3 第三步：检索结果注入对话上下文

记忆存了、能查了，最后一步是把它用起来。每次用户发消息，先检索相关记忆，拼进系统提示词里。

def build_context(user_input): memories = search_memory(user_input, top_k=5) texts = [get_content(mid) for mid, _ in memories] context = "\n".join(f"- {t}" for t in texts) return f"以下是关于用户的已知信息，回答时请参考：\n{context}\n\n用户说：{user_input}"

这一步看似简单，但有几个坑。第一，注入的记忆不能太多，否则会挤占正常对话的上下文空间，我一般控制在 5 条以内。第二，注入的内容要标注来源，让模型知道这是「背景信息」而不是「用户当前说的话」。第三，要处理记忆冲突，比如旧记忆说用户喜欢 A，新记忆说用户不喜欢 A，这时候应该以新记忆为准，或者干脆都注入让模型自己判断。

4.4 第四步：封装成 MCP 服务

前三步跑通后，把它封装成 MCP 服务就是水到渠成的事。核心是把add_memory、search_memory这些函数暴露成 MCP 工具。协议层可以用现成的 SDK，Python 和 TypeScript 都有官方实现。封装完之后，任何支持 MCP 的客户端都能接入你的记忆库，这才算真正实现了「本地 AI 记忆」的跨工具共享。

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

5.1 记忆检索不准，怎么办

这是最高频的问题。排查思路我一般按这个顺序走：先看 embedding 模型是否适合你的语言和场景，中文场景用英文模型效果会打折；再看检索的 top_k 是不是太小，导致相关记忆没被召回；然后看排序权重是否合理，有时候语义相似度高但时效性差的记忆挤掉了真正有用的；最后看记忆本身的质量，如果抽取阶段就抽错了，检索再准也没用。

一个实用的调试技巧是：把检索结果和对应的分数打印出来，人工看几条，很快就能定位问题在哪一环。我踩过的坑是早期用了默认的余弦距离阈值，结果把很多弱相关的记忆也召回了，后来改成动态阈值才好转。

5.2 记忆越存越多，性能下降明显

这是必然的，任何只增不删的系统都会这样。解决办法有三个层次：第一，去重，相同或高度相似的记忆合并；第二，压缩，把多条相关的中期记忆合并成一条摘要；第三，淘汰，长期未被检索到的低权重记忆可以归档或删除。

我一般会定期跑一个「记忆整理」任务，比如每周一次，做去重和压缩。淘汰策略要谨慎，有些记忆可能很久不用但很重要，比如用户的身份信息。我的做法是给记忆加一个「重要度」标记，重要度高的永不淘汰，其他的按 LRU（最近最少使用）策略处理。

5.3 隐私和便利怎么平衡

本地记忆的核心卖点就是隐私，但完全本地意味着模型能力受限。我的建议是分层处理：敏感信息（身份、联系方式、私密对话）只存本地、只用本地模型处理；非敏感信息（技术偏好、公开项目信息）可以走云端模型获得更好的抽取和检索效果。这个边界要在产品设计阶段就定清楚，并且明确告诉用户。

注意：即使数据存在本地，也要考虑加密。尤其是笔记本丢失或多人共用设备的情况。SQLite 本身支持加密扩展，或者你可以对敏感字段单独加密后再存。

5.4 常见问题速查表

6. 找合伙人时最容易踩的几个坑

6.1 只谈技术，不谈产品和用户

我见过太多技术合伙的失败案例，根源都是「两个人对要做的东西理解不一致」。一个想做一个极客玩具，一个想做一个大众产品，做着做着就分道扬镳。本地 AI 记忆这个方向尤其容易这样，因为它既可以做成开发者工具，也可以做成普通用户的助手。你们必须在开始之前就明确：第一版给谁用，解决什么具体问题，成功标准是什么。

6.2 股份和分工含糊不清

技术合伙最常见的雷是「先做着，以后再谈股份」。这种模糊状态在项目顺利时没事，一旦遇到困难或者有外部投资进来，就会爆发。我的建议是：开始合作前就写清楚各自的投入（时间、资金、资源）、股份比例、决策机制、退出条款。哪怕只是一页纸的简单协议，也比口头约定强。

6.3 低估了「记忆」这件事的复杂度

很多人觉得记忆就是「存下来、查出来」，实际上从抽取、去重、压缩、检索、注入到淘汰，每个环节都有大量细节。如果技术合伙人没有做过类似的信息检索或推荐系统，他可能会严重低估工作量。你在评估他的时候，可以问他一个具体问题：「如果两条记忆内容冲突，你怎么处理？」能答上来的人，说明他真的想过。

6.4 忽略了 MCP 生态的快速变化

MCP 这个方向现在变化很快，协议在迭代，客户端支持程度参差不齐。今天能用的方案，下个月可能就有更好的替代。这意味着你的技术选型要留有余地，不要把核心逻辑和某个具体客户端绑死。找合伙人的时候，也要看他有没有「快速学习和切换技术栈」的能力，而不是只会一套东西。

7. 我个人的一些实操体会

做这个方向一年多，最大的体会是：记忆系统的价值不在于记得多，而在于记得准、用得对。我早期追求「什么都记」，结果检索出来的东西又杂又乱，反而干扰了模型。后来把抽取阈值提高、注入条数减少，效果明显变好。另一个体会是，本地记忆的用户体验很大程度上取决于「无感」——用户不应该感觉到记忆系统的存在，它应该像空气一样自然。任何需要用户手动管理记忆的设计，都是失败的。

最后分享一个小技巧：在开发阶段，给自己做一个「记忆查看器」，能直观地看到存了哪些记忆、每条记忆的权重和来源。这个东西对调试和建立直觉帮助极大，我几乎每天都要打开看几眼。等你对记忆的分布和检索效果有了手感，再去做自动化优化，方向会清晰很多。