利益关系披露：DragonAI 运营 AI 产品经理课程。本文及配套 JSON 是第一方编辑框架；JSON 提供七段字段规范与两个关键空白记录，不是统一行业标准、用户研究证明或项目结果保证。真实需求、数据权利与高影响用途仍需相应责任人复核。
30 秒答案：把“用户说了什么”变成一条可追溯证据链
AI 产品经理做需求分析、需求调研或需求挖掘时，要区分四件事：用户表达、观察到的任务问题、团队对原因的假设，以及准备验证的解决方案。用户说“希望 AI 自动处理”只能作为输入线索，不能直接证明应使用 AI；一段模型生成的需求总结也不能替代访谈原话、行为记录或任务数据。
更稳妥的顺序是：保存原始证据，重建当前任务与失败，定义理想输出和不可接受结果，比较非 AI 与 AI 方案，核对数据和权限，建立失败切片与初始样例，最后决定进入 PRD、继续研究、缩小范围或停止。可下载 AI 产品需求证据链 JSON 逐项记录。
| 阶段 | 要回答的问题 | 可复核产物 |
|---|---|---|
| 证据 | 谁在什么场景表达或表现出问题？ | 访谈、观察、日志、来源和限制 |
| 任务 | 用户当前怎样完成，哪里失败？ | 任务步骤、基线、替代办法、失败成本 |
| 输出 | 什么结果才有用，什么结果不可接受？ | 理想输出属性、澄清、拒绝与接管规则 |
| 方案 | 为什么需要 AI，简单方案是否足够？ | 人工、规则、搜索、软件与 AI 比较 |
| 数据 | 需要哪些依据，能否合法且持续使用？ | 来源、用途、许可、质量、更新与删除 |
| 验证 | 哪些用户群体、输入类型和失败切片必须单独测试？ | 切片、样例、指标、阻断项和责任人 |
| 决定 | 证据支持继续、修改、暂停还是停止？ | 状态、理由、未决问题和复审日期 |
一、先登记原始证据，不要先归纳“用户需求”
需求可以来自访谈、现场观察、客服记录、搜索词、任务日志、销售线索或已有流程数据。每条证据至少记录来源类型、日期、目标人群、任务场景、原始表述或事件、收集方法、样本限制、是否获得相应使用许可，以及谁负责复核。
“五位用户都想要智能助手”仍然太早。需要回到记录检查：他们真正遇到的是查找资料慢、输入重复、决策标准不清，还是跨系统执行困难？同一句“自动处理”可能分别意味着减少复制、获得建议、生成草稿或替用户执行动作，产品风险完全不同。
用大模型整理材料时，模型输出应标记为派生分析。研究者要保留它引用了哪些原始记录、哪些主题由人工确认、哪些是推断、哪些反例没有被归入主主题。敏感或无权使用的材料不能因为“只用于总结”就自动获得处理权限。
二、还原当前任务，而不是直接写功能
把任务写成“某类用户在某个触发条件下，为了完成某个结果，经历哪些步骤”。逐步记录工具、输入、等待、交接、错误、返工和当前替代办法。基线不一定是某个软件，也可能是人工搜索、表格、同事咨询或放弃任务。
优先确认四类差距：
- 信息差距：缺少、过期、冲突或找不到依据；
- 判断差距：标准存在，但用户难以在多个条件间取舍；
- 表达差距：结论已知，但整理为合适格式耗时；
- 行动差距：需要在外部系统执行并处理权限、失败与回滚。
差距类型影响方案。信息问题可能先优化内容和搜索；稳定规则可由确定性逻辑完成；表达任务可能只需要受限生成；外部行动才需要进一步定义工具、身份和确认。关于行动型系统可继续查看 AI Agent 产品设计与上线清单。
三、把“理想回答”改成可观察输出要求
AI 产品经常用“回答准确、自然、有帮助”描述目标，但这些词无法直接生成一致的测试决定。理想输出应按任务写成可观察属性：
- 必须包含哪些事实、字段、步骤或依据；
- 哪些内容必须保持原文、引用来源或标记版本；
- 哪些格式、长度、语言和语气适用于当前用户；
- 信息不足、冲突或超出范围时怎样澄清、拒绝或转人工；
- 哪些敏感推断、确定性承诺或执行动作禁止出现；
- 用户如何发现错误、修改输入、撤销或申诉。
同一输入不一定只有一段唯一正确文本。可把“必须满足的属性”“允许变化的部分”“不可接受结果”分开，再由领域责任人确认。产品界面和说明还应向目标用户传达实际能力与限制，使预期与可交付行为相符。这样后续评测可以检查任务是否完成，而不是只比较字面相似度。
四、比较五类方案，再决定 AI 承担哪一步
Google 的机器学习问题定义指导将“是否适合使用机器学习”、清晰目标和成功标准放在起点。对同一任务至少比较：维持现状或改人工流程、规则与数据库查询、传统搜索或软件功能、带模型的固定工作流，以及需要自主选择步骤的 Agent。
每个方案用同一组字段：解决哪段差距、需要什么数据、可解释和可恢复程度、人工投入、延迟、成本、主要失败，以及什么证据会使团队停止采用。不能用最简单样例测试 AI，再用完整真实流程评价人工基线。
“用户喜欢 AI”不是选型证据，“竞品都有”也不是。若改进表单、内容结构、搜索或责任流程已经解决问题，需求决定可以是不增加生成式 AI。若只有某个子步骤需要概率能力，就把 AI 范围限制在该步骤，而不是把整条流程包装成智能体。
五、在需求阶段登记数据、上下文与权限
需求成立不等于数据可用。列出每项输入和依据的所有者、原始用途、许可或同意状态、敏感等级、覆盖人群、缺失与偏差、更新频率、保留期限、删除路径和输出可追溯字段。只有相应责任角色才能确认特定数据是否允许用于训练、检索、评测或生产输入。
还要分别测试资料不存在、冲突、过期、格式异常、语言变化和权限不足。Google PAIR 的数据与评测指导强调数据应反映预期使用者、用例与环境；方便取得的演示样例不能自动代表真实输入分布。
数据登记要连接到输出要求。例如需要展示政策依据，就必须记录文档、片段、版本和可打开位置；需要删除用户信息，就必须知道它进入了哪些日志、索引、缓存或评测集。没有这些路径时，需求状态仍是待验证。
六、把需求变成失败切片与初始评测样例
在 PRD 和原型之前先写少量高信息样例。每条样例包含用户与场景、输入、允许数据、预期输出属性、禁止行为、人工接管、严重度和复核人。优先覆盖：
- 高频正常任务；
- 信息缺失或表达含糊；
- 来源冲突、过期或无权访问；
- 少数但高影响的用户与场景；
- 对抗、提示注入或越权请求；
- 依赖失败、超时和人工接管。
样例不是为了证明方案已经成功，而是暴露需求是否可测试。若团队无法对同一案例达成预期行为，说明需求、责任或领域规则仍不清楚。可把样例继续扩展到 AI 产品评测集模板，再用 指标与发布门禁 固定指标、阈值和阻断项。
七、用证据状态决定是否进入 PRD
每条需求可以采用四种状态：signal 表示仅有线索；hypothesis 表示已有解释但待验证；validated_for_scope 表示在声明的人群、任务和证据范围内得到支持；rejected_or_deferred 表示证据反对、价值不足、条件不具备或暂缓。状态必须附日期、依据、责任人和复审触发器。
进入 AI 产品 PRD 前，至少检查：用户任务和当前基线是否明确；原始证据能否追溯；AI 与非 AI 方案是否同口径比较；理想输出和不可接受结果是否可测试；数据与权限是否有负责人；高风险失败是否进入样例；成功、停止和人工接管条件是否写清。
需求不是一次性冻结。新用户证据、严重失败、模型或数据变化、用途扩大和监管要求都可能触发重审。NIST AI RMF 将角色、测量、监测与风险处置视为生命周期事项，因此发布后的失败应回流需求证据链，而不是只进入缺陷列表。
“用 AI 做需求分析”与“分析 AI 产品需求”不要混为一谈
大模型可以帮助转写、整理、提取矛盾、生成访谈追问或把记录转换为结构化草稿；这些属于研究工具。AI 产品需求分析则要决定概率系统是否适用、输出怎样失败、依据来自哪里、哪些行为必须受限，以及用什么证据决定发布。
前者可以提高整理效率，但不能自动证明主题真实、样本充分、需求有价值或方案可行。后者即使完全不用大模型整理材料，也必须完成用户、任务、方案、数据、评测和责任判断。
使用边界
本文与 JSON 是需求证据记录框架，不替代专业用户研究、数据授权、隐私与安全评估、法律意见、领域专家判断或生产验证。模板中没有真实用户、样本规模或项目结果；填写字段、生成 PRD、完成原型或发布页面都不证明需求已被验证。没有充分证据时，应保留假设状态并明确下一项验证动作。