独立开发：不是想清楚了再做，而是边做边确定

一个人用 AI 做产品以后，我最不适应的一件事，是很多东西还没完全想清楚，开发就已经开始了。

以前在团队里，我更习惯需求相对明确、设计完成，再进入开发。现在却经常是先确定一部分，做出来，再根据真实结果补下一层。

一开始我会觉得：这是不是流程不够完整？

做了一段时间后，我反而越来越觉得，独立开发不是先把一切想清楚，而是知道什么必须现在确定，什么可以边做边确定。

1. 有些东西，越早想清楚越好

不是所有事情都适合边做边改。

有些决定一旦错了，后面会牵一大片。

比如：

• 产品到底给谁用
• 解决什么核心问题
• 这一版最重要的使用场景是什么
• 核心对象和数据之间是什么关系
• 主流程怎么走
• 哪些东西明确不做
• 安全、权限、合规这些不能出错的基础规则

这些地方，我现在反而会比以前更谨慎。

因为如果底层方向错了，AI 写代码再快也只是更快地把错误做大。

2. 有些问题，不做出来其实很难回答

另一类问题就完全不同。

比如：

• 结果页应该先显示结论还是依据？
• 一个操作应该用弹窗，还是单独打开一个页面？
• 哪些内容应该默认展开？
• 某个功能到底值不值得单独存在？

这些问题可以在文档里讨论很久，但真实页面出现以后，答案可能马上变得很明显。

• 信息放进去才知道挤不挤。
• 真的点一遍才知道流程顺不顺。
• AI 结果跑出来以后，才知道用户到底需要什么解释。

所以这类问题，我现在不会强迫自己在开发前得出一个“最终答案”。

先有一个合理方案，做出来，再判断。

越依赖真实内容和真实使用才能判断的事情，越没必要过早锁死。

3. 先走通一个真实的流程，不要一下铺开整个产品

这个改变对我也挺重要。

以前容易按功能模块推进：

这个页面做完，再做那个页面；列表做完，再做详情；功能一个个往计划里划掉。

现在我更愿意先选一个用户真的会完成的动作，从头走到尾。

比如做任务管理工具，不急着先完成：

筛选、搜索、通知、设置、各种列表。

先把最基本的一条路跑通：

创建任务 → 找到它 → 修改状态 → 保存成功。

因为一条完整路径跑起来以后，会一次暴露很多问题：

• 需求本身合理吗
• 数据够不够
• 步骤顺不顺
• 页面放入真实内容以后是不是太重
• 用户完成以后知不知道下一步
• 技术结构有没有明显问题

有些问题，真的只有产品活起来以后才看得到。

4. 做出来以后，别马上继续加东西

这可能是我现在最需要提醒自己的地方。

AI Coding Agent 特别容易让开发一直往前滚。

一个任务完成，再给下一个。

一个页面做好，再补三个功能。

以前团队里的需求评审、设计评审、技术评审、测试，本来会自然让项目停一下。

一个人做产品以后，这些停顿都消失了。

所以需要自己主动停下来看看。

我现在至少会换几个角度：

产品

这件东西真的值得存在吗？

用户

第一次使用的人知道自己在哪里、下一步做什么吗？

设计

重点清楚吗？几个页面放在一起还像同一个产品吗？

工程

当前实现是在支撑后续，还是已经开始制造麻烦？

如果是 AI 产品，还要再看：

• 输出真的好吗
• 错了的时候能不能发现
• 速度和成本是否合理

过去这些问题会有不同的人来问。

现在得自己记得问。

5. 每做完一轮，把已经想清楚的东西留下来

这一步我以前很容易跳过。

功能跑通了，就觉得可以继续了。

结果做久以后，产品底下会积一层东西：

• 过期的需求；
• 临时的数据结构；
• 已经不用却还存在的组件；
• 试过后来放弃，但文档里还写着的方案。

所以现在我觉得，一轮真正结束，不只是“代码能跑”。

还要把这一轮已经确认的东西整理一下。

可能只是：

• 更新几句产品定义
• 删掉已经失效的需求
• 改一下数据模型
• 把重复出现的东西整理成公共组件
• 删除临时代码
• 补测试
• 记下一个重要决定为什么这么做

不一定需要写很多文档。

但下次继续的时候，我和 AI 都不应该重新猜一遍过去发生过什么。

6. 下一步，也不一定是继续加功能

这也是我最近慢慢改变的一个习惯。

很容易把产品进度理解成：

A 做完 → B → C → D。

但真实开发里，下一步最值得做的事情有时是：

• 删掉一个其实没价值的功能
• 把主流程缩短
• 统一已经长得不一样的页面
• 重新处理一个反复出问题的数据结构
• 找人真正用一次
• 降低 AI 成本
• 补可靠性

所以现在我越来越少用“今天又做了多少功能”判断进展。

我更关心：

这一轮以后，产品有没有比上一轮少一点模糊？

这可能是我从团队开发转到独立开发以后，最大的流程变化之一。

不是以后都不用提前想。

也不是“反正 AI 做得快，先做再说”。

而是把不同问题放到更适合它们被回答的时间：

越难改、越高风险的事情，越早确定。

越需要真实产品才能判断的事情，允许它晚一点成熟。

这样看，“边做边调整”就不一定意味着流程失控。

真正危险的是：什么都没有想清楚，却因为实现太快，一路往前做。

最近我就是在这个过程中又撞上了一个很具体的问题：

功能已经做了很多，产品却非常丑。

我原本以为只是 UI 最后没处理好。

后来发现，很多本来属于设计的问题，其实早就在开发过程中被默默决定了。

下一篇想继续写这个：

一个人用 AI 做产品，设计到底应该什么时候介入？