一人公司3天出MVP：我如何用4阶段工作流取代10步瀑布流

作为一个独立开发者，我曾花两周写需求文档，一周画UI，一个月后才写出第一行代码。然后发现——方向错了。这套流程，让我用3天验证一个想法。

---

传统流程杀死的不是时间，是机会

大多数软件设计工作流是这样设计的：

PM写需求 → SA评审 → PM修改 → 写测试用例 → 写代码 → 代码评审 → 测试 → 修Bug → 回归测试 → 写报告

10步瀑布，11份文档。

这套流程在大团队里没问题——角色分离、层层把关、质量可控。但当你是一个人做0-1产品时，它成了最大的敌人：

• 你既是PM又是SA又是QA又是Dev，写文档给自己审自己，形式主义拉满
• 流程还没跑完，机会已经没了——等你想清楚所有边界情况，竞品已经上线三周了
• 方向可能下周就Pivot，前期两周的投入全部沉没

所以我重新设计了一套工作流。不是改良，是彻底推翻重来。

---

核心理念：先验证，再完善

我把流程砍成了4个阶段，形成一个循环：

Think（半天） → Build（1-5天） → Ship（半天） → Learn（3-7天）
    ↑                                              │
    └────────── Continue / Pivot / Kill ───────────┘

每个循环3-7天。不是要做完所有功能，而是要验证一个假设。

---

Phase 1：Think——想不明白不准动手

时间上限：1天。产出：一页纸。

很多人（包括曾经的我）拿到想法就开始写代码。写了一个星期发现：用户根本不在乎这个功能。

Think阶段强迫你回答5个问题，写在 idea.md 里：

1. 用户与痛点（越具体越好）

❌ 错误：“目标用户是所有小微企业”
✅ 正确：“目标用户是月入5-10万的独立设计师，他们在给客户发报价单时手动填Excel很麻烦”

2. MVP范围（最多3个功能，其余全部砍掉）

这是最难的一步。你的脑子里有20个功能，但MVP只能有3个。不是"最重要的3个"，而是**“没有这3个，产品就不成立”**的最小集合。

3. 验证指标（必须量化）

❌ 错误：“用户会喜欢”
✅ 正确：“7天内100个注册用户完成核心链路"或"3个用户愿意付费”

4. 技术选型（默认栈）

层级	选择	理由
前端	Next.js App Router	全栈一体，一个人前后端通吃
数据库	Supabase PostgreSQL	托管，零运维
认证	Supabase Auth / Clerk	绝不自己写登录
部署	Vercel	Push即部署
组件库	shadcn/ui + Tailwind	复制粘贴就能用

原则：默认这套栈，除非你有明确理由偏离。 一个人维护不了微服务，也维护不了自建服务器。

5. 最坏情况

如果验证失败，损失多少天？能不能承受？Plan B是什么？

关键纪律：回答不清楚，不准进入Phase 2。

---

Phase 2：Build——AI写代码，你做决策

时间：1-5天。产出：可运行的代码 + tech-debt.md。

开发原则

• UI不设计：直接用shadcn/ui，不画wireframe
• API不文档：tRPC类型推导就是文档
• 测试有取舍：核心链路自动化测试，边缘情况手动测
• 数据库从简：需要加字段就加，先让业务跑通

技术债管理

用一个 tech-debt.md 记录，一句话一条：

# Tech Debt
- 用户表没有加索引，用户量过千会慢
- 支付回调没有做幂等处理
- 前端表单没有统一校验逻辑

最多10条。 超过10条说明MVP范围还是太大了。

AI的角色：主力开发

在这个工作流里，AI不是你的"工具"，是你的联合创始人。AI写大部分业务代码，你负责：

1. 架构决策
2. 代码验收（每完成一个功能，自己跑一遍完整链路）
3. 核心算法逻辑

---

Phase 3：Ship——直接上生产，不要预发布

时间：半天。产出：线上产品 + ship-log.md。

这是反直觉的：

• 没有预发布环境。直接部署生产，崩了立刻修。维护两套环境的时间，比你修一次生产Bug的时间多得多。
• 监控只要一个：Sentry错误通知，够了。用户量小的时候，你不需要Grafana大盘。
• 域名从简：先用Vercel默认域名，验证成功后再买正式域名。

# Ship Log: 2024-05-08
## 部署平台
- Vercel (自动部署 main 分支)

## 关键环境变量
- DATABASE_URL, NEXTAUTH_SECRET, STRIPE_SECRET_KEY

## 已知问题
- 移动端首页样式未适配（不影响核心链路，下期修复）

---

Phase 4：Learn——用数据说话，别骗自己

时间：3-7天观察。产出：learn.md + 决策。

上线不是结束，是开始。必须收集：

1. 验证指标达成率：Phase 1定义的数字，达成了多少？
2. 用户行为数据：最简单的埋点就够了（Vercel Analytics或Supabase事件表）
3. 用户反馈：找3个真实用户聊，记录原话，不要转述

然后做一个决策：

达成率	决策	下一步
≥ 80%	Continue	进入下一循环，扩展功能
30%-80%	Pivot	调整方向，回到Phase 1
< 30%	Kill	放弃，启动下一个idea

最难的纪律：如果决定Kill，立刻执行，不要沉没成本。 写进 learn.md 复盘，然后下一个。

---

文档瘦身：从11个到4个

传统流程的文档负担：

传统文档	新处理方式
requirements.md + sa-review.md + dev-plan.md	合并为 idea.md（1页）
test-cases.md + sa-test-review.md	核心测试写代码里，其余手动
sa-code-review.md	删除——AI做代码审查
api-doc.md + ui-ux-spec.md	自动生成或直接用组件库
deploy.md	合并为 ship-log.md（半页）
bugs/BUG-xxx.md	简化为列表或GitHub Issues
test-report.md	合并为 learn.md

从11个文档 → 4个：idea.md、tech-debt.md、ship-log.md、learn.md

---

7个一人公司常见死亡陷阱

陷阱	后果	解药
Phase 1写了3天还没写代码	想法永远停留在想法	Think严格限制1天
MVP做了10个功能	每个都60分，没有一个打动用户	最多3个核心功能
花2天画UI/写设计文档	0-1阶段没人care UI好不好看	用现成组件库
自己写登录/支付/权限系统	浪费1-2周在基础设施上	Supabase Auth / Clerk
上线后不看数据，凭感觉迭代	在错误方向越走越远	Phase 4必须收集数据
舍不得Kill，硬撑3个月	沉没成本越来越高	定义失败标准，到点就执行
担心"技术债太多以后还不上"	先担心有没有"以后"	0-1阶段能跑通比代码优雅重要100倍

---

写在最后

这套工作流不是让你写更优雅的代码，是让你更快知道这条路对不对。

一个人做0-1产品，最大的风险不是代码写不好，是花三个月做了一个没人要的东西。3天验证一个想法，一个月可以验证6-8个想法。只要其中一个对了，再回来补技术债、优化UI、完善文档。

先验证，再完善。先上线，再优化。

---

如果你也在做一人公司(One Person Company，简称OPC)的产品开发，欢迎在评论区分享你的 workflow。我们都是在黑暗中摸石头过河的人。