今天正好有朋友邀请去他公司做了一个分享，题目是：0-1 打造一个 AI Native 产品有多难——一个毫不知名的 AI Startup 实践自述。
本周的 YouNavi 产品日志就借此把这个内容也分享给大家。
2026 年 5 月 22 日 YouNavi 的实践分享
分享主题：从 0 到 1 构建 AI Native 产品：YouNavi 的踩坑、去魅与组织演进
主讲人：Ray —— YouNavi 产品负责人 / Co-founder
一、自我介绍
说实话，我不确定这些内容对大家日常的实际工作能有多少直接的帮助，大家不妨把它当作一个故事来听，这样可能会更符合预期。
今天我想和大家分享的，其实是我在过去一年多的时间里，从 0 到 1 去做一个 AI Native 产品，以及背后一个 Startup 真实的创业过程。
这个过程"有多难"？这个重音可以是"多"（第二声）、也可以是"难"，听完我的分享后，大家可能自己会有自己的感受。
我们这个产品叫 YouNavi，待会儿我会具体介绍它是干什么的。我是这个团队的产品合伙人。我自己做了 15 年的产品经理，最早是百度的校招生，职业生涯正好完整经历了整个移动互联网最蓬勃发展的阶段，先后在蚂蚁金服和滴滴出行负责产品工作。到了 2022 年，我明显感受到移动互联网的发展遭遇了瓶颈，于是决定跨界，加入了一家新能源造车新势力，也负责过 AI 平台产品。
二、汽车行业的 AI 幻觉：智驾与智能座舱的落差
现在的车企（尤其是最近很火的几家新势力，包括特斯拉在内）最典型的一个宣传口径，就是标榜自己不是传统的制造车企，而是"AI 企业"。但在车企做 AI 的这两年，我发现里面存在很多"幻觉"。
幻觉一：智驾
我是 2021 年左右开始接触 Transformer 这个词的。如果你是正儿八经做 AI 的，在 2017 年那篇奠基性论文发布时就应该知道了；如果你是通过 ChatGPT 发布才了解的，那大概是在 2023 年。我比大家稍微早一点知道这个词，大概是在 2021-22 年左右。
当时，Andrej Karpathy（前特斯拉智驾负责人和 OpenAI 创始成员，最近加入了 Anthropic 的大牛）在特斯拉搞了一套纯视觉方案——结合多路摄像头，通过鸟瞰图（BEV）拼接出视觉模型，并用 Transformer 架构去做智驾感知。我的车也有智驾功能，由于某些原因，该系统从 2024 年开始就不再更新了。但坦白讲，我现在用得依然很好。因为智驾本质上还是个"小模型"，它需要的算力和复杂度并没有那么高，但它能达到的水平也就是 L2.x 级别，连真正的 L3 都不到。目前市面上虽然有很多更先进的智驾系统，但在复杂的城市路况下，大多数人依然不敢放心使用。从特斯拉发布这一套架构开始，短短两年内，整个行业都掌握了这套技术，后面竞争就变成了极致的成本压榨和算力堆砌，技术在实际体验上的成长空间已经不大了。
幻觉二：智能座舱
当时车企内部有一个现在想起来有点好笑的推理逻辑：AI 大模型需要极高的算力和能耗，那么从消费终端来看，什么设备最符合这个特征？答案是电车。因为电车有 100 度的电池，车端算力通常也高达几百甚至上千 TOPS，似乎大模型在车端落地是顺理成章的。
但现实是，用户在开车时的真实需求用一只手就能数得过来：导航、听歌、车辆控制，顶多加上副驾小朋友和语音助手聊聊天。用户在座舱里的实际需求，与大模型庞大的能力相比，是严重错配的。这是我在车企感受到的最大的一个跟 AI 有关的幻觉。
三、探索期：从 ToB 的困局到 ToC 的试错
于是在 2024 年下半年，我和合伙人一起开始尝试新的 AI 方向创业。
这里需要先帮大家做个 Recall：2024 年的 AI 行业处于什么水平？当时的主流大模型应该是 GPT4。行业里最火的方案有两种：
- RAG（检索增强生成）：通过向量检索的方式做知识库问答。
- Workflow（工作流编排）：以 Dify 和 Coze 为代表的低代码编排平台。
我们初期创业时，也顺着这两个范式做了不少 ToB 项目，涵盖图书馆、景区、高校、银行等系统。但我们很快发现，在国内做 ToB 的 AI 项目和做传统的 ToB SaaS 没有本质区别。客户的需求总结起来就两个：第一是要深度定制，第二是想要白嫖。这种模式不仅极重，而且基本赚不到钱。
到了 2024 年底，我们决定转向 ToC 领域的尝试。虽然团队很小，但我和合伙人都有十余年的 ToC 产品经验。当时我们结合了自己的个人痛点（我合伙人以前在腾讯做过浏览器，我自己也是一个古早 RSS 的重度爱好者，比如 Google Reader），想做一个定制化获取信息的移动端 App。这个思路其实非常类似于后来 ChatGPT 做的 Pulse 产品：结合用户订阅的信息源和全局记忆，再通过大模型做个性化信息推荐。
这个 App 后来做出来了，但我们最终没有选择上线。为什么？我们当时设计的最核心 feature 是：推荐逻辑不用传统的算法，而是用大模型，并结合一个 500 字左右的用户长期记忆画像的 Context（上下文）描述。
但试下来我们发现，当时模型的注意力机制根本无法胜任这件任务。举个例子，我合伙人在那 500 字的个人背景描述里写了一句"有两个小孩"。结果大模型在推荐每篇资讯时，都会生硬地往这个方向靠拢。比如你有两个小孩，应该看看 AI 教育之类的，无论推什么文章，大模型最后都会绕到"你因为有两个小孩，所以应该如何"上。当时市面上的模型在处理这种全局记忆推荐时，无法做到真正 sensible 的注意力分配。
四、YouNavi 的诞生：Deep Research 与沟通录音的缝合
真正的转机发生在 2025 年。一方面是 DeepSeek 把推理模型普及和开源，让高性能大模型的使用成本大幅降低。我们在这个新的技术范式下，看到了两个已经跑通 PMF 的产品方向：
- AI Coding：当时虽然还没有 Claude Code，但 Cursor 的体验已经让人惊艳，我也在用它做 demo 和处理文档。
- Deep Research：ChatGPT 和 Gemini 都陆续推出了这个功能。
我们观察到，大家在使用 Deep Research 时，主流场景多是输入一个简短的 Prompt，比如去调研某个行业格局或某家公司的股价。但很少有人想到，把一整场长达数小时的会议、沟通录音的文本全部塞给大模型，让它结合里面的具体主题，自动在后台去做一次跨越时间的 Deep Research。
作为一个资源有限的小团队，我们做不了宏大的叙事，我们的策略就是在这些尚未被巨头填满的空白场景中，寻找缝合点。于是，我们决定为身边的创业者、投资人、独立顾问和产品经理，打造一款能够结合上下文做深度研究的分析工具，这就是 YouNavi 的雏形。
五、踩过的坑：产品定位、框架迷信与"屎山"代码
在把 Demo 拿给早期用户测试的过程中，我们踩了非常多的坑。
1. 关于产品定位的坑
最开始，我们也用了 AI PR 稿中常见的宏大词汇，跟早期用户说这是你的"AI 参谋"、"决策助手"或"第二大脑"。但实际沟通中，这些词汇根本无法打动用户。他们会直接问："你这个和 ChatGPT、Gemini 有什么区别？"你根本解释不清楚，而且无形中把用户的预期拉得极高。
于是我们把定位进行了极大的聚焦，将其定义为：录音分析洞察 Agent。它只做一件事——从你的日常沟通录音里，榨取和洞察最有价值的信息。
最近我去上海虹桥那边摆地摊做用户调研，我们总结出了一个可能更受职场人欢迎的非正式 Slogan——"职场废话回收站"。开会时废话的占比是极高的，一提到这个词，大家立刻心领神会。但同时，我们的产品有很强的落脚点，那就是"沟通"和"录音"，如果日常工作不怎么开会或交流，那就不是我们的核心目标用户。
2. 关于开源框架与重构的坑
2025 年 Q4，我们开始动手做这个产品。当时想法很简单，直接在 GitHub 上找了个好评如潮、有几千上万 Star 的字节开源框架——Deer-Flow（底层是 LangChain 和 LangGraph 的 Agent 编排框架）。我们在此基础上进行魔改，加录音同步和文件上传功能。
结果，我们一位实习生魔改了两个月，发现 Demo 的任务运行成功率甚至不到 50%。到了 9 月份，我们终于招募了正式的研发同学，入场做的第一件事就是：彻底推倒重构底层的 Agent Runtime。
我想提醒大家：千万不要迷信 GitHub 上的 Star 数。开源框架要直接转化为商业级产品，中间的工程鸿沟非常巨大。（虽然还是要致敬一下 Deer-Flow 这个框架）
3. 关于 AI Coding 与"屎山"
我们团队的同学开始在写代码时大量使用 AI Coding。在这个过程中，我们也遇到了一些团队共识上的冲突。像 React 这种前端框架，对于人类开发者来说是非常好用的，因为它有成熟的组件复用、嵌套和高度的抽象设计。但在当时，大模型在写 React 时非常痛苦。它写着写着就会把代码变成堆叠的"屎山"，层级深不见底，人类想去改也无从下手。
后来我们花了将近一个月时间在技术栈上做减法，规范了我们的技术栈和技术规范，将约束条件写进 claude.md。直到 12 月份，代码库才算整洁好用。这时候，像我这样完全不懂代码的产品经理，才开始能直接在这个代码库里提交 Commit，小到修改文案、改静态官网，大到调整端上的一些交互和完整的功能。
4. 从 Web 版转向本地客户端
最开始，我们和大家一样做的是网页版（Web）。我们有一个创新功能，就是可以一键同步飞书、腾讯会议等平台的录音文件。但用户在扫码登录授权时，飞书后台会发送安全警告，提示你在"杭州的某个 IP 地址"登录了，请确认。因为我们公司机房在杭州，这引起了用户对数据隐私的极大担忧。毕竟，会议录音是极度敏感的数据。
为了彻底解决隐私问题，我们果断决定将产品形态全面转向桌面客户端。除了调用大模型需要云端交互外，录音存储、数据同步、数据管理全部保存在用户本地，并与本地文件系统深度绑定。虽然当时 OpenClaw 还没火，但如今回过头来看，这种本地化 Agent 架构已经成为了行业的普遍共识。
六、组织演进：无 PRD 的"赏金猎人"全员 Coding 模式
有了 AI friendly 的代码库，我们彻底抛弃了传统的研发流程。以前常说"Talk is cheap, show me your code"，现在我可以说是"Also the code"。
我们现在团队有 7 个人（4 个研发，1 个设计师，1 个增长产运，再加上我）是"全员 Coding"的状态。团队没有任何形式的 PRD（产品需求文档），也没有所谓的需求评审和拉通会。
我的日常运作模式是这样的：每周发布一个类似"赏金猎人"的 Feature List（需求清单），然后分为两个分支：
- 轻量化 / 交互分支：由我和设计师直接认领。我们自己通过 Vibe Coding 在本地改代码、跑自测、提 PR。如果 AI 改了两次还改不对，说明这个逻辑确实复杂，我们再把分支转交给研发。对我们而言，代码本身就是产品想法和交互最精准的沟通媒介，不需要画原型和写文档。
- 核心工程分支：涉及 Agent Harness（核心运行机制）、全局记忆管理、任务编排、模型串联等底层逻辑，这部分由于技术门槛高，由专业的研发同学主导。但他们写完之后，如果我对文案、边框、交互不满意，我会直接上去拉代码修改。
通过这种"全员 Coding + 异步换手"的模式，我们现在能做到每天 Release 一个内部测试版本，每周发布一个正式版本。目前我们一周迭代的需求量，放在我以前待过的大厂里，我觉得差不多需要一个 10 人团队干上整整一个月。
当然了，我觉得这里有一半的时间节省不是因为开发变快了，而是因为不开很多无效的会了。作为 Startup，所有决策直接下达，没有汇报，没有拉通。
七、研发去魅：回归第一性原理
在实际的工程落地过程中，我对很多所谓的"先进 Agent 技术"进行了祛魅：
1. 祛魅图编排（LangGraph/Workflow）
最初我们因为 LangGraph 的"图编排（Graph）"概念听上去高级、有工程美感而采用了它。但最后发现，这些复杂的人工结构在实际生产中是不必要的。现在大家逐渐达成共识：Agent 运行的最核心逻辑就是最基础的 ReAct Loop。即：输入 → 模型调用工具 → 执行观察（Observation）→ 判断是否完成 → 循环。这样一个简单的 React 环，在合理设计下可以稳定运行数个小时乃至一整天，来完成非常复杂的任务。
2. 祛魅复杂记忆工程
2024 年，行业里充斥着利用"艾宾浩斯遗忘曲线"、"多模态向量库"、"语义与情景记忆分类"等高深理论构建的记忆工程。后来，有人逆向了 ChatGPT 的记忆机制，其实它就简简单单做了三层：
- 第一层：User Profile（用户全局静态事实，比如职业、偏好）。
- 第二层：Session Summary（单次会话的逻辑总结）。
- 第三层：Current Window Context（当前对话窗口的实时上下文）。
再看看行业标杆的 Claude Code 或 OpenClaw，文件记忆系统的做法大同小异，底层几乎都是这三层结构。有些做得好的，也不过是后台每隔 24 或 48 小时跑一个定时任务，把记忆整理成干净的 Markdown 文件。我们没看到有哪家是要去把所谓人类的情景记忆、语义记忆等等十几种记忆理论完美复刻的。
3. 祛魅上下文管理
从 Manus 开始，业界有很多关于上下文卸载、隔离、缓存和动态检索的分享，这些工程实践和理念其实都很好，很受启发。但在实际场景下，我觉得够用就好。现在基座模型的窗口动辄 100 万起步，而我们一场会议的文本通常也就 1、2 万字。目前模型的长文本处理能力，已经足以应付绝大多数连续对话中的上下文关联。
八、当前最大的瓶颈：增长与注意力的争夺
当产品做出来、跑通了、工程去魅了之后，我发现我们面临的真正瓶颈，已经不再是技术和产品本身，而是增长。
在增长这件事情上，我个人觉得 AI 能够给独立开发者带来的红利非常有限。AI 可能可以帮你批量产出一些 SEO 内容、做点简单的投放任务，但实际上这些很难带来质的改变。
目前最大的挑战在于：用户的注意力已经被以 Claude Code、Codex 和 OpenClaw 为代表的巨头或顶级开源 Agent 吞噬了。劝说用户在日常工作流里再去尝试一个全新独立产品的门槛，比以往任何时候都要高。
我们在今年 2 月份产品公测时，跟一个国内很有名的社区做过一次推荐合作，当时带来了非常可观的第一批新用户。到了 5 月份，我们用同样的渠道再次尝试，发现转化率直接下滑了一个数量级。这也是为什么大家现在在小红书上刷到的"独立开发"案例越来越娱乐化——因为纯靠产品本身获取消费级用户的自然增长太难了，很多独立开发的产品在最后只是他们打造个人 IP、做社群和知识付费的"Trigger（引流工具）"，而不是一个真正严肃的商业级产品。
九、结语与我们的初心
最后，打一个小的广告。如果大家对 YouNavi 感兴趣，欢迎扫码加入我们的用户群。
用一个更深层的价值内核来阐述我们的 Slogan，就是：我们不希望大家手头里的 Agent，每天都在帮你做一些"交差性质的杂活"。
批量生成小红书笔记、做 SEO、改表格、写基础代码……这些杂活 Agent 确实能做，但现在 SOTA 模型的 Token 成本其实很贵，将如此宝贵的智能廉价地倾注在这些经济价值低的任务上，我觉得是一种浪费。
YouNavi 想做的事，是交付思考。我们可能不会直接帮你一键生成一份平庸的 PPT（虽然我今天分享的幻灯片就是用 YouNavi 生成的版式，但这在今天对 agent 来说已经非常常见了），我们更希望提供一个场域，让你可以和 SOTA 模型进行深度的、推演式的对话，共同去复盘、分析你工作和生活中那些真正需要深思熟虑、能产生巨大杠杆效应的复杂决策。
它目前的着力点非常明确：听懂每一场沟通，过滤废话，洞察水下的非共识，并最终付诸积极的行动。
这就是我今天的分享，谢谢大家！
本周 YouNavi Release Note
本周 YouNavi 升级至 v0.3.6 版本。功能更新如下：
[新增] 支持扫码绑定钉钉智能体（bot），通过钉钉 IM 来跟 Navi 对话
[优化] 重构了用户登录与本地数据逻辑，现在在断网或无网络环境下，录音、本地数据管理等核心功能依然可用
[优化] 优化了全局记忆文件的编辑、新建和导入体验
[优化] 优化了在对话中要求生成 pdf 等文件格式的生成质量（后续会进一步优化 docx、pptx 等文件格式）
[优化] 优化了录音面板交互、录音忘关提醒、browser use 的浏览器交互、图标展示问题等用户反馈的问题
[升级] 全面接入 Gemini 3.5 flash 最新模型
YouNavi 产品研发团队 敬上
2026.05.22