构建 MVP 总览

验证过方向之后，这一阶段只做一件事：把核心假设变成一个能被真实用户试用的版本。

MVP 不是功能少一点的完整产品，而是能验证核心假设的最小产品。先让一个真实用户完成一条核心路径，再考虑更多页面、更多角色和更完整的系统。

本阶段要完成什么

• 选定第一版技术路线和产品形态。
• 跑通最小项目脚手架。
• 做出核心页面、核心流程和最小数据闭环。
• 让 AI 参与拆任务、写代码、查问题和做验收。

必做任务

技术路线怎么选

做 MVP 时，技术栈选择不要从“哪个框架最流行”开始，而要从第一版产品要验证什么开始。

先判断产品形态：

早期真正重要的是：

• 用户能不能打开。
• 核心流程能不能跑完。
• 你能不能快速改。
• 数据和反馈能不能收回来。
• 部署、域名和支付不要卡住主线。

如果你已经决定做 Web MVP，并且想理解 Next.js、TanStack Start、Hono、oRPC 这些技术边界，可以看 01MVP 模板的技术选型说明。

如果你已经决定把项目放到 Cloudflare，再看 Cloudflare 技术栈选型。那篇会具体解释 Astro、Hono、React Router、Next.js/OpenNext 分别适合什么项目。

三条推荐路线

国内用户：微信小程序 + 腾讯云开发

在国内，小程序比网页更容易触达用户，也比 App 更容易安装和分享。适合面向国内 C 端用户、需要微信支付/微信登录、社交内容或轻工具类产品。

推荐组合：

前端：微信原生小程序 / Taro 4.x + React + TypeScript
后端：腾讯云开发 CloudBase（云函数 + 数据库 + 存储）
AI：CloudBase AI 集成（混元 / DeepSeek / GLM / Kimi）
部署：微信开发者工具上传 / 云开发静态托管

CloudBase 的 CLI、MCP 和 Skill 是三层东西：

• CLI（@cloudbase/cli，命令 tcb）：管理云开发环境、查看资源状态。
• MCP（@cloudbase/cloudbase-mcp）：让 AI 直接执行建表、部署函数、查日志等管理操作。
• Skill（cloudbase-skills）：让 AI 知道正确的代码写法和最佳实践。

npm install @cloudbase/cli@latest -g
tcb ai
npx skills add TencentCloudBase/cloudbase-skills

国内 Web / 后台：云服务器 + Zeabur

如果你做的是 Web 应用、管理后台或 API 服务，不需要小程序载体，可以用国内云服务器配 Zeabur。它比手工 Docker 部署轻，又比小程序自由。

推荐组合：

前端：Next.js / Nuxt / React / Vue
后端：Hono / Express / FastAPI / 任意语言
数据库：PostgreSQL / MySQL
部署：Zeabur 关联云服务器 / 手动 Docker
域名：国内备案域名

海外产品：Cloudflare 全栈

面向全球用户时，Cloudflare 对独立开发者很友好：免费额度大、DNS 和部署在一个平台、边缘节点覆盖广。

推荐组合：

前端：Astro（内容站）/ React Router v7（Web App）/ Next.js（OpenNext）
后端：Hono / 原生 Workers
数据库：D1 / Neon
存储：R2 / D1 / KV
AI：Workers AI / AI Gateway
部署：Wrangler CLI / GitHub Actions
域名：Cloudflare Registrar + DNS

Vercel 适合强 Next.js 项目，Zeabur 适合 Docker 化项目。不要把“未来能不能撑到一百万用户”放在第一位，先选一条能在一周内上线并改得动的路线。

MVP 开发原则

MVP 的重点不是“最小可用”，而是“最小可验证”。只要它能帮你验证一个关键假设，就已经完成了第一版的任务。

只做核心功能

所有不能帮助你验证核心价值的功能，都先砍掉。

不要在第一版做这些：

• 多语言。
• 完整权限系统。
• 数据导出。
• 高级搜索。
• 复杂统计面板。
• 邮件通知自动化。
• 微服务、读写分离、缓存层、负载均衡。

可以接受的第一版：

• 配置写死在代码里。
• 少量重复代码。
• 简单数据结构。
• 先手动处理少量边界情况。

不可接受的是核心流程不能跑、改一个地方要改十个文件、用户出错后没有任何提示。

先跑流程，后写代码

在写代码前，先手动帮几个真实用户解决问题，把每一步记录下来。很多产品不是先自动化，而是先人工跑通，再把稳定步骤产品化。

