手把手教你用AI做需求分析：把“领导说要一个报表”变成可执行需求
原文用“采购总监要看采购执行情况报表”的 B 端场景，演示如何把一句模糊需求通过 AI 采访、文档整理和多角色挑战，压缩成可交付研发的需求文档。核心不是让 AI 替 PM 写需求，而是让 AI 逼 PM 把“谁用、看什么、解决什么决策、数据从哪来、多频繁”这些关键上下文问清楚。
基本信息
- 来源：人人都是产品经理
- 作者：光点神奇（公众号：产品研究所）
- 原文：https://www.woshipm.com/pd/6423553.html
- 重复采集：https://www.woshipm.com/ai/6423539.html（`raw/articles/2026-07-05-170458-tg-44e80f.md`，内容与本页已消化素材一致）
- 采集时间：2026-07-05
- 主题归类：AI产品经理工作流 / 产品需求分析 / B端产品经理
- 关键概念：AI需求分析三步法、产品需求分析、AI产品PRD、Skill
核心观点
-
AI 在需求分析里的角色不是“代写文档”，而是“结构化追问器”。直接输入“帮我写一个采购执行报表需求文档”，AI 会生成看似完整但脱离真实系统和领导意图的三千字空文档；正确用法是让 AI 先当面试官，围绕用户、场景、决策、数据源和频率逐步追问，把 PM 自己没想清楚的盲区暴露出来。
-
“一个一个问”是需求采访质量的关键约束。作者特别要求 AI“每次只问一个问题，等我回答完再问下一个”，避免一次抛出 15 个问题导致回答质量下降。逐问逐答让 PM 能真正思考“采购总监现在怎么看”“执行情况到底是执行率还是执行进度”“粒度是订单级、供应商级还是物料级”等关键定义。
-
模糊需求必须先还原决策场景，再落到报表字段。采购总监要的不是“一个报表”，而是每日早晨 5 分钟快速定位卡住的采购订单；这会直接改变报表设计：核心模块应是订单进度总览、异常订单清单、供应商交付排行，而不是堆满图表的全量数据大屏。
-
需求文档要写到研发可直接执行，而不是写“提升体验、赋能决策”的空话。作者给 AI 的整理约束包括：包含背景、用户场景、功能描述、数据字段清单、异常场景、不做的事；每部分不超过 200 字；不写空话；每条都能直接给研发看。这个约束把 AI 从“写漂亮文案”拉回“生成工程输入”。
-
评审前让 AI 扮演需求方、后端研发和测试，能提前暴露三类翻车点。采购总监视角指出异常订单还缺“采购员是谁”；后端研发视角指出 30 天准时交付率在样本量太小时统计意义不足；测试视角追问分批到货且部分超期时如何判定。这些问题若到评审会才出现，会变成 PM 的专业度风险。
-
三步法最终可沉淀为一个需求分析 Skill。采访、整理、挑战三步的骨架稳定，变化的只是产品背景和领导原话；因此可以把它写成可复用的 Skill：输入上下文与需求原话，AI 逐步采访，输出需求文档，再由需求方、研发、测试三角色挑战。
实操内容保留
操作步骤
- 采访：给 AI 上下文和需求原话，让 AI 当记者，每次只问一个问题，把模糊需求问到能写需求文档。
- 整理：基于采访回答输出需求文档，覆盖背景、用户场景、功能、数据字段、异常场景和不做的事，并限制每部分不超过 200 字。
- 挑战：让 AI 扮演需求方、后端研发、测试三类利益相关方，从价值、实现、验证三个角度挑刺。
- 沉淀：把这三步抽象成需求分析 Skill，下次换上下文和需求原话即可复用。
Prompt 模板
第一步：让 AI 采访你
我在做B端招采平台，客户是中型企业采购部门。
领导今天跟我说”给采购总监做一个报表，让他能看看采购执行情况”。
就这一句话，没有别的了。
你来当记者，采访我。
每次只问一个问题，等我回答完再问下一个。
你的目标是帮我把这个模糊需求问到能写需求文档的程度。
重点关注：谁用、看什么、解决什么决策、数据从哪来、多频繁。
不要一次列一堆问题，一个一个来。第二步：整理成需求文档
基于刚才的采访，帮我输出一份需求文档，包含以下部分：
1. 需求背景（一段话，说清楚为什么做这个报表）
2. 目标用户和使用场景（谁、什么情况下、看什么）
3. 功能描述（报表包含哪些模块，每个模块展示什么数据）
4. 数据字段清单（每个字段：名称、来源、计算方式）
5. 异常场景（数据缺失怎么办、权限不够怎么办）
6. 不做的事（明确边界，防止需求蔓延）
格式用Markdown。每个部分不要超过200字。
不要写”提升用户体验””赋能决策”这种空话。
每一条都要能直接给研发看，不需要二次翻译。第三步：多角色挑战
现在你扮演三个人，分别审阅这份需求文档：
1. 采购总监（需求方）：你只关心这个报表能不能帮你快速发现哪些采购单卡住了。如果不能，哪里不够？
2. 后端研发（实现方）：你关心数据能不能查出来、性能扛不扛得住、有没有遗漏的接口。找出三个技术风险。
3. 测试（验证方）：你关心怎么验证这个需求做对了。列出三个你必须测的边界case。
每个人说2-3点，直接说不满，不用客气。可复用需求分析 Skill 骨架
【需求分析 Skill】
步骤一：采访
– 上下文：[填你的产品名、客户、当前情况]
– 领导原话：[填需求原话]
– 你来当记者，每次问一个问题，帮我把这个需求问到能写文档的程度
– 重点问：谁用、看什么、解决什么决策、数据从哪来、多频繁
步骤二：整理
– 基于采访结果，输出需求文档
– 包含：背景/用户场景/功能描述/数据字段/异常场景/不做的事
– 每部分≤200字，不写空话，每条可直接给研发
步骤三：挑战
– 扮演需求方、研发、测试三人审文档
– 每人说2-3个问题，直接说不满示例需求文档片段
**需求背景：** 采购总监目前通过采购员手工导出Excel查看采购执行情况，效率低且数据滞后。需在系统内建设采购执行看板，支持实时查看订单进度。
**目标用户：** 采购总监。使用场景：每日早晨花5分钟浏览当日采购订单执行状态，快速定位卡住的订单。
**功能描述：**
模块一：订单进度总览。展示当日所有进行中采购订单的数量、总金额，按状态分布（待发货/部分到货/全部到货/超期未到）
模块二：异常订单清单。列出超期未到货的订单，含供应商名称、下单日期、应到日期、当前状态
模块三：供应商交付排行。按近30天准时交付率排序，Top5和Bottom5
**异常场景：**
1. 订单无合同约定交期：显示”未约定”，不计入超期统计
2. 供应商已停用：在交付排行中标红，但保留历史数据
**不做的事：**
1. 不做报表导出功能（二期再考虑）
2. 不做自定义筛选条件（二期再考虑）
3. 不做采购总监以外的角色权限（本期只服务采购总监一个人）关键概念
- AI需求分析三步法：用 AI 采访、整理、挑战三步，把模糊需求转成可执行需求文档。
- 产品需求分析：本文补充了“AI 逐步追问”这一操作层，让症状、偏方、病因的诊断不只依赖 PM 自己憋问题。
- AI产品PRD：本文强调需求文档要写到研发可执行，并通过多角色挑战提前补齐字段、统计口径和边界 case。
- Skill：本文把一次需求分析流程抽象成需求分析 Skill，说明 Skill 可以承载 PM 的追问和评审 SOP。
- B端产品经理：采购执行报表案例说明 B 端 PM 不能直接做“报表功能”，而要还原业务决策场景和数据口径。
与其他素材的关联
- 与 2026-07-01-woshipm-ai-prd-full-workflow 同源：两者都反对“上来就写 PRD”，强调先让 AI 帮 PM 把问题拆清楚，再生成文档。
- 与 2026-05-27-b端产品经理业务设计分水岭 互补：业务设计强调从症状/偏方找到病因，本文提供了一个借助 AI 逐步追问来逼出上下文的实操流程。
- 与 2026-05-13-ai-pm-requirement-scheduling 互补：那篇把需求拆成 Feature/Story/Gherkin，本文则更前置，解决“需求原话只有一句”时如何把上下文问出来。
- 与 2026-05-11-skill-sop-for-ai 互补：本文正是把 PM 需求分析经验编译成 Skill 的例子。
原文精彩摘录
AI不帮你写需求。AI帮你问对问题，然后把你的答案整理成结构化的东西。
这个问题把我问住了。我一开始想的是执行率，但仔细想，采购总监看报表的频率如果是每天，他更可能想看进度——哪个采购单卡在哪了，谁的供应商还没发货。执行率是月度复盘才看的。
这三个问题，如果上了评审会才被发现，你要当场拍板、当场改文档、当场被质疑专业度。现在提前发现了，你花十分钟想清楚，改完文档，带着答案去开会。
“领导说要一个报表”——这句话的本质是什么？是领导脑子里有一个问题，但他用一句话压缩了。你的工作不是把这句话展开成功能列表。你的工作是还原领导脑子里那个问题——他到底想看什么、看完想做什么决定、不做这个报表他现在怎么凑合的。