构建 MVP
把核心假设变成一个真实用户能试用的版本，并知道这段路有多长。
验证过方向之后，这一阶段只做一件事：把核心假设变成一个能被真实用户试用的版本。
MVP 不是"功能少一点的完整产品"，是能验证核心假设的最小产品。这两句听起来像，做起来完全不同。
这一章做完，你要能拿出：
一个别人能打开的地址、一条陌生人能自己走完的主路径、一份不做清单、一份已知问题清单。
"我本地能跑"不算。
Demo 和产品的距离
Demo 只要跑通主路径就行。产品要处理的是：
- 输入是空的、超长的、格式错的、带表情符号的
- 网络断了、接口超时、第三方服务挂了
- 同一个人快速点了两次
- 手机上打开，屏幕只有一半宽
- 没登录的人直接访问了内页
- 用户填到一半刷新了页面
这些加起来，通常比主功能本身工作量还大。
这就是"Demo 发了朋友圈，然后就没有然后了"的真实原因——不是没坚持，是低估了后面这段路。知道它有多长，你才不会在中途以为自己失败了。
这一章的顺序
| 你现在的状态 | 先看哪一篇 |
|---|---|
| 还没决定做网页、小程序还是 App | 技术路线与产品形态 |
| 不想从零写代码 | 从模板起步 |
| 不会写代码 | 不写代码也能做出第一版 |
| 路线定了，要跑起来 | 一天做出可打开版本 |
| 能跑了，要稳定推进 | AI 编程工作流 |
| 要做登录和权限 | 账号、权限与数据模型 |
| 改一个坏两个 | 测试与排错 |
| 产品里有 AI 功能 | AI 功能的质量、成本与兜底 |
| 能用但看着不像能信的东西 | 界面基础、让第一版看起来可信 |
| 要写首页 | 写清首页与产品文案 |
范围还没砍定的，先回到把 MVP 砍到最小。
用 AI 写代码的实际节奏
有效的做法只有一条：一次只让 AI 做一件能验证的事。
- ✅ "给这个表单加上邮箱格式校验，错误提示显示在输入框下方"
- ❌ "帮我做一个用户系统"
第二种写法会得到一堆看起来对、跑起来错的代码，而且你不知道错在哪，因为你没看着它一步步长出来。
每完成一步就跑起来看一眼，不要攒着一次性验收。攒到最后一起调，等于放弃了 AI 最大的优势：改一次只要几秒。
完整节奏见 AI 编程工作流。
先让它能跑，再让它好看
顺序错了会浪费大量时间。
- 数据流通——输入能进去，结果能出来，存得下，取得回
- 异常不崩——出错有提示，不是白屏
- 能用——移动端能打开，按钮点得到
- 好看——这一步放最后
很多人反过来做，在还没跑通的功能上调了三天间距。
每加一个功能，先过四个问题
- 能用一个周末做完并交付吗？
- 能让用户的情况好一点吗？
- 有人愿意为此付费吗？
- 能快速拿到反馈吗？
有一个答"不能"，就先别做。 把它写进不做清单，标上"什么证据出现后再做"。
脏活才是产品的护城河
主功能通常两天就能做出来。真正难的是那些没人愿意写的部分：
- 多数据源的差异——每家接口格式、字段命名、错误码都不一样
- 限流和重试——第三方接口有配额，超了要排队，挂了要退避重试
- 结果去重——同一条数据从不同来源拿到，格式还不一致
- 缓存策略——什么该缓存、缓存多久，直接决定你的成本
- 降级——一个数据源挂了，产品要还能用
这些东西不性感，写完也没人夸，但它们才是别人抄不走的部分。主功能人人能做，脏活处理得好不好，决定了产品能不能被真实使用。
如果你的产品有一块特别难的脏活，把它写成一篇文章。
这类内容全网都稀缺，因为只有真做过的人写得出来。放法见做成搜索资产。
竞争力来自窄而深
一个人很难靠功能数量竞争。更现实的竞争力来自：
- 更窄的人群——只服务一个明确角色，不服务所有人
- 更深的场景——懂这个人群的语言、流程、禁忌和预算
- 更快的反馈——用户一句话，你当天就能改
- 更清晰的取舍——知道哪些功能不做
- 更强的内容资产——用教程、案例、公开记录反复解释你的产品
第一版不需要证明你能做很多功能。它要证明：你能不能把一个具体问题解决得足够顺手，让目标用户愿意回来。
时间不要全花在开发上
技术背景的人容易把九成时间花在写代码上。这一阶段更合理的分配是：
| 事项 | 大致占比 |
|---|---|
| 开发核心功能 | 一到两周 |
| 设计和测试 | 三到五天 |
| 准备可以发出去的内容 | 一到两周 |
| 找第一批用户 | 从第一周就开始，持续做 |
什么时候算做完了
不是功能清单打完勾，是这个标准：
一个不认识你的人，不用你在旁边解释，能自己走完一遍主流程。
达不到就还没做完，不管你写了多少代码。
什么时候该重构
只在这四种情况下考虑：
- 有付费用户了，说明方向有信号
- 代码真的改不动了，改一个功能要花一周
- 性能问题已经影响用户
- 有明确的安全风险
没有用户时，扩展性通常不是第一问题。
常见错误
Demo 跑通就以为快做完了。 后面那段路通常更长。
一次让 AI 做一个大功能。 得到看起来对、跑起来错的代码。
先调视觉再跑通数据。 顺序反了会白做。
功能想加就加。 每个都要过那四个问题。
只做主功能，不做脏活。 主功能人人能做，护城河在脏活里。
等产品做好再找用户。 找用户需要几周，不能压到最后。
没人用的时候就在重构。 扩展性是有用户之后的问题。
验收标准
- 有一个别人能打开的地址，不是"我本地能跑"
- 一个陌生人不用你解释，能自己走完主路径
- 主路径的失败状态有明确提示，不是白屏
- 真机打开过，移动端能用
- 有一份不做清单，每条写了"什么证据出现后再做"
- 有一份已知问题清单
- 已经开始找第一批用户，不是等发布后再开始
本章动作
找一个不认识的人，让他打开你的东西，你在旁边看着，全程不要说话。
他卡住的第一个地方，就是你下一步要改的地方。
下一步
- 技术路线与产品形态——还没定形态先看这篇
- 一天做出可打开版本——定了就今天开工
- 把 MVP 砍到最小——一天做不完就回去砍范围