1. 30%和4%到底在数什么口径不同差距才吓人先泼一盆冷水。制造业AI普及率超过30%这个说法我在不同场合至少听过四个版本每个版本背后数的东西都不一样。有的口径是调研样本里至少有一个AI相关项目在试点的企业占比有的口径是用过AI工具包括办公类的员工比例还有的把买了个视觉相机、上了个带算法功能的软件都算进去了。而只有4%跑通闭环里的4%数的却是另一回事模型输出能直接进到生产执行环节、有反馈数据稳定回流、能拿出经得起财务核对的指标改善、并且连续运行超过一个季度没停。这两个数字放在一起看好像很惊悚其实它们本来就不在一个坐标系里。一个数的是碰过一个数的是跑通。就像健身房办卡率和使用率从来不是一回事。1.1 一个更贴近现场的拆分方式我更愿意把工厂里的AI状态拆成四层这样看问题会清楚很多。层级典型特征大致占比感受观望层知道AI但没立项或者只在PPT里数量最大试点层有POC有Demo跑在离线数据上相当多上线层模型进了产线但靠人工搬运结果明显变少闭环层输入-决策-执行-回流全自动有KPI背书最少真正的断崖不在观望到试点而在上线到闭环。很多项目卡在第三层看着像成功了发布会也开了奖也报了但模型每天跑出来的结果得靠一个工程师手动导出Excel再手动填进工艺参数表。这种状态我给它起了个名字叫人肉API。1.2 三种我在现场见过的伪闭环第一种是展示型闭环。大屏上数据在跳报警在闪看起来很智能但大屏和产线控制系统之间没有任何写权限通道。模型说这个批次温度要下调2度操作工看一眼凭经验决定调不调。这本质上是个高级看板。第二种是离线型闭环。模型每天凌晨跑一次生成当天的工艺建议单早上班前会发下去。反馈呢下个月的质量报表出来了有人拿去和模型建议对比一下。这个回路的时间常数是月而产线的扰动时间常数是分钟到小时两者根本对不上谈不上闭环控制。第三种是指标型闭环。指标确实变好了但没人能说清是不是AI带来的。可能是同期换了模具、换了原料批次、也可能是操作工知道在做试点所以格外上心霍桑效应。这种闭环最危险因为它会在半年后被人翻旧账然后整个AI项目组一起背锅。1.3 我给闭环划的最小定义跟团队内部对齐的时候我一般用四条硬标准来判断一个场景算不算闭环输入端模型所需的数据由系统自动采集采集链路有监控断了会告警不需要人每天去拔U盘。决策端模型输出是结构化的、带置信度或不确定度的、有明确取值范围约束的不是一段建议关注的自然语言。执行端输出能通过标准协议OPC UA、Modbus TCP、MQTT或者直接的数据库写入送到执行机构或控制系统且有人工确认或自动执行两种明确模式。回流端执行后的结果质量检测值、能耗、节拍、设备状态能以同样的自动化程度回到数据层进到下一次训练或评估里。四条缺一条我就把它叫半闭环在项目排期上单独标色绝不让它混进已闭环的统计里。这个习惯看着有点轴但能省掉后面无数次扯皮。2. 断点扫描一条AI闭环在工厂里的五道关卡闭环断在哪里这个问题不能靠开会讨论得靠沿着数据流走一遍。我一般的做法是拿一张A3纸从左到右画一条链路传感器→采集网关→数据平台→特征/模型→决策输出→执行→结果采集→回流每一个箭头处标三个东西谁负责、用什么协议、断了怎么办。走完一遍断点基本自己就冒出来了。下面这五道关卡是我在十几个项目里反复遇到的。2.1 第一道数据拿得到但拿不齐数量上够了质量上不够。典型表现是采样频率对不上——振动传感器1秒采一次温度是30秒一次质量检测报告是按批次出的一天两批。三条时间轴要拼到一起中间得做重采样、时间对齐、批号映射。这一步没有技术难度但极其耗人而且一旦设备换了、网关重启了、时钟漂移了对齐关系就悄悄失效。更烦的是时钟。我见过一个项目边缘网关和数据平台差了两分多钟模型一直在用未来的数据做过去的预测离线指标看着特别好上线之后一塌糊涂。后来加的规则很土但很有效所有设备必须走同一套时间同步采集端必须打上两个时间戳——采集时刻和入库时刻差值超过阈值的记录直接标记为可疑。# 时间对齐的极简示例以质量检测批次为锚点向前回溯一段窗口 import pandas as pd df_sensor df_sensor.set_index(ts).sort_index() df_quality df_quality.set_index(batch_ts).sort_index() # 对每个质量批次取它之前 15 分钟到之前 1 分钟的传感器数据做聚合 df_sensor[batch_ts] pd.NaT idx df_sensor.index.searchsorted(df_quality.index) # 实际项目里用 merge_asof 更稳这里只说思路 # 1) 明确锚点2) 明确回溯窗口3) 明确聚合方式4) 记录对齐后的覆盖率覆盖率这个指标特别值得盯。如果一个批次里只有60%的传感器数据成功对齐那这个样本进不进训练集我的经验是设一条线比如覆盖率低于85%的样本直接丢掉宁可样本少不要样本脏。2.2 第二道模型算得准但输出没人接这是最典型的组织性断点。AI团队交付一个模型输出是JSON设备团队只认PLC里的寄存器中间需要一个胶水层而这个胶水层不在任何人的KPI里。解决方式其实不复杂关键是提前定模型输出的物理含义是什么、单位是什么、取值范围是什么、超范围怎么处理、写哪个地址、写之前要不要人工确认。这些东西必须在模型开发阶段就定死而不是等模型训好了再谈对接。我一般要求AI团队在交付模型的同时交一份《输出接口约定》包含字段名、类型、单位、量程、默认值、异常值、写入频率、回滚条件。这份东西看着枯燥但它决定了一个模型是能上线还是只能躺在服务器里。2.3 第三道执行了但没有反馈标签制造业的数据有个残酷现实标签比特征贵得多。特征随手就有标签要靠质检、要靠停机记录、要靠人工判定。你做了个预测性维护模型预测某台设备三天内会出故障结果三天内它没坏——这算模型错了还是运气好如果一直没坏你连负样本都拿不到。所以闭环设计里必须包含标签获取机制而且这个机制要尽可能自动化。视觉质检相对幸运检测结果天然就是标签工艺参数优化就麻烦得靠抽检、靠下游工序的反馈、靠终检数据。我的做法是尽量把闭环挂在一个必然会产生测量值的环节上比如挂到终检、挂到能耗表、挂到节拍统计。挂不到测量值的场景就先别做闭环做辅助决策更合适。2.4 第四道指标改善了算不清归因归因问题的核心是没有对照组。整条线全上了AI指标变好了你怎么知道不是别的原因工业场景做A/B测试确实难但有几个变通办法影子模式模型在后台跑不执行先记录它的建议和实际执行的差异跑一两个月看如果按模型说的做会怎样。时间分段对照同一条线前两周人工操作后两周AI辅助中间留一段过渡期不算数。当然前提是订单结构、原料批次尽量可比。工位对照有多条同类产线或同型号设备的一条上一条不上这个最干净但需要产线配置允许。历史回放用过去半年的数据做离线回放估算模型建议下的指标分布作为预期值的参考区间。我更倾向影子模式起步。它风险最低还能顺便攒一批模型和人对同一场景判断差异的数据这些数据后面调阈值、定人工确认规则时极有用。2.5 第五道人走了闭环就断了这条最容易被忽略但杀伤力最大。项目的核心工程师离职脚本没人维护当初手动搭的数据管道没人敢动模型版本、特征版本、配置文件散在几台机器上。我的应对是三条土规矩所有管道脚本进版本库包括那些一次性的清洗脚本所有配置外置不写在代码里每季度做一次交接演练让不熟悉这个项目的人按文档从零跑一遍流程。跑不通的地方就是文档该补的地方。3. 数据质量闭环便宜、烦人但决定生死AI项目里模型架构能带来的差异往往远小于数据质量带来的差异。我做过一个粗略的复盘同一批数据只做了时间对齐和异常值处理某分类任务的指标就跳了一截比换模型结构带来的提升大得多。问题是数据质量这件事没有发布会可以开没有论文可以发所以在很多组织里排不到优先级。3.1 制造业数据的三个天生毛病非平稳。设备会磨损原料会换批次环境温湿度随季节变操作工也会换。今天训好的模型三个月后分布就变了。互联网场景里的分布漂移通常是缓慢的工厂里可能一次换料就跳变。样本少且不平衡。故障样本天然稀少一年的故障记录可能就几十条。你没法靠堆数据解决只能靠机理知识、靠数据增强、靠异常检测这类不吃标签的方法。多源异构且语义不统一。同一个温度在PLC里是一个点位在MES里是一个字段在质检报告里是一个手填数字单位可能还有摄氏度、华氏度、开尔文的区别。不做语义层统一后面所有分析都是空中楼阁。3.2 落地四步对齐、清洗、校验、监控我的做法基本固定成这四步每一步都有明确产出物。第一步对齐产出是宽表覆盖率报告。宽表按统一时间轴或批次轴组织覆盖率报告记录每个字段的对齐成功率低于阈值要标红。第二步清洗产出是清洗规则清单影响记录。规则包括量程越界、死值连续N个点不变、尖峰、缺失填充策略。关键是要记录每条规则筛掉了多少数据否则你可能在不知不觉中把真实工况滤掉了。我就吃过这个亏设了个振动幅值上限结果把真正的异常工况全滤掉了模型学了个永远正常。第三步校验产出是数据契约。字段上下限、类型、允许为空、变化率限制全部写成可执行的校验规则进管道自动跑。数据契约一旦破坏管道直接拒绝出数并告警而不是默默降级。第四步监控产出是数据质量看板漂移告警。输入分布漂移和输出分布漂移都要盯前者用简单的统计量均值、方差、分位数配合滑动窗口就够后者要看模型输出的分布有没有整体偏移。3.3 一个注塑车间的具体做法注塑这个场景特别典型锁模力、注射速度、保压压力、料筒各段温度、模温、冷却时间参数一大堆最后的质量指标是尺寸和外观。我参与过的一个做法是这样的。把每模作为一个样本模次号作为主键。传感器数据按模次聚合取每段的均值、峰值、标准差形成几十维特征。质量端靠抽检每两小时抽几模测关键尺寸。这样特征是全量的标签是稀疏的——大概只有5%到10%的模次有标签。稀疏标签怎么办两条路并行一条是用有标签的样本训一个轻量模型做局部精确预测另一条是用无标签样本做异常检测找出和正常模次明显不同的批次把这些批次优先送去抽检。第二条路其实更重要因为它把抽检从随机抽变成了按风险抽同样的检测人力命中率能高不少。反馈回路就这样建起来了模型挑出高风险模次→质量端优先检这些模次→检测结果回流→模型更新。整个循环的周期是天级别不是月级别这就是能跑起来的关键。提示稀疏标签场景下主动挑样本去检测往往比提高模型精度带来的实际收益更大。先优化采样策略再优化模型。4. AI 与 PID、PLC 共处控制回路里的分层设计一提到闭环很多人的第一反应是做控制回路。但工厂里的底层控制回路过去几十年跑的都是PID稳、快、可解释、工程师都会调。AI要进去绝大多数情况下不是替代而是往上站一层。4.1 为什么实时回路不适合直接上大模型用一个几百毫秒级响应的回路去跑一个推理耗时不确定的模型工程上是站不住的。推理时间抖动、模型更新导致行为突变、异常输入下输出不可预期这些在离线环境无所谓在实时回路里就是事故。而且底层回路对可解释性的要求很高出问题要能在几分钟内定位原因一个几十层的网络做不到这一点。所以我的基本判断是采样周期在秒级以下、直接驱动执行机构、失效会造成安全或质量事故的回路继续交给PID和PLC。这不是保守是分工。4.2 分层架构慢环给AI快环给PID一个能落地的结构通常是三层底层毫秒到秒级PID、顺序控制、联锁全部在PLC或专用控制器里AI不碰。中层分钟到小时级设定值优化、参数推荐、工况识别。AI在这一层输出的是目标值比如把某段温度的目标从设定值A调到设定值B具体怎么跟、怎么稳还是PID的事。上层天到周级排产、能耗优化、维护计划、质量趋势分析。这一层时间常数大容错高是AI最能发挥的地方。这个分层的好处是AI出问题的时候底层依然安全。最坏情况是设定值不够优而不是设备失控。4.3 安全边界、降级与影子模式设定值优化必须带硬约束。做法是给每个可调参数定一个AI可调区间这个区间比工艺允许的极限区间更窄。比如某段温度工艺允许180到220度AI可调区间设成195到210度。超出的建议直接裁剪并记录一次越界事件越界频繁就说明模型该重训了。降级策略也要提前写清楚模型服务超时怎么办输入数据缺失怎么办输出置信度低于阈值怎么办我的默认策略是——任何一种异常都回落到上一次的有效设定值或者人工经验值同时告警。绝不出现模型不确定所以随便给一个的情况。4.4 一组可参考的参数下面是某类工艺参数优化场景里我用过的一组配置供参考实际必须按设备和工艺重新标定。项目取值说明AI 决策周期5 分钟远慢于底层回路留出人工确认时间参数单次调整幅度不超过量程的 3%防止大幅跳变最小调整间隔30 分钟避免来回震荡影子模式时长不少于 4 周覆盖不同班次和原料批次自动执行阈值置信度 ≥ 0.85 且不越界其余转人工确认回滚触发连续 3 次调整后指标恶化自动回落到基准值震荡这件事值得多说一句。AI优化和PID叠加在一起如果节奏没拉开很容易形成两个控制器互相打架AI调设定值PID去跟跟的过程中AI又看到偏差调了一次。解决办法就是把AI的决策周期拉长到显著大于底层回路的整定时间中间加变化率限制。这一点和经典控制里的串级结构思路是一致的。5. AI Agent 和代码生成在制造业里到底能干什么这两年Agent和代码生成很热工厂里的期待值也很高。我的看法是它们在制造业里确实有价值但价值的位置和大家想象的不太一样——不在控制回路里而在工程效率和知识管理上。5.1 PLC 代码生成省的是谁的时间一个典型的PLC程序大量内容是重复的点位映射、报警逻辑、手自动切换、联锁条件、HMI变量绑定。这些逻辑结构高度模板化非常适合让AI生成初稿。但要注意AI生成的PLC代码只能作为初稿。原因很简单它不知道你的安全规范、不知道现场的点位命名习惯、不知道这台设备的联锁优先级。我的实际流程是先整理出模板和命名规范让AI按模板生成骨架然后由电气工程师逐段审核重点看联锁和安全相关的部分。效率提升主要是这部分把原来一天的工作压到两三个小时剩下的时间花在审核和现场调试上。审核时间不能省这是底线。5.2 Agent 适合接的任务清单按我实际用下来的体感Agent类应用在工厂里比较能落地的任务有这么几类设备手册、工艺文件、历史工单的检索与问答帮新人快速上手故障代码的解释和排查步骤推荐作为一线人员的辅助报表汇总与异常摘要生成把多个系统的数据整合成一段话日志分析从大量运行日志里提取异常模式测试用例生成尤其是接口测试和回归测试。反过来这几类我坚决不碰实时控制、安全联锁、涉及人身安全的判断、最终质量判定。这些场景要么延迟要求太高要么责任无法界定。5.3 提示词的写法差异制造业场景的提示词和通用场景有个明显区别必须带上下文约束和历史对照。举个例子让AI分析一段设备日志你只说分析这段日志里的异常它会给你一大堆泛泛而谈。但如果补上这几条效果立刻不一样这是哪台设备、什么工艺段、正常运行时的典型值是多少、最近一次保养是什么时候、上次同类异常是怎么处理的。我的提示词模板大致是四段角色与任务、设备与工艺背景、已知的历史参照、输出格式要求。最后一段尤其重要输出必须是结构化的比如疑似原因、置信程度、建议排查步骤、需要哪些额外数据这样才方便后续做自动化处理。注意把工艺参数、设备型号、内部工单这些内容喂给外部服务之前先确认数据管理要求。涉及核心工艺参数的场景优先考虑在本地或私有环境里部署模型。5.4 绝对不能放的位置一句话总结Agent 不能进实时控制回路不能进安全联锁不能作为最终质量判定者。它可以做建议者、助手、加速器不能做决策的最终承担者。这个边界一旦模糊出一次事故整个工厂的AI推进都会倒退两年。6. 云、边、本地怎么选三个约束决定部署形态部署形态这个问题很多团队一开始就想错了方向先选技术方案再去找场景。正确的顺序是反过来的先看场景的三个约束形态自己就出来了。6.1 延迟约束把延迟拆成三段采集到推理、推理耗时、推理到执行。任何一段超了闭环就不成立。场景类型允许端到端延迟一般部署形态实时视觉检测几十到几百毫秒边缘设备就近部署工艺参数优化分钟级边缘或厂内服务器质量趋势分析小时到天级厂内服务器或云端排产与能耗优化天到周级云端或私有集群一个常见误区是只看推理耗时忽略网络往返和数据准备。实际的端到端延迟里数据准备往往占大头这一块在做架构设计时就得算进去。6.2 数据与网络约束有些数据不方便出园区有些数据量大到传输成本不划算比如高速相机、振动高频采样。这种情况下边缘侧先做特征提取和降采样只把特征和事件传走原始数据留在本地。这个思路能同时解决带宽和合规两个问题。另外工厂网络经常是分区的办公网、生产网、设备网。跨区通信要经过网关和审批这一点在方案设计阶段就要摸清不要等到部署时才发现连不上。6.3 运维成本约束边缘设备最大的隐性成本是运维。几十台设备散在不同车间固件升级、模型更新、故障排查都是人力。我的经验是边缘设备数量控制在能手动管理的范围内宁可单台设备算力配高一点、承载多个场景也不要为了省钱铺一堆低配盒子。设备数量翻倍运维成本往往不止翻倍。模型更新也一样必须有统一的推送和回滚机制。手动登录每台设备换模型文件的做法只适合项目验证期。6.4 选型对照表维度边缘部署厂内服务器云端延迟最低中等依赖链路数据可控性最高高需评估算力弹性差中等最好运维复杂度高设备分散中低适合场景实时检测、高频采集多场景集中推理训练、大模型、非实时分析我的常规组合是训练放厂内服务器或云端推理分两层——实时相关的下到边缘非实时的留在厂内服务器。模型在训练侧训好经过验证后按版本推送到边缘每一步都有记录。7. 让闭环活过三个月的推进节奏前面讲的都是技术层面的断点但真正让项目死在第三个月的往往是节奏和组织。这部分我说几个自己用下来比较靠谱的做法。7.1 选场景先选能算清钱的场景选择有个很实用的筛选标准这个场景的收益能不能在财务口径上说清楚。比如视觉质检省了几个质检工、漏检率降了多少、返工成本省了多少这些能直接算。比如能耗优化一度电多少钱降了几个百分点也能算。相比之下提升整体智能化水平这种目标半年后没人能回答做得怎么样。我一般按三个维度给候选场景打分收益可量化程度、数据可得性、闭环周期长度。闭环周期最好在天级别超过一个月的场景项目还没看到效果就被别的事情挤掉了。7.2 选指标一个工位一个指标不要一上来就盯着OEE这种综合性指标。OEE受太多因素影响你的AI项目做完了OEE没动你解释不清。正确的做法是选一个能被单一环节显著影响的指标某道工序的尺寸合格率、某台设备的单位能耗、某个工位的平均处理时间。指标越窄归因越清楚。等这个指标稳住三个月再去谈更大范围的收益。同时要提前定成功线和止损线。成功线比如指标提升5%止损线比如连续六周没有改善趋势就停下来复盘。没有止损线的项目会一直耗着耗到最后没人愿意承认失败。7.3 组织谁对闭环负责这是我见过最多的失败原因AI团队和设备团队之间没有人对整条闭环负责。模型准不准是AI团队的事设备稳不稳是设备团队的事中间那段胶水层谁都不管。解决办法是设一个明确的负责人他不对模型指标负责也不对设备可用率负责只对闭环能不能稳定运行负责。这个角色需要的能力比较特殊既要懂数据和模型的基本边界又要懂现场工艺和设备逻辑还得能推动两个团队配合。通常是从现场工艺工程师里选再补一些数据方面的训练比从纯算法背景的人里选更容易成功。配套的是考核方式。如果AI团队的考核只挂模型精度他们就会优化精度不管上线如果设备团队的考核只挂设备可用率他们就会拒绝任何可能带来波动的改动。考核指向哪里行为就走向哪里。7.4 我踩过的几个坑第一个坑是一上来就追求全自动。有个项目我坚持要取消人工确认环节结果第一个月就出了两次误调虽然没造成损失但操作工的信任度直接掉到底。后来改回高置信度自动、低置信度人工确认跑了三个月才逐步放宽。信任是靠一次次的正确积累起来的比任何技术指标都重要。第二个坑是忽略了班次差异。模型在一个班次上表现很好换到夜班就变差。排查很久才发现夜班的操作习惯、环境温度、甚至原料上料方式都和白天不同。后来在特征里加了班次标识并且分班次评估指标问题才清晰。第三个坑是数据管道没有监控。某个数据源悄悄断了三天模型还在跑用的全是填充值输出自然一塌糊涂但因为没有监控没人发现。现在我的规矩是任何进模型的数据源必须有新鲜度检查超时直接停推理并告警宁可不出结果也不出错结果。第四个坑是过早引入复杂模型。项目初期用了深度模型调参调了两周效果还不如一个逻辑回归加几个机理特征。后来想明白了在样本量小、机理清楚的工业场景里简单模型加好特征往往更稳、更好解释、更容易维护。等数据量真的上来了再考虑复杂模型。关于闭环这件事我现在的基本判断是技术上的坑基本都有成熟解法难的是让一条链路在真实的生产环境中稳定运行足够久。30%到4%的差距大部分不在算法里在数据管道、在接口约定、在责任划分、在那个人人都觉得不重要但一旦缺了就全盘停摆的中间环节上。所以每次启动新场景我都会先问一句这条闭环跑起来之后谁来守着它跑满一年这个问题答不上来我就先不急着开工。