2. 需求澄清与场景锁定

用户需求是AI解决方案设计的核心输入,但原始需求往往是模糊、矛盾或过度笼统的。本章通过结构化访谈、功能/非功能需求剥离和场景优先级矩阵,将“用户愿望”转化为可落地的系统边界与验收标准。

2.1 用户访谈要点

每次访谈前必须准备结构化的提纲,避免开放式漫谈。下面是标准访谈框架:

访谈阶段 核心问题 产出物
背景了解 业务当前使用什么流程?哪个环节最耗时/易错? 痛点列表
理想状态 如果AI完全解决,一天的工作流会变成什么样? 愿景描述
约束挖掘 有没有必须保留的现有系统?数据来源是否可控? 约束清单
优先顺序 哪些场景必须第一个上线?哪些可以后续迭代? 场景权重
避坑要点:不要追问技术实现细节(如“模型用什么算法”),聚焦在业务结果和可接受的误差范围。

2.2 功能需求与非功能需求拆分

所有收集到的需求必须按以下维度拆解,避免把“响应快”和“识别准确”混在同一条目里。

需求类型 典型描述 度量指标 设计影响
功能需求 系统能自动分类客户工单为5个类别 分类正确率 ≥ 92% 决定模型选型、训练数据标注标准
非功能需求 – 性能 单次推理应在500ms内完成 P99 延迟 ≤ 500ms 选择推理引擎、硬件规格、缓存策略
非功能需求 – 安全 用户数据不能离开内部网络 所有数据本地加密存储 部署架构必须私有化,仅使用本地模型
非功能需求 – 可维护性 模型更新后无需停服 滚动升级时间 < 1分钟 设计模型热加载、蓝绿部署
常见失误:非功能需求常被忽视或后置,导致上线后无法满足SLA。务必在需求阶段明确每个约束的优先级。

2.3 关键场景优先级矩阵

将所有候选场景按业务价值和技术可行性两个维度打分,形成四象限优先级矩阵:

技术可行性 \ 业务价值 高 低
高 🔥 第一优先级 — 立即启动 ✋ 第二优先级 — 可做但非急迫
低 🔄 需要技术验证 — 先做POC ❌ 暂不考虑 — 未来迭代

具体打分标准(示例):

  • 业务价值(1~5):直接影响收入/成本/客户满意度?覆盖多少用户?
  • 技术可行性(1~5):数据是否易得?模型成熟度?是否有现成API?团队经验?
实操建议:在访谈结束后立即组织内部评审会,用利益相关者权重投票得到每个场景的最终分数,避免“全五星”现象。

2.4 系统边界与模块分层定义

场景优先级矩阵决定了第一版系统的范围。以一个典型的“智能工单分类”场景为例,系统边界如下:

场景锁定 → 系统边界 → 模块分层 用户访谈 需求清单 F / NF 拆分 场景优先级矩阵 系统边界定义 边界划定原则:只包含优先级为“立即启动”的场景,其他场景标记为“后续迭代”。 模块分层:输入层(工单解析) → 推理层(分类模型) → 输出层(标签/路由)。

2.5 组件职责与数据流(以第一场景为例)

选定“智能工单分类”为第一优先级场景后,模块职责划分如下:

模块 组件 职责描述 信任链路要求
输入层 工单采集器 从CRM系统接收原始工单,校验格式并清洗PII 与CRM之间的API调用必须使用mTLS双向认证
推理层 分类推理引擎 加载预训练BERT模型,执行多标签分类,返回置信度列表 模型存储需签名验证,防止模型被篡改
输出层 路由分发器 根据分类结果将工单写入对应部门队列 队列访问使用服务账号+RBAC权限
监控层 质量看板 收集推理延迟、分类正确率、数据量等指标 数据经过脱敏后才进入监控数据库
数据流简述:工单采集器 → 推理引擎(带缓存) → 路由分发器 → 部门队列。控制流中增加“人工审批环节”:当模型置信度低于阈值(0.85)时,工单自动转入人工复核队列。

2.6 风险点与落地步骤

风险点 影响 缓解措施
标注数据不足导致模型效果差 分类准确率低于业务要求 第一阶段使用预训练+少量标注,同时启动主动学习
用户对分类结果的不信任 人工流程无法被替代 提供置信度显示,并保留人工修改权限
系统边界不清晰,需求蔓延 开发周期失控 严格以优先级矩阵为基准,新增需求走变更流程

落地步骤:

  1. 完成用户访谈并输出《需求澄清报告》。
  2. 组织评审会确定功能/非功能需求列表,签字确认。
  3. 根据优先级矩阵锁定第一迭代范围,起草《系统边界说明书》。
  4. 输出第一版本的模块分层与组件职责文档,与开发团队进行可研预评审。

2.7 验收标准

本章结束后,必须交付以下产物并通过检查:

  • 需求澄清报告:包含访谈纪要、痛点列表、约束清单。
  • F/NF需求拆分表:每个需求有唯一编号、类型、度量指标、优先级。
  • 场景优先级矩阵:至少8个候选场景按业务价值+技术可行性排列。
  • 系统边界定义:明确第一版本包含/不包含的功能边界,并用架构图展示。
评审建议:邀请业务方、架构师、QA三方共同参与痛点列表的确认,防止遗漏关键场景。