第3章 梳理AI功能候选列表的输入方式

本章聚焦于从三个核心来源——业务需求文档、用户反馈记录与技术可行性报告——中系统提取候选AI功能，并按照统一格式汇聚为结构化候选列表。这是整个优先级划分流程的“原料准备”阶段，输入质量直接决定后续排序的有效性。

适用场景

• 产品团队已收集到初步的业务需求文档（BRD/PRD）或业务方口头需求记录。
• 用户反馈渠道（客服工单、NPS评论、用户访谈、App Store评分）积累了一定量的原始数据。
• 技术团队出具了针对候选AI特性的可行性研究报告（含数据可得性、模型成熟度、基础设施成本）。
• 团队计划启动季度或里程碑级别的AI功能优先级排序工作。

前置条件

操作步骤

步骤1：从业务需求文档提取功能

产品经理逐条解析BRD/PRD中的业务诉求，将“业务语言”转化为“AI功能描述”。

1. 映射业务目标：将“提升客服响应率”映射为“AI智能客服意图识别与自动回复”。
2. 标注约束标签：标注“合规性要求”“离线可用”“延迟<200ms”等技术约束。
3. 填写提取表：按下方模板记录。

【业务需求功能提取表·示例】
原始需求：“降低订单异常人工审核量”
→ 功能ID：BR-001
→ 功能名称：订单异常自动分类与风险分级
→ 优先级参考（业务方）：P1（高）
→ 关联指标：人工审核量降低≥40%
→ 约束条件：必须本地部署，数据不出域

步骤2：从用户反馈中归类功能

用户研究团队对反馈文本进行主题聚类，识别高频诉求，将其转化为候选功能。

1. 聚类标签：使用关键词+人工校验，将反馈归入“搜索不准”“推荐不相关”“流程太慢”等主题。
2. 量化诉求强度：统计每个主题的提及频次与情感倾向（正面/负面/中性）。
3. 输出功能卡片：每个聚类生成一张功能候选卡。

【用户反馈功能归类卡·示例】
聚类主题：“搜索结果不准确”
提及次数：127次 | 负面占比：89%
→ 功能ID：UF-002
→ 功能名称：基于语义理解的搜索排序优化
→ 预期收益（用户侧）：搜索点击率提升≥15%
→ 证据来源：2025Q2客服工单 + App Store评论

步骤3：从技术可行性报告中筛选可行功能

技术架构师根据可行性报告评估每项候选功能的技术成熟度与成本，剔除不可行项。

1. 匹配模型能力：确认是否有开源/商业模型支持，或需要自研。
2. 估算资源消耗：标注所需的GPU/CPU、存储、带宽及开发人·天。
3. 标记风险等级：高风险（数据不可得/模型不成熟）、中风险（需实验验证）、低风险（已有成熟方案）。

【技术可行性评估项·示例】
功能ID：UF-002
功能名称：基于语义理解的搜索排序优化
技术方案：基于BERT的微调排序模型
数据可得性：已有5年搜索日志（可用） ✅
模型成熟度：HuggingFace开源模型，社区活跃 ✅
估算人·天：45人·天
风险等级：中（需标注1000条测试数据）
技术决策：建议纳入候选列表

步骤4：合并去重与格式标准化

将三张来源表汇总为统一的AI功能候选列表，消除重复项，统一字段格式。

1. 去重规则：功能名称相似度≥85%或描述指向同一业务目标时，合并为一条，保留所有来源标签。
2. 标准化字段：功能ID（前缀区分来源）、功能名称、来源标签、预期收益、约束条件、技术风险等级。
3. 输出最终清单：按“来源-功能ID”排序，生成CSV或Excel文件。

输入输出物

责任边界

• 产品经理：主导业务需求解析与功能提取，负责候选列表的最终合并与格式校验，对列表的完整性和一致性负责。
• 用户研究团队：完成用户反馈的清洗、聚类与量化分析，输出归类卡，对反馈数据的代表性和准确性负责。
• 技术架构师：逐项评估技术可行性与资源成本，标记风险等级，剔除不可行项，对技术结论的客观性负责。
• 产品总监（审核角色）：审核合并后的候选列表，确认无遗漏、无重复，签字准入下一章“优先级排序”。

记录材料

异常处理

验收标准

• 输出一份字段完整的 AI功能候选列表（.xlsx格式），包含字段：功能ID、功能名称、来源标签、业务目标、预期收益、技术风险等级、约束条件。
• 列表中的每一项都至少能追溯到一张提取表、归类卡或评估记录（R1/R2/R3）。
• 列表无重复项：任意两个功能名称的语义相似度＜85%，或已手动合并并保留双来源ID。
• 列表数量控制在 8～30 项之间（含），超出范围需附初筛说明。
• 产品总监签字确认：列表已覆盖所有已归档的业务需求、已聚类的用户反馈、已评估的技术可行项。