19 案例：从业务问题到 AI 场景

本章产出： 一个贯穿全书的虚构企业背景、业务问题树、用户旅程和基线指标。

本案例中的“山城精工”是为教学构造的中型制造企业，组织、系统、指标和情节均为虚构或综合化假设，不指向任何真实公司。案例吸收了企业数据项目中常见的矛盾：业务已经数字化，但事实分散；文档很多，但适用关系不清；专家经验宝贵，却没有稳定反馈；系统拥有权限，却不能支持 Agent 跨域、安全地完成任务。

案例的目的不是展示一套标准答案，而是把前文的方法放进一个有约束的环境：先解释为什么做，再决定做什么，随后定义数据产品、架构、治理和路线图。读者可以替换企业规模与行业，把过程复用到自己的场景。

19.1 企业背景

山城精工约有两千名员工，生产工业控制和自动化设备，客户分布在多个地区。公司经历了十余年的信息化建设：

ERP 管理客户、订单、物料、合同和库存；
MES 记录生产批次、出厂配置和检验；
CRM 管理客户关系与售后机会；
工单系统承载报修、派工、过程和结案；
设备平台接收联网设备状态与告警；
文档库保存说明书、维修手册、服务公告和培训材料；
即时沟通与个人笔记中仍保存大量专家经验。

每个系统在自身边界内基本可用，跨系统工作却依赖人。设备序列号、客户安装地点和型号编码存在历史差异；现场换件有时只写在工单文本；手册有多个版本，文件名未稳定表达适用范围；结案工单的“故障原因”质量不一；库存账面量与售后可用量口径不同。

企业并非“没有数据”，而是数据尚未以 Agent 可安全消费的方式成为上下文。

19.2 业务压力

公司售后设备数量增加，新型号迭代加快，但资深工程师增长有限。新人遇到故障时，通常在工单、文档库和聊天群之间搜索，再电话询问专家。高峰期专家被相似问题反复打断，现场工程师可能因为资料版本不适用而多次上门，也可能带错备件。

管理层最初提出：“建设一个企业知识助手，让工程师什么都能问。”数据产品团队没有直接接受这个范围，而是跟随工程师观察完整工作。研究发现，真正高频且有结果反馈的任务，是收到故障后判断可能原因、找到适用步骤并准备备件。单纯回答制度或解释产品参数虽然容易演示，对核心流程价值较弱。

于是首期场景被定义为“售后诊断与备件协同助手”，服务范围限制在两个主力设备系列和一个服务区域。它不是自动维修系统，而是为工程师提供带证据的诊断建议。

19.3 当前用户旅程

一次典型现场任务如下：

工程师从工单读取客户和设备描述；
尝试在 ERP 或 MES 核对序列号与出厂配置；
在文档库按型号、故障码或关键词搜索手册；
在历史工单中寻找相似记录；
无法判断时联系资深专家；
登录库存系统查询候选零件；
汇总判断，手工填写工单和客户沟通内容；
任务完成后选择一个结案原因。

旅程中存在四类等待：等待找到正确身份，等待找到适用证据，等待专家回复，等待确认备件。还存在四类风险：使用旧手册、将相似型号经验错误迁移、把账面库存当作可承诺量、结案结果无法成为高质量经验。

这些发现把“知识助手”改写为一个数据闭环问题：设备、规则、经验、状态和身份必须在任务发生时聚合；建议被人工修改和最终结案后，结果又应回流。

19.4 用户与待完成任务

首要用户是一线售后工程师。他们需要在现场压力下快速判断，不希望学习新的数据工具，也不愿重复录入。资深专家是第二类用户，他们希望减少重复咨询，并能审核高价值经验。区域主管关心处理周期、一次解决与风险；数据运营和平台团队负责质量与服务，但不是主要交互用户。

核心待完成任务可以表述为：

当工程师处理范围内设备故障时，帮助他在十分钟内获得与当前设备配置相符、来源可核验的诊断步骤和备件建议；证据不足或风险过高时，明确要求补充信息或升级专家。

这个表述包含时间、上下文、证据和失败行为。它没有承诺“自动解决所有故障”，也没有把“使用大模型”写入业务目标。

19.5 问题树

flowchart TD
    A[诊断慢、重复上门、专家被打断] --> B[设备上下文难聚合]
    A --> C[资料与经验难匹配]
    A --> D[状态与规则难确认]
    A --> E[结果不能稳定反馈]
    B --> B1[标识不一致]
    B --> B2[配置变更不完整]
    C --> C1[手册版本混乱]
    C --> C2[工单结论质量不一]
    D --> D1[库存口径不同]
    D --> D2[保修与权限分散]
    E --> E1[修改未结构化]
    E --> E2[结案标签粗糙]

