制造业AI落地：需求清单背后的真实难题

制造业AI这个赛道，这几年喊得特别响，但真正能把项目落地的人少之又少。我见过太多团队开会时拿着一张A4纸的需求清单，看起来每一条都清清楚楚——"识别率99%""提前48小时预警""误差控制在3%以内"，可真到产线上跑起来，才发现清单上每个字背后全是坑。这份需求清单，恰恰是制造业AI最被低估的地方：外行看热闹，觉得AI什么都能干；内行看门道，看到的是数据质量、工控边界、部署约束、模型漂移这一连串硬骨头。这篇文章想跟你聊聊，制造业AI落地时那些"需求清单背后没写出来的"真实难题，以及我踩过的坑。无论你是甲方工艺工程师、乙方算法团队，还是想转行做工业AI的产品经理，都有参考价值。

1. 会议室里那张A4纸：需求清单背后的潜台词

1.1 一份典型需求清单长什么样

先还原一份我真实见过的"制造业AI需求清单"。甲方是某零部件制造企业，想搞一条AI质检线，需求一共五条，都是典型的制造业AI诉求：

• 基于AI的视觉质检系统，对产线上的产品进行外观缺陷检测，识别准确率不低于99%
• 关键设备的预测性维护，需提前48小时预警异常，减少非计划停机
• 基于历史数据与实时数据的产量预测，误差控制在3%以内
• 能耗优化模型，对空压机、注塑机等设备的运行参数进行优化建议
• 工艺参数推荐，当出现质量波动时给操作工推荐调整方案

单看清单，这是不是特别正常、特别"合理"的需求？但恰恰是这种"合理"，会让不明内情的乙方团队一进场就跪。因为需求的每一句话背后，都藏着完全不同的工业逻辑。制造业AI项目和互联网AI项目最根本的差别在于，互联网AI面对的是海量用户行为数据，数据量大、维度丰富、标签相对清晰；制造业AI面对的是产线上一个个具体的物理设备、工艺环节和老师傅脑子里的经验。算法还是那些算法，但需求清单的表达方式、验收标准、约束条件完全不同。

1.2 表面需求与真实意图的对应关系

我建议所有做工业AI的人都把需求清单做一次"翻译"，你会发现很多话术底下才是真正的诉求。下面这份表格是我这些年接触了多家制造型企业之后总结出来的共性，你可以拿它当参考：

你会发现一条规律：真正的需求清单往往不是在提"技术指标"，而是在提"管理目标"。管理目标的背后是成本、效率、质量和交期，AI只是实现手段。如果把"识别率99%"当成纯技术问题去接，你会死在"漏检"和"误杀"的权衡上；只有把它当成一个"质量成本管理"问题，你才能真正找到解法。这个认知差异，决定了你是做一个能交付的项目，还是做一个被反复打回修改的Demo。

1.3 为什么"互联网AI思维"在制造业会翻车

我见过太多从互联网大厂出来的算法工程师，拿着CV/NLP那套打法进工厂，第一周就被现实教育一遍。不是说他们技术不行，而是制造业AI的约束条件完全不一样。

第一个约束是数据量。互联网场景下动辄上亿条数据，工业场景里一个工序一个月可能就只有几百个样本，其中正常样本占绝大多数，缺陷样本寥寥无几。你拿大数据思维去做，连训练集都凑不齐。第二个约束是错误代价。互联网推荐系统猜错一次推荐，用户顶多点一下不感兴趣；质检系统漏掉一个缺陷件，整批次发货后可能是退货和索赔，这不是算法指标能完全衡量的东西。第三个约束是系统集成。互联网AI是独立的线上服务，制造业AI必须跟PLC、SCADA、MES这些老家伙打交道，物理世界的滞后性、网络隔离、工控安全都会成为需求清单上没写但必须解决的问题。所以在看制造业需求清单的时候，我的第一条建议是：放下技术自嗨，先去产线蹲两天。

2. 数据才是最硬的骨头：小样本、脏数据与"老师傅不干了怎么办"

2.1 别指望凑齐漂亮的缺陷样本

