1. 需求模糊问题排查

需求模糊是AI产品需求建模中最频发、代价最高的缺陷类型。模糊需求会在开发阶段引发反复返工，在验收阶段导致预期偏差，最终造成项目延期或交付失败。本章围绕“现象识别 → 数据采集 → 原因定位 → 修复动作 → 复测 → 预防”六步闭环，提供可执行的排查框架和操作工具。

1.1 现象定义

需求模糊不会以单一形式出现，而是表现为一组可识别的症状。排查的第一步是准确识别这些症状，避免将模糊问题误判为技术分歧或资源不足。

1.2 数据采集方法

精准的根因定位依赖高质量、多维度的原始数据。以下三种采集方法需配合使用，避免单一信源带来的偏差。

1.3 根因定位

数据采集完成后，使用故障树快速定位模糊根源。以下故障树覆盖了AI产品需求模糊的三大主因及其子因素。

需求模糊问题（根节点）
│
├── 用户场景缺失
│   ├── 未识别目标用户（未区分终端用户/审核方/运维方）
│   ├── 未定义使用环境（设备、网络、光照、并发量等）
│   └── 未描述触发条件（什么事件引发该需求）
│
├── 目标不清晰
│   ├── 缺乏量化指标（“提升准确率”未指定基准与目标值）
│   ├── 成功标准模糊（“用户满意”未定义满意度阈值）
│   └── 优先级未对齐（多个目标之间缺少权衡规则）
│
└── 沟通断层
    ├── 术语理解不一致（“召回率”“精度”在不同角色认知不同）
    └── 需求传递失真（口头传递 → 文档记录 → 开发理解逐层衰减）

基于故障树，使用以下判断规则表对采集到的数据进行逐条匹配。

1.4 修复动作

根因确认后，针对不同原因选择对应的修复模板。以下提供两种核心修复工具：用户故事（修复场景缺失）和验收标准（修复目标不清晰）。

补充用户故事（修复场景缺失）

使用标准用户故事模板，将缺失的场景补全。每个故事必须包含角色、功能和价值三要素。

用户故事模板：
作为 【具体的用户角色】
我希望 【描述功能目标，而非实现方式】
以便 【说明业务价值，可量化】

示例（修复前）：
“系统需要能自动识别用户情绪。”

示例（修复后）：
作为 【在线客服质检员】
我希望 【在对话结束后自动标记用户的情绪倾向（积极/中性/消极）】
以便 【将情绪消极的对话优先提交人工复核，提升客诉响应速度】

明确验收标准（修复目标不清晰）

使用 Given/When/Then 结构为每个故事定义可测试的验收标准。

验收标准示例：
Given  对话文本中用户连续发送了3条以上负面关键词（如“投诉”“差评”“退款”）
When   自动情绪标记模块完成分析
Then   将对话标记为“消极”，并自动插入高优先级工单队列
And    标记置信度不得低于90%（置信度＜90%时转人工复核）

1.5 复测与预防

修复不是终点。必须经过系统化复测确认模糊已被消除，同时建立预防机制避免复发。

复测检查表

预防机制

将以下三项机制嵌入团队日常工作流，从源头减少模糊需求的产生：

• 需求模板强制化： 所有新增需求必须使用统一模板提交，模板内置用户角色、场景描述、量化指标和异常分支字段，缺少任一字段则退回补全。
• 评审检查单制度化： 每次需求评审前，评审人使用固定检查单逐条过筛，检查单内容与复测检查表保持一致，评审记录归档备查。
• 复盘案例库建设： 每个已修复的模糊案例，整理为“症状-根因-修复-复测”四段式案例，纳入团队知识库，作为新成员培训材料和后续需求评审的参考依据。