问题树揭示，模型只覆盖“理解问题与组织答案”的一部分。若设备标识错误，检索再准确也会找到错误资料；若最终结果不回流，历史经验不会改善。项目优先级因此从“训练模型”转为“建立设备售后上下文产品与反馈闭环”。

19.6 数据现状

团队抽取小范围样本进行发现，而不是立即全量建设。以下数值仅为案例设定：

目标设备中约八成五可通过序列号直接连接出厂配置；
一部分现场换件只有自由文本，无法确定当前配置；
正式手册大多可读取，但适用型号与有效日期元数据不完整；
历史工单数量充足，只有约六成结案原因可作为确认标签；
设备告警时效较好，但少量设备时钟不准和离线补发；
库存系统有稳定 API，但“可用”仍需经过售后业务规则；
用户身份统一，客户和区域级授权需要从工单关系动态判断。

这些结果足以支持受控试点，却不足以开放全品类。范围限制因此是一项架构决策，而非项目能力不足的遮掩。

19.7 业务基线与价值假设

在试点前，团队用四周样本建立基线。案例假设：

指标	基线	首期目标方向
从接单到形成初步诊断	中位数 28 分钟	明显下降
跨系统人工搜索	平均 4 个入口	收敛为一次工作流
首次修复率	作为对照基线	稳步提高
重复询问专家	每周持续发生	高频问题下降
工单结论可复用率	约六成	通过结构化反馈提高

正式项目不应只写“明显下降”，而要结合真实样本与风险承受确定阈值。案例保留方向，是强调指标需要先有基线再设目标，不能凭空承诺一个百分比。

价值假设是：如果设备身份与有效资料可以自动聚合，工程师会减少搜索；如果建议带证据且能融入工单流程，工程师会采用；如果结果回流，案例质量会提升；搜索和诊断时间下降，配合正确备件，最终可能提高一次修复率。

每个“如果”都需要验证。流程结果受人员、设备难度和供应链影响，不能把所有变化归因于 Agent。

19.8 场景边界

首期包括：

两个主力设备系列；
一个区域的一线工程师；
设备识别、故障证据、排查建议、备件查询；
生成工单草稿；
人工确认与专家升级；
修改和结案反馈。

首期不包括：

全产品和全区域推广；
自动锁定或调拨库存；
自动修改保修和合同；
直接向客户发送承诺；
远程控制设备；
用未经审核的反馈自动训练或发布知识。

不做清单让治理和验收能够落地，也控制了失败半径。

19.9 约束与错误后果

业务高峰期服务需要稳定，但并非所有数据实时。设备告警要求分钟级，配置小时或分钟级，手册发布后十分钟级，历史案例日级，库存和权限在请求时确认。

最严重错误不是回答语言不优美，而是给出危险操作、使用错误型号规则、越权泄漏客户信息或作出错误库存与保修承诺。系统必须对这些设置单独护栏。一般性解释不完整可以由工程师补充，高风险证据缺失必须拒答。

组织方面，售后业务拥有规则和案例，IT 拥有源系统，数据团队负责产品与质量，平台团队负责服务，安全团队负责策略。若责任只落在“AI 项目组”，上线后很快无人能修源数据。

19.10 为什么它适合作为首期

该场景具有清晰用户、频繁任务、可观察基线和自然反馈；价值不只依赖模型，还能推动设备标识、手册版本和工单质量；首期可保持建议模式，风险可控；设备上下文未来还能被质量、销售和运维场景复用。

它也没有过度简单。多源实体、文档检索、实时状态、权限、人工审批和反馈同时存在，足以验证企业 AI Ready 的核心能力。

19.11 本章交付物：场景章程

场景章程应一页说明：

企业与流程背景；
用户及待完成任务；
问题树与最关键未知；
数据现状与范围缺口；
基线、价值假设、主指标和护栏；
首期包括与不包括；
时间、权限、合规和组织约束；
失败后澄清、拒答、降级与升级；
业务、产品、技术、数据和安全负责人；
九十天后扩展、调整或停止的判断。

山城精工的案例由此从“做一个助手”变成一项可以验证的业务改变：让可信上下文进入售后判断，让人的修订与最终结果回到数据产品。AI 是其中的交互与推理能力，数据闭环才是可持续能力。

场景章程还应由真实用户复述确认。若工程师用自己的语言无法解释产品解决什么、何时不该使用，说明定义仍停留在会议室。团队可以把章程带回现场，用几次真实任务验证步骤与风险，再由业务负责人签署。这一步看似朴素，却能防止技术团队对错误问题进行精致建设，也让后续的架构选择拥有稳定北极星。

章程一旦生效，新增诉求也要回到问题树判断。与首期任务无关的“顺便接入”并非免费，它会扩大数据、权限、评测和运营范围。守住场景边界，本身就是产品与架构共同承担的管理职责。