AI需求分析三步法
用 AI 采访、整理、挑战三步，把一句模糊需求转成可执行需求文档的方法论。它的核心不是让 AI 替 PM 写需求，而是让 AI 持续追问上下文、结构化整理答案，并在评审前模拟需求方、研发、测试三类角色挑刺。
简介
AI需求分析三步法来自 2026-07-05-woshipm-ai-requirement-analysis-report 的采购执行报表案例。文章从一个典型 B 端场景切入：领导只说“给采购总监做一个报表，让他能看看采购执行情况”，没有说明采购总监现在怎么看、真正关心执行率还是执行进度、报表粒度是订单级还是供应商级、数据从哪里来、每天看还是每月看。传统做法很容易直接画七八个图表，三天后被一句“这不是我想要的”打回。
这套方法的核心洞察是：AI 不负责替 PM 下判断，AI 负责逼 PM 把判断所需的上下文问出来。直接让 AI 写“采购执行报表需求文档”，它会生成背景、目标、功能列表和指标字段，但这些内容未必与真实系统、真实数据和真实决策场景匹配。真正有效的流程是先让 AI 充当“记者/面试官”，每次只问一个问题，围绕“谁用、看什么、解决什么决策、数据从哪来、多频繁”逐步追问；然后再把 PM 的回答整理成结构化需求文档；最后让 AI 扮演需求方、研发、测试进行挑战，提前发现缺字段、统计口径不严、边界 case 未定义等问题。
因此，AI需求分析三步法不是“提示词技巧”，而是一个可复用的需求澄清 SOP。它把 产品需求分析 中“不要直接做字面需求，要穿透症状找到病因”的原则，落到了 AI 协作场景：PM 不再一个人憋问题，而是让 AI 作为不知疲倦的追问者和评审预演器，帮助自己把模糊需求变成可讨论、可开发、可测试的需求输入。
关键信息
| 维度 | 内容 |
|---|---|
| 类型 | PM 方法论 / AI 协作流程 |
| 适用场景 | 领导一句话需求、B 端报表/看板/功能需求、客户口头需求、需求评审前自检 |
| 三个步骤 | 采访 → 整理 → 挑战 |
| 关键约束 | 采访时每次只问一个问题；整理时不写空话；挑战时必须从需求方、研发、测试多角色挑刺 |
| 核心输出 | 可直接交给研发看的需求文档 + 待补充问题清单 + 边界 case |
| 相关方法 | 产品需求分析、业务设计、AI产品PRD、Skill |
核心特性
一、先采访：让 AI 当“结构化追问器”
第一步不是让 AI 生成需求文档，而是让 AI 采访 PM。采访的前提是给 AI 足够上下文：产品类型、客户类型、现状、领导原话和自己卡住的地方。然后明确要求 AI“每次只问一个问题，等我回答完再问下一个”。
这个约束很关键。很多人让 AI 提问时会得到十几个问题的清单，看似全面，实际会造成两个问题：一是 PM 只能粗略回答，无法真正思考每个问题；二是问题之间缺少递进，AI 无法根据上一轮回答继续追问。逐问逐答把需求澄清变成了类似访谈的过程：AI 先问“采购总监现在怎么看采购执行情况”，PM 回答“采购员每周手工导 Excel”；AI 再问“执行情况更像执行率还是执行进度”，PM 才意识到如果总监每天看，更可能关心卡单进度而不是月度执行率。
这个过程的价值在于暴露盲区。AI 不知道企业系统里有什么数据，也不知道领导真正想要什么，但它可以用稳定的提问框架逼 PM 回到用户、场景、决策和数据源。它问的“订单级、供应商级还是物料级”“部分到货怎么算”“无合同交期怎么办”，往往正是研发评审时会追问、测试用例里会卡住的问题。
二、再整理：把回答压缩成可交付文档
采访完成后，AI 才进入第二步：把零散回答整理成需求文档。这里的关键不是文档越长越好，而是要有强约束：包含需求背景、目标用户和使用场景、功能描述、数据字段清单、异常场景、不做的事；每部分不超过 200 字；不要写“提升用户体验”“赋能决策”之类空话；每一条都要能直接给研发看。
这种约束把 AI 的写作能力限制在正确轨道上。没有约束时，AI 很容易写出三千字“看起来像 PRD”的文档，却没有可实现字段、数据来源、统计口径和边界定义。有约束后，文档会落到具体模块：订单进度总览展示进行中订单数量、总金额和状态分布；异常订单清单列出超期未到订单、供应商名称、下单日期、应到日期和当前状态；供应商交付排行按近 30 天准时交付率排序。
这一步对应 AI产品PRD 的一个重要原则：AI 可以帮助生成结构，但高价值判断必须由 PM 提供。AI 不能凭空知道“近 30 天”是否合理、“采购员字段”是否必须展示、“不做导出功能”是否可接受；它只能根据采访内容组织成可讨论的文档。PM 需要扫一遍、改措辞、补细节，再把它变成真正的需求交付物。
三、最后挑战：用多角色预演需求评审
第三步是让 AI 扮演需求方、后端研发和测试，审阅需求文档并直接说不满。这个步骤的价值在于把需求评审会上的冲突前置到安全环境里。采购总监视角只关心报表能否快速发现卡住的采购单，因此会指出“异常订单里只看到超期没用，还要知道该找哪个采购员催”；后端研发视角关心数据能否查出、性能能否支撑、统计有没有意义，因此会指出“近 30 天只有 1 笔订单的供应商准时率没有统计意义，应设置最低订单数门槛”；测试视角关心怎么验证，因此会追问“一个订单分三次到货，第三次超期，整个订单算不算超期”。
这些挑战本质上是三类验收：业务价值验收、技术实现验收、质量验证验收。它们分别对应 PM 最容易遗漏的三种问题：字段不够支撑决策、统计口径不够严谨、异常路径没有定义。评审前发现这些问题，PM 只需花十分钟补文档；评审会上才发现，就会变成现场拍板和专业度质疑。
这一步也说明 AI 在需求分析中可以承担“反方角色”。它不是只负责顺着 PM 的意图生成内容，而是通过角色扮演帮助 PM 从不同利益相关方的视角检查需求。对 B 端产品而言，这种预演尤其有价值，因为真实需求评审往往涉及业务方、研发、测试、数据、权限、运维等多方口径，任何一方没被提前考虑，都可能导致返工。
四、沉淀为 Skill：把一次经验变成可复用 SOP
三步法的结构非常稳定：采访、整理、挑战。每次变化的只是上下文和需求原话。因此它天然适合沉淀成 Skill。这个 Skill 的输入可以是“产品名、客户、当前情况、领导原话”；输出不是直接 PRD，而是先逐轮追问，再生成文档，再给出多角色挑战清单。
这与 Skill 的本质完全一致：Skill 是写给 AI 的 SOP，把人的隐性经验编译为可复用的程序性知识包。优秀 PM 脑中本来就有一套需求澄清 checklist：谁用、现在怎么做、要做什么决策、用什么数据、多久看一次、异常怎么处理、不做什么。这套 checklist 如果只靠人记忆，容易在忙乱中漏掉；写成 Skill 后，AI 可以每次稳定执行，降低遗漏概率。
但把它沉淀成 Skill 并不意味着 PM 可以交出判断权。Skill 负责提醒和追问，PM 负责回答是否符合真实业务、判断哪些问题重要、决定边界和取舍。换句话说，这个 Skill 的价值不是“替你做需求分析”，而是把 PM 的需求分析过程从“靠状态发挥”升级为“靠流程稳定”。
不同素材中的观点
- 2026-07-05-woshipm-ai-requirement-analysis-report：首次提出并完整演示“采访 → 整理 → 挑战”的 AI 需求分析三步法。素材用采购执行报表案例证明，模糊需求不能直接展开成功能列表，必须先还原领导脑中的问题：采购总监到底想看什么、看完要做什么决定、现在靠什么方式凑合。AI 的作用是当面试官和评审预演器，而不是替 PM 承担业务判断。
实用信息
最小使用模板
我在做[产品/业务背景]，客户/用户是[用户类型]。
领导/客户原话是：“[需求原话]”。
请你当记者采访我，每次只问一个问题，等我回答后再问下一个。
目标是把这个模糊需求问到能写需求文档的程度。
重点关注：谁用、看什么、解决什么决策、数据从哪来、多频繁、异常怎么处理、不做什么。
采访完成后，帮我整理成需求文档：背景、用户场景、功能描述、数据字段、异常场景、不做的事。
每部分不超过 200 字，不写空话，每条都要能直接给研发看。
最后扮演需求方、研发、测试三类角色审阅，每人说 2-3 个问题，直接挑刺。适用场景
- 领导只给一句话：“做个报表”“加个看板”“优化一下流程”。
- 客户提的是功能名，但没有说清背后的业务目标。
- PM 已经有初稿，但担心评审会上被研发或测试追问。
- 需要把一次需求澄清过程沉淀成团队 SOP 或 Skill。
注意事项
- 不要跳过采访直接生成文档：直接生成会得到漂亮但不一定可执行的需求文档。
- 采访必须一次一个问题：一次列十几个问题会降低回答质量，也会丢掉追问递进。
- 整理文档必须禁止空话：“提升效率、赋能决策”不是需求，字段、口径、异常和边界才是需求。
- 挑战阶段要让 AI 不客气：如果角色扮演只说“整体很好”，说明提示词不够强，应要求它直接指出不满和风险。
- AI 问出的答案仍要由 PM 校验：AI 可以追问“部分到货怎么算”，但最终口径必须由 PM 和业务方确认。
与其他方法论的关系
- 与 产品需求分析 的关系：AI需求分析三步法是产品需求分析在 AI 协作场景下的操作层补充，把“区分症状、偏方、病因”变成逐轮追问流程。
- 与 业务设计 的关系：业务设计要求先理解业务模型再做功能；AI需求分析三步法提供了从模糊原话进入业务模型的入口。
- 与 AI产品PRD 的关系：三步法中的“整理”和“挑战”能提高 PRD 的可执行性，尤其是字段口径、异常场景和不做事项。
- 与 Skill 的关系：三步法本身就是一个可编译为 Skill 的 PM 工作流，体现“把隐性 checklist 写给 AI 执行”的价值。
- 与 B端产品经理 的关系：B 端需求常常从一句含糊功能名开始，三步法能帮助 B 端 PM 从“功能传声筒”回到“业务问题还原者”。