AI 产品 MVP 开发：我如何用 4 个月做出飞天猫

Mon, 23 Mar 2026 18:00:00 +0800

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 开发，如果你有问题，欢迎在评论区交流。

AI 产品 on 方糖猫Blog