制造业AI第一个真正劝退人的难题，就是数据。我在前面提到，缺陷样本少得可怜。很多产线的良率在99%以上，缺陷率只有百分之零点几。你做视觉质检，需要各种类型缺陷的标注图——划痕、脏污、毛刺、缺胶、气泡，每一种还得有不同角度、不同光照、不同严重程度的变体。这听起来像CV项目的基础工作，但在工业现场，这些样本可能要连续收集好几个月都不一定够用。

那种"缺样本就上数据增强"的思路，在工业场景要小心。旋转、翻转、加噪声对自然图像有效，但对工业缺陷不一定有效，因为缺陷的成像机理和生产工艺强相关，你增强出来的"假缺陷"很可能学不到真正缺陷的本质。更靠谱的做法是跟产线、质量部门合作，把过去半年甚至一年的缺陷记录翻出来，看有没有图片存档、有没有对应的工艺参数记录；如果连历史记录都没有，那就得老老实实在产线上安排一个"缺陷样本收集期"，同时配合工艺人员主动制造一些可控缺陷，比如故意调整温度、压力来触发缺陷。但这么做又涉及报废成本和产线安全，需要跟甲方反复确认边界，一个不小心就会因为几块报废件被现场主管骂到怀疑人生。

2.2 现场数据的三种"脏法"

就算你搞到了样本，数据干净程度也堪忧。工业数据最常见的三类"脏"，我逐个拆开讲。

第一类是采样不同步。产线上温度传感器可能每秒采一次，PLC里压力变量可能每100毫秒刷新一次，MES里的批次记录可能是每一小时一条。你要做设备故障预警，把这三个数据源合在一起，时间对齐本身就是个工程问题。我遇到过一个项目，PLC里的数据带时区问题，和MES的记录对不上，光校准时间就把人折腾了两天。第二类是标签不可靠。设备维护记录里"异常"和"故障"的标注，往往是操作工手填的，不同班组的标准不一样。有的班组觉得"有点异响"就该报，有的班组觉得"还能跑就不算故障"。这种标签噪声会直接污染模型训练，你辛辛苦苦训出来的分类器，可能学的不是故障特征，而是班组填写习惯的差异。第三类是工程单位混乱。有些传感器数据已经做了非线性变换，有些是百分比，有些是绝对值，有些变量名是德语缩写，你根本不知道它代表什么。遇到这种情况，别硬猜，直接找现场仪表工程师逐条确认，比自己反推快得多，也安全得多。

2.3 老师傅的经验怎么变成"标注"

制造业AI里最有意思的数据源，其实是老师傅。老师傅看一眼设备声音、摸一下产品表面，就知道哪个参数要调，靠的是什么？是多年积累的模式识别。这种模式识别能不能变成AI的训练数据？能，但过程远没有想象中顺畅。

我在一个注塑项目里做过这样的尝试：把老师傅的判断逻辑拆解成规则。比如他判断"注塑缺胶"时会先看产品外观哪个部位、再查料温设定、再看保压压力曲线，那就把这些条件写成标注规则，用历史数据自动打标，再用这些标签训练模型。你会发现，老师傅的规则往往能覆盖80%的常见场景，但总有一些"我也说不清为什么，就是感觉不对"的特殊场景，这时就只能在老师傅还在岗的时候，安排专人跟拍跟记录，做成"经验知识地图"。说白了，AI落地有时就是在和时间赛跑——先把经验抢救下来，再谈建模优化。很多企业找过来做AI，其实就是老师傅要退休了，想在最后几年把隐性知识固化下来，这种项目技术含量未必很高，但意义很大。

2.4 模型上线三个月后失效，才是真正的考验

数据坑的最后一层，也是很多项目"上线即巅峰、三个月后没人用"的原因：分布漂移。工业现场不是静止的，产品换型、原材料批次更换、季节温湿度变化、设备磨损，都会让输入分布悄悄发生变化。

举一个真实的例子：一个热压工艺的质量预测模型，上线时准确率很好，到了冬天突然大幅下滑。排了半天原因，发现是车间供暖开启之后温湿度变化导致传感器读数偏移，进而改变了特征分布。这种问题，你在离线测试阶段永远发现不了，因为历史数据里就没有冬天的记录。所以做工业AI一定要有"模型监控"的概念——不只是算准确率，还要监控特征分布是否发生偏移、告警频率是否异常、关键变量是否有跳变。这些监控项，应该在需求清单阶段就跟甲方确认好，否则模型退化了没人知道，几个月后客户就会觉得"AI不靠谱"，你也很难再拿到后续合作。

