前阵子一个朋友约我吃饭聊着聊着就开始诉苦他手里有个自认为不错的想法想做一款所有对话和记忆都留在本地的 AI 助手但他是产品出身写不了代码找了一圈技术合伙人不是被质疑方向就是聊崩在股权分配上。他问我“如果是你你会怎么找”这不是第一次有人问我类似的问题了。近半年随着 AI Agent 的概念被反复提起“记忆”成了几乎所有 AI 产品绕不开的一个词。而“本地 AI 记忆”这个方向恰好踩在隐私焦虑和 Agent 落地两个热点中间想做的人不少真正跑出来的却不多。原因往往不是技术太难而是发起人自己没想清楚项目边界也没有一套判断技术合伙人的标准导致见面聊几句就各说各话。这篇文章就是写给这类发起人的。我会把“本地 AI 记忆”这个项目拆开揉碎说清楚技术合伙人应该具备什么能力到哪里找、聊什么、怎么验证也会把我认为比较靠谱的第一版技术路线和合伙机制直接摆出来。你不需要是技术出身但读完这篇文章你至少能跟候选人在同一个频道上对话。1. 先把“本地 AI 记忆”拆开揉碎你做的到底是什么找合伙人之前必须先想清楚自己做的是什么。很多发起人挂在嘴边的话是“我要做一个有记忆的 AI 助手”但这句话的信息量几乎为零。你需要在见第一个候选人之前把“本地”“AI”“记忆”这三个词分别落成具体的产品决策。1.1 “本地”两个字的分量不是部署方式是产品立场很多人把“本地”理解成一种技术部署方式觉得就是把模型下载下来跑没什么大不了。这是最大的误解。“本地”首先是一个产品立场。它意味着用户的所有数据——对话记录、偏好、习惯、甚至思维模式——都留在用户的设备上不出门、不上云、不经过第三方服务器。这个立场天然吸引几类人注重隐私的极客、对云端数据持有不信任感的普通用户、以及有敏感数据处理需求的专业人士。但这个立场也带来实打实的技术代价。本地设备的算力远不如云端集群你不可能跑一个 70B 的大模型还指望秒回本地的生态是碎片化的Windows、macOS、Linux、iOS、Android 各自为政每一次跨平台支持都是一笔不小的工程开销本地的软件分发也更麻烦用户没有耐心去配置 Python 环境和一堆依赖。所以在跟候选人沟通之前你得先问问自己你接受这些代价吗你愿意为“数据不出设备”这个承诺牺牲多少性能和便利如果你自己都没想清楚这个问题那任何技术合伙人都没法替你回答。1.2 “记忆”不是聊天记录是 AI 的长期主义再说记忆。AI 领域过去被吐槽最多的一个点就是“没有记忆”——你上周跟它聊过的事情它这周就忘得干干净净。每次对话都是重新开始用户需要反复解释自己的背景和偏好体验非常割裂。真正的“记忆”至少分四个层次短期记忆当前这次会话里的上下文聊到一半提到的事情AI 应该记得。长期记忆跨会话的关键事实比如用户的职业、家庭情况、常用工具链。语义记忆用户的偏好和画像比如“他喜欢简洁的回答”“他讨厌 emoji”。情景记忆用户做过什么、经历了什么比如“他上周五写完了季度汇报”。一个真正好用的 AI 记忆系统应该能把这四层记忆分开管理知道哪些该长期存、哪些该过期清理、哪些需要主动向用户确认。这不是一个简单的“存起来再查出来”的工程而是一套需要设计的信息管理机制。“本地”和“记忆”结合起来其实就是一句话你的 AI 助手要像一台私人秘书它只服务你一个人记得你所有的事但从不把你的信息泄露给任何人。这个价值主张足够清晰也足够打动目标用户。1.3 这个项目的真正卖点和护城河想清楚卖点你才能跟合伙人描述“我们到底在做什么”。我认为“本地 AI 记忆”至少有三个真实的卖点隐私闭环。数据不出设备这是云上 AI 永远给不了的承诺。尤其当用户涉及健康数据、财务信息、工作机密时这个卖点是决定性的。个性化深度。因为记忆是长期积累的AI 对用户的了解会越来越深使用时间越长体验越好用户越离不开。而云端方案出于成本和合规考虑很难做到这种程度的深度个性化。离线可用。飞机上、地铁里、网络差的地方它依然正常工作。这一点在移动场景下的体验优势非常明显。护城河则来自两点一是用户数据的长期积累——用户在这个系统里沉淀的记忆数据越久迁移到别处的成本就越高二是本地运行带来的生态壁垒——一旦形成了“本地记忆本地工具调用”的飞轮后来者要复制的不只是一个功能而是一整套习惯。2. 找技术合伙人之前先给候选人画一幅“能力画像”很多发起人犯的第一个错误就是按“会写代码、懂 AI”这个模糊标准去找人。结果聊了十个人感觉“好像都行”又“好像都不合适”。这是因为脑子里没有一个清晰的能力模型。下面我把我认为比较关键的几项能力列出来你可以拿去当checklist。2.1 硬实力清单从架构到工程落地做“本地 AI 记忆”这个项目技术合伙人需要能搞定以下几件事本地推理能力。知道怎么选适合端侧的开源模型怎么用 llama.cpp、Ollama 这类工具做推理部署怎么在效果和速度之间做权衡。不需要他会训练模型但必须懂推理优化。嵌入与向量检索。记忆系统的核心是把信息向量化、存进向量数据库、在需要时检索召回。他需要熟悉 embedding 模型比如 bge、nomic-embed-text和至少一个向量数据库Chroma、LanceDB、sqlite-vec 都行。跨平台工程能力。这件事比想象中重要。如果第一个版本只支持桌面端技术栈可以简单很多一旦要上移动端整个架构的复杂度会直线上升。候选人至少要对“哪些技术栈能做到跨平台”“哪些模块需要分别适配”有清晰的判断。数据管道经验。记忆不是从天上掉下来的它来自用户的对话记录、文件、浏览器行为等数据。你得有本事把这些杂乱的原始数据清洗、结构化、抽取成有用的记忆条目。这活儿不性感但没有它记忆系统就是空中楼阁。有一类候选人要特别留意只会做大模型 API 调用、一问到本地部署就含糊其辞的“云原生 AI 工程师”。这类人做云端产品没问题但“本地”这个前提对他来说可能是一个完全陌生的世界。2.2 容易被忽略的软实力硬能力好考察软实力才决定你们能不能长期共事。根据我的经验以下三点比大多数人以为的更重要对隐私信念的认同感。做本地产品很多时候是在跟市场主流的“云端优先”思路唱反调。如果候选人本身对数据隐私无感只是把这当成一份活儿那他在遇到“把某个功能放云端更省事”的诱惑时大概率会妥协。你需要的是一个真心相信“数据应该属于用户自己”的人。产品 sense。技术合伙人不能只懂技术。他得知道为什么“记住用户偏好”比“实现一个通用向量数据库”更重要他得能在你说“我想让用户感觉这个AI懂我”的时候把它转化成具体的技术方案。完全没有产品 sense 的纯工程型选手合作起来会很累。独立决策能力。创业公司里每天都有几十个没人替你拿主意的小决定。候选人如果事事都要问“你觉得怎么办”你们的进度会慢到让人崩溃。他需要能在关键时刻拍板并且为自己的技术决策负责。2.3 什么样的候选人坚决不能碰有几种人哪怕技术再强我都不建议合作只会做 Demo、撑不起工程的。他能在一个干净环境里三天跑出一个效果惊艳的演示但一遇到真用户的各种奇怪环境、边缘条件系统就崩。这类人擅长表演不擅长建设。满嘴技术黑话、不接地气的。跟你聊天五分钟出现了五个你听不懂的英文缩写。这不一定是他水平高很可能是他习惯了用术语掩盖思路不清。好的技术合伙人应该能把复杂问题讲得连产品出身的人也能听懂。对隐私问题嗤之以鼻的。如果他说“现在大家根本不在乎隐私你看XX产品不也收集数据”赶紧打住。理念不合是合作中最难调和的问题早发现早止损。3. 找人的渠道和第一轮判断聊什么、怎么看画好了能力画像接下来是实操环节去哪里找、怎么聊、怎么判断。这部分我尽量给出可以直接用的方法。3.1 渠道别去招聘网站去代码和讨论发生的地方指望在 Boss 直聘上搜到靠谱的技术合伙人概率不大。真正优秀的技术人很少刷招聘软件他们活跃在代码、讨论和信息流动的地方。我建议重点关注几个通道GitHub 上的活跃维护者。去搜本地 AI 相关的开源项目比如 Ollama、llama.cpp、Chroma 的贡献者列表看看那些持续提交、有质量评论的人。这些人不仅有实战经验而且大概率对本地 AI 有真兴趣。Hugging Face 和各类 AI 社区的活跃用户。注意不是灌水的那种而是认真回答问题、分享实战经验的人。线下 meetup 和黑客松。这类场合见到的人是三维的你能感受到他说话的方式、跟别人互动的状态比线上看简历可靠得多。技术博客作者。写“我如何用树莓派跑本地大模型”这类实操文章的人通常既有动手能力也愿意分享是很好的潜在合伙人。一个比较实用的技巧不要只盯住“最厉害的那个”可以多联系几个技术背景不错、但当前工作成就感不强的人。创业公司需要的是跟你一起成长的人不一定是行业大牛。3.2 第一轮聊天的几个关键问题第一次见面别聊情怀、别聊使命、别聊“我们要改变世界”。你应该聊具体的、能看出对方真实水平的问题。以下是我觉得比较好用的几个“如果要给这个 AI 助手设计记忆你会怎么决定‘什么该记住、什么该忘’”“当向量检索召回的结果明显不相关时你打算怎么办有没有兜底方案”“你怎么看待在端侧跑模型和调用云端大模型 API 之间的选择在什么情况下你会愿意妥协”“讲一个你最近踩过的最大的技术坑后来怎么爬出来的”这些问题没有一个标准答案但聊完之后你基本能判断出对方是“真做过”还是“想当然”。真正有经验的人会给你讲具体的场景、具体的取舍、甚至具体的报错信息没经验的人只能给你讲概念和大道理。3.3 用“最小评估项目”测试候选人聊天可以筛选掉一半不合适的人但真正靠谱的判断来自一起做一件小事。我强烈建议在正式谈合作之前给候选人布置一个一两周内能完成的“最小评估项目”。比如“帮我在你本机跑通一个 Ollama 向量数据库的迷你记忆系统实现‘记住我告诉你的三件事下次对话时能答出来’。”评估的时候不要只看结果更要看过程他有没有留下清晰的 README方便别人复现遇到问题时他是会自己研究文档还是第一反应问你怎么办他对“用户不是程序员”这件事有没有意识愿不愿意把使用门槛降到最低实际情况是很多人会在这个阶段退缩——嫌任务太简单没意思或者觉得这是“免费试稿”。提前说清楚这不是试稿而是双方互相验证的“技术约会”本身就是一次价值观筛选。真正对项目有兴趣、也务实的人不介意花两周时间证明自己。4. 技术路线第一版怎么设计MVP 从哪开始切假设你找到了合适的技术合伙人接下来进入更实际的话题第一版到底做什么、技术栈怎么选、记忆系统怎么搭最合理。虽然你可能不写代码但理解了这条路线你既能参与讨论也能避免被带偏。4.1 MVP 的边界别一上来就做“通用记忆框架”我做技术咨询这几年见过最多的失败模式就是发起人一上来就要做“完整的记忆系统”支持对话记忆、文件记忆、浏览器历史、日程记忆还要跨端同步。这个体量对只有两个人的创业团队来说基本等于宣布死刑。第一版必须窄。我建议只锁定一个最痛、最具体的场景比如“一个桌面端聊天助手能记住用户告诉它的个人偏好和工作信息下次对话时主动用上”。这个场景足够小但已经能把整个记忆闭环跑通信息进来、抽取、存储、召回、在对话中使用。验证的指标也很清晰用户第二次使用的时候是不是觉得“这个 AI 居然记得我”。4.2 推荐技术栈与理由尽量抄作业的选型以下是我认为现阶段做端侧 MVP 最省力的技术选型组合理由一并写清楚模型运行框架Ollama。理由安装简单、配置少、跨平台支持好适合产品原型期快速验证。后期如果需要极致的端侧性能可以迁移到 llama.cpp 自己做更细的优化但那是后话。开源基座模型Qwen 或 Llama 3 的 7B~8B 量化版本。理由在消费级 CPU/GPU 上能跑效果在端侧模型里是第一梯队中文支持也比很多外国模型好。嵌入模型bge-m3 或 nomic-embed-text。理由中文效果好、体积不大、社区资料多。嵌入模型选择直接影响召回质量千万别随便拿一个 text2vec 老模型糊弄。向量数据库sqlite-vec 或 LanceDB。理由这俩都是嵌入式向量库不需要单独开服务安装零负担适合桌面应用。Chroma 也可以备选但当前项目早期没有太多高级特性需求够用就行。应用外壳Tauri 优先如果你跟合伙人愿意啃一下 Rust退而求其次选 Electron。理由Tauri 打包体积小、资源占用低更适合本地应用。但如果合伙人说“我只熟 Electron能快一倍”那听他的——MVP 阶段速度优先技术栈的洁癖不是第一位的。注意上面这套选型不是唯一答案但它是一个被很多人验证过、坑相对少的组合。MVP 阶段纠结技术栈的时间应该控制在三天以内剩下的力气全部用来实现功能。4.3 记忆系统的三个核心环节写、存、取不管用什么技术栈记忆系统都绕不开下面三个环节技术上能不能打通就看这三件事记忆的写入。什么值得记这是记忆系统里最难也最关键的一步。你不能把用户的每一句话都存下来那样既浪费空间又会把检索质量拖垮。需要有一个“记忆抽取”层从对话中提炼出结构化的信息。比如用户说“我在一家跨境电商公司做运营负责东南亚市场”系统应该抽取出“职业跨境电商运营”“负责市场东南亚”这样结构化的事实。MVP 阶段可以用大模型来抽取但要注意控制 Prompt 的成本和时延。记忆的存储。抽出来的信息不能随便堆在一起要分层。核心事实可以存成结构化的键值对或关系表对话片段、原文引用则需要向量化之后存入向量库每条记忆要带上时间戳和来源为后续的更新和遗忘提供依据。记忆的召回。对话时怎么把相关记忆找出来一般做法是每次用户发来新消息先把消息转成向量在向量库里做相似度检索找出最相关的若干条记忆连同当前对话一起拼进 Prompt 送给大模型。这里有个细节容易被新手忽略相关性和时效性的平衡。一个五年前的记忆就算跟当前话题百分之百匹配也不一定还适合直接用。所以召回结果最后要加一道重排结合时间和上下文综合打分。4.4 这一版最容易踩的三个坑按老规矩我把自己见过的实际项目里最容易翻车的地方挑出来说一下没有专门设计记忆的“遗忘”机制。只写不删时间长了向量库会越来越脏召回准确率肉眼可见地下降。至少要有“根据时间衰减权重”“用户直接删除”“相似记忆覆盖”这三种遗忘路径。忽略“记忆的确认”环节。AI 主动记错了信息用户纠正起来非常难受。好的产品应该在写入关键记忆时向用户展示“我记住了这件事”让用户有机会改或删。别觉得这是多余的交互它恰恰是信任感的来源。低估了本机环境的多样性。你开发时用的是一台 32G 内存的 Mac用户可能是一台 8G 内存的 Windows 办公本。模型量化等级、参数量、内存占用必须针对最差的硬件做配置而不是按开发机的标准来。这个道理谁都懂但几乎每个团队都会在第一个版本上栽一次。5. 合伙机制与长期协作谈钱、谈权、谈退出技术能力匹配、项目方向也对路了接下来就是一个更现实的问题合伙机制怎么设计。我把话放这里这个环节谈崩的创业团队比因为技术做不出来而散伙的还多。5.1 股份怎么分先干活、再分股、逐步兑现最常见的谈崩原因是发起人上来就说“我给你 20% 股份我们一起干”对方觉得太少于是不欢而散。我觉得更好的方式是分阶段谈。首先确定对方全职加入之后按双方的实际贡献来定最终的股权比例。但任何情况下都建议采用vesting成熟期机制也就是股份按时间逐步拿到手而不是入职当天就一次性登记。一个常见的设计是技术合伙人持股 20%-35% 之间分 4 年按月成熟其中第 1 年为“悬崖期”——干满一年才能拿到第一批提前走人则分文不拿。这样做是为了防止一种特别磨人的局面创始人花了大半年时间跟一个合伙人磨合结果三个月后他跑了还带着 30% 的股份离开彻底堵死了后来者入局的路。“干满一年才兑现第一批”不是单方面保护你它也保护对方。对一个真心想做事的技术人来说和靠谱的伙伴绑定四年比拿一笔随时可能归零的“纸面大饼”稳得多。5.2 分工明确谁对技术架构说了算很多项目的内耗来自创始人和技术合伙人对“谁该管什么事”没有共识。我建议在合作第一天就立下几条简单明确的规则产品方向和用户研究以发起人为主技术合伙人可以提出建议但主导权明确。技术选型、架构设计、开发节奏以技术合伙人为准发起人不得拿“用户想要这个功能”去强行压方案。如果双方对某个方向存在重大分歧设置一个“讨论-再讨论-最终定夺”的机制而不是谁嗓门大听谁的。这个看起来像废话但在实际项目里作用非常大。技术合伙人在自己的领域里没有拍板权他就永远是执行者而不是合伙人发起人如果事事都要跟技术合伙人争论那等于自己给自己找了个老板。5.3 合作中常见的翻脸点提前打好预防针跟技术合伙人最容易闹掰的往往不是技术分歧而是这几件事需求蔓延。今天想给 AI 助手加个语音明天想接个日历同步看起来都是“小需求”但每一样都在吞噬技术合伙人本来就紧张的投入产出比。我见过最夸张的例子是创业第 4 个月产品里同时塞了聊天、文件管理、闹钟提醒和买菜清单四个模块没有一个打磨清楚。提前约定“MVP 锁定场景之外的功能一律进 backlog排队等二期”能省掉无数争吵。谁先全职。不少项目的发起人自己有份稳定工作想把技术合伙人忽悠过来全职卖命自己却还在观望。我觉得这类项目很难成事。合伙人最怕的就是发起人两头下注你自己都舍不得 All in凭什么让对方把身家压上去如果你暂时没法全职至少要在合作条款里给技术合伙人“一旦你全职加入前期兼职时间按约定比例计入股份”的明确保障。退出机制。没人愿意在合作第一天谈分手但越是回避分手时越难看。提前约定好如果一方因为“理念不合”要退出股份怎么办如果一方遭遇不可抗力的客观原因无法继续怎么处理有没有回购机制、怎么估值把这些问题写进协议不是为了诅咒项目失败而是为了让双方都能放手干活。5.4 我见过最好的合作模式小步快跑先用短期合作验证最后分享一个我观察到的、成功率相对更高的合作模式叫先合作验证再正式合伙。具体做法是前期不用“合伙人”身份绑死而是以“项目制兼职开发”的形式合作 4-8 周。项目发起人付给对方一笔合理的开发费用或者明确约定这期间的贡献折算成未来的股份。合作期结束时双方已经经历了需求讨论、技术选型、第一个 Demo、甚至一次小规模的用户测试。这时候再聊合伙你们互相之间已经有了亲身体验知道对方是什么性格、做事什么风格、遇到压力什么反应比喝十次咖啡都管用。说实话我见过不少喝咖啡聊得很投缘、一开工就崩的组合也见过先干活后合伙、到现在还干得好好的团队。后者更符合人性。最后说点我个人这些年观察到的体会。我越来越觉得“本地 AI 记忆”这个方向最大的机会不在技术上而在时机上。过去半年端侧模型的能力在快速逼近云端大模型的及格线向量数据库和嵌入式推理框架也正在变得足够成熟更关键的是用户对“隐私换便利”这件事的态度正在明显转变。这些条件其实都是最近一年左右才真正齐备的。我这篇文章写到的选型、路线和合作方法换个时间点拿出来用都会打折扣但现在这个时间点上它会很顺手。真正难的不是技术也不是找人而是你能不能找到一个让你愿意把身价投进去的合作伙伴以及你自己有没有做好把自己也投进去的准备。