工厂里真正值得用 AI 做自动化的是哪些事

决定一个工厂 AI 项目成败的，大部分不是建模。而是说清楚你面对的是哪一类问题，确认你的执行层数据撑不撑得住，以及设计好模型判断错了以后会发生什么。

规则、机器学习、优化求解与大语言模型：什么问题该用什么

规则和统计排在最前面，它们得到的尊重远远不够。如果一条工程师写得出来的规则就能拿到大部分收益，那么任何模型该对标的就是这条规则，而不是对标“什么都不做”。

机器学习真正用得上的场合，是输入和结果之间确实存在关系、但谁也写不出来：几十个工艺变量相互作用，一种缺陷同时取决于物料批次、环境湿度和型腔位置。它只认得见过的工况，对于从未见过的工况，它说的话没有任何价值。

优化求解是另一门学问，却经常被贴上 AI 的标签。有限产能排程、以最小化换型为目标的排序、把有资质的操作工分配到岗位上——这些是带目标函数的约束问题。它们不需要带标签的样本，但需要真实的工序工时和约束条件，而这些通常得实测，不能靠拍脑袋。就计划排程而言，能把你真实的工装共用和干燥等待约束表达出来的求解器，几乎永远是正确的工具，因为排程是约束问题，不是预测问题。

大语言模型是最新来的一位，适用范围很具体。它适合文档和对话形态的工作：读一封来询、拟一份结构化的回复；把一长段维修履历浓缩成技术员走到设备前之前能看完的东西；回答某份作业指导书里关于某个调机步骤是怎么写的。它们不是测量仪器：让它从振动数据里预测轴承失效，等于拿锤子去拧螺丝。

工厂里的 AI 项目到底需要什么数据

模型需要的样本，是把一个工况和一个结果配成对，并且带有足够的上下文来区分不同工况：一段信号或一组条件，挂在某张工单、某台设备、某套工装、某个物料批次、某个操作工上，再加一个真实的时间戳。时间戳的分量比大多数人想的重。如果报工是等到班末补录的，那这个班次里所有事件的时间都只是个大概，凡是依赖先后顺序或持续时长的模型，学到的都是录入习惯，不是工艺。

结果这一侧通常更糟。预测性维护需要把故障作为故障记录下来，带原因、带日期，而不是一条原因栏空着的非计划停机。质量预测需要废品按工序、按导致它的缺陷类别报废，而不是汇总成一个月度数字。需求预测需要的是没有被库存调整悄悄改写过的消耗历史。多数工厂里，输入躺在历史数据库中，结果躺在一本维修笔记或某个人的 Excel 里。

检验标准不是历史数据库里存了多少 GB，而是：针对一条产线、一个产品族，你能不能拉出一年的数据，每一行都同时带着工况和结果，并且有两位懂工艺的人认可这些行是真的。如果这份数据提取需要一周的人工对账，那项目的主体就不是模型，而是记录本身。这正是 MES 和历史数据库的数据质量成为硬约束的原因，再高明的建模也补不回当初根本没采到的东西。

需求与消耗预测：回本路径最短的一块

需求预测通常是离钱最近的，因为它的对照组明显很弱：多数工厂拿去年的数加一个百分比，或者向销售要一个数，而那个数其实是任务目标。用订单历史、季节性、客户结构、在谈商机和日历效应建的模型，在需求规律、重复出现的物料上能打赢这种做法。而在间断型和项目驱动的物料上——它们往往占了大部分料号、只占一小部分产量——通常打不赢，朴素法或 Croston 类基线很难被超越。诚实的做法是先对料号做分段，把这些物料交给备货策略和人的判断。

价值不体现在预测本身，而体现在下游：安全库存随之调整，长提前期物料的采购时点改变，那些把排程搅乱的紧急换型变少了。PPT 上的预测准确率不是收益，库存天数和加急次数才是。

预测性维护：只做失效模式真的可预测的那部分

这里的一切都取决于失效是不是渐进发展、并且在你测得到的量上留下特征。轴承劣化、不平衡、不对中、滤芯或冷却回路的渐进堵塞、液压压力漂移、同一道工序上电机电流一点点爬升——这些在几周到几个月里发展，偶尔只有几个小时，而那通常已经晚到不值得上传感器了，并且会反映在振动、电流、温度或压力上。模型能看出来；很多时候，一条选得好的阈值同样能看出来，所以在这里跟简单统计做对照才格外重要。

控制板卡突然死掉、一块不合格刀片崩断刀具、操作失误造成的损伤——这些实际上是瞬时发生的，趋势根本不存在，任何模型都预测不了。

