产品立项的起点，不是先列功能

最近我又被提醒了一次：很多项目一开始就急着列功能、画页面、拆接口，但真正决定项目质量的，往往是更前面的那个问题：为什么做。

AI 工具把原型和代码生成的速度拉得很高，做出一个“看起来像产品”的东西越来越容易。但也正因为这样，我更觉得立项阶段不能被跳过。功能做得快，不等于方向想得清楚。方向一旦没想清楚，后面做的每一项功能，都可能只是更快地偏离。

先想清楚“为什么做”，功能才有判断依据

这次最触动我的一句话是：如果不先想清楚“为什么做”，功能就没有判断依据。

这句话看起来很简单，但我觉得它几乎可以当成很多产品讨论的起点。比如一个博客网站，表面上很容易把需求越写越完整：登录、发文、草稿、评论、分类、管理后台，似乎每个都合理。但只要回到“为什么做”这个问题，很多功能的必要性就会立刻变化。

如果这个博客只是给自己记事、整理想法用的，那分享和评论未必重要；如果它是为了公开表达、让别人阅读甚至互动，那内容发布、展示和评论才开始变得有意义。也就是说，功能不是天然成立的，它是被目标推导出来的。

我越来越觉得，立项文档最重要的价值，不是把事情写得显得完整，而是逼自己把这个“为什么”说清楚。

AI 时代工具越快，越需要慢一点判断

现在做产品，一个很现实的变化是：很多东西几小时内就能搭出来。页面能生成，接口能补齐，部署方案也总能找到一个临时可跑的版本。

这会带来一个错觉，好像“先做出来再说”比“先想清楚再做”更有效率。但我自己的判断恰恰相反。因为当工具足够快时，真正稀缺的不是执行速度，而是判断质量。

以前做错一个方向，成本还比较高；现在做错方向，反而会错得更快、更像样。你会更容易被一个已经跑起来的原型说服，以为自己已经接近答案了，实际上可能只是把一个未经判断的想法包装得更完整。

所以我现在会更警惕一种习惯：不是不会做，而是太快进入“开始做”。在 AI 时代，慢下来的那几步不是拖延，而是筛选。先把目标、使用者、场景和取舍讲清楚，后面的速度才真的有价值。

技术方案不该提前替代实现设计

另一个让我印象很深的点，是文档边界。

我经常看到一种问题：技术方案阶段写得过细，把接口结构、目录组织、登录实现怎么拆都提前写进去了。这样看起来很认真，但其实容易把不同阶段的事情混在一起。

在我理解里，技术方案更应该回答的是这些问题：准备用什么技术栈，整体架构怎么搭，部署方式是什么，可行性和约束在哪里。它的任务是说明这件事怎么成立，而不是提前把实现细节写死。

像接口代码结构、模块目录设计、具体字段怎么组织，这些更接近 READY 文档要承接的内容。READY 的价值，在于把“准备如何实现”讲清楚；技术方案的价值，在于把“为什么这样选、这样做能不能走通”讲清楚。

如果在技术方案阶段就把实现写得太满，表面上像是更严谨，实际上会让文档失焦，也会让后面的设计空间被过早锁死。

对我自己的提醒

这件事最后落到我自己身上，其实是一个很具体的提醒。

以后我再看一个项目，不管它是博客、工具还是内部系统，我都应该先问：它到底是为了解决什么问题，服务谁，在什么场景下成立。只有这几个问题有了答案，功能取舍、技术方案和后续实现文档才有顺序可言。

我不想再把“能做什么”当成起点，而是把“为什么值得做”放在前面。尤其是在 AI 已经把执行门槛降下来的今天，这种判断能力不是变得不重要了，反而变成更核心的分水岭。