mvp-spec

编写代码前先写好规范。将一个粗略的想法转化为可落地的 v1，明确精简后的功能范围、数据模型和技术栈建议。

如何开始

只问一个问题。

“你的想法是什么？用一句话说明。”

等待回答。然后立即先挑战范围，再做其他事情。

进入阶段 1 前，先问缩小范围的问题：

“如果这周只能发布一个功能，而且它必须带来实际价值——你会选什么？”

这不是可选项。规范将围绕这个问题的答案来构建。如果用户答不上来，说明这个想法还没准备好进入规范阶段。继续追问，直到他们说出一件事。

如果他们把 3 个功能都列为“唯一要做的事”，就提出质疑：“这是三件事。哪一件排第一？如果发布时必须砍掉另外两件，你会保留哪一件？”

确定唯一的核心功能后，再继续。在此之前不要编写规范。

---

阶段 1：梳理想法

询问缺失的信息：

1. 想法——它能做什么？用一句话说明。
2. 面向谁？——目标用户。“开发者”太笼统。“使用 Next.js 构建产品的独立 SaaS 创业者”才够具体。
3. 变现方式——免费、免费增值、付费，还是按点数收费？如果还不明确，暂时跳过。
4. 技术偏好——有技术栈限制吗？还是由该技能给出建议？

如果用户给出一段话，就从中提取这些信息，并在继续前与用户确认。不要重复询问已有信息。

阶段 2：只做一个产品的规则

在编写任何内容前，验证范围：

• 这是一个产品，还是把三个想法硬拼在一起？
• 一个人能否在 1–2 周内构建并发布 v1？
• 用户是否能通过一个明确的操作获得价值？

如果想法过于宽泛，就缩小范围。本规范只涵盖 v1——不涵盖愿景，也不涵盖路线图。

缩小范围的问题：“如果这周只能发布一个功能，而且它必须带来实际价值——你会选什么？”这就是核心循环。围绕它构建规范。

阶段 3：拆分功能

列出所有提到的功能，然后严格分类。

发布时包含（在 v1 中发布）

仅保留能够完成核心循环的功能：

• 用户可以注册
• 用户可以完成那件事
• 用户能从中获得价值
• 你能确认他们确实获得了价值

以后再做（第 2 个月及之后）

其他所有内容。除非能明确证明是发布所必需，否则默认归入此类：

• 设置、偏好设置、通知
• 团队功能、协作、多用户
• 管理后台
• 分析仪表板
• 移动端优化
• 集成、webhook、API 访问

判断标准：“去掉这个功能，用户还能从 v1 中获得价值吗？”如果可以 → 以后再做。

阶段 4：数据模型

只为发布时包含的功能设计。不要为以后再做的功能建模——反正架构之后还会变。

users
├── id (uuid)
├── email
├── [plan | credits — if monetized in v1]
├── created_at
└── updated_at

[core resource]
├── id (uuid)
├── user_id → users.id
├── [core fields]
├── created_at
└── updated_at

Relationships:
- users has many [resources]
- [resource] belongs to user

每个实体使用一张表。除非 v1 包含协作功能（这种情况几乎不会发生），否则不需要联结表。

阶段 5：API 路由

只添加发布时包含的功能实际需要的路由。

Auth
POST   /api/auth/signup
POST   /api/auth/login
GET    /api/auth/me

[Resource]
GET    /api/[resource]           — list (current user only)
POST   /api/[resource]           — create
GET    /api/[resource]/:id       — get one
DELETE /api/[resource]/:id       — delete

除非编辑是 v1 核心循环的一部分，否则不要添加 PUT/PATCH。

阶段 6：页面

列出用户在 v1 中会看到的所有屏幕。

/                  — Landing page
/login             — Auth
/signup            — Auth
/dashboard         — Main view after login
/[resource]/:id    — Detail view (if needed)
/settings          — Only if required for launch

阶段 7：技术栈

根据用户提出的限制条件给出建议。

优先事项	技术栈
一个人最快发布	Next.js + Supabase + Vercel
完全掌控后端	Next.js + Postgres + Prisma + Railway
以 AI 为主	Next.js + Vercel AI SDK + Supabase
Python 后端	FastAPI + Postgres + Supabase Auth

始终解释原因——每个选择用一句话说明。“Supabase：在一项服务中提供身份验证和 Postgres，v1 无需单独的后端。”

阶段 8：明确不纳入的范围

这是最重要的部分。明确列出 v1 不会构建的内容。

v1 does NOT include:
- Team workspaces or multi-user support
- Email notifications
- API access for external integrations
- Mobile app
- Custom domains
- [anything that came up but got cut]

这可以防止开发过程中范围不断蔓延。每当有人说“再加一个小功能”时，都要参考这一部分。

验证

[ ] Problem statement is one sentence
[ ] 2-3 user personas with specific pain — not demographic labels
[ ] Core loop identified — one action, one value delivered
[ ] Feature list split into LAUNCH and LATER
[ ] LAUNCH features cover exactly one core loop, nothing else
[ ] Data model covers LAUNCH features only — no speculative tables
[ ] API routes listed with HTTP methods
[ ] All pages listed — no screens without a route
[ ] Tech stack recommended with one-sentence reasoning per choice
[ ] Scope cut list explicitly names what v1 does NOT build
[ ] Entire spec is buildable in 1-2 weeks by one person