第3章 需求来源梳理清单

3.1 适用场景

本章流程适用于以下典型场景：

• AI产品项目结项后的完整复盘会议准备
• 需求变更频繁的项目中期需求回溯审查
• 多源需求（用户/业务/数据/合规）交叉验证
• 新建需求知识库或需求基线文档的前置整理

3.2 前置条件

1. 项目原始需求资料已归档（访谈录音/文字稿、用户反馈平台截图、竞品报告PDF、数据报表、法规原文）。
2. 复盘角色已确认：至少包含产品经理、业务分析师、数据工程师（若涉及数据报告）。
3. 已建立统一的“需求来源标签体系”（例如：来源类型+时间+提交人）。
4. 复盘工具（如Confluence、Notion、Excel）可访问。

3.3 操作步骤

步骤	操作内容	关键检查点
① 访谈记录清洗	将原始访谈录音转化为结构化文本，提取“需求陈述句”，标注发言人角色与场景。	每条需求对应完整上下文，避免断章取义；废弃与AI模型无关的闲聊内容。
② 用户反馈聚类	从App Store评论、客服工单、社区回帖中提取“功能请求”与“痛点描述”，按频次排序。	区分“单用户偶发声”与“高频共性诉求”；去除Spam与重复提交。
③ 竞品对标分析	整理竞品核心功能清单、差异化价值点、用户评价，标记“可借鉴”与“需规避”项。	注明竞品版本与调研时间；避免将过时竞品数据引入当前需求。
④ 数据报告解读	从用户行为统计、A/B测试结论、模型评估报告中提取量化需求（如准确率提升、响应时间缩短）。	确认数据样本量、统计显著性、报告生成日期。
⑤ 法规映射校验	对照GDPR、个人信息保护法、行业监管条例，识别合规性需求（数据脱敏、可解释性、审计日志）。	每条法规引文要精确到条款编号；区分“强制要求”与“推荐建议”。
⑥ 清单合并去重	将5个子清单按“需求描述相似度”合并，保留最高优先级来源的引用，形成总清单。	引用保留原始来源ID；冲突项标记为“待仲裁”。

3.4 输入与输出

类别	内容	格式
输入	原始访谈记录、用户反馈汇总表、竞品分析报告、数据报告、法规文档	.docx/.txt / .xlsx / .pdf
输出	需求来源清单（含来源ID、需求描述、原始来源、置信度、状态）	.xlsx 或 .csv

3.5 责任边界

• 产品经理：负责访谈记录清洗、竞品对标分析、清单合并仲裁。
• 业务分析师：负责用户反馈聚类、法规映射校验。
• 数据工程师/分析师：负责数据报告解读、指标提取。
• QA/测试：负责验证输出清单的完整性与可追溯性（验收角色）。

3.6 记录材料（模板示例）

使用以下需求来源清单模板完成记录，字段说明见注释。

需求来源清单（模板）
| 来源ID          | 需求描述                           | 原始来源类型 | 原始文档/链接        | 提出者   | 置信度 | 仲裁状态 |
|-----------------|------------------------------------|--------------|----------------------|----------|--------|----------|
| INT-20240710-ZS | 支持批量上传图片进行AI标注         | 访谈记录     | 访谈-张三-240710.mp3 | 张经理   | 高     | 已确认   |
| UFD-20240711-LS | 搜索结果的排序应优先显示最近更新   | 用户反馈     | App Store评论 ID 9876| 李用户   | 中     | 待验证   |
| COM-20240712-WB | 增加对话历史保存时长至30天         | 竞品分析     | 竞品A_v2.5功能清单   | 王产品   | 高     | 已采纳   |
| DAT-20240713-BL | 优化推荐模型响应时间<200ms       | 数据报告     | A/B测试报告 v1.3     | 陈数据   | 高     | 已排期   |
| REG-20240714-CY | 用户数据必须在前端进行脱敏显示     | 法规要求     | 个保法第21条         | 法务组   | 强制   | 已实施   |

字段说明：
- 来源ID：按规则自动生成，确保全局唯一。
- 需求描述：一句话精准概括，避免模糊描述。
- 原始来源类型：访谈记录/用户反馈/竞品分析/数据报告/法规要求。
- 置信度：高（有明确数据/多人验证）/ 中（有线索但尚需确认）/ 低（推测或单次提及）。
- 仲裁状态：已确认/待验证/已采纳/已排期/已实施/已废弃。

3.7 异常处理

常见异常	根因分析	应对措施
原始访谈录音缺失或无法辨识	归档不规范，录音文件损坏	联系访谈人补录关键内容；使用AI语音转文字后人工核查，对无法恢复的部分标注“缺失”，并在清单中降低置信度。
用户反馈数据量过大，聚类结果杂乱	未进行预筛选，存在大量噪声	先按“关键词+情感极性”粗聚类过滤，再使用K-means或LDA主题模型辅助，人工复核高频簇。
竞品分析内容滞后或版本不匹配	调研时间过早，竞品已更新	在清单中注明“调研日期”与“竞品版本”，若当前版本重大差异，需启动快速补充调研。
数据报告与访谈结论冲突	样本偏差或统计口径不一致	组织产销多方会议，重新审阅数据定义；若无法统一，记录两种结论并标记“待仲裁”，由产品负责人决策。
法规要求被遗漏或理解错误	法务参与不足，合规解读不准确	引入法务评审节点，对每条法规映射打上“强制/推荐/参考”标签，并在需求清单中附法规原文链接。

3.8 验收标准

1. 需求来源清单中每个条目均包含完整的7个字段（来源ID、需求描述、原始来源类型、原始文档/链接、提出者、置信度、仲裁状态）。
2. 所有原始资料均可通过来源ID直接定位原文片段（可追溯率100%）。
3. 来源类型覆盖全部5种（访谈记录、用户反馈、竞品分析、数据报告、法规要求），每种类型至少包含1条记录。
4. 置信度为“低”的条目不超过总条目数的15%，且已附加人工复核说明。
5. 仲裁状态不包含“待仲裁”超过3天无进展的条目（需在备注中更新进度时间戳）。
6. 清单中通过 COUNTIF(唯一值) 检查无重复需求描述（语义近似度大于85%视为重复）。

3.9 检查表（复盘自检）

检查项	结果	备注
所有5种来源类型均已覆盖	□ 是 □ 否	漏填需补充调研
每条需求均关联唯一来源ID	□ 是 □ 否	必须通过公式校验
置信度为“低”的条目占比≤15%	□ 是 □ 否	需回访或补充数据
仲裁状态“待仲裁”均设置最晚解决日期	□ 是 □ 否	超过3天须上报
清单无语义重复条目（人工+工具检查）	□ 是 □ 否	用余弦相似度≥0.85判定
原始文档/链接可正常访问或定位	□ 是 □ 否	损坏链接需备注