制造业AI这两年热度一直没降过，但我发现一个很普遍的现象：很多甲方拿着PPT里的“上AI”口号，真到梳理需求时，写出来的东西往往要么太空泛，要么只盯着某个单点工具，完全没搞明白AI在制造业里到底解决的是什么层面的问题。最近我整理了一份制造业AI需求清单，越梳理越觉得这里面藏着不少硬核难题，真不是采购一套软件、部署几台边缘盒子就能糊弄过去的。这篇就把清单背后的技术考量和落地坑位一次性聊透。
1. 内容整体设计与思路拆解
1.1 制造业AI的三种需求层级
先给需求分层。我接触过的制造企业AI需求，基本可以归为三个层级：现场级、车间级、工厂级。现场级解决的是单台设备、单个工位的感知与控制问题，比如视觉质检、设备异常声音识别；车间级解决的是多条产线、多个工序之间的协同调度，比如生产排程优化、物料配送预测；工厂级则是覆盖计划、采购、库存、销售等经营全链条的决策优化。
绝大部分企业嘴里说的“上AI”，其实只停留在现场级，也就是买个视觉检测系统替换人工质检。这个层级相对成熟，落地难度可控，供应商也多，但价值天花板明显。真正能拉开差距的反而是车间级和工厂级的应用，可这两个层级的需求梳理难度陡增，因为涉及的数据范围、组织边界、系统集成复杂度都不是一个量级。我这份需求清单，重点就是剖析三个层级的典型需求样本。
1.2 需求清单里最容易踩的认知误区
把真实需求翻译成AI需求，是第一个大坑。制造业客户经常把“业务流程优化需求”直接等同于“AI算法需求”。举几个例子：产线主管说“我们希望AI能自动减少换型时间”，听起来很AI，拆解一下其实是工装夹具的快速换型、标准作业程序的优化、人员动作的规范，AI可能只承担其中排程优化的一小块；质量经理说“我们要用AI做零缺陷出厂”，可追问下去，当前的数据采集覆盖率、传感器精度、工艺参数记录的颗粒度，根本支撑不了这个目标。
所以我的需求清单整理原则是：先区分业务需求和技术需求，再把技术需求解剖到“数据是否可得、模型是否可行、ROI是否划算”三个层面。这点后面展开细讲。
1.3 大模型热潮下制造业需求的变与不变
行业里所有人都在追问大模型会给制造业AI带来什么变化。我的观点是：变化在交互层和知识层，不变的是控制层和感知层。大模型最擅长的是把老师傅的知识、设备手册、工艺文档这些非结构化数据变成可问答、可推理的知识库，帮助快速定位质量问题、生成工艺建议。但真正控制设备运动轨迹、做毫秒级的安全联锁、闭环调节温度压力，大模型替代不了，也不敢让它干。
因此这份需求清单里，我把大模型相关需求放在了“知识管理、交互问答、工艺辅助决策”这一类，而传统深度学习模型的需求依然集中在“视觉检测、预测性维护、参数优化”等方向。两类需求的技术栈不同，实施团队也不同，混为一谈就会把项目做砸。
2. 核心细节解析与实操要点
2.1 需求一：复杂工件表面缺陷视觉检测
这个需求看似最常见，但“复杂”二字意味着大量隐藏难点。比如要检测的工件可能是高反光金属面、纹理极细的碳纤维表面、或者多层叠合的不规则曲面。普通光源方案打上去，反光一片白，缺陷完全淹没在光晕里。这里的关键不在算法，而在光学方案设计。
我整理需求时会要求团队先回答一组问题：缺陷类型有哪些，各自的尺寸范围、灰度对比度、出现频率如何；产线节拍要求多少毫秒内完成拍照和判定；现场有没有振动、粉尘、油雾干扰光学成像；缺陷样本能不能批量采集，有没有足够多的不良品留样。这组问题直接决定硬件选型和算法方案的可行性。很多时候做完这组问答，客户自己就发现，当前的产线改造空间根本不足以支撑稳定的成像环境，AI项目还没启动就要先补机器视觉的课。
算法层面，传统机器视觉加深度学习的混合方案仍是制造业视觉检测的主流。深度学习负责复杂纹理背景下的缺陷识别，传统算法负责精确的定位、尺寸测量和边缘检测。库内样本不足时，先用传统算法做粗筛、圈定可疑区域，再用分类网络做细判，是比较务实的落地方案。不要一上来就端到端一个大模型，推理速度、标注成本、现场调试难度都受不了。
2.2 需求二：关键设备预测性维护与剩余寿命预测
预测性维护写进需求清单很容易，落地之难却超乎想象。核心问题出在数据上：故障样本天然稀缺。一台正常运行的设备，传感器数据99.99%都是健康状态，故障数据凤毛麟角。训练一个能够区分健康与故障的模型，本质上是极度不平衡的分类问题。
而且很多企业的历史数据并没有打标，设备停机记录、维修工单、备件更换信息分散在不同系统里，甚至只有纸质的点检表。要打通设备数据（SCADA/PLC）与维修工单数据（CMMS/EAM），本身就是一个数据治理项目。我在需求清单里会专门标注清楚：实施预测性维护之前，必须先做“数据可用性审计”，确认有哪些设备具备传感器数据采集条件，历史维修记录是否结构化，故障代码是否统一规范。这一步没做扎实，后面的算法做得再漂亮都是空中楼阁。
算法选型上，告诉大家一个实践经验：不要一上来就搞深度学习的剩余寿命预测。对绝大多数工厂而言，基于阈值的统计监测加上轻量级异常检测模型就够了。比如先用滑动窗口提取振动信号的时域特征（RMS、峰值因子、峭度）和频域特征（特征频率能量占比），再用孤立森林或自编码器做异常评分，当异常评分连续跨过阈值并持续一段时间后触发告警。这套方案对数据量要求低，部署简单，解释性强，现场工程师也愿意接受。只有当这一层跑通、积累了足够的故障案例后，才值得考虑用LSTM或Transformer做更精细的寿命预测。
2.3 需求三：生产排程与动态调度优化
排程问题的需求描述通常是“我们要实现智能排产，快速响应订单变更”。可真要落地，约束条件多得吓人：物料齐套时间、设备可用状态、模具寿命、工艺路线约束、人员技能矩阵、交期优先级、最小生产批量……这些约束还相互耦合，一个订单插单可能牵动整条产线的节奏。
这个需求的核心难点在于业务建模。很多企业连当前排程依赖哪些约束条件都没完整梳理过，更别说量化优先级和惩罚权重。我在需求清单里通常会附一张约束清单模板，让生产计划员勾选并标注重要程度。只有把业务约束翻译成数学模型的变量、目标函数和约束条件，算法才能派上用场。
算法选择方面，小规模场景用整数规划或约束规划就可解，中等规模可以用遗传算法、模拟退火等元启发式算法，大规模动态场景才需要上强化学习。但即便用了强化学习，仿真环境的搭建才是大头。如果企业没有数字孪生模型或者高保真度的仿真平台，强化学习智能体根本没有训练环境。因此这个需求的实际交付物往往不是一个“排程算法”，而是一个“排程决策支持系统”，算法负责出推荐方案，计划员负责审核调整。期望值管理，从一开始就要做好。
2.4 需求四：工艺参数智能优化
工艺参数优化的典型场景是注塑、压铸、热处理、焊接这类参数多、非线性强、质量波动大的工序。老师傅凭经验调参，但换料、换模、换环境后参数往往不再适用，试错成本高、周期长。AI在这里的价值是把“试错”变成“预测”。
实操上，这个需求若要落地，需要采集工艺参数曲线与质量检测结果的对应数据，而且质量数据要有足够的量化精度。举个例子，注塑机的工艺参数包含料温、模温、注射速度、保压压力、冷却时间等几十个参数，质量指标可能是尺寸公差、外观缺陷率、翘曲度等。要建立参数到质量的映射模型，需要成百上千组有效样本。很多工厂生产记录不全、质量检验数据只有合格与不合格标签，建模难度非常大。
如果数据条件允许，我建议用贝叶斯优化来替代传统的实验设计（DOE）。贝叶斯优化可以利用已有的生产数据建立代理模型，在参数空间中搜索最优区域，并且能够明确给出下一次试验建议的参数组合。相比网格搜索和随机搜索，效率高得多。实际项目中，我们甚至可以把老师傅的经验参数作为先验分布，让优化算法在经验参数附近做局部精细搜索，一方面减少探索风险，另一方面说服老师傅接受AI建议。
3. 实操过程与核心环节实现
3.1 从需求清单到可执行项目：一个标准的六步拆分法
需求清单如果只是一张Excel表，那价值有限。我会把清单上的每一条需求都推进到“可执行项目”的粒度，一般走六步。
第一步，明确业务收益。先回答“做这个能带来多少可量化的收益”，比如良率提升0.5个百分点对应多少金额，设备停机时间减少10%对应多少产出。收益不明确的需求，直接砍掉或暂缓。
第二步，盘点数据条件。对应数据能不能采、有没有历史积累、数据质量是否达标、数据接口是否开放。这是判断项目真伪的分水岭。数据条件不满足的，要么先做数据基建项目，要么降低目标预期。
第三步，定义模型任务。把业务目标转换为算法可优化的数学问题，比如分类、回归、异常检测、组合优化还是强化学习。这一步需要算法工程师和业务专家深度共创，反复校准。
第四步，评估技术可行性。参考行业标杆案例和团队自身能力，判断在给定数据量、算力、时间窗口下，目标能否达成。技术不可行的，拆解成阶段目标，从简单方案起步。
第五步，制定试点计划。选一条产线、一台设备或一个工序做试点，明确试点范围和验收指标。小步快跑，用试点结果说话，比任何蓝图规划都有说服力。
第六步，规划规模化路径。想清楚试点成功后如何复制到其他产线、如何与现有信息化系统集成、需要哪些组织和流程变革支持。
这套拆解方法我一直在用，它的核心价值是让所有参与者在项目启动前对“做什么、为什么做、凭什么能做”达成共识。制造业AI项目失败，八成不是因为算法不行，而是因为需求模糊、数据不匹配、期望错位。
3.2 以“设备预测性维护”为例：从需求到试点的完整链路
拿预测性维护来完整走一遍流程，方便大家对照。假设目标设备是注塑车间的液压机，需求是“提前48小时预警液压系统故障”。
数据盘点阶段，需要检查液压机的PLC里采集了哪些信号，通常包括系统压力、油温、油位、泵的振动、电机电流等。频率是多少？很多老设备的PLC程序扫描周期在100毫秒以上，想分析高频振动特征是不现实的，那就要外接加速度传感器和高速采集卡。这一步就会引出改造预算和安装空间的问题。
历史数据方面，要翻维修记录，看过去一年液压系统出过哪些故障，当时传感器数据是否留存。如果历史数据只保留了每天的平均值，那训练数据的信息量就严重不足。这时候就得降低目标，先从“在线异常监测”开始做起，而不是“剩余寿命预测”。
模型搭建阶段，先做数据清洗，去掉停机时段、保养时段的无效数据，通过带通滤波去除工频干扰。特征工程上，提取压力波动方差、油温变化速率、泵电流频谱峰值等特征。异常检测模型用孤立森林或单类SVM，设定合理的告警阈值，用历史故障数据回顾验证阈值效果。
试点阶段，选择一台状态较差的设备先跑起来，运行三个月，记录模型告警与实际维护动作的对应关系。这个阶段最关键的是让设备维护团队参与进来，他们需要理解AI告警的价值和局限，否则误报两次就会被打入冷宫。所以每次告警都要做复盘：模型为什么报警、实际检查发现了什么、下次如何优化。把误报当模型优化素材，而不是项目失败的证据。
3.3 视觉检测项目的现场实施经验记录
视觉检测项目我做过不少，现场实施的血泪教训比算法设计多得多。第一个教训是光源和相机的固定方式。很多视觉项目在现场跑一段时间后误判率上升，排查来排查去发现是相机支架松动、光源角度偏移了。产线振动是元凶。所以需求清单里就必须包含机械固定方案和环境防护等级要求。
第二个教训是样本采集的节奏。很多项目一上来就想收集几万张缺陷图，结果拖了几个月数据还不够。实际上，先用几百张图把模型v1版本跑起来，部署到产线边做试运行，边收集边缘样本（模型不确定的样本），持续在迭代中扩充数据集，效果反而好得多。
第三个教训是缺陷样本的多样性问题。早期收集的缺陷样本往往集中在某几类高频缺陷上，长尾缺陷样本寥寥无几。处理方式是引入异常检测思路，用仅含正常样本的编码器-解码器结构做重建误差分析，专门捕获未知型缺陷，而不是只依赖分类模型。这种方式对长尾缺陷的召回效果出奇地好。
3.4 排程优化项目的数学建模与参数配置过程
再详细说说排程优化的建模过程。我在和企业计划员沟通时，会先用一个最简单的场景做基准：假设只有5台设备、20个订单、所有工件工艺路线相同，问计划员“当前你们最优排程的规则是什么”，通常会得到“交期紧的先做、设备空闲的优先派活”这类启发式规则。然后逐步加入约束：不同设备加工同一种工件的效率不同，那么启发式规则就需要加权；模具数量有限，转产有准备时间，问题复杂度立刻上来了；出现插单和急单，又要考虑动态重排策略。
建模时我倾向于用混合整数规划来做基础模型，因为MIP模型的可解释性强、求解器（如Gurobi、COPT）成熟，小规模问题可以得到全局最优。但MIP求解时间随规模增长极快，所以当订单规模超过一定程度，就会切换成两阶段法：先用启发式算法快速生成初始可行解，再用邻域搜索（比如自适应大邻域搜索）在时间窗口内优化解的质量。参数配置上，需要定好最大求解时间、邻域操作的选择概率、温度参数（如果用模拟退火）或种群大小和交叉变异概率（如果用遗传算法）。这些参数不是拍脑袋定的，而是用历史订单数据做回测，在仿真环境里比较不同参数组合下的总拖期时间和设备利用率，选出综合表现最优的一组。
4. 常见问题与排查技巧实录
4.1 需求侧常见的“假大空”问题与应对
制造业AI需求清单里，最容易出现的三类“假大空”需求：一是“全面智能化”型，什么都想上、没有优先级；二是“一步到位”型，希望一次性上线一个覆盖全工厂的AI中台；三是“凭空想象”型，需求描述很美好，但工厂现场根本不具备基础条件。
应对办法是建立需求分级评审机制。所有需求先过“收益-成本-风险”三维评分，收益看可量化价值，成本算数据条件、硬件投入、算法开发、组织变革的综合成本，风险评估技术成熟度和团队承接能力。评分结果出来后再排序，从最容易见效、风险最低的需求开始切入。制造业AI不是秀肌肉，是用最小的代价解决最痛的问题，稳妥的路径远比激进的故事有价值。
4.2 数据可用性差的技术排查思路
数据问题是制造业AI项目最大的拦路虎。经常遇到的情况是：数据接口不通、采集频率太低、数据缺失率过高、时间戳不对齐。排查思路我总结成一张表。
| 数据问题类型 | 常见现象 | 排查方法 | 解决方案示例 |
|---|---|---|---|
| 接口不通 | 数据拉取失败 | 检查网络访问权限、OPC UA Server配置、防火墙规则 | 增加网关设备，通过Modbus TCP中转 |
| 采集频率过低 | 信号变化捕获不到 | 统计信号变化率，确认部件动作周期 | 外接高频采集模块，缓存高频数据、按需上传 |
| 缺失率高 | 序列存在大量空值 | 检查传感器故障、采集程序异常中断记录 | 增加心跳监测与断点续传机制 |
| 时间戳不对齐 | 多源数据无法关联 | 核对各系统时钟同步，检查时区偏差 | 部署NTP统一校时，写入统一的基准时区 |
| 标签信息缺失 | 无法区分正常和故障 | 核对维修工单与设备档案 | 在CMMS中补录故障代码，建立设备树映射 |
这张表基本上覆盖了我遇到过的大部分数据问题。可以说，有一半的AI项目时间都消耗在解决这些“不性感”的问题上，它们不属于研究成果，但却是走向落地绕不开的路。
4.3 模型上线后效果衰减的监测与处理
制造业现场环境时刻在变，模型上线后性能衰减是必然的。原材料批次波动、环境温湿度变化、设备磨损都会让输入数据分布发生漂移。我见过很多项目上线时效果惊艳，两三个月后指标悄悄下滑，最后被产线弃用。
应对方式是在需求清单阶段就规划好模型监控方案。至少要做到三个层面的监测：数据分布监测，定期对比当前输入与训练集的分布差异，可以用PSI（群体稳定性指数）量化；推理结果监测，跟踪模型预测结果与真实结果的一致性，比如检测缺陷与人工复判的吻合率；业务指标监测，把模型效果与最终业务指标（良率、停机时间）关联起来。发现指标异常后，及时触发模型重训练流程。重训练要形成闭环，样本回流、标注、版本管理、灰度发布，一个都不能少。
这里特别想说一点：制造业AI项目的成功，不在于模型的算法有多新潮，而在于有没有一套持续运营的机制。模型漂移监测、重训练流程、版本管理、效果评估，这些运营工作虽然枯燥，却决定了AI应用能不能长期活下去。
4.4 团队协作中的沟通错位与流程设计
最后一个常见问题来自人与人的协作。IT团队、OT团队、算法团队、业务部门，各方语言体系完全不同，经常出现“鸡同鸭讲”的场面。IT关心网络安全和数据接口，OT关心设备稳定和生产节拍，算法团队关心数据质量和模型指标，业务部门关心KPI和领导视察汇报。这种多目标并存的局面，需要一套清晰的协作机制。
项目启动阶段建立跨职能联合团队，指定业务负责人和IT负责人双牵头。需求梳理会一定邀请现场工程师和一线操作员参加，他们掌握的细节是文档里永远找不到的。每周的例会不是各汇报各的，而是围绕试点目标过指标、解决问题。关键节点要有统一的评审文档，把每个阶段的目标、交付物、验收标准写得清清楚楚。建立一个共享的“问题与决策日志”，所有关键决策都记录下来，避免后期扯皮。管理预期、管理冲突、对齐语言，这不仅是项目经理的工作，更是每一个参与者的责任。
结尾
整理这份需求清单的过程，让我越发觉得制造业AI最稀缺的不是炫技的算法，而是把复杂问题拆解成可执行方案的工程能力。从视觉检测的光学方案设计，到预测性维护的数据可用性审计，再到排程优化的约束建模，每一步都在考验团队对制造场景的理解深度。我个人的体会是，千万别被“AI”两个字唬住，踏踏实实从数据盘点开始，从最小可行项目切入，比任何宏大叙事都管用。最后再分享一个小技巧：需求清单里每一条需求，都强制附加一个“如果只做一件事，这件事是什么”的回答。这个问题的答案，往往才是客户真正需要的东西，剩下的都是围绕它的锦上添花。制造业AI这条路没有捷径，但需求梳理清楚，至少能让每一步都踩在实地上。