第二个条件是：预警必须换来你用得上的时间。如果备件提前期很长、产线周末之前又停不下来，那么真正能回本的投资是备件策略，不是模型。先把可干预窗口算清楚，再谈传感器预算。

质量预测与废品削减

质量往往是钱最多的地方，也是对数据要求最苛刻的地方。理想的形态是：根据生产过程中的工况，预测哪些零件或哪些批次有风险，让人在废品产生之前就去调整，而不是到终检时才发现。

它成立的前提，是工艺的采集分辨率对得上你想预测的对象，并且废品带着真实的原因代码挂在工序上。它失效的方式很安静：当废品是在工单结束时按整张工单报的，模型就无法分辨是哪一段工况造成了哪一次失效。

有一步毫不起眼的工作，在任何模型见效之前就先把自己赚回来了：在设备端、在当下，从一份操作工认得出来的短原因清单里采集废品原因。很多提出质量预测需求的工厂，仅凭这份数据就会发现少数几个原因占了大部分损失，然后用一次工程变更把最大的那个关掉。这是好结果，不是失败的项目。

用 AI 做生产排程：这是优化问题，不是预测问题

如果计划每周都被打乱，原因很少是“不够聪明”，通常是约束不够。真正能改变它的，是一个能遵守共用工装、换型族、操作工资质、固化时间以及你打算守住的维保窗口的排程器。

学习在这里有一个很窄但确实存在的用武之地：工序工时。建立在多年没人重测过的标准工时之上的排程，精确地用着错误的数字，而通过 MES 采集到的实际工时可以更新排程器的计算依据。评判一个排程方案，要看它能表达哪些约束，以及出状况时重排有多快；一份要跑一整夜才能重新生成的计划，第二天早会上就会被人工推翻。

能耗与工艺信号上的异常检测

异常检测学习“正常长什么样”，再对偏离报警。它适合连续信号，适合那种正常数据很多、带标签故障很少的场合：单周期能耗、压缩空气消耗、冷水机组性能、状态良好时形态稳定的某个工艺信号。

它的长处是能对谁都没预料到的情况做出反应。它的短处是只告诉你“不寻常”，从不告诉你哪里不对，而一个不断收到无法解释的报警的工厂，会学会无视它们。真正要设计的不是检测器，而是流向：哪条报警发给谁，第一步先查什么，处理结果如何记录，好让下一次同样形态的报警带着历史一起送到。

销售与客户运营中的 AI：工作本身是文档形态的

制造企业的商务侧靠文档和对话运转：询价、规格、报价、订单确认、交期问询、投诉。这里才是大语言模型真正合适的地方，因为工作内容就是阅读、抽取、起草和摘要。

具体一点：把一封来询解析成零件、数量、要求交期和特殊要求，同时把历史报价调出来放在旁边。把一整串邮件浓缩成一条 CRM 记录，写明做出的承诺和下一步动作。

有两条规则能让这件事不出事。模型起草、由人发送，至少在这条流程的错误率被摸清之前如此。凡是事实性的内容——价格、提前期、库存、承诺交期——都取自业务系统这个唯一数据源，而不是取自模型；模型应该是在引用一个查出来的值，绝不能自己生成。会编出一个提前期的 CRM 自动化，比没有自动化更糟，因为它是在替公司做承诺。

买任何东西之前，先把收益算出来

用你工厂已经在统计的口径说清楚损失是什么：相关产品族每月的废品成本；瓶颈设备的非计划停机小时数，乘以那里一小时值多少边际贡献（不是机时费率）；加急运费；被预测能盘活的那些物料占用的库存；每周花在系统之间重复录入上的工时。

然后保守地估计，这个应用大概能覆盖其中多大一部分。预测性维护不消灭停机，它最多把它覆盖到的那些失效模式下的一部分非计划停机变成计划内停机。质量模型不消灭废品，它缩短的是从工艺跑偏到有人发现之间的时间。

如果这个诚实的数字，对上一个按你真正会规划的生命周期计算的总成本（含集成，含将来运维它的人），仍然过不了财务部门对同等金额的其他投资所设的门槛，那这个项目就是一次科学实验。做实验是可以的，但就该按实验的方式立项和评判。

集成真正的成本在哪里

模型通常是便宜的那部分；成本藏在接缝里。首先是把信号从设备上取下来，而真实工厂是一个混杂的设备群：有的资产讲 OPC UA，有的是 Modbus 或某种串口协议，有的只给一个干接点，还有些封闭控制器需要在主轴、液压回路或电源线上加装传感器。然后，输出必须落到某个会引发动作的地方：操作工本来就在看的一块画面、维修里开出的一张工单、喂给排程器的一条约束、质量里下达的一次扣留。

