最近回头看我之前做的一个产品，有个事越来越清楚：动手太早，是我花过最贵的学费之一。
该做还是要做。只是这种挺垂的需求，最怕一边写代码一边想。
01 垂类需求最坑的，是边做边想
我做那个产品的时候，需求听起来特别简单。
用户拿一段自己的资料进来，你帮他变成另一种能直接用的东西。一句话就能讲完。
真做起来不是那么回事。
输入是什么格式？长度限制多少？输出要长什么样，字段怎么定？哪些情况你不支持，得提前说清楚？还有更麻烦的——你怎么验证你给的结果是对的？
这些事，只要你做的是个挺垂的东西，几乎一定比想象中多。
通用工具还好，用户自己知道怎么用。垂类需求面向的是一群具体的人，他们对"对不对"很敏感，你含糊一点，他们立马能看出来。
所以这类需求，最怕开工前没想清楚，做到一半发现"不对，这里应该是另一个逻辑"，然后改，改完又发现旁边也要改。
02 动手前，先写一张需求清单
我现在习惯，写代码之前，先逼自己写一张清单。
不用很长，但得 cover 几件事：
输入输出。用户给什么，你出什么，中间字段怎么定，格式长什么样。
用户是谁。服务哪群人，更重要的，不服务谁。后者经常比前者还难写，但写了之后，你后面少做很多无用功。
定价和付费点。免费给多少，卡在哪个动作上让人愿意付费。这个不开工前想，后面补起来特别别扭。
UI 大概长什么样。不用画好看，有个雏形就行——首屏放什么，用户下一步点哪。
还有一条最关键的：第一版不做什么。写得越具体越好，比如"不做 X、不做 Y、不做 Z"。
我那个产品当时就写了这么一张。现在看，它最大的作用，是挡住我自己。开发具体怎么走，它管不了那么多。每次想加功能，看一眼清单，很多东西就知道该不该做。
我自己也走过弯路。清单写好了，有次放任 AI 先去研究一堆背景资料，它自己绕了很远，最后还是回到清单上才动起来。想清楚之后，直接搭第一版，比先研究靠谱。
03 先做个纯页面 Demo，别一上来接后端
清单写完了，也别急着把数据库、登录、支付全搭上。
我现在更愿意先做一个纯页面：没有后端，核心交互能跑就行。
拿我那个产品说，第一版 Demo 就是：用户粘贴一段内容，点一下，结果直接显示在页面上，能复制走。不登录，不保存，不付费。
就这一页，已经能验证很多东西——这个流程用户顺不顺手，结果展示得清不清楚，第一眼看上去像不像个能用的东西。
手感对了，再决定下一步接什么。
很多返工，其实是还没验证手感，就先把后端全做了。等发现流程不对，后端也白搭。
04 什么时候直接干，什么时候先试
也不是所有东西都要先写清单、先做个 Demo。
我自己的判断是：
如果需求特别简单、单一，比如一个明确的格式转换，你脑子里的流程已经很清楚了，直接干，别磨叽。
但如果这个需求有点逻辑，或者你根本找不到一个对标的产品参考，那就别硬上。先写一个页面，自己点一遍，看效果，再决定下一步怎么做。
说白了，简单的事别拖，复杂的事别莽。
收个尾
我现在做产品，基本是这个顺序：先把需求想清楚，写张清单，做个纯页面 Demo 试手感，对了再往里加东西。
谈不上什么方法，就是少吃几次返工的亏，慢慢形成的习惯。
你要是也在用 AI 做产品，可以先从写一张需求清单开始试。哪怕只写半页，也比直接打开编辑器强。