2. 需求澄清与场景锁定
用户需求是AI解决方案设计的核心输入,但原始需求往往是模糊、矛盾或过度笼统的。本章通过结构化访谈、功能/非功能需求剥离和场景优先级矩阵,将“用户愿望”转化为可落地的系统边界与验收标准。
2.1 用户访谈要点
每次访谈前必须准备结构化的提纲,避免开放式漫谈。下面是标准访谈框架:
| 访谈阶段 | 核心问题 | 产出物 |
|---|---|---|
| 背景了解 | 业务当前使用什么流程?哪个环节最耗时/易错? | 痛点列表 |
| 理想状态 | 如果AI完全解决,一天的工作流会变成什么样? | 愿景描述 |
| 约束挖掘 | 有没有必须保留的现有系统?数据来源是否可控? | 约束清单 |
| 优先顺序 | 哪些场景必须第一个上线?哪些可以后续迭代? | 场景权重 |
避坑要点:不要追问技术实现细节(如“模型用什么算法”),聚焦在业务结果和可接受的误差范围。
2.2 功能需求与非功能需求拆分
所有收集到的需求必须按以下维度拆解,避免把“响应快”和“识别准确”混在同一条目里。
| 需求类型 | 典型描述 | 度量指标 | 设计影响 |
|---|---|---|---|
| 功能需求 | 系统能自动分类客户工单为5个类别 | 分类正确率 ≥ 92% | 决定模型选型、训练数据标注标准 |
| 非功能需求 – 性能 | 单次推理应在500ms内完成 | P99 延迟 ≤ 500ms | 选择推理引擎、硬件规格、缓存策略 |
| 非功能需求 – 安全 | 用户数据不能离开内部网络 | 所有数据本地加密存储 | 部署架构必须私有化,仅使用本地模型 |
| 非功能需求 – 可维护性 | 模型更新后无需停服 | 滚动升级时间 < 1分钟 | 设计模型热加载、蓝绿部署 |
常见失误:非功能需求常被忽视或后置,导致上线后无法满足SLA。务必在需求阶段明确每个约束的优先级。
2.3 关键场景优先级矩阵
将所有候选场景按业务价值和技术可行性两个维度打分,形成四象限优先级矩阵:
| 技术可行性 \ 业务价值 | 高 | 低 |
|---|---|---|
| 高 | 🔥 第一优先级 — 立即启动 | ✋ 第二优先级 — 可做但非急迫 |
| 低 | 🔄 需要技术验证 — 先做POC | ❌ 暂不考虑 — 未来迭代 |
具体打分标准(示例):
- 业务价值(1~5):直接影响收入/成本/客户满意度?覆盖多少用户?
- 技术可行性(1~5):数据是否易得?模型成熟度?是否有现成API?团队经验?
实操建议:在访谈结束后立即组织内部评审会,用利益相关者权重投票得到每个场景的最终分数,避免“全五星”现象。
2.4 系统边界与模块分层定义
场景优先级矩阵决定了第一版系统的范围。以一个典型的“智能工单分类”场景为例,系统边界如下:
2.5 组件职责与数据流(以第一场景为例)
选定“智能工单分类”为第一优先级场景后,模块职责划分如下:
| 模块 | 组件 | 职责描述 | 信任链路要求 |
|---|---|---|---|
| 输入层 | 工单采集器 | 从CRM系统接收原始工单,校验格式并清洗PII | 与CRM之间的API调用必须使用mTLS双向认证 |
| 推理层 | 分类推理引擎 | 加载预训练BERT模型,执行多标签分类,返回置信度列表 | 模型存储需签名验证,防止模型被篡改 |
| 输出层 | 路由分发器 | 根据分类结果将工单写入对应部门队列 | 队列访问使用服务账号+RBAC权限 |
| 监控层 | 质量看板 | 收集推理延迟、分类正确率、数据量等指标 | 数据经过脱敏后才进入监控数据库 |
数据流简述:工单采集器 → 推理引擎(带缓存) → 路由分发器 → 部门队列。控制流中增加“人工审批环节”:当模型置信度低于阈值(0.85)时,工单自动转入人工复核队列。
2.6 风险点与落地步骤
| 风险点 | 影响 | 缓解措施 |
|---|---|---|
| 标注数据不足导致模型效果差 | 分类准确率低于业务要求 | 第一阶段使用预训练+少量标注,同时启动主动学习 |
| 用户对分类结果的不信任 | 人工流程无法被替代 | 提供置信度显示,并保留人工修改权限 |
| 系统边界不清晰,需求蔓延 | 开发周期失控 | 严格以优先级矩阵为基准,新增需求走变更流程 |
落地步骤:
- 完成用户访谈并输出《需求澄清报告》。
- 组织评审会确定功能/非功能需求列表,签字确认。
- 根据优先级矩阵锁定第一迭代范围,起草《系统边界说明书》。
- 输出第一版本的模块分层与组件职责文档,与开发团队进行可研预评审。
2.7 验收标准
本章结束后,必须交付以下产物并通过检查:
- 需求澄清报告:包含访谈纪要、痛点列表、约束清单。
- F/NF需求拆分表:每个需求有唯一编号、类型、度量指标、优先级。
- 场景优先级矩阵:至少8个候选场景按业务价值+技术可行性排列。
- 系统边界定义:明确第一版本包含/不包含的功能边界,并用架构图展示。
评审建议:邀请业务方、架构师、QA三方共同参与痛点列表的确认,防止遗漏关键场景。