2. 需求调研与场景定义：用户需求收集、业务场景分解、模型能力边界确认

需求调研与场景定义是AI产品验收标准制定的基石。本环节的核心目标是将模糊的业务意图转化为可量化、可验证的模型需求，并明确“AI能做什么”与“AI不该做什么”的边界。缺乏这一环节，后续的验收标准将沦为无根之水。

适用场景

• 新AI产品立项，需从零定义验收基线。
• 对已有AI模型进行重大迭代升级，需重新校准能力边界。
• 跨部门协作的AI项目，需统一业务方与技术方的认知语言。
• 涉及安全合规（如金融、医疗）的高敏感度AI应用。

前置条件

• 已完成初步的市场/竞品分析（对应第1章内容）。
• 已确定核心干系人列表（业务方、技术方、QA方、法务/合规方）。
• 已准备需求调研模板（访谈大纲、问卷模板、场景卡片）。
• 已获取必要的原始数据样本或数据描述文档。

操作步骤

1. 步骤一：用户需求收集
   • 通过结构化访谈、工作坊、问卷等形式，收集业务方对AI系统的核心期望。
   • 区分“真实痛点”与“伪需求”。例如：“希望能100%准确”是伪需求；“在噪声环境下，关键短语的转写准确率不低于85%”是真实需求。
2. 步骤二：业务场景分解
   • 将抽象的业务需求（如“提升客服效率”）拆解为具体的AI交互场景。
   • 使用“场景卡片”法：定义场景名称、触发条件、输入数据、执行动作、期望输出、异常状态。
   • 区分“主流程场景”（占80%业务量）与“边缘场景”（占20%业务量但包含高风险）。
3. 步骤三：模型能力边界确认
   • 基于分解后的场景，与算法工程师共同评估当前模型的技术上限。
   • 明确“能力范围”（支持的语言、支持的输入格式、推理延迟下限）与“能力禁区”（不支持的功能、禁止使用的输入类型）。
   • 输出《模型能力边界说明书》，作为后续验收标准制定的硬约束。

输入与输出物

责任边界

• 产品经理： 主导需求调研与场景分解，确保需求可追溯。
• 算法工程师： 提供模型能力的技术评估，验证能力边界的可行性。
• 业务方： 确认场景卡片与需求优先级的真实性与必要性。
• 测试工程师（QA）： 提前介入，从可测试性角度对场景分解提出质疑。

记录材料

• 会议纪要： 每次干系人访谈或对齐会的完整录音/文字记录。
• 需求变更日志： 记录任何需求的增删改及原因。
• 场景卡片库： 按统一格式归档所有分解后的场景卡片。

场景ID： SC-001
场景名称： 智能客服转接人工
触发条件： 用户连续三次询问“转人工”
输入数据： 用户当前对话文本（历史12轮对话）
期望输出： 1. 返回“人工客服排队中”提示；2. 生成工单摘要
异常状态： 1. 模型无法识别“转人工”意图；2. 返回空摘要
优先级： P0

异常处理

• 需求冲突： 业务方期望与模型能力严重不符时，启动“需求-能力适配评审会”，由产品经理给出降级方案或需求否决意见。
• 场景断层： 发现关键业务场景无法被任何AI能力覆盖时，标记为“人工兜底场景”，不纳入AI验收范围。
• 边界模糊： 当模型能力边界存在争议时，以最小可行能力（MVP）为准，并将扩展能力放入Roadmap的“待验证”池。

验收标准

• 完整性： 需求汇总表覆盖了所有核心干系人提出的关键诉求。
• 可分解性： 每个业务需求已被拆解为具体的场景卡片，且卡片信息完整无误。
• 边界明确性： 模型能力边界说明书已获得产品、算法、业务三方签字确认。
• 一致性： 场景分解矩阵与模型能力边界说明书之间不存在逻辑矛盾。

下图展示了从“原始需求”到“可验收模型能力”的分解与确认流程。核心在于将模糊的业务语言，经过场景化解构与工程技术评估，最终收敛为清晰的、可度量的“能力模块”。

完成本章节内容后，你将拥有一份包含明确场景与边界的《需求规格说明书》。这份文档将成为第3章《核心指标定义与量化标准》的输入材料。请务必确保在本章节点上，所有干系人对“什么能做、什么不能做”已达成共识。