开发一个AI应用,从MVP到PMF

写给想做或正在做 AI 应用的人，不讲理念，只讲做法——从第一行代码到用户愿意掏钱，这中间到底要经历什么。

先说清楚两个词

MVP（Minimum Viable Product）：能跑、能用、能验证核心假设的最小版本。不是"做得粗糙一点"，而是"只做最关键的那一件事"。

PMF（Product-Market Fit）：产品和市场之间的咬合感。Sean Ellis 的标准是：40% 以上的用户说，如果你的产品消失了，他们会"非常失望"。达到这个，说明你找到了。

从 MVP 到 PMF，不是一条直线，是一个反复测试、收缩、调整的过程。很多团队卡在中间出不来，原因往往不是技术，而是方向没锁定就开始堆功能。

第一阶段：MVP 之前，先做一件事

在写任何代码之前，先把"核心假设"写下来。

一个 AI 应用的核心假设通常长这样：

"我认为 [某类用户] 在 [某个场景] 下，有一个 [具体痛点]，他们现在用 [现有方式] 解决，但这个方式的问题是 [缺陷]，我的 AI 应用可以用 [AI 能力] 更好地解决这个问题，用户愿意为此付出 [时间/钱/数据]。"

这句话你能不能写出来，决定了你的 MVP 要不要做。写不出来，先别动手。

一个反例：某团队看到 LLM 能写代码，就做了一个"AI 编程助手"，功能很全——解释代码、写代码、Debug、生成文档都有。三个月后发现：用户根本不知道什么时候该用他们的产品，因为 GitHub Copilot 已经在 IDE 里了。

核心假设没有，做的是一个没有差异化的功能集合。

第二阶段：MVP 怎么做

选技术栈：够用就行，别追新

企业级 AI 应用的技术栈，目前相对简单的组合类似这样的：

LLM 调用层

模型：OpenAI GPT-4 系列 / Anthropic Claude 系列 / Google Gemini 系列，具体根据任务特性选
调用封装：LangChain（功能全，适合快速接入多种能力）或直接用官方 SDK（更轻，调试方便）
国内场景：通义千问 / DeepSeek / 智谱 GLM，API 接口基本兼容 OpenAI 格式

RAG（检索增强生成）

向量数据库：Pinecone（云托管，省事）/ Weaviate / Milvus（自托管，数据可控）
Embedding 模型：OpenAI text-embedding-3-small，或 BGE 系列（中文效果好）
文档解析：LlamaIndex 做文档切分和索引，比自己写省很多力气

后端

Python + FastAPI：生态最好，AI 相关库几乎都是 Python 优先
数据库：PostgreSQL（主数据）+ Redis（缓存 + 会话状态）

前端

前端：Next.js（React）或 Nuxt（Vue），根据团队技术栈选；Tailwind CSS + shadcn/ui 快速出界面，流式输出（streaming）支持好
组件库：shadcn/ui，等等，很多，拿来即用。

部署

MVP 阶段：Vercel（前端）+ Railway 或 Render（后端），能省掉大量 DevOps 工作
往后扩：迁到 AWS / 阿里云，上 Docker + K8s

这套栈的选择逻辑是：不让技术债拖慢验证速度。MVP 阶段最贵的资源是时间，不是服务器费用。

MVP 要做什么，不做什么

要做的：

核心流程跑通（从用户输入到 AI 输出，完整链路）
最基础的用户认证（哪怕是 Magic Link 也行）
能记录用户行为的埋点（这是后面分析 PMF 的原材料）

不要做的：

精心设计的 UI（能用就行）
完善的权限系统
多租户支持
完整的错误处理（重要错误兜底，其他 log 记下来就好）
性能优化（先跑起来，再谈快）

一个判断标准：每次你想加一个功能，问自己一句话——"这个功能的有无，会改变我对核心假设的验证结果吗？"如果不会，放进 Backlog，先不做。

AI 应用特有的 MVP 问题

普通应用的 MVP 逻辑大家都懂，但 AI 应用有几个特别的地方：

1. Prompt 就是产品核心，不是代码

很多团队把精力放在工程架构上，但 AI 应用早期，Prompt 的质量直接决定用户体验。Prompt 要版本管理，要 A/B 测试，要有专人维护。

建议从一开始就把 Prompt 从代码里分离出来，存到数据库或配置文件里，方便快速迭代。用 LangSmith 或 PromptLayer 做 Prompt 的追踪和评估。

