4、需求分析入门：如何从业务痛点出发，识别工业AI联动项目的真实需求
工业AI联动项目（如预测性维护、质量缺陷根因分析、工艺参数自优化、能源调度联动等）在启动时最容易犯的错误，不是技术选型失误，而是需求定义失真。业务方说“设备总停机”，IT部门理解为“装一堆传感器”；车间主任说“良率不稳定”，算法工程师直接开始做异常检测模型。结果项目上线后，发现采集的数据与业务决策链路脱节，模型精度再高也无法落地。本章的核心任务，是建立一套从业务痛点出发、逐层穿透到数据与联动逻辑的需求分析方法论，确保项目立项时的“真实需求”不是被包装过的表象，而是可量化、可验证、可联动的工程需求。
上图展示了工业AI联动项目需求分析的五层穿透模型。与传统的软件需求分析不同，工业AI项目必须从业务痛点出发，依次穿透业务目标、联动场景、数据点表、测试验收，最终形成闭环。下面我们将逐层展开，讲解每一层的核心方法、判断标准与常见陷阱。
4.1 核心原理：需求不是“收集”来的，而是“穿透”出来的
工业AI联动项目的需求分析，本质上是一个因果链还原的过程。业务方给出的痛点往往是结果指标（如“设备非计划停机每月超过8小时”），而AI联动项目需要的是过程指标和可干预变量（如“主轴温度在停机前30分钟持续上升，且与进给速度存在耦合关系”）。需求分析的核心原理可以概括为三个穿透：
- 从结果指标穿透到过程指标：业务痛点描述的是“发生了什么”，而AI联动需要知道“在什么条件下发生”“哪些参数在变化”“变化的时间窗口是多少”。例如“良率低”需要穿透到“哪道工序、哪个参数组合、在什么环境温湿度下良率下降”。
- 从单点故障穿透到联动关系：工业AI的价值在于联动——设备参数影响质量，质量数据反馈给工艺，工艺调整又影响能耗。需求分析必须识别出这些跨系统的耦合关系，而不是孤立地看一个设备或一条产线。
- 从人工经验穿透到可计算逻辑：老师傅知道“声音不对就要停机检查”，但AI联动项目需要把这种经验转化为可量化的特征（如振动频谱的特定频段能量超过阈值）和可执行的联动策略（如自动降速、自动报警、自动切换工艺参数）。
4.2 判断方法：五步需求穿透法
在实际项目中，我们推荐使用以下五步法来识别真实需求。每一步都有明确的输入、输出和判断标准，避免需求分析变成无休止的会议讨论。
| 步骤 | 输入 | 核心问题 | 输出物 | 判断标准 |
|---|---|---|---|---|
| 1. 痛点量化 | 业务部门描述、月度报表 | 这个痛点每年造成多少损失？频率多高？ | 痛点量化表（损失金额/时间/频次） | 年损失>50万或频次>12次/年才值得立项 |
| 2. 目标拆解 | 痛点量化表 | 改善到什么程度算成功？ | SMART目标（MTBF提升20%，误报率<5%） | 目标可测量、有基线、有时间限制 |
| 3. 场景联动分析 | 工艺流程图、设备拓扑 | 哪些设备/系统需要联动？联动触发条件是什么？ | 联动场景清单（触发信号→动作→目标设备） | 每个联动动作都有明确的触发源和执行机构 |
| 4. 数据点表映射 | PLC点表、DCS组态、数据库字段 | 现有数据能否支撑联动逻辑？缺哪些点？采样频率够吗？ | 数据差距分析表（已有/缺失/需新增传感器） | 关键参数覆盖率>80%，采样频率满足故障特征提取 |
| 5. 验收标准定义 | 目标拆解表、联动场景清单 | 如何证明AI联动有效？测试方案怎么设计？ | 验收KPI表（精度/响应时间/误报率/联动成功率） | 每个KPI都有测试方法和通过阈值 |
这五步不是线性走一遍就结束，而是需要至少两轮迭代。第一轮快速穿透，形成需求初稿；第二轮带着数据可行性约束回来修正目标。很多项目失败，是因为第一轮穿透后直接进入开发，没有做第二轮的数据可行性校验。
4.3 案例拆解：某汽车零部件工厂的压铸机预测性维护需求分析
下面通过一个完整的案例，展示需求穿透法的实际应用。这个案例来自某铝合金压铸工厂，该工厂有12台大型压铸机，主要生产新能源汽车电机壳体。
背景与约束：工厂的OEE（设备综合效率）只有72%，其中非计划停机是最大损失项。每台压铸机停机1小时，损失产值约3.8万元。工厂已有一套SCADA系统，采集了压铸机的PLC数据，但数据只用于事后报表，没有做实时分析。IT团队希望引入AI预测性维护，但车间主任担心“AI误报导致不必要的停机检查”。
初始现象与目标：过去半年，12台压铸机共发生非计划停机47次，平均每次停机4.2小时。主要故障类型包括：液压系统泄漏（18次）、锁模机构卡滞（12次）、伺服阀响应异常（9次）、其他（8次）。工厂的目标是：将非计划停机次数降低30%，平均修复时间缩短20%。
需求穿透过程：
- 痛点量化：47次停机 × 4.2小时 × 3.8万元/小时 = 750万元/年损失。加上紧急维修的备件和人工成本，实际损失超过900万元。痛点足够大，值得立项。
- 目标拆解：与车间主任和生产经理讨论后，确定SMART目标：6个月内将非计划停机次数从47次/半年降至33次/半年以内；预测性维护的误报率不超过10%（即每10次报警中，最多1次是虚惊）；提前预警时间不少于30分钟。
- 场景联动分析：这一步是关键。通过分析故障记录，发现液压系统泄漏的前兆是“液压油温度持续偏高 + 油泵电流波动 + 压力建立时间变长”。锁模机构卡滞的前兆是“锁模力曲线在合模末端出现异常抖动 + 伺服电机扭矩上升”。这些前兆信号分布在PLC的不同数据块中，且需要跨系统联动——液压站、锁模伺服、模具温度控制器。联动场景定义为：当AI模型检测到上述特征组合时，触发三级联动——① 向中控室发送预警；② 自动降低压射速度（防止带病生产）；③ 通知维修工单系统生成预检修任务。
- 数据点表映射：检查SCADA系统现有的PLC点表，发现液压油温度、油泵电流、压力传感器信号都有采集，采样频率为1秒。但锁模伺服电机的扭矩信号没有接入SCADA，需要从伺服驱动器直接读取（通过Modbus TCP）。另外，模具温度控制器的数据在另一套系统（MES）中，需要做数据集成。数据差距分析后，决定新增3个数据采集点：锁模伺服扭矩、合模位置编码器细分信号、液压油污染度传感器（新增硬件）。
- 验收标准定义：与IT和车间共同制定验收方案：使用历史数据回测（47次停机中，模型能提前30分钟预警多少次）+ 现场试运行4周（记录误报率和提前预警时间）。通过阈值：历史回测召回率>85%，试运行误报率<10%。
结果与复盘：项目上线后第3个月，成功预警了2次液压系统早期故障和1次锁模机构异常，避免了3次非计划停机。实际停机次数从47次/半年降至31次/半年，达到目标。但过程中也发现两个问题：一是新增的液压油污染度传感器在高温环境下漂移严重，需要每月校准；二是车间主任最初担心的误报问题确实存在——试运行第一周有3次误报，原因是模具温度波动导致的特征误匹配。后来通过加入“连续3个周期持续异常”的确认逻辑，误报率降至6%。
4.4 常见误区与总结复盘
在工业AI联动项目的需求分析中，以下四个误区最为常见，需要特别警惕：
- 误区一：把“数据采集”当成需求本身。业务方说“我们需要上传感器、建数据平台”，但这只是手段。真实需求是“减少停机”或“提升良率”。如果需求分析停留在数据采集层面，项目很容易变成数据仓库建设，而不是AI联动项目。
- 误区二：忽略联动动作的执行代价。AI模型输出一个预警信号很容易，但联动动作（如自动降速、自动切换工艺）可能带来生产节拍损失或产品质量风险。需求分析必须明确：联动动作失败时的降级策略是什么？人工确认的环节在哪里？
- 误区三：用历史数据的平均性能代替实时性能。很多项目用历史数据做离线验证时精度很高，但上线后实时数据流存在延迟、丢包、噪声，导致性能下降。需求阶段就要明确数据质量要求（时延<500ms，丢包率<0.1%），并在验收标准中体现。
- 误区四：需求分析没有业务方深度参与。如果需求文档只是IT和算法团队写的，车间主任、设备工程师没有签字确认，那么项目上线后大概率被业务方抵制。需求分析必须包含业务方的“验收承诺”——他们认可这些目标，并愿意为联动动作承担操作责任。
总结复盘：工业AI联动项目的需求分析，本质上是一次“业务-数据-算法-执行”四方对焦的过程。业务方定义痛点和目标，数据团队盘点数据资产和缺口，算法团队评估可行性，执行团队确认联动动作的可操作性。五层穿透模型提供了一个结构化的对话框架，但真正决定项目成败的，是需求分析师能否引导各方说出“真实约束”——包括预算限制、停机窗口、操作习惯、安全规范等。记住：需求文档不是一份交差的报告，而是项目启动后所有设计、开发、测试活动的唯一基准。需求分析阶段多花一周时间，往往能节省开发阶段一个月以上的返工成本。