前阵子后台收到一条私信：我花两个月做了一个「本地AI记忆」的原型，功能和流程都跑通了，但一个人实在撑不住产品化和运营，想找个技术合伙人，我该去哪找、怎么聊、股份怎么分？
这个问题我自己也琢磨了很久。说实话，这几年经手的创业项目里，「找技术合伙人」踩的坑，比技术本身踩的坑多十倍。而「本地AI记忆」又正好是一个特别适合拿来讨论这个话题的赛道——你光看今年各个技术社区的讨论热度就知道，大家都在谈怎么让AI记住用户：大模型再聪明，也改变不了它"一条金鱼"的本质，单次会话里能调用的信息很多，换一个新会话，用户就得把自己的背景、偏好、手头项目重新介绍一遍。云端也有记忆方案，但对话记录、文档、习惯全部放在别人的服务器上，隐私敏感的用户天然抗拒。
所以这篇文章我打算把这两件事合在一起聊：一边帮你理清「本地AI记忆」这个方向的技术逻辑和产品切入点，一边把「找技术合伙人」这件事从渠道、筛选、聊法到股权、退出机制，一层层拆开讲。适合手里已经有原型、正在纠结要不要找人合伙的创业者，也适合想接这种项目、但不确定该用什么姿态入场的工程师。
1. 先说赛道：本地AI记忆到底在解决什么问题
1.1 大模型的"金鱼记忆"，和它背后的真实成本
用过在线大模型的人应该都体会过这种烦躁：你明明在上一段对话里交代过自己的职业背景、项目目标、偏好的输出风格，换个会话、换个设备，AI全忘了，你又得从头说一遍。对一个重度用户来说，这不是小麻烦，是每天都要重复的隐性劳动。
云端产品其实已经在做记忆功能，比如让你手动保存某段偏好、形成账号级记忆。但这条路径有一个绕不过去的问题：数据归属。你跟AI聊的每句话，你的医疗记录、合同条款、融资方案、市场策略，全部离开你的设备，进入第三方服务商的存储和处理链路。你没法确认这些数据被谁看过、被谁拿去训练、会不会被泄露。这不是杞人忧天，而是律师、医生、财务顾问、企业管理者这类人群每天都要面对的合规压力和职业风险。
本地AI记忆的产品逻辑是把这条链路整个翻转过来：读取、处理、存储都在用户自己的设备上完成，只有"需要模型理解语义"的那一步才调用外部能力，敏感数据不出本机。用户不是被迫在"便利"和"隐私"之间二选一，而是两者兼得。这种产品定位天然自带情感信任感——用户会觉得：这台设备是我的，这些记忆是我的，AI只是暂时替我保管。
1.2 现在做本地记忆，机会窗口在哪
很多人一听到"本地"两个字就担心：本地怎么跑得动大模型？嵌入模型会不会很慢？存储会不会爆炸？这些担心部分成立，但恰恰说明这个赛道真正拼的不是"能不能做"，而是"怎么做得聪明"。
第一个机会点是模型生态的变化。本地小模型（几B参数的开源模型）现在在普通笔记本上就能跑得不错，配合开源嵌入模型做语义检索，个人设备完全承载得了一个中等规模的记忆库。第二个机会点是"模型可替换"的诉求变强了。今天你可能用A家的模型，明天换成B家的，如果记忆存在各自生态里，换一次模型就意味着历史全部丢失。记忆如果存在本地，它就变成了独立于任何模型供应商的资产——AI忘记一切没关系，记忆还在，换一个AI接着用。第三个机会点更隐蔽：记忆本身就是下一代智能体的基础设施。以后你的AI助手要替你写邮件、管理日程、跟进项目，它靠什么了解你？不是靠一次对话，而是靠长期积累的结构化记忆。谁先把记忆层的体验做好，谁就占据了智能体生态的入口。
需要注意，这是一个有门槛但不至于吓退人的赛道。技术难度不如自研大模型那么高，但远高于做个套壳应用，恰好适合"小团队 + 强产品能力"的组合，也是技术合伙人容易被项目本身吸引的那种题目。
1.3 先想清楚产品形态，再去想合伙人的技术栈
本地AI记忆不是单一产品，而是可以落成好几种形态：
- 个人知识库助手：把用户的笔记、PDF、网页剪藏变成可检索、可对话的长期记忆；
- 写作风格记忆器：记住用户的文风、常用术语、积累的素材，辅助日常写作；
- AI编程助手记忆层：记住项目架构决策、历史改动、编码规范，减少重复沟通；
- 生活管家记忆库：记住家庭信息、日程偏好、纪念日，驱动日常提醒。
不同的产品形态对技术合伙人的要求完全不同。偏知识库的，要重视检索和文件解析能力；偏写作的，要重视模型调优和上下文构建能力；偏编程的，则要有IDE插件和本地工具链经验。所以我不建议你用"本地AI记忆"这四个字直接去招人，而是先把你的具体产品场景描述清楚，这是后续所有筛选动作的基础。
2. 想清楚你要找的究竟是谁：技术合伙人不是写代码的外包
2.1 外包谁都能找，合伙人要找的是"共同承担方向的人"
我在帮人牵线时经常发现一个误解：创始人嘴上说找合伙人，心里其实在找一个"能把想法实现出来的程序员"。如果只是这种需求，请外包、招兼职、甚至自己用低代码工具都能解决，完全不需要把公司股权分出去。
技术合伙人真正的价值不在"会写代码"，而在三个层面：第一，他能跟你一起把模糊的想法翻译成明确的技术方案，并且告诉你哪些功能现在能做、哪些要推迟、哪些根本不该做；第二，他能独立负责整个技术侧，从数据建模到部署发布，不用你事无巨细盯着；第三，他在产品方向和商业路径上有自己的判断，敢说"你这是个伪需求"，而不是你说什么他做什么。
你要找的不是你的手，是你的大脑搭档。这个定位决定了你筛选人的标准，也决定了你愿意给出的股权条件。
2.2 技术能力之外，更关键的是这三项软素质
第一项叫"端到端交付能力"。很多人简历很漂亮，但没独立把一个东西从零做到上线过。你可以问对方："你自己维护过什么开源项目？从立项到第一个用户，你经历了哪些事？"做记忆类产品尤其如此，因为它不是写个算法就完事，而是涉及文件解析、存储设计、用户界面、权限管理一整条链路，任何一个环节脱落，产品就是废的。
第二项叫"对数据隐私有本能直觉"。本地AI记忆的核心卖点是隐私，你的技术合伙人如果不懂本地优先（local-first）的理念，不理解用户为什么需要控制自己的数据，那他大概率会把你的产品做成"一个上传到云端的记忆库"，这是方向性的致命伤。我合作过一位工程师，聊天时主动问"用户删除记忆的时候，底层数据要不要做物理删除还是标记删除？如果做标记删除，那些备份文件怎么处理？"这种对隐私细节有本能敏感的人，才是对的人。
第三项叫"开源心态和长期主义"。本地AI记忆这个方向，早期几乎不可能赚大钱，技术合伙人要有耐心陪你把地基打牢，而且愿意把部分技术以开源形式反哺社区、建立信任。如果一个候选人开口就问"这个项目什么时候能月入百万"，那他不是合伙人，是投机客。
2.3 见人之前，先把手里的"技术需求清单"列出来
这一点最容易被忽略，但也是最能体现你诚意的地方。技术合伙人最怕的合作伙伴是什么都不懂、只想指挥的人。你不需要会写代码，但你需要能清晰地告诉对方：这个产品的MVP包含哪几块功能，用户怎么使用它，哪些数据会被记录。
我建议用我这个模板自己先写一遍：
- 记忆的输入来源：我打算让用户通过什么方式提供信息？手动输入、导入文档、还是浏览器插件自动采集？
- 记忆的存储结构：一条记忆要保存哪些字段？时间、主题、标签、原文、嵌入向量？
- 记忆的检索方式：用户提问时，AI怎么知道该调用哪些记忆？是关键词匹配还是语义匹配？
- 记忆的管理界面：用户能不能看到AI记住了什么？能不能手动修改或删除某条记忆？
这个清单不求专业，但求具体。当你拿着这份清单去找人聊的时候，对方一眼就能看出你是认真做过功课的，还是在用一个概念画饼。这一份诚意，就帮你过滤掉一半本就不合适的人。
3. 从哪儿找、怎么聊、怎么验证一个技术合伙人
3.1 靠谱渠道就这几种，别迷信大平台海投
我自己实践下来，渠道按靠谱程度排序大概是：
- 第一推荐：你身边的朋友和技术圈同事。强关系带来信任，信任是合伙关系的地基。你认识他一年以上，你知道他做事靠不靠谱，他也知道你不是那种会过河拆桥的人。
- 第二推荐：开源技术和本地优先社区。做本地AI记忆的人，大概率对本地优先、隐私保护这些话题本身就有热情。你在GitHub上维护一个相关项目，或者去技术社区发帖分享你的原型思路，会吸引感兴趣的人主动找上门。
- 第三推荐：创业社群和孵化器活动。这里面的好处是大家都有创业预期，聊股权不尴尬，但鱼龙混杂，需要仔细甄别。
- 最后才是招聘平台或发帖找人。不是不行，而是成本高、信息量少，而且容易吸引来"只想找活干"的人，而不是想合伙的人。
我在技术社区帮人发帖时，会建议附上三样东西：一句话说清你要解决什么问题、一个原型录屏或截图、以及你希望合伙人承担什么角色。发帖别只写"想找技术合伙人做AI产品"，这种帖子收到的回复一半是"我很感兴趣"，另一半是空泛的自我推荐，都没什么用。
3.2 第一次聊的方向问题：不聊代码，聊判断
第一次见面千万别急着看对方的GitHub代码，也不要让对方马上给你讲技术方案。你要做的是抛出几个"方向判断题"，看这个人的思考深度。
我常用的五个问题，你可以直接拿去用：
第一个问题：你觉得做本地AI记忆，最大的技术风险在哪？
这个问题没有标准答案，但有好答案和坏答案。坏答案是一上来就讲"嵌入模型要调参""没有GPU怎么跑"，这些都属于"工具层面的问题"，不是风险。好答案会说：最大的风险不是模型精度，而是"检索时机"——你很难判断在当前这段对话中，用户到底需要哪条记忆被唤起。检索时机错了，AI会在无关的时候调出大量旧信息，让回答变得冗长混乱。这个级别的思考说明他真的理解产品，而不是只懂技术。
第二个问题：你过去做过的最完整的端到端项目是什么？从需求到最后上线，你一个人还是团队？卡在哪一步？
这是在验证他的交付边界和复盘能力。能清晰讲出"我在哪个环节卡了多久、最后怎么解决"的人，比只会讲成功故事的人靠谱得多。
第三个问题：如果让你做MVP，第一版你会做成什么样？
注意他有没有抓住"最小"两个字。好的合伙人会说：先只做写作场景，不做知识库；先手动导入，不做自动采集；先跑通单机，不急着加云同步。如果你听到的是"那肯定得先做一个完整的RAG系统，用向量库加本地模型再加自动抓取"，这人是在炫技，不是在帮产品成功。
第四个问题：你对股权分配怎么看？
这个问题是为了探底，不是为了当场谈定。如果他一上来就狮子大开口，或者完全不在乎股权只问工资，这两个极端都不太适合合伙。成熟的技术合伙人会说：初期可以按里程碑谈，我需要看到项目能往前走，股权比例可以聊。
第五个问题：你愿意在这个项目上投入多少时间？是全职，还是业余？
这个问题直接关系到后面所有安排。兼职不是不行，但你必须知道，一个有全职工作、只能周末写代码的人，和全职投入的人，对项目的承诺程度完全不是一个量级。
3.3 别急着谈股份，先做一个14天的试合作项目
很多人找我帮忙牵线时，第一句就问"我们股份应该怎么分"。我通常都会劝他们先停一下：你们还没一起写过一行代码，怎么就谈到分钱了？婚姻还没开始就讨论离婚财产怎么分，虽然必要，但顺序不能乱。
我的标准做法是设计一个短周期的试合作项目，控制在两周到一个月，目标非常明确。举个例子，他可以做一个极简的本地记忆管理工具：用户丢进来几段文本，工具自动抽取关键主题和时间信息，存储到本机SQLite；当用户输入一段新的文字时，工具能基于关键词和语义相似度，把相关的历史记忆找出来并展示在侧边栏。这样一个东西不涉及复杂的UI，不需要接大模型API，核心就是在测试数据建模和检索逻辑，一两天就能出原型，两周可以做到可体验。
这14天里你要观察的东西包括：第一，他写完代码后会不会主动帮你写一个简单的README，说明怎么运行、怎么测试；第二，遇到他不懂的领域，他是自己查资料解决，还是直接问你让你去查；第三，他面对你提出的修改意见时，是耐心讨论还是防御式反驳；第四，他有没有主动提出你没想到的风险，比如"你这个标签体系在数据量大了之后会失控""用户误删除记忆怎么找回"。这四个观察点分别对应：工程素养、主动性、协作模式、产品意识。任何一点不合格，都不建议继续。
试合作期间的付费问题，我的建议是即便对方说不要钱，也应该按兼职开发水平支付报酬。一方面钱是表达尊重，另一方面，付了钱你就有了提要求的权利，对方也有了按时交付的责任。合伙人可以后面再谈，但试工阶段应该钱货两清。
4. 股权、报酬与退出机制：丑话说在前面
4.1 初始阶段最容易达成的分配原则
等到试合作通过、双方都确认要往前走之后，再坐下来谈股权。这时候就一个核心原则：利益绑定要跟持续投入匹配，而不是跟初始想法匹配。
团队的常规做法是用"贡献估值法"做初始分配。创始人投入的想法、原型、前期的调研按一个估值计入，技术合伙人投入的时间和技术能力按另一个估值计入，然后换算成初始比例。举例来说，假设你（创始人）已经投入了三个月时间做出了原型和用户验证，估值占40%的贡献；技术合伙人接下来全职投入一年，加上技术能力本身的价值，估值占60%的贡献。那么初始分配可以是40/60，但这里要注意，这个比例必须放在动态调整的框架里看，因为技术合伙人的贡献在时间轴上会持续发生。
我在这里一定要提醒：尽量不要简单地五五开。不是说五五开一定不行，而是五五开往往是为了"公平"而不是为了"合理"，后续一旦有一方投入变化，这个比例马上失衡。我见过一个项目，两个创始人五五开，三个月后创始人天天在外面跑用户，技术合伙人全职开发，两个人的实际投入差了一倍，但股权一样，矛盾很快爆发。最后只能做股权调整，中间消耗了巨大的信任成本。
4.2 成熟期和离职回购：这是你保护自己的方式
很多第一次创业的人不理解为什么要设成熟期（vesting），觉得这是大公司才玩的套路。实际上恰恰相反，创业公司更需要这种机制，因为它保护的不是某个人，是项目本身。
我建议采用最常规的四年成熟期，按月解锁，其中前十二个月设一个悬崖（cliff），也就是说，如果合伙人在第一年内离开，他只能带走已满足悬崖期所对应的一小部分股权，其余由公司收回。举例来说，你们约定技术合伙人占40%股份，四年成熟，悬崖期一年。他干了九个月发现做不下去、主动退出，那他就拿不到那40%，因为他没有迈过一年的时间门槛。如果他干了两年半离开，他已经解锁了约一半，也就是项目股权的20%，这部分不能收回。
同时还要约定离职回购的价格计算方式。最合理的做法是：未解锁部分直接放弃，已解锁部分公司按一个约定的倍数（比如最新一轮融资估值的折扣，或上一年净利润的合理倍数）回购。如果公司还没有融资，就按"净资产评估+初期投入折算+对公司现有价值的合理判断"来谈。这个公式最好在早期书面定一个框架，而不是离职当天再商量，否则一定会吵起来。
我自己就知道一个真实案例：两位朋友合作做工具类软件，磨合了大半年，技术合伙人提了十几次重构，创始人都以"先上线"为由拒绝，最后技术合伙人觉得自己的架构理想无法实现，直接离职。因为没有提前谈股权成熟和回购方案，他带走了核心代码，创始人几个月后才彻底接手重构。如果他们在开始合作的时候花半天时间把"分红、回购、分手"这几件事白纸黑字写清楚，整个结局会体面很多。
4.3 技术合伙人最关心的问题：知识产权和数据归属
本地AI记忆项目里，有一件事比股权更容易被忽略，那就是：这个项目产生的代码、记忆数据格式、算法设计，到底归谁？
我的建议是在签订合伙协议的一开始就写明"职务技术成果归项目主体所有"：只要是为了这个项目而写的代码、产生的文档、训练出来的模型参数，知识产权益归公司或项目实体。这看起来像霸王条款，但实际上对一个早期项目是必要的——你也不想自己的核心代码哪天以另一种形式出现在竞品里。
但反过来，你也要尊重技术合伙人的劳动：如果在合作中产生了可以独立成品的通用工具（比如一个本地向量检索库），可以约定单独开源，作为项目品牌的一部分，也作为技术合伙人的个人履历背书。这样双方都舒服。凡是没写进协议的，默认都是雷。
5. 给技术合伙人看的"地图"：本地记忆系统的分层架构
5.1 一套可以照着做的技术框架
这一节写给非技术背景的创始人，也写给想评估项目可行性的工程师。我帮你把本地AI记忆的技术体系拆成五层，每一层对应一个明确的问题。当你跟技术合伙人讨论的时候，能聊到这五层的具体取舍，对方就会认真看待你。
- 第一层：采集层。用户怎么把信息送进来？手动输入是最简单的MVP做法；批量导入文档（Markdown、PDF、网页剪藏）是第二个版本的事；浏览器插件自动抓取网页内容会更方便，但伴随隐私和误采集问题，必须靠后放。注意，即便是本地采集，用户在操作层面也要有明确的授权意识，不能让产品变成"悄悄记录一切"的东西。
- 第二层：记忆构建层。这层的任务是"从原材料变成结构化记忆"。原始文本进来之后，要抽取主题、识别实体（人、事、时间、项目）、生成摘要、打标签。如果条件成熟，还可以生成嵌入向量。这里有个关键选择：用什么样的模型来做信息抽取？如果看重隐私，可以选本地的小参数模型；如果看重效果，走开放平台API的提取能力，但只传必要文本，并且做好数据最小化。
- 第三层：记忆存储层。原始文本、结构化记录、标签、向量，分别放在哪里？我的建议是起步阶段用SQLite一种数据库打天下，一张记忆主表，一张标签关联表，一张全文字段，再加一张向量字段。等你要做语义检索，再在SQLite之上扩展向量索引，或者单独接一个向量库组件。千万别一上来就搭一堆分布式存储，那是给自己找麻烦。
- 第四层：检索唤醒层。用户提出一个问题，系统怎么知道该调用哪些记忆？常规做法是混合检索：先用BM25类关键词检索召回一批候选，再用向量语义相似度召回另一批候选，然后合并去重，按"相关度+记忆重要度+时间热度"排序。这一层的核心指标是"命中率"和"噪音率"：该想起来的没想起来是失败，不该想起来的老冒出来也是失败。
- 第五层：注入层。选出来的记忆怎么送到AI面前？这不是简单把文本拼进提示词那么简单，还要考虑上下文窗口长度、记忆的格式、哪些记忆应该按高优先级放在靠前位置、哪些应该被忽略。这里的关键设计是"可插拔"：用户应该能手动选择这一轮要不要启用记忆，以及能一键清除全部记忆注入。给用户控制权，是本地记忆产品区别于云端记忆产品的灵魂。
5.2 为什么我建议不要一开始就上向量数据库
这是我跟很多技术合伙人争论最多的话题，也是我最有把握的一个建议：MVP阶段，别用向量数据库。
原因有三。第一，向量数据库的部署和维护成本对一个早期单人/双人团队来说太高了，遇到问题排查困难，迭代速度会被拖慢。第二，语义向量召回在数据量很小（几千条以内）的时候，跟关键词匹配的体验差距没你想的那么大——用户的记忆往往有明确的时间、人名、项目名，输入关键词就能搜到。第三，产品的早期核心是验证"用户需不需要这个功能"，而不是"语义检索做得有多酷"。你用SQLite的全文搜索（FTS5）就能支撑第一版体验，等用户量上来、搜索需求变难，再平滑迁移到混合检索架构。
我真的见过一个团队，花了两个月搭了一个完整的RAG系统，接了好几个向量模型，最后发现用户总共就往里面存了二十几条备忘录，全部跑在纯规则检索上。那个复杂度完全是自我感动。一个真正懂工程取舍的合伙人，应该在你说"要不要上向量库"的时候反问一句：我们手头的数据量有多少？预计半年内能到多少？如果答案是没有几千条的规模，就用简单的方案。
下面是一段极简的SQLite记忆表代码，可以作为技术合伙人对齐范围的参考：
import sqlite3 from datetime import datetime # 创建本地记忆库（示例结构） conn = sqlite3.connect("local_memory.db") cur = conn.cursor() cur.execute(""" CREATE TABLE IF NOT EXISTS memories ( id INTEGER PRIMARY KEY, created_at TEXT NOT NULL, content TEXT NOT NULL, topic TEXT, importance INTEGER DEFAULT 5 ); """) def save_memory(content, topic, importance=5): cur.execute( "INSERT INTO memories (created_at, content, topic, importance) VALUES (?, ?, ?, ?)", (datetime.now().isoformat(), content, topic, importance), ) conn.commit() return cur.lastrowid def recall_by_keyword(keyword, limit=5): # FTS 关键词召回；MVP 阶段足够用 cur.execute( """ SELECT content, topic, importance FROM memories WHERE content LIKE ? OR topic LIKE ? ORDER BY importance DESC LIMIT ? """, (f"%{keyword}%", f"%{keyword}%", limit), ) return cur.fetchall()这段代码放在GitHub上，就是你们第一次技术对话的起点：数据表怎么建、字段怎么定义、召回怎么实现。它不华丽，但它通向一个能交付的产品。
5.3 别忽视"记忆清理"和"负面记忆"的设计
技术合伙人往往喜欢研究怎么记住更多，产品合伙人反而要警惕"记住一切"带来的负担。用户最怕什么？怕AI记住了他不想被记住的事情，怕删除记忆时删不干净。
所以产品设计里必须有一块"记忆管理面板"，让用户看到AI记住了什么，并且能逐条删除、批量清空。更进一步，在采集层就要支持"负面记忆"：用户明确说了"这件事不要记"，系统就要尊重，并把这句话本身作为一条控制指令存下来，之后所有提取流程都要避开这个话题。本地记忆的信任感，不是靠宣传语建立起来的，是靠用户敢打开记忆面板看、敢放心删除建立起来的。
过去几年做隐私相关产品，我自己的体会是：只有用户能够轻松销毁数据，他们才愿意长期保存数据。这个反直觉的设计原则，建议写进产品原则第一条。
6. 三周做出一个"诚实"的MVP：验证比完美重要
6.1 第一版先切一个窄场景
本地AI记忆如果做成"所有记忆都能管"的通用工具箱，几乎必死。因为通用意味着你没有特征，用户不知道该拿它干嘛。
我建议你切三个方向中选一个，先做得特别顺手：
- 方向A：写作记忆。面向自媒体作者、产品经理、咨询顾问，帮他们记住自己的术语库、常用案例、活跃的灵感片段。配合写作场景的AI辅助，价值明确。
- 方向B：项目记忆。面向独立开发者和小团队，记录项目的关键决策、往期代码变更、同事偏好，让AI助手在协作中具备项目级上下文。
- 方向C：个人顾问记忆。面向高频使用AI做知识问答的用户，把每天的问答精华沉淀成个人知识库，形成"越用越懂你"的体验。
选哪个取决于你自己是什么身份、你最了解哪个用户群、你能找到谁来做内测。别选"听起来市场最大"的，选"你自己就在那个场景里天天痛苦"的。
6.2 三周怎么排，每一周交付什么
这里给你一个可以直接照搬的三周排期，以方向A"写作记忆"为例：
第一周：做记忆写入。只支持用户手动输入或粘贴文本，系统自动抽取主题和时间，保存到SQLite。不加任何自动采集。这一周的目标是跑通一条最干净的数据链路。
第二周：做记忆读取。搭一个最简陋的对话面板，用户在输入框里问"我之前写过一篇关于本地AI记忆的文章，里面提到过检索时机的问题，帮我找找"，系统能从记忆库里召回相关片段，展示出来。这一周的目标是验证召回能不能工作，以及检索时机这个体验痛点到底存不存在。
第三周：做记忆管理。给用户一个清单页，展示所有记忆条目，支持编辑、删除、标记为不再记录。这一周的目标是验证用户对"AI记住了什么"这件事的掌控感有多重要——我自己的判断是，很多用户看到面板的一瞬间会既安心又警惕，这种反应本身就是最好的产品反馈。
每周末都要做一次判定：这一周的核心指标过线了没有？比如第一周要有至少10条真实记忆被正确抽取；第二周要在5个测试问题里至少正确召回4次；第三周要找5个真人来试用，记录他们使用时的表情和第一反应。任何一周没过线，停一下，先搞清楚是产品问题还是实现问题，而不是靠加班把下一周也挤掉。
6.3 MVP阶段最容易犯的三个错
第一个错：迷恋自动化采集。自动采集网页、自动监听剪贴板、自动转录语音，听起来特别强大，但MVP阶段会带来一堆数据质量问题和隐私疑虑，而且用户也不知道你到底采集了什么。手动输入虽然笨，但它让用户清楚地知道"系统只会记住我主动给它的东西"，这种心理安全感是无价的。
第二个错：一上来就做精美的图形界面。对MVP来说，一个命令行工具、一个最简单的网页界面都够了，核心是验证记忆的写入和召回链路。界面做得很精致，但底层逻辑一塌糊涂，用户试用一次就会被体验问题淹没。
第三个错：只给自己看，不给用户用。很多人在做原型的时候有一种"怕被嘲笑"的心理，躲在自己的小范围里打磨了三个月才公开。这等于放弃了前两个月的用户反馈机会。哪怕产品只有六十分，丢给五个内测用户，他们的反馈比你关起门来磨三个月有价值得多。
7. 合伙过程中那些细碎但致命的裂缝，怎么提前堵住
7.1 节奏错位：创始人一天一个想法，工程师一周一次提交
本地AI记忆项目是典型的"慢工出细活"，但创始人往往焦虑，恨不得每天都改方向。这很正常，但很消耗技术合伙人的热情。
我的解决办法是定一个固定的同步节奏：每周一次文字周报，每两周一次视频会议。周报里创始人说清楚本周在市场上听到什么、产品打算怎么改进；技术合伙人说清楚本周完成了什么、下周计划做什么、有哪些风险。节奏一旦固定下来，双方就不会被临时的想法牵着走。任何不在周报框架里的"紧急改动"，都默认放到下次同步时讨论。这条规矩立起来之后，我自己的项目沟通成本降了一半。
7.2 技术选型之争：别用"我感觉"来否定技术判断
创始人容易犯的一个错误是，因为听说过某个技术名词很火，就逼着技术合伙人用某个框架或平台。技术合伙人的沮丧感往往不是来自任务量大，而是来自"外行指导内行"。
我建议在合作协议里就写清楚决策规则：方向类决策（做什么、为谁做）由你主导但必须听取技术合伙人的意见；技术类决策（用什么工具、怎么实现）由技术合伙人主导但必须对里程碑负责；产品类决策（具体功能和交互）由两人共同讨论决定。如果技术合伙人说"这个功能用SQLite就够了，不用上向量库"，你即使半信半疑，也应该尊重这套判断，同时给他一个期限：如果检索体验在数据量到达某阈值后仍无改善，再重新评估。用数据和期限来决策，而不是用情绪和职位。
7.3 定期做一次"合伙关系体检"
我和团队一起做的固定动作，是每季度一次"双方复盘"，不是复盘产品数据，是复盘两个人的合作状态。坐下来，互相回答四个问题：第一，我们对项目目标的理解还一致吗？第二，你对过去一个季度的进展感到骄傲吗？第三，你最近有哪些担忧没有说出口？第四，我们可以各做一件什么事来让对方的日子更好过？
这些问题听着有点肉麻，但实际跑起来特别能提前暴露问题。技术合伙人可能说："你最近在朋友圈里宣传产品的时候，把我说得像是外包开发，我有点不舒服。"这种话在平时是绝对不会说出口的，只有在固定的、认真的复盘框架里才会浮上来。及时处理这种小情绪，远比最后矛盾总爆发再补救便宜得多。
7.4 如果真的走不到最后，怎么体面地分手
不是说好签字就不吵架了，我劝你在合作刚开始的时候就把"分手条款"当成一个正常商业条款来聊：如果任何一方想退出，提前一个月书面通知；退出后已解锁股份按协议价格回购，未解锁部分自动失效；项目代码、用户数据、生成的模型文件全部留在项目主体；双方承诺两年内不直接复刻对方的MVP，不做恶性竞争。
写这些不是诅咒项目失败，而是把所有不确定性都变成确定性。我见过太多本来技术关系不错的小伙伴，因为没有分手条款，最后闹到互相拉黑、项目烂尾。如果你们本来是朋友，这套条款保住了你们的友情；如果你们本来只是商业伙伴，这套条款保住了彼此的基本体面。
8. 选人这件事最后拼的是"价值观"，不是简历
带过几次合作之后，我的体会是：技术合伙人的能力可以训练，判断力可以培养，但价值观层面的东西很难改变。
你要找的那个人，得跟你一样相信"用户的数据应该由用户自己掌控"这件事，否则他做出来的产品一定会在某个角落产生数据滥用；他得相信"小步快跑比一步到位更稳妥"，否则他会把时间花在"完美架构"而不是"用户反馈"上；他得愿意在你遇到困难的时候说一句"别慌，我来想办法"，而不是默默打开招聘软件看下一家公司。
我也要提醒做技术的那一侧：如果你正在考虑加入一个本地AI记忆项目，请先想清楚自己是被"技术挑战"吸引，还是被"产品愿景"吸引。这个方向确实有足够深的技术题目可以啃，但真正撑起一个项目长期走下去的，是你跟创始人对"本地优先、隐私保护、长期主义"这些价值观有没有默契。技术会过时，模型会替换，只有价值观一致，才能在一次次分歧之后还愿意坐在同一张桌子前。
最后分享一个我自己的小习惯：每次跟潜在合伙人聊完，不管聊得多投机，我都会把我们的共识写成一页纸的文档，发给对方确认。内容包括：我们为什么做这个产品、第一版打算做什么、你负责什么、我负责什么、下一次什么时候碰头。别小看这一页纸，它能帮你筛掉那些"嘴上说好、回去就忘"的人，也能帮你们的合作关系一开始就建立在清晰的基础上。本地AI记忆这个方向，值得找到那个跟你一样认真的人。