2. 延迟是用户体验的一部分

LLM 调用慢，这是事实。MVP 阶段要做的不是优化延迟，而是让延迟"看起来不那么慢"：

用 Streaming 输出，让用户看到文字在流动
加一个有意义的 Loading 状态（"正在分析您的数据……"比转圈圈好很多）

3. AI 会犯错，你需要一个"出错了怎么办"的设计

不是指代码异常处理，而是当 AI 输出质量差时，用户怎么办？MVP 阶段可以加一个简单的"这个回答有帮助吗"的反馈按钮，收集数据的同时也给用户一个出口。

第三阶段：从 MVP 到 PMF，这段路怎么走

先定义你的"PMF 信号"

不同产品的 PMF 信号不同。对 AI 应用来说，常见的信号有：

信号	说明
留存率	D7 留存 > 30%，D30 留存 > 15%，是个不错的起点
自发传播	用户主动分享给别人，不靠广告
用户抱怨你的限制	"为什么只能用 X 次？""能不能加 Y 功能？"
付费转化	用户愿意付钱，哪怕是象征性的费用
NPS > 50	推荐意愿强

在开始跑用户之前，先想清楚：你会看哪个指标来判断自己是否接近 PMF？这个答案要在团队内对齐，否则后面很容易陷入"数据解读之争"。

找到你的"核心用户"，不是"所有用户"

PMF 不是让所有人都喜欢你，而是让某一类人非常依赖你。

做法：在早期用户里，找到那些使用频率最高、反馈最积极、愿意帮你介绍朋友的人，单独拉一个群，深度访谈。

访谈不是问"你觉得我们产品怎么样"，而是问：

"你上次用我们产品是什么时候，当时在做什么？"
"如果没有我们，你会怎么处理这件事？"
"你有没有把我们推荐给别人？为什么推荐（或为什么没有）？"

这些问题挖出来的答案，比任何问卷都有价值。

迭代的节奏：两周一个循环

MVP 跑起来之后，建议保持这个节奏：

第 1 周：收集数据 + 用户访谈第 2 周：做一个具体的改动，上线然后重复

每个循环对应一个假设验证。比如：

假设：用户看不懂 AI 的输出，加一个"解释一下"按钮会提高满意度
验证：加了之后，看这个按钮的点击率和后续留存变化

不要同时改太多东西，否则你不知道是哪个改动起了作用。

什么时候该"转向"，什么时候该"坚持"

这是从 MVP 到 PMF 最难的判断。

转向的信号：

用户流失原因高度一致，且不是你的核心场景能解决的
留存曲线一直是向下的，没有趋稳的迹象
你能找到用户，但他们只是"觉得挺有意思"，不是"离不开"

坚持的信号：

有一小撮用户（哪怕只有 20 人）真的非常依赖你
问题出在触达和引导，不是产品本身
留存曲线在某个分层（比如某类职业的用户）是趋稳的

转向不是推倒重来，通常是"换一个目标用户"或"换一个核心场景"，而不是"换一套技术"。

第四阶段：到了 PMF，接下来怎么做

找到 PMF 之后，反而是很多团队翻车的时候——因为开始"做大"，但基础没打好。

几个常见的坑：

1. 过早扩张用户规模，PMF 信号刚出来就开始大规模投放，结果服务稳定性跟不上，口碑反而变差。先把核心链路的稳定性做到 99.9%，再谈增长。

2. 忘记继续做用户访谈，团队大了，就觉得"我们已经懂用户了"。PMF 之后，用户画像会变，使用场景会变，继续保持和真实用户的接触是必须的，不是可选的。

3. 技术债集中爆发，MVP 阶段为了速度欠下的债，在规模化阶段会一起来找你。建议在 PMF 信号确认后，专门拿出一到两个迭代做技术债的偿还，尤其是：

Prompt 管理和版本控制
LLM 调用的错误处理和降级策略
数据库查询性能

最后说一句

AI 应用和普通应用的本质区别不在于技术，而在于：用户的期望值比以前高得多，但 AI 能做到的边界又很模糊。

这意味着你要比以前更精准地定义产品边界，更快速地响应用户反馈，也要更诚实地面对"AI 在这件事上做不好"的情况。

从 MVP 到 PMF 没有捷径，但有清晰的路。先做对方向，再做速度。