3. 不是所有需求都该上AI：AI与PLC/工控系统的边界拉扯

3.1 先想清楚：AI在产线上到底是"决策者"还是"建议者"

很多需求清单上会写"实现产线AI自动控制""无人化智能工厂"，这种话往往来自对AI的过高期待。现实是，产线上的核心控制逻辑几乎都跑在PLC、DCS这类工业控制器里，它们可靠性极高、经过严格的安全认证，并且是闭环控制——传感器采集、控制器计算、执行器动作。AI现在想插一脚，本质上只能做两件事：要么当"传感器"，提供更好的检测和预测信号，给PLC或操作工参考；要么当"参数优化器"，在后台计算推荐工艺参数，由人工或上层系统确认后执行。

这两件事背后是同一句话：制造业AI绝大多数时候是辅助者，不是决策者。别听PPT上吹的"AI自主控制"，真要落地，没人敢把安全关交给一个神经网络。对乙方来说，最稳妥的定位是"让AI的建议进入决策回路，但保留人的最终控制权"。这样既解决了实际问题，又避开了安全认证和法律责任的大坑。这个定位从销售阶段就要跟客户讲清楚，不然最后验收时，客户拿"你为什么不直接控制设备"来质问，场面会非常尴尬。

3.2 要打通多少系统，才能拿到一份"干净数据"

需求清单里写"基于实时数据建立预测模型"，喊起来容易，做起来你才知道要从多少系统里取数。离散制造企业，数据可能散落在下面这些系统里：

• PLC/SCADA：设备层实时数据，如温度、压力、转速、电流
• MES：制造执行数据，如工单、批次、完工数量、工序流转
• ERP：计划、库存、订单、物料数据
• QMS：质量检测数据，如检验项、指标值、判定结果
• EMS：能源数据，如电耗、水耗、气耗

每个系统都有自己的数据库、字段规范、接口协议和数据粒度。最麻烦的是IT/OT网络隔离。很多工厂有严格的信息安全要求，生产网和办公网物理隔离，数据不能随意跨网传输。你模型要部署在生产网边，训练数据却要导出来，中间就需要摆渡、防火墙规则、审批流程。一些项目看似只做AI模型，实际上一大半时间耗在了数据接入和网络打通上。我的经验是：立项阶段就要把"数据接入范围、网络隔离方式、接口开发责任方"写清楚，不然后面全是扯皮。别看客户嘴上说"数据随便用"，等真要碰生产网的时候，IT部门的安全审批够你喝一壶的。

3.3 哪些"看起来很美"的需求注定是坑

其实很多需求一出现就该警觉。我列几个典型的"坑需求"，供各位参考：

• "全流程AI无人化"：风险极高，涉及安全认证、复杂异常处理，现阶段几乎不可能在主流制造业落地。谁接这种项目，谁就是拿职业前途开玩笑。
• "AI直接替代老师傅的判断"：老师傅的价值不只是判断，还有现场应变和责任心，AI暂时替代不了。把预期降成"辅助老师傅"更现实。
• "一个平台解决所有产线的AI问题"：制造业场景碎片化程度极高，跨工序、跨产品、跨工厂的通用模型非常难做。硬做只会陷入"看起来都有、用起来都不行"的尴尬。
• "100%准确率"：只要不是全检之后的复判，任何检测都做不到100%。这种需求一般不是技术问题，是责任边界问题，要在合同里明确"漏检误检责任怎么划分"。

看到这类需求，我的做法是直接和客户聊透：目标是什么、失败了最坏结果是什么、谁为决策负责。如果客户不愿意聊这些，那这个项目大概率要黄，早发现早脱身。

3.4 一条安全落地AI集成的通用路径

最后给一套我实践下来比较稳的集成路径，分四步走。

