识别需求何时滑向具体方案

一句话提醒

还没确认问题和目标就跳到功能解法，会把实现方式误当需求，遮蔽更优路径。

为什么今天看它

• 产品讨论容易把第一种可行做法直接当成答案；先拆开问题层、目标层和方案层，才能保留替代路径和判断空间。

留一个问题

你现在讨论的“需求”是在描述谁的什么问题，还是已经偷偷指定了某个功能解法？

参考思路

1. 1.先说清楚谁在什么场景下遇到什么问题，不要一开始就命名功能。
2. 2.确认问题背后的目标和约束，避免把表面诉求当成完整需求。
3. 3.至少列出两条可能的解决路径，防止把第一种做法当成唯一答案。
4. 4.检查当前表达是否把实现方式误写成需求本身。
5. 5.比较流程、业务规则、协作方式和产品功能等不同层级的解法，再决定是否进入具体设计。

03_知识库/问题/什么叫需求滑向方案.md