夜雨聆风前言
以前做产品经理，最怕听到一句话：
“这个需求很简单。”
因为凡是被说成“很简单”的需求，最后大概率都不简单。
业务方觉得简单，是因为他只看到了自己想要的结果。
老板觉得简单，是因为他只关心这个功能什么时候能上线。
研发觉得不简单，是因为一进入实现层面，权限、数据、状态、异常、边界、兼容、历史逻辑全冒出来了。
产品经理夹在中间，最容易出问题的地方，不是不会画原型，也不是不会写 PRD，而是需求一开始就没拆透。
过去我做需求，通常是这样：
听业务说一遍需求、自己理解一下、画个流程图
写个 PRD。
拉研发评审。
然后在评审会上被一堆问题打回来。
比如：
“这个状态从哪里来？”
“用户重复提交怎么办？”
“这个按钮谁能看到？”
“失败了有没有兜底？”
“历史数据怎么处理？”
“这个流程和原来的规则冲不冲突？”
这些问题很正常，但如果每次都在评审会上才暴露，说明前面的需求分析不够扎实。
后来我开始调整自己的工作方式。
现在收到一个需求后，我不会马上写 PRD，也不会马上画原型。
我会先让 AI 跑完一套固定的需求分析流程。
不是让 AI 替我做产品经理，而是让 AI 先帮我把需求里最容易遗漏的部分扫一遍。
这套流程跑完之后，再去写 PRD、画原型、做 Demo，效率会高很多。
---
先说结论：我现在的需求分析流程是这 6 步
这 6 步看起来不复杂，但对产品经理非常有用。
因为它解决的不是“怎么写文档”的问题，而是解决“需求到底有没有想清楚”的问题。
---
第 1 步：先别讨论功能，先还原真实问题
很多需求一上来就是方案。
比如：
“我们要做一个 AI 助手。”
“我们要做一个智能推荐。”
“我们要做一个数据看板。”
“我们要加一个提醒功能。”
听起来都像需求。
但严格来说，这些都不是问题，而是解决方案。
真正的问题可能是：
用户不知道下一步该做什么。
销售不知道怎么跟进客户。
运营不知道哪里出了异常。
老板不知道哪个门店转化率下降。
业务说“我要一个看板”，不一定是真的需要看板。
他可能只是想知道：
到底哪里出了问题，以及下一步该怎么改。
所以我现在收到需求后，第一件事就是问 AI：
请帮我分析这个需求背后真正想解决的问题是什么。注意：1.不要直接接受当前方案。2.判断这个需求描述里哪些是问题，哪些是方案。3.尝试还原业务方真正的目标。4.给出可能存在的其他解决路径。
这一步特别重要。
因为产品经理最怕的不是需求复杂，而是一开始就沿着错误方向往下做。
如果真实问题没找到，后面 PRD 写得再完整，原型画得再漂亮，也只是把一个错误方案包装得更正式。
---
第 2 步：让 AI 帮我识别用户角色
很多需求之所以越做越乱，是因为一开始没有分清楚谁在用。
比如一个“销售跟进提醒”功能。
表面上看，用户是销售。
但实际涉及的角色可能有：
销售本人、销售主管、门店经理、总部运营、系统管理员、甚至还有客户
不同角色关心的问题完全不一样。
销售关心：
我今天该跟进谁？
主管关心：
谁没有按时跟进？
门店经理关心：
这个门店整体转化为什么低？
运营关心：
哪类客户最容易流失？
如果角色没拆清楚，后面就会出现一个典型问题：
一个功能想同时满足所有人，最后谁都用得不顺。
所以第二步，我会让 AI 输出角色表。Prompt 很简单：
请基于这个需求，识别所有可能涉及的用户角色。请按照以下结构输出：1.角色名称2.角色目标3.使用频率4.关注的信息5.可能的操作权限6.和其他角色的关系
这一步跑完后，你会明显感觉需求开始变清楚。
因为产品不是给“用户”用的。
产品是给一个个具体角色，在具体场景下完成具体任务用的。
---
第 3 步：把“需求”拆成具体场景
产品经理一定要警惕一句话：
“用户需要这个功能。”
用户到底在什么时候需要？
为什么需要？
他当时处于什么状态？
前后发生了什么？
如果这些没说清楚，需求就会很虚。
比如：
“销售需要 AI 话术推荐。”
这个描述太粗了。
继续拆场景后，可能变成：
销售刚接触客户，不知道怎么开场。
客户提出价格太贵，销售不知道怎么回应。
客户说要回去考虑，销售不知道怎么推进。
客户担心理赔真实性，销售不知道怎么建立信任。
你看，同样是“AI 话术推荐”，不同场景下产品设计完全不一样。
开场推荐，强调破冰。
异议处理，强调针对性。
成交推进，强调时机。
复盘训练，强调能力提升。
所以第三步，我会让 AI 专门拆场景：
请把这个需求拆成具体使用场景。每个场景请包含：1.场景名称2.触发时机3.用户当前状态4.用户想完成什么5.系统应该提供什么帮助6.这个场景的优先级
很多时候，AI 输出完场景后，我会发现原来的需求描述太笼统了。
这时候先别急着写 PRD。
先把场景拆细。
场景越清楚，后面的页面、流程、状态、规则才越稳。
---
第 4 步：让 AI 帮我梳理完整业务流程
场景拆完后，下一步才是流程。
注意，不是页面流程，而是业务流程。
很多产品经理一上来就画页面：
首页放什么、按钮放哪里、弹窗怎么出
但真正应该先想的是：
这件事在业务上是怎么发生的？
谁先触发？
谁处理？
系统判断什么？
数据从哪里来？
结果反馈给谁？
状态如何变化？
比如一个“客户跟进提醒”需求，业务流程可能是：
客户进入待跟进池、系统判断客户状态、生成跟进提醒、销售收到提醒、销售进行跟进、系统记录跟进结果、主管查看跟进情况、运营分析整体转化
这里面每一步都可能有产品问题。
所以我会让 AI 按“用户、系统、后台、管理者”几个视角拆流程。
请基于当前需求，输出完整业务流程。要求：1.按步骤拆解。2.标注每一步由谁触发。3.标注系统需要判断什么。4.标注每一步输入和输出。5.标注涉及的数据状态变化。6.如果涉及多个角色，请用泳道图思路表达。
这一步的价值非常大。
因为 AI 可以快速给你一版完整流程。
虽然第一版不一定准确，但它能帮你快速搭出骨架。
产品经理要做的是判断、修改、补充，而不是从空白页开始想。
---
第 5 步：异常流程和边界场景，才是真正拉开差距的地方
正常流程，很多人都能写。
真正体现产品能力的，是异常流程。
比如：
用户没权限怎么办？
数据为空怎么办？
接口失败怎么办？
重复提交怎么办？
中途退出怎么办？
状态已经变化了怎么办？
历史数据不兼容怎么办？
人工处理和系统处理冲突怎么办？
这些东西如果不提前想，后面一定会变成研发问题、测试问题、线上问题。
我现在会固定让 AI 做一次“异常场景扫描”。
请从以下几个角度，帮我检查这个需求可能遗漏的异常流程和边界场景：1.用户操作异常2.系统状态异常3.数据异常4.权限异常5.网络或接口异常6.并发或重复操作7.历史数据兼容8.运营后台处理异常请用表格输出： 异常场景 / 触发条件 / 影响 / 产品处理建议
这一步非常适合收藏成检查清单。
尤其是做复杂业务系统、后台系统、AI 产品、交易流程、审批流程时，特别有用。
很多评审会上研发会问的问题，其实都可以在这一步提前暴露。
---
第 6 步：让 AI 先替研发、测试、老板质疑一遍
需求分析最后一步，我会让 AI 扮演不同角色来质疑需求。
这一步有点像提前开一场模拟评审。
我通常会让 AI 扮演三个角色：
资深研发、测试负责人、业务负责人、他们关注点不一样
研发会问：
数据结构怎么设计？
接口怎么返回？
状态怎么流转？
和老系统怎么兼容？
测试会问：
异常怎么测？
边界怎么测？
失败场景怎么测？
有没有回归影响？
业务会问：
这个功能解决什么问题？
上线后怎么看效果？
会不会增加一线负担？
有没有运营抓手？
请你分别扮演资深研发、测试负责人、业务负责人，对这个需求进行评审。请每个角色至少提出 10 个尖锐问题。要求：1.问题要具体。2.不要泛泛而谈。3.尽量指出需求中可能缺失的信息。4.最后总结这个需求当前最大的 5 个风险。
这一步很狠。
有时候 AI 提出来的问题，会让你发现：
这个需求其实还没到能评审的程度。
但这不是坏事。
在自己电脑前发现问题，比在会议室里被研发当场问住要好得多。
---
跑完这 6 步后，我会得到什么？
通常会得到 5 样东西：
第一，真实问题。
这个需求到底解决什么，不再只停留在业务原话。
第二，角色清单。
谁使用，谁管理，谁决策，谁受影响。
第三，场景拆解。
用户在什么情况下需要这个能力。
第四，业务流程。
从触发到结束，中间每一步怎么走。
第五，风险问题。
哪些地方还没想清楚，哪些地方容易被研发和测试挑战。
有了这些东西，后面再写 PRD 就不再是硬憋。
而是把分析结果整理成文档。
再画原型，也不会只是在堆页面。
而是知道每个页面、每个按钮、每个状态为什么存在。
---
给你一份可以直接复制的完整 Prompt
下面这段可以直接拿去用。
`text 你现在是一位拥有 10 年经验的资深产品负责人，擅长复杂业务需求分析。
我会给你一个需求，请你不要急着写 PRD，也不要直接给方案。
请先帮我完成需求分析，按照以下结构输出：
一、真实问题分析
业务方表面提出的需求是什么？
这个需求背后真正想解决的问题是什么？
当前方案是否只是其中一种解法？
还有没有其他可能的解决路径？
二、用户角色分析
涉及哪些用户角色？
每个角色的目标是什么？
每个角色关注什么信息？
每个角色有哪些操作权限？
三、使用场景拆解
用户会在什么情况下使用？
高频场景有哪些？
低频但重要的场景有哪些？
哪些场景应该优先支持？
四、业务流程梳理
请按步骤输出完整业务流程。
每一步由谁触发？
系统需要判断什么？
每一步的输入和输出是什么？
涉及哪些状态变化？
五、异常和边界场景 请从用户操作、系统状态、数据、权限、网络、并发、历史数据、后台处理等角度，列出可能遗漏的异常场景。
六、模拟需求评审 请分别扮演资深研发、测试负责人、业务负责人，对这个需求提出尖锐问题。
七、最终输出
这个需求当前是否清晰？
最大风险是什么？
还需要补充哪些信息？
是否建议进入 PRD 阶段？
需求内容如下： 【粘贴你的需求】 `
这段 Prompt 的核心不是让 AI 给你一个漂亮答案。
而是让它帮你把需求拆开。
产品经理真正要看的，不是 AI 写得好不好，而是它有没有帮你发现遗漏。
---
再给一份需求分析 Checklist
如果你不想每次都写 Prompt，也可以直接用下面这份 Checklist。
收到需求后，先问自己 10 个问题：
---
最后说一句
AI 时代，产品经理不是不需要需求分析了。
恰恰相反，需求分析变得更重要。
因为 AI 可以帮你写文档，可以帮你画原型，可以帮你做 Demo。
但它不能替你判断：
这个需求值不值得做。
这个问题是不是真的存在。
这个方案是不是最优解。
这个流程会不会给业务带来新的负担。
所以，AI 产品经理真正要练的，不是把 Prompt 写得多花哨。
而是把 AI 放进自己的工作流里，让它帮你更快发现问题、更快拆清逻辑、更快完成判断。
以前我们靠经验一点点拆需求。
现在，我们可以让 AI 先跑一遍。
产品经理再做判断。
这才是 AI 工作流真正有价值的地方。
下一篇，我准备继续写：
《AI 产品经理工作流 02：我已经很少从零开始写 PRD 了》
因为当需求分析跑完之后，PRD 真的不应该再从空白文档开始写了。
