4. 业务问题定义
业务问题定义是AI产品场景化需求建模的起点，也是整个需求工程中最容易被跳过或草率处理的一步。许多AI产品最终沦为“技术演示”而非“业务解决方案”，根源在于问题定义阶段就存在偏差。本章聚焦三个核心产出：问题陈述、痛点分级和影响范围评估，三者共同构成需求建模的业务基线。
核心原则：不要用AI术语描述业务问题。好的问题陈述应该让业务方点头，让技术方知道“为什么做”，而非“怎么做”。
4.1 问题陈述：结构化描述业务缺口
问题陈述不是“用户不满意”这种模糊表述，而是一个包含主体、场景、现象、后果四要素的结构化句子。推荐使用以下模板：
【主体】在【特定场景】下，因【当前限制或障碍】，
导致【可观测的不良后果】，进而造成【量化影响】。一个典型的反例与正例对比：
| 类型 | 示例 | 问题 |
|---|---|---|
| 反例 | “客服响应太慢，用户不满意” | 无量化、无场景、无因果 |
| 正例 | “大促期间，一线客服在客户发起会话后平均等待45秒才能调取历史订单，导致用户重复描述问题，首响时长超行业基准2.3倍，NPS下降8个点” | 具象、可测量、有业务影响 |
实操清单：问题陈述自检
- 是否包含具体角色？（谁遇到了问题）
- 是否包含可观测的指标？（时长、频次、金额、转化率）
- 是否排除了“技术预判”？（不要写“因为缺少AI模型”，只写业务现象）
- 是否可被非技术人员理解？（让运营总监也能复述）
4.2 痛点分级：P0–P3 四级分类法
并非所有业务问题都需要AI来解决。痛点分级帮助团队在资源有限时聚焦高价值场景。分级标准以业务中断程度和用户容忍度为双轴：
| 级别 | 定义 | 业务表现 | 典型示例 |
|---|---|---|---|
| P0 | 业务阻断型 | 核心流程中断，用户无法完成任务，每日影响超过1000人次 | 支付系统超时导致订单丢失 |
| P1 | 效率损失型 | 流程可走通但耗时翻倍，用户需绕行或手工干预 | 客服手动翻查3个系统才能答复一个简单问题 |
| P2 | 体验摩擦型 | 功能可用但体验差，用户有抱怨但未流失 | 搜索结果中无关项占比高于40% |
| P3 | 期望提升型 | 现有流程无明显痛点，但竞品已提供更好体验 | App内无智能推荐，用户需自行筛选商品 |
避坑提醒：P0和P1是AI产品的“必争之地”，但如果P0问题能用简单规则引擎解决，就不应优先引入AI。痛点分级要独立于技术方案，先判断业务严重性，再评估AI必要性。
4.3 影响范围评估：三个维度
影响范围评估决定了一个业务问题值得投入多少资源。从用户范围、业务范围和数据范围三个维度交叉衡量：
- 用户范围：受影响用户占整体用户的比例，以及用户角色（一线员工、管理者、终端客户）的层级权重。
- 业务范围：波及的核心业务链路数量（售前、售中、售后、复购等），以及是否涉及营收或合规。
- 数据范围：问题是否具备可采集、可标注、可闭环反馈的数据基础，数据量级是否满足AI训练的最低要求。
| 维度 | 高影响（3分） | 中影响（2分） | 低影响（1分） |
|---|---|---|---|
| 用户范围 | ≥30% 活跃用户 或 关键角色全员 | 5%–30% 活跃用户 | <5% 活跃用户 |
| 业务范围 | 涉及2条以上核心链路，或直接影响营收 | 涉及1条核心链路 | 仅影响非核心辅助流程 |
| 数据范围 | 已有≥3个月历史数据，标注成本可控 | 数据存在但需清洗或重建标签 | 几乎无可用数据，需从零采集 |
三个维度得分相加（总分3–9），结合痛点分级，共同决定该业务问题的需求建模优先级：总分≥7且P0/P1的问题，应进入下一阶段的深度用户访谈；总分≤4或P3级问题，可考虑推迟或采用非AI方案。
4.4 综合案例：智能客服场景
以某电商平台“大促期间客服响应超时”为例，演示完整的三步定义过程：
- 问题陈述：“大促期间，一线客服在客户发起会话后平均等待45秒才能调取历史订单，导致用户重复描述问题，首响时长超行业基准2.3倍，NPS下降8个点。” —— 符合四要素：主体（一线客服）、场景（大促期间）、现象（等待45秒）、后果（NPS下降）。
- 痛点分级：P1（效率损失型）。核心流程可走通，但处理时长翻倍，且影响大促期间的客户留存。
- 影响范围评估：用户范围2分（涉及全部一线客服，占客服团队100%）；业务范围3分（影响售中咨询和售后投诉两条链路）；数据范围3分（已有18个月会话日志和订单关联数据）。总分8分，进入深度访谈阶段。
交付物模板：业务问题定义卡
【问题ID】PRB-2025-0042
【问题陈述】大促期间，一线客服在客户发起会话后平均等待45秒
才能调取历史订单，导致首响时长超行业基准2.3倍。
【痛点级别】P1（效率损失型）
【影响范围】用户范围 2 / 业务范围 3 / 数据范围 3 → 总分 8
【建议动作】进入深度用户访谈，输出场景化需求拆解
常见误区：问题定义阶段就引入AI方案描述，例如“需要一个智能订单摘要模型”。正确做法是只描述业务缺口，让后续的需求拆解和方案设计环节自然推导出AI介入点。问题定义卡中严禁出现“AI”“模型”“算法”等词汇。
4.5 从定义到访谈的衔接
业务问题定义的输出将成为下一章用户访谈的输入材料。带着清晰的问题陈述、痛点等级和范围评分进入访谈，能够有效避免“漫谈式调研”，让每一场访谈都聚焦在已验证的高优先级业务缺口上。建议在访谈前将问题定义卡同步给受访者，作为访谈大纲的共同起点。
| 阶段 | 输入 | 产出 |
|---|---|---|
| 业务问题定义（本章） | 业务场景描述、用户反馈、运营数据 | 问题陈述 + 痛点分级 + 影响范围评分 |
| 用户访谈（下一章） | 问题定义卡、访谈提纲 | 场景化需求描述、用户验证、隐藏痛点挖掘 |
完成本章的三步定义后，你应当能够为每一个候选AI场景输出一张完整的业务问题定义卡，作为后续需求建模的“锚点”。