4. 业务问题拆解框架：问题树、影响范围、可AI化程度评估
产品经理与AI工程师协作时，最常犯的错误是拿一个模糊的业务痛点直接问“能不能用AI解决”。缺乏系统拆解，会导致模型选型偏差、训练数据偏离真实场景、上线后用户不买单。本章给出标准拆解框架，分三步走：问题树结构化分解、影响范围界定、可AI化程度评估。
4.1 问题树：从模糊痛点到可执行子问题
问题树（Issue Tree）源自麦肯锡结构化思维。将顶层业务问题逐层拆解为MECE子问题，直到每个子问题都可被独立分析、可被AI模型或规则覆盖。
- 根节点：业务方反馈的原始痛点，如“客服响应效率低”。
- 一级分支：按流程、人员、系统、数据等维度拆解，如“坐席分配不合理”“常见问题重复问答”。
- 叶节点：可量化、可被技术方案解决的具体子问题，如“50%的咨询为订单查询，需人工切到自助页面”。
实操技巧：用“为什么”连问3～5层，确保叶节点能指向明确的数据源或规则。避免出现“系统太差”这种不可拆解的描述。
4.2 影响范围评估：技术、用户、业务三维度
拆解出子问题后，需要评估每个子问题的“影响范围”，决定优先级。推荐三维度加权打分模型：
| 维度 | 指标举例 | 权重建议 |
|---|---|---|
| 用户范围 | 日活用户覆盖数、用户角色类型（如仅管理员 vs 全体C端） | 40% |
| 业务价值 | 单次问题解决带来的GMV/成本节省/满意度提升 | 40% |
| 技术复杂度 | 所需数据是否已有、模型成熟度、合规风险 | 20% |
每个子问题打1～5分，加权总分越高，越应优先进入AI化方案设计。
4.3 可AI化程度评估：判断是否适合用模型解决
并非所有子问题都值得“AI化”。评估框架包含四个核心检查项：
- 输入是否可结构化？（文本、图像、数值 vs 模糊的人类情感判断）
- 是否有明确的正确/错误模式？（如分类任务 vs 主观审美）
- 数据是否存在？（历史标注量、数据质量、标注成本）
- 失败容忍度？（推荐系统可接受90%准确，但医保辅助诊断需99.99%）
根据以上检查项，将子问题分为三类：高AI适配（推荐算法方案）、中AI适配（混合规则+模型）、低AI适配（优先人工或流程优化）。
避坑：不要强行AI化。如果子问题“低适配”但商务诉求强烈，应在PRD中建议做短期规则方案，同时规划数据积累路径，而非直接上深度学习模型。
4.4 框架协同：问题树→影响范围→可AI化评估
完整流程如下：
- Step 1：业务痛点 → 构建问题树至叶节点。
- Step 2：每个叶节点做影响范围三维打分。
- Step 3：对高影响叶子节点做可AI化程度检查。
- Step 4：输出优先级矩阵，定义每个节点“是否用AI以及用哪种AI”。
4.5 案例：电商客服效率问题拆解
某电商平台反馈“客服每天处理大量物流咨询，人工成本高”。使用框架拆解如下：
| 问题树（叶节点） | 影响范围总分 | 可AI化程度 | 建议方案 |
|---|---|---|---|
| 订单物流状态自动查询（API数据已存在） | 4.5（用户量大+成本节省高+技术简单） | 高 | NLP意图识别+FAQ机器人 |
| 退换货规则咨询（规则复杂，需上下文理解） | 3.8（用户中+业务价值中+数据不足） | 中 | 先做规则决策树，后续积累数据再训练模型 |
| 情绪化投诉安抚（需要同理心判断） | 2.2（用户少+价值不明+数据极难获取） | 低 | 保持人工处理，仅做质检辅助 |
要点回顾：问题树确保全局无遗漏；影响范围三维度量化优先级；可AI化检查避免技术滥用。三者串联形成产品经理与AI工程师的共同语言。