第一步，AI旁路验证：模型在后台跑，只输出日志和离线报告，不参与任何现场决策，用一两个月积累对比数据，看看模型判断和实际情况的吻合度。第二步，人工确认阶段：AI给出建议，操作工决定是否采纳，同时记录采纳率和效果。这一步往往能暴露出很多模型细节问题，比如建议频率太高操作工嫌烦、建议时机不对影响节奏等，都是宝贵的迭代素材。第三步，受限自动执行：在工艺允许区间内，AI可以对某些不敏感参数自动微调，但超出安全边界必须报警停机。第四步，全流程可控运行：经历前面三个阶段充分验证后，再考虑更大的自动控制范围。

每一步都要有评审节点和回退方案。这样做的好处是，万一模型出问题，损失是可控的，而且能逐步积累现场信任。信任不是靠PPT讲出来的，是拿几个月不闯祸、不出错跑出来的。制造业客户一般都很朴实，你跟他讲先进理念他不会太兴奋，但你让他的产线少停一分钟机、少废一个件，他会记在心里。

4. 验收那一刻才是噩梦：模型漂移、"最后一个问题"与产线信任

4.1 离线测试99%，上线怎么就变成80%

这件事几乎每个工业AI项目都会遇到，我也翻过车。问题根源往往不是算法退步，而是"离线测试和在线运行之间的数据差异"。离线阶段，你是用历史数据做的回测，数据是静止的；上线之后，模型面对的是实时数据流，环境在变、工况在变、数据分布也在变。再加上很多人在离线测试时犯了一个隐蔽错误：随机划分训练集和测试集。时间序列数据一旦随机划分，相当于让模型"偷看未来"，测试指标自然虚高。正确做法是必须按时间顺序划分，用前80%时间段的数据训练、后20%时间段的数据测试。

另外一个常见坑是特征计算方式不一致。离线时候你可能用某个窗口统计量，比如"过去5分钟均值"，但上线代码里窗口滑动逻辑有偏差，哪怕差一秒，结果也可能天差地别。所以上线前一定要做一个"离线/在线一致性验证"：用同一批实时抓取的数据，分别跑模型脚本和线上服务，比对输出是否一致，不一致就一行行排查特征工程代码。这一步做完，能避免很多上线后的"灵异事件"。

4.2 客户追问"为什么报警"，才是真正要过的坎

工业AI和互联网AI的另一个本质差别是"可解释性"。互联网推荐算法给你推个商品，你最多疑惑一下"为什么推这个"，然后划走；但工业场景里，系统报警了，操作工、班组长、质量经理、设备厂商都会围过来问：凭什么报警？依据是什么？如果答不上来，下一次报警就没人当回事了，系统就废了。

有些算法，比如树模型、线性模型，解释起来还容易，给出特征重要度、规则路径，客户能听懂；但深度神经网络你只能给热力图、置信度，客户不一定买账。所以我在制造业项目里，会优先选可解释性强的方案，实在要用深度学习，也会配套一个规则引擎做兜底解释——比如"模型置信度0.87，同时关键特征X超过工艺上限Y%，所以触发预警"。这个解释当然不完美，但在现场足够建立一个"AI说话有依据"的初步信任。

4.3 部署环节的隐形门槛：算力、工控机与"数据不出厂"

验收阶段最容易被低估的是部署环境。工业现场不像云服务器，网络隔离、算力受限是常态。有的工厂不允许数据上传云端，模型必须部署在本地工控机或边缘设备上。这些设备往往CPU性能一般、内存不大、没有独立GPU，你训练时用的ResNet可能跑不起来，得换成轻量级模型或者做量化压缩。

还有一个现实问题：生产环境不允许随便远程登录过去改模型。有些工厂网络隔离严格，算法工程师不能直接访问生产设备，那监控和更新模型怎么办？必须提前设计好离线升级包、模型版本管理和灰度发布机制。别小看这件事，我见过不少项目就是死在"模型上线后无法迭代"上，算法团队改了一版又一版，却永远进不了现场，最后只能看着模型效果一天天变差，干着急。

4.4 信任是"陪跑"出来的：从报警日志到灰度试点

