构建 MVP

Demo 和产品的距离

Demo 只要跑通主路径就行。产品要处理的是：

• 输入是空的、超长的、格式错的、带表情符号的
• 网络断了、接口超时、第三方服务挂了
• 同一个人快速点了两次
• 手机上打开，屏幕只有一半宽
• 没登录的人直接访问了内页
• 用户填到一半刷新了页面

这些加起来，通常比主功能本身工作量还大。

这就是"Demo 发了朋友圈，然后就没有然后了"的真实原因—— 不是没坚持，是低估了后面这段路。知道它有多长，你才不会在中途以为自己失败了。

用 AI 写代码的实际节奏

有效的做法只有一条：一次只让 AI 做一件能验证的事。

• ✅ "给这个表单加上邮箱格式校验，错误提示显示在输入框下方"
• ❌ "帮我做一个用户系统"

第二种写法会得到一堆看起来对、跑起来错的代码，而且你不知道错在哪， 因为你没看着它一步步长出来。

每完成一步就跑起来看一眼，不要攒着一次性验收。 攒到最后一起调，等于放弃了 AI 最大的优势：改一次只要几秒。

先让它能跑，再让它好看

顺序错了会浪费大量时间。

1. 数据流通 —— 输入能进去，结果能出来，存得下，取得回
2. 异常不崩 —— 出错有提示，不是白屏
3. 能用 —— 移动端能打开，按钮点得到
4. 好看 —— 这一步放最后

很多人反过来做，在还没跑通的功能上调了三天间距。

脏活才是产品的护城河

主功能通常两天就能做出来。真正难的是那些没人愿意写的部分：

• 多数据源的差异 —— 每家接口格式、字段命名、错误码都不一样
• 限流和重试 —— 第三方接口有配额，超了要排队，挂了要退避重试
• 结果去重 —— 同一条数据从不同来源拿到，格式还不一致
• 缓存策略 —— 什么该缓存、缓存多久，直接决定你的成本
• 降级 —— 一个数据源挂了，产品要还能用

这些东西不性感，写完也没人夸，但它们才是别人抄不走的部分。 主功能人人能做，脏活处理得好不好，决定了产品能不能被真实使用。

什么时候算做完了

不是功能清单打完勾，是这个标准：

一个不认识你的人，不用你在旁边解释，能自己走完一遍主流程。

达不到就还没做完，不管你写了多少代码。

本章动作

找一个不认识的人，让他打开你的东西，你在旁边看着，全程不要说话。

他卡住的第一个地方，就是你下一步要改的地方。