AI 产品 MVP 开发：我如何用 4 个月做出飞天猫
- 约 7 分钟读完 - 全文 2644 字AI 产品 MVP 开发：我如何用 4 个月做出方糖猫
方糖猫是我从 0 到 1 主导的一个 AI 视频生成平台。从有想法到第一个版本上线，花了大约 4 个月。这篇文章会复盘整个 MVP 开发过程，包括当时做了什么对的决定、犯了什么错、以及如果重来我会怎么改进。
一、为什么要做方糖猫
1.1 观察到的痛点
2025 年前后，我身边很多朋友开始做短视频：
- 有人做知识科普，但剪辑太慢，一周只能出 2-3 条
- 有人做口播，但画面单调，自己又不会做 B-roll
- 有人做产品宣传，请不起专业剪辑团队
大家共同的需求是：用更短的时间、更低的成本，做出一条能看的短视频。
1.2 技术时机成熟
当时几个关键技术已经可用：
- 大模型：DeepSeek / GPT 能写脚本、做规划
- 语音识别：Whisper 能生成词级时间轴
- TTS：多种中文配音模型质量可用
- 视频渲染：Remotion 让程序化渲染变得可行
这让我觉得，一个「文案 → 视频」的自动化平台有机会做出来。
1.3 要做的产品
一句话定义：
用户输入一段文案，系统自动匹配素材、生成配音、渲染成短视频。
二、MVP 范围定义
2.1 核心场景
我们锁定了第一批目标用户：知识类口播创作者。他们的视频结构相对固定：
- 开头点题
- 中间展开 3-5 个要点
- 结尾总结
这种结构最适合自动化处理。
2.2 MVP 功能边界
做：
- 文案输入
- AI 生成故事板
- 自动匹配本地素材库
- TTS 配音
- Remotion 渲染
- 基础前端编辑
不做：
- 用户自定义复杂动画
- 多轨音频编辑
- 多人协作
- 付费订阅系统
- 移动端 APP
2.3 为什么敢砍这么多功能
MVP 的核心目标是验证：用户愿不愿意为「文案 → 视频」这个核心流程付费。
如果核心流程没人用，再多的周边功能也没用。如果核心流程有人用，周边功能可以慢慢加。
三、四个月开发节奏
第一个月：核心链路跑通
目标：让一条文案能生成一个最粗糙的视频。
工作：
- 搭建 Spring Boot 3 + Vue 3 基础项目
- 接入 DeepSeek API，让 LLM 根据文案输出故事板
- 用 Remotion 渲染最简单的画面：标题卡 + 说话人占位图 + 字幕
- 用 edge-tts 生成配音
里程碑：输入一段 100 字文案，5 分钟后拿到一个能播放的视频。
第二个月：素材库和编辑能力
目标：让视频能看，用户能微调。
工作：
- 搭建 RAG 素材库（ChromaDB + BGE-M3）
- 根据文案语义自动匹配图片/视频素材
- 前端增加故事板编辑：替换素材、调整文案、修改标题
- 接入阿里云 OSS 存储成片和素材
里程碑：生成的视频不再是「占位图」，而是有真实素材的「半成品」。
第三个月：稳定性和产品化
目标：从「能跑」到「能用」。
工作：
- 渲染任务接入 RocketMQ，支持多 Worker
- 增加 SSE 实时进度推送
- 用户注册登录、任务历史记录
- 错误处理和降级策略
- 横竖屏多分辨率输出
里程碑：邀请 5-10 个目标用户内测，他们能独立使用。
第四个月：上线和迭代
目标：正式对外开放，收集真实反馈。
工作：
- 域名备案、服务器部署
- 基础运营后台
- 用户反馈收集和快速修复
- 发布 1.0 版本
里程碑：ftmao.com 正式上线，有真实用户注册使用。
四、技术栈选择
| 层级 | 技术 | 选择理由 |
|---|---|---|
| 前端 | Vue 3 + Vite + Pinia | 团队熟悉，开发效率高 |
| 后端 API | Spring Boot 3 + Java 17 | 业务系统稳定性好 |
| AI Worker | Python 3.11 + FastAPI | AI 生态丰富 |
| 数据库 | MySQL + Redis | 成熟稳定，团队熟悉 |
| 向量库 | ChromaDB | 部署简单，适合 MVP |
| 消息队列 | RocketMQ | 负载均衡和重试机制完善 |
| 对象存储 | 阿里云 OSS | 国内访问快 |
| 渲染 | Remotion + FFmpeg | 组件化渲染 + 强大后处理 |
| LLM | DeepSeek | 性价比高，中文效果好 |
4.1 有没有后悔的选型
暂时没有大后悔的：
- Java + Python 双栈增加了复杂度，但确实是当时最优解
- ChromaDB 在数据量大了以后可能会换 Milvus，但 MVP 阶段完全够用
- Vue 3 + Spring Boot 是稳妥选择
唯一值得反思的是：
- 过早引入了 RocketMQ。其实前两个月用 HTTP 轮询也能支撑，第三个月再切队列压力更小。
五、内测与反馈
5.1 如何找到早期用户
- 朋友圈和抖音播客粉丝中筛选做内容创作的人
- 主动私聊，邀请试用
- 不收费，只要求反馈
5.2 收集到的关键反馈
| 反馈 | 我们的反应 |
|---|---|
| 「生成的视频节奏太慢」 | 优化故事板时长计算，增加紧凑模式 |
| 「素材匹配不够精准」 | 优化 RAG 召回策略，增加查询改写 |
| 「配音太机械」 | 测试多个 TTS 模型，增加情感参数 |
| 「希望能导出字幕文件」 | 增加 SRT 导出功能 |
| 「不会写文案」 | 增加 AI 文案扩写功能 |
5.3 哪些假设被推翻
原本以为用户最在意「视频质量」，实际上最在意「等待时间」。
用户可以接受视频不完美，但如果要等 10 分钟以上，很多人就直接放弃了。
这让我们把优化优先级从「画质」转向了「渲染速度」和「队列调度」。
六、犯的错误
6.1 过早做通用化
第二个月时，我想让平台支持多种视频类型：口播、科普、剧情、广告。结果为了兼容各种场景，架构变得复杂，核心口播场景反而没做好。
教训：MVP 只服务一个细分场景，做深再做广。
6.2 忽视前端体验
前三个月我主要精力放在后端和 AI 流程上，前端做得很简陋。内测用户反馈「不知道点哪里」。
教训：产品是给用户用的，不是给工程师自己看的。前端体验至少要做到「不迷路」。
6.3 没有尽早建立数据看板
上线后我不知道用户的真实使用情况：平均生成多少条、平均等待多久、失败率多少。
教训：MVP 阶段也要有基础埋点和看板，否则无法判断产品健康度。
6.4 低估了合规和成本
TTS、LLM、OSS、CDN、服务器，每一项都是按量付费。上线第一个月没注意控制，账单超出预期。
教训：MVP 阶段就要做成本预算和限额，避免烧钱不自知。
七、如果重来，我会怎么做
7.1 第一个月就用真实用户测试
不需要等 4 个月再邀请用户。第一周就可以给目标用户看原型图，第二个月就可以给粗糙版本试用。
7.2 更早砍掉非核心功能
比如「用户自定义动画」「多分辨率导出」这些，其实可以晚两个月再做。
7.3 更早做数据埋点
从第一天就记录：
- 用户从进入网站到生成视频的转化率
- 每个步骤的流失率
- 生成成功率和平均耗时
7.4 更克制地引入中间件
消息队列、向量库这些都可以先用简单方案顶上，等真的成为瓶颈再升级。
八、上线后的数据
（待补充真实数据）
| 指标 | 数值 |
|---|---|
| 上线时间 | 2026 年 X 月 |
| 注册用户 | X |
| 累计生成视频 | X 条 |
| 平均生成耗时 | X 分钟 |
| 生成成功率 | X% |
| 付费转化率 | X% |
九、对技术创业者的话
9.1 技术不是壁垒，产品化才是
会用 LLM、会调 Whisper 的人很多。但能把这些技术做成稳定、可用、有商业价值的产品的人很少。
9.2 不要等完美了再上线
第一个版本一定很丑、很慢、很多 Bug。但只要核心流程能跑通，就值得给用户看。
9.3 找到愿意骂你的用户
夸你的用户没价值，愿意指出问题的用户才是真用户。把他们服务好，产品会越来越好。
9.4 控制成本
AI 产品的边际成本不低，尤其是调用大模型和渲染视频。MVP 阶段就要算清楚账。
十、总结
方糖猫的 MVP 开发让我真正理解了「从 0 到 1」的含义：
- 范围要狠：只做一个场景，一个核心流程
- 速度要快：4 个月不算短，但可以更短
- 用户要早：从第一天就找目标用户
- 数据要全：用数据判断产品方向
- 成本要控：别让自己死在黎明前 https://gitee.com/soulnew/geekcast 如果你也在做 AI 产品的 MVP，希望我的经验能帮到你。
关于 AI 产品化、MVP 开发，如果你有问题，欢迎在评论区交流。
18 年后端架构，现在独立做 AI 产品。这里记录 AI 视频、AI Agent 与工程实践。