最后谈一谈信任这件事。制造业客户对AI天然有戒心，这很正常，毕竟出了事故是要停产、要赔钱的。你怎么赢得信任？我的经验是：重视每一份报警日志。报警了、误报了、漏报了，都要有记录。上线后前三个月，每周给客户出一份"模型行为报告"，统计告警数量、误报率、漏报率、采纳率，让客户看到模型在持续学习、持续收敛，而不是一个黑盒子。同时建议做灰度试点：先选一条线、一个班次跑起来，和人工/传统方式对比，用数据说服客户。等这个班次的老师傅开始觉得"这AI有时候还真提醒对了"，信任就慢慢建立起来了。制造业是个靠口碑和案例说话的领域，你在一条产线上做扎实了，后面的项目会好谈得多。

5. 写在需求清单之外：先啃哪块骨头，以及我踩过的坑

5.1 选课题的三个标准：价值看得见、风险可控、数据基本能拿到

给还在需求清单阶段迷茫的人一句实在话：制造业AI不适合一上来就干"革命性大项目"，更适合从"外科手术式"的小切口切入。具体挑课题，我一般用三个标准衡量。

第一，价值要用钱说话。这个项目做完，一年能给客户省多少钱、多赚多少钱？如果算不清楚，项目大概率做不大。视觉质检省人工、预测性维护省停机损失、能耗优化省电费，这些都能算成钱。第二，风险要可控。不碰安全关键环节、不影响主工艺流程、失败最多损失一个试点线，这种课题最适合起步。千万别第一个项目就奔着"全厂无人化"去，那是给自己挖坑。第三，数据要有基础。现场得有历史数据，哪怕乱一点、脏一点，至少有东西可摸。如果现场连记录都没有，那先做数据采集和数据治理，再谈AI。制造业AI的第一步往往不是算法，而是把你的数据管线先理顺。

5.2 哪些方向最值得先试：难度与收益的视角

我接触过的制造业AI方向里，有几个性价比相对高的，列个表给各位参考。

这张表不是绝对标准，但作为切入点参考足够了。我的建议是：第一个项目选"产量预测"或"视觉质检"这类目标明确、价值可量化的方向，更容易跑通全流程，也更容易向客户展示成果。做完一个成功案例后，再往外扩展其他场景，会顺畅很多。

5.3 谈需求时，一定要问清客户的三个问题

很多项目翻车，根源不在技术，而在需求阶段没有把边界问清楚。我现在接制造业需求，必问三个问题。

第一，你们有多少历史数据？样本量多少？有没有标注？如果客户支支吾吾答不上来，那说明数据基础很差，需求再漂亮都是空中楼阁。第二，这个模型判断错了，后果是什么？漏检一个坏件赔多少钱？误报一次停机损失多少？把这个问清楚，你就知道该优化"漏检率"还是"误报率"了，这是技术方案的分水岭，也是报价时需要重点考虑的部分。第三，系统上线后，谁来维护、谁来调参、谁为AI的决策负责？如果客户完全没有运营团队的准备，那你要么把服务包揽下来，要么建议客户先别上AI。否则模型一上线没人管，三个月后肯定废弃。这三个问题看着简单，但每次都能问出答案背后的真相。制造业AI项目的成败，往往在签合同之前就已经决定了。

5.4 送我自己的一个收尾：交付不是终点，是"养"模型的开始

最后再说一点个人体会。很多人把"模型上线"当项目结束，这是制造业AI最大的误区。工业现场变化太多，模型漂移、工艺调整、人员流动都会影响效果，没有持续的运营和迭代，AI系统迟早变成摆设。

我在实际项目里，倾向把交付定义为"陪跑期结束"，而不是"模型部署完成"。上线后至少留一段时间，跟客户一起看报警日志、一起调阈值、一起迭代特征。等模型真正稳定下来、客户自己也学会看数据了，才是合格的交付。这个过程很累，但它就是制造业AI区别于互联网AI的地方——你在那里多陪的每一个小时，换来的是客户未来几年的信任。

提示：如果你正准备接制造业AI项目，别被漂亮的案例和宏大的概念牵着走。先蹲产线、再谈数据、后定方案。制造业AI拼到最后，拼的不是算法炫技，而是你对现场的理解和敬畏。