每次你想加新功能时，用四个问题拦住自己：

1. 能用一个周末做完并交付吗？
2. 能让用户的生活变好一点吗？
3. 有用户愿意为此付费吗？
4. 能快速得到反馈吗？

有一个答案是“不能”，就先别做。

技术不用优雅，但必须改得动

MVP 阶段不适合顺手练新技术。你要验证的是需求，不是证明自己会用某个新框架。

优先选：

• 成熟框架，不追刚发布的新东西。
• PostgreSQL、SQLite、D1 这类容易理解的数据库。
• Cloudflare、Vercel、Zeabur、CloudBase 这类能快速上线的平台。
• 现成模板、Starter Kit 和开源项目。

模板不是竞争力，它只是帮你更快补齐登录、支付、部署、统计、邮件、存储这些底座。真正让用户留下来的，是核心场景、交付结果和对目标人群的理解。

选模板时用一个朴素标准：24 小时内能不能去掉演示内容，跑通一个真实用户流程。如果第一天都卡在环境、文档和陌生抽象里，它不适合当前这个 MVP。

时间不要全花在开发上

很多技术人会把 90% 的时间花在开发上，但 MVP 阶段更合理的分配是：

• 开发核心功能：1-2 周。
• 设计和测试：3-5 天。
• 准备营销内容：1-2 周。
• 找第一批用户：持续进行。

产品还没有真实反馈前，不要把“代码扩展性”看得比“用户是否愿意用”更重要。

竞争力来自窄而深

独立开发者很难靠功能数量和大公司竞争。更现实的竞争力来自：

• 更窄的人群：只服务一个明确角色，而不是所有用户。
• 更深的场景：理解这个人群的语言、流程、禁忌和预算。
• 更快的反馈：用户一句话，你当天就能改。
• 更清晰的取舍：知道哪些功能不做，避免产品被需求拖散。
• 更强的内容资产：用教程、案例、模板和公开构建不断解释你的产品。

所以第一版不需要证明你能做很多功能。它要证明：你能不能把一个具体问题解决得足够顺手，让目标用户愿意回来。

什么时候该重构

只有在这些情况下才考虑重构：

1. 有付费用户了，说明方向有信号。
2. 代码真的改不动了，改一个功能要花一周。
3. 性能问题已经影响用户。
4. 有明确安全风险。

没有用户时，扩展性通常不是第一问题。

可选深入

• 设备、环境、账号准备：第一次配开发环境时看。
• 不会写代码也能做产品：适合先用无代码工具验证。
• 代码模板怎么选：需要从 starter 或 boilerplate 启动项目时看。
• UI 设计基础：让页面看起来可信。
• 设计系统是什么：需要和 AI 或设计稿长期协作时看。
• 微信登录：能不碰就不碰：国内登录方案选型前看。
• Cloudflare 技术栈选型：已经确定用 Cloudflare 时看。

常见卡点

复制给 AI

你是我的 01MVP 技术合伙人。

我已经验证过的产品假设是：
【写下目标用户、痛点、核心场景】

我想做的第一版 MVP 是：
【写下你想做的功能】

请帮我把它压缩成 7 天内能完成的版本：
1. 第一版必须有的核心流程
2. 可以先不做的功能
3. 推荐技术栈和理由
4. 页面与数据结构草案
5. 适合交给 AI 编程工具的任务拆分
6. 每个任务的验收标准

输出格式：
- MVP 范围
- 页面清单
- 数据清单
- 任务列表
- 不做清单
- 验收清单

推荐 Skills / 工具 / 案例

• 开发者 Skills：适合拆任务、查代码、做 review。
• AI 编程工具选型：选 Codex、Claude Code、Cursor 或 Trae。
• AI 编程工作流：学习如何把 PRD 变成可执行任务。
• 10 分钟复现网站：先练一次端到端 AI 编程。
• Codex 游戏开发案例：看 AI 如何从需求推进到可玩 Demo。

做完的验收标准

完成这个阶段后，你应该能拿出：

• 一个可以访问或演示的产品版本。
• 一条真实用户能走完的核心流程。
• 一份暂不做清单。
• 一份已知问题和下一轮迭代清单。
• 一个可以发给用户试用、收集反馈的入口。

延伸阅读

• MVP 导航：按验证问题选择第一版产品形态。
• 《小而美》里的做最小版本：先让核心流程跑通，再谈自动化和扩展。