再往后是没人纳入范围的主数据对账。系统之间相差一个后缀的料号、对不上的计量单位、两处各自维护的物料清单（BOM）、产线重排之后就变了的设备编号。这些没有一件是难的，但每一件都比软件本身更花时间。一份只给模型报价、把接缝留作“集成部分另议”的方案，算不上一个报价。

谁来运维这个模型，以及它判断错了会怎样

每一个上线的模型都需要一个有名有姓的责任人，而采购时该问的问题是：在你们组织里，这个人是谁。这个人需要知道它是用什么数据训练的、哪些工况在训练范围之外、它为什么给出这个输出，以及如何在不停产的前提下把它从回路里摘出来。一个不再给出答案的模型，必须回退到它上线之前控制这道工艺的东西——抽样方案、阈值、操作工自检——而不是回退到一道敞开的闸门或一条卡死的产线。上线之前就把这两者中选哪个定下来。

可解释性在车间里不是哲学问题，而是落地的必要条件。一条说明了是哪个信号在变、变了多少、相对哪个基线的建议，才会有人照着做。一个没有依据的分数会被人工推翻，而一旦推翻成了常态，这套系统就只是装饰。

报警过多比漏报更快地摧毁信任，道理和检测站误判过杀是一样的：误报立刻被所有人看见，漏报要等到故障真的发生才显形。报警频率要按车间实际能分配的注意力来设计，把不确定的中间地带交给人，而不是交给产线。

治理、漂移，以及没人做预算的运维负担

模型是你的工艺在训练那一刻的一张快照，而你的工艺在动：换了供应商、工装翻修、零件改版、产线重排、产品结构变化、传感器换成了略有差异的另一款。每一项都可能让输入偏移到足以使昨天的模型今天悄悄出错，而它的失效方式不是一条报错信息，而是建议一天比一天差。

要监控输入，不只监控输出，因为输入漂移会先于结果劣化显现出来。留一套真实案例的留出测试集，把临界案例也包含进去，这样新模型才能和现行模型做诚实的对比。给模型做版本管理，记录哪个版本产生了哪条建议；重新训练之后，昨天的输出来自的是另一位裁判。

还要为持续投入做预算。生产中的模型是一项需要维护的资产，它更接近工艺设备，而不是一份买回来的报表。如果没人有时间做再训练、审阅报警、检查数据是否还在按时到位，它就会一直劣化到没人再用。

一个现实的首个项目，以及它的验收标准

挑一条产线或一个产品族上的一项有名有姓的损失，用一句带数字的话说出来：我们在这道工序上废品是多少、我们在这台设备上损失了多少瓶颈工时、我们因为预测不了这个产品族而多压了多少库存。如果项目没法这么表述，它就还没准备好。

买任何东西之前，先把数据提取做掉。一年、一条线，工况和结果落在同一行里，两位懂工艺的人确认这些行是真的。然后拿它和简单方案做对照：一条阈值、一张控制图，或者现任计划员的判断。

上线之前，用工厂自己的口径写好验收标准，而且要成对地写，把取舍摆到明面上。预测性维护：覆盖的失效模式中，抓住其中约定的若干种并至少提前一周预警，同时每月误报不超过一个上限。需求预测：建模产品族的库存天数下降到约定幅度，且缺货不增加。质量：目标工序的废品率相对去年同期下降到约定幅度，同时把期间做过的工艺变更一并记录在案。

把责任人、失效时的行为和再训练周期写进同一份文件，并定一个评审日期，且诚实地保留“就此停止”这个选项。一个基于证据、最终决定不再扩大的首个项目，是成功的。一个变成长期演示的试点，不是。

Meta Smart Factory 在其中的位置

Meta Smart Factory 是模块化的，这一点在这里很关键，因为 AI 与机器学习模块是架在执行层之上，而不是摆在它旁边。MES 提供事件和上下文，IIoT 连接与 OPC UA 提供设备信号，质量模块提供带原因的废品，维护模块提供故障履历，而当答案是一份排程而不是一个预测时，APS 负责消费这些输出。

你可以先用一个模块对付一项有名有姓的约束，等它真正用起来之后再加下一个。任何平台都去不掉的，是难的那部分：就数字的含义达成一致，把原因在设备端采集起来，以及决定模型出错时由谁负责。针对一家具体工厂把这个顺序谈清楚，是比看演示更有价值的第一次对话，因为演示永远都会成功。