1. 那句"全产线覆盖"到底杀死了什么
我做过好几个工业AI检测项目，从服装面料瑕疵检测到3C结构件外观检，也跟不少同行聊过他们折在哪儿。聊到最后发现一个特别扎心的规律：技术方案本身没大毛病，模型也能跑，demo也好看，但项目就是推不下去。推不下去的原因，十有八九能追溯到项目启动会上老板拍的那句话——"我们要做全产线覆盖"。
这句话听起来特别有魄力，特别有战略高度。但对于真正要落地这套系统的工程师来说，它基本等同于一句判决书。为什么？因为工业AI检测和互联网AI应用有一个本质区别：互联网产品可以灰度发布、可以容忍99%的准确率、可以边跑边修；工业产线上的检测系统，一旦上线，它面对的是节拍、良率、停线成本这三座大山。
我见过一个做服装检测的团队，老板要求一条线上十几个工位全部上AI检测，从面料进厂到成衣出库全流程覆盖。团队花了三个月做POC，在第一个工位跑通了，准确率97%。老板很高兴，说"那就铺开吧"。结果铺到第三个工位就崩了——不同工位的相机角度、光照条件、产品姿态完全不同，第一个工位调好的模型迁移过去直接掉到70%以下。更要命的是，产线不能停，你不可能为了调模型让整条线停下来等你。
这就是"全产线覆盖"最致命的地方：它把一个需要逐点突破的工程问题，包装成了一个可以整体推进的战略问题。而工业现场的现实是，每个工位都是一个独立的战场，光照、机械结构、节拍、产品型号、甚至当班工人的操作习惯，都会影响最终效果。
所以这篇内容我想聊的不是某个具体模型怎么调，而是工业AI项目从"能跑"到"能上线"之间，到底隔着哪些坑，以及怎么用单点突破的思路把项目真正推下去。适合正在做或准备做工业AI检测的工程师、项目经理，也适合那些被老板一句"全产线覆盖"搞得焦头烂额的一线同学。
2. 单机还是云联网：工业AI检测的部署形态选择
2.1 为什么工业现场很少用纯云端推理
先回答一个被问得最多的问题：工业AI检测到底用云联网还是单机？
我的经验是：绝大多数产线级检测，用的是单机或边缘端推理，云端只做训练和管理。原因很直接——产线节拍不等人。一条高速产线，产品在相机视野里停留的时间可能只有几十毫秒，你让图像传到云端、推理完再传回来，光网络延迟就够产品跑出去好几米了。而且工厂网络环境复杂，断网、抖动是常态，你不可能让检测系统依赖一个不稳定的外网连接。
那云端用来干什么？训练、模型管理、数据回流、版本分发。也就是所谓的"云边端"架构：云端负责重活（训练、标注管理、模型迭代），边缘端负责实时推理。这个分工是经过大量项目验证的，不是拍脑袋定的。
但这里有个坑：很多团队一开始图省事，直接在工控机上跑推理，用Python写个脚本，模型加载进去就完事。跑demo没问题，一上产线就出问题——内存泄漏、GPU显存不释放、长时间运行后推理速度下降。工业现场要的是7x24小时稳定运行，你的推理服务必须能扛住连续跑几个月不重启。
2.2 边缘推理的硬件选型逻辑
边缘端用什么硬件，取决于你的检测精度要求和节拍要求。我大致分三档来说：
| 场景 | 典型硬件 | 推理框架 | 适用情况 |
|---|---|---|---|
| 轻量检测 | Jetson Nano/Orin Nano | TensorRT | 简单分类、低分辨率检测 |
| 中等复杂度 | Jetson Orin NX/AGX | TensorRT | 多模型串联、中等分辨率 |
| 高精度高节拍 | 工控机+独立GPU | TensorRT/ONNX Runtime | 高分辨率、多相机、复杂模型 |
选型的时候有个经验：不要按峰值需求选，要按持续运行需求选。我见过一个项目，算法同学在RTX 4090上测出来单帧推理8ms，觉得稳了，结果现场用的是工控机上的T4，实际跑起来单帧35ms，节拍直接跟不上。所以选型时一定要在目标硬件上实测，而且要考虑连续运行后的性能衰减。
另外，工业现场对硬件的散热、防尘、抗震都有要求。你不可能把一张消费级显卡直接塞进产线机柜里，夏天机柜温度能到50度以上，显卡分分钟降频。所以工控机的选型要关注宽温、无风扇或工业级风扇、以及足够的PCIe插槽。
2.3 上位机在整套系统里的角色
说到工业现场，就绕不开"上位机"这个词。很多做算法的同学对上层软件架构不太熟，觉得模型跑通就完事了。但实际上，上位机才是把AI能力真正接入产线的桥梁。
上位机要干的事包括：跟PLC通信拿触发信号、控制相机采集图像、调用推理服务、把结果发给执行机构（比如剔除气缸）、记录检测数据、提供人机界面给操作工看。这一整套流程，任何一个环节出问题，产线就停了。
我见过太多算法团队和上位机团队扯皮的场景：算法说"我模型没问题，是你图像没采好"，上位机说"我图像采得好好的，是你推理服务挂了"。所以我的建议是，算法同学一定要懂一点上位机的基本逻辑，至少要知道图像是怎么从相机到推理服务的，结果是怎么从推理服务回到执行机构的。这样出问题的时候才能快速定位。
上位机开发常用的语言是C#，也有用C++和LabVIEW的。C#上位机在工业现场特别常见，因为开发效率高、界面好做、跟各种硬件SDK的对接也方便。如果你做工业AI，建议至少能看懂C#代码，能跟上位机同学顺畅沟通。
3. 模型选型：大模型在工业检测里到底能不能用
3.1 工业检测的主流模型还是小模型
现在大模型很火，很多老板一听"大模型"就觉得高级，要求项目里也用上。但我要泼一盆冷水：在工业实时检测场景里，主流方案仍然是轻量级的小模型，比如YOLO系列、MobileNet、EfficientNet这些。
原因很简单：节拍。一条产线可能要求每秒检测几十个产品，每个产品可能有多张图像，你用一个几十亿参数的大模型去推理，延迟根本扛不住。而且工业检测的任务通常很聚焦——就是判断有没有瑕疵、瑕疵在哪个位置、属于哪一类。这种任务不需要大模型的通用理解能力，一个小模型针对性训练就能做得很好。
那大模型在工业AI里有没有用武之地？有，但不在推理端，而在数据标注、模型辅助训练、以及复杂场景的语义理解上。比如用大模型做预标注，可以大幅减少人工标注的工作量；或者用大模型做异常检测的辅助判断，处理一些传统模型搞不定的长尾case。
3.2 什么情况下才考虑大模型
我总结了几种适合引入大模型的场景：
- 缺陷样本极少：传统监督学习需要大量标注样本，但有些缺陷一年就出现几次，根本凑不够训练集。这时候可以用大模型做零样本或少样本检测。
- 缺陷类型极其多样：比如服装面料的瑕疵，可能有几十种类型，而且新类型不断出现。传统模型每加一类就要重新标注训练，大模型可以更灵活地处理。
- 需要语义理解：比如判断"这个划痕是否影响使用"，这需要结合产品功能来理解，不是简单的分类问题。
但即便在这些场景，我的建议也是先用小模型跑通基线，再评估大模型是否真的能带来提升。不要一上来就上大模型，那是给自己找麻烦。
3.3 模型微调在工业场景的实操要点
如果你确实需要微调模型，有几个点要注意：
第一，数据质量比数量重要。工业场景的数据往往很不平衡，正常样本一大堆，缺陷样本少得可怜。这时候不要盲目扩充数据，而是要把有限的缺陷样本标注准确。我见过一个项目，标注团队把一些模棱两可的样本标错了，导致模型学偏了，怎么调都上不去。
第二，数据增强要符合工业实际。不要随便用网上的增强策略，比如随机旋转、随机裁剪。工业图像里，产品的位置和姿态是有物理约束的，你乱增强反而会让模型学到错误的特征。增强策略要基于对产线实际情况的理解来设计。
第三，验证集要能反映真实分布。很多团队训练集和验证集是从同一批数据里随机切的，结果验证集准确率很高，一上产线就崩。正确的做法是，验证集要包含不同时间段、不同班次、不同批次的样本，尽量模拟真实产线的数据分布变化。
4. 从单工位到全产线：为什么必须逐点突破
4.1 每个工位都是一个独立问题
回到开头那个话题。为什么"全产线覆盖"这么难？因为每个工位的光照、相机、机械结构、产品姿态都不一样，模型不能简单复制。
我拿服装检测举个例子。面料进厂时的检测，相机是从上往下拍，面料是平铺的，光照可以做得比较均匀。但到了成衣环节，衣服是挂在衣架上的，有褶皱、有阴影、有各种角度，同一个模型直接拿过去用，效果肯定不行。
再比如3C结构件检测，不同工位的相机角度可能差几十度，打光方式也不同——有的用环形光，有的用条形光，有的用背光。这些差异会导致图像的特征分布完全不同，模型必须针对每个工位单独训练或微调。
所以正确的做法是：先在一个工位上做到极致，把准确率、稳定性、节拍都跑通，然后再复制到下一个工位。每复制一个工位，都要重新评估数据、重新训练或微调模型、重新调参。这个过程很慢，但它是唯一可靠的路。
4.2 单点突破的完整流程
我总结了一个单工位落地的标准流程，供参考：
第一步：现场勘查。去产线实地看，记录光照条件、相机型号和位置、产品节拍、机械结构、以及操作工的实际操作习惯。这一步很多人跳过，直接拿数据就开始训模型，结果做出来的东西跟现场对不上。
第二步：数据采集。采集要覆盖不同时间段、不同班次、不同批次的数据。特别要注意采集一些边界情况，比如产品位置偏移、光照变化、以及各种缺陷样本。采集的时候要记录每张图像的采集条件，方便后续分析。
第三步：标注和清洗。标注规范要提前定好，什么算缺陷、什么不算、缺陷边界怎么定，都要跟产线质量部门对齐。标注完之后要做一致性检查，确保不同标注员的标准一致。
第四步：模型训练和调优。先用一个基线模型跑通，然后根据bad case逐步优化。不要一上来就追求高准确率，先把召回率做上去，确保不漏检，再逐步优化准确率。
第五步：现场部署和验证。把模型部署到现场硬件上，用真实产线数据跑一段时间，观察准确率、节拍、稳定性。这个阶段一定要有算法同学在现场盯着，因为很多问题是实验室里发现不了的。
第六步：持续迭代。上线不是终点，而是起点。要建立数据回流机制，把现场误检漏检的样本收集回来，定期更新模型。
4.3 复制到多工位时的注意事项
当一个工位跑通之后，复制到其他工位时要注意：
- 不要假设模型可以直接迁移。每个工位都要重新评估，可能需要重新训练或微调。
- 建立标准化的部署流程。把第一个工位的部署过程文档化，包括硬件配置、软件环境、参数设置、调试步骤，这样复制的时候能少走弯路。
- 考虑集中管理。当工位多了之后，模型版本管理、数据回流、远程监控就变得很重要。这时候需要一个统一的管理平台，而不是每个工位单独维护。
5. 那些让项目翻车的隐形坑
5.1 节拍和准确率的矛盾
工业现场最现实的问题：你要么准确率高但慢，要么快但准确率低。老板通常两个都要，但物理规律不允许。
我的经验是，先跟产线确认清楚：到底能容忍多少误检和漏检？漏检通常比误检严重，因为漏检意味着不良品流出，可能导致客诉。误检则是把良品判成不良品，增加返工成本。两者要分开谈，不能笼统地说"准确率要到99%"。
确认清楚之后，再根据节拍要求来设计模型和硬件方案。如果节拍实在跟不上，可以考虑抽检而不是全检，或者降低图像分辨率，或者用更轻量的模型。这些都是需要跟产线一起商量的，不是算法团队单方面能决定的。
5.2 数据回流和模型迭代的闭环
很多项目上线之后就没人管了，模型一直用初始版本，效果慢慢下降。这是因为产线的产品、光照、设备状态都在变化，模型需要持续更新。
建立数据回流机制是关键。具体做法是：在现场部署一个数据收集服务，把推理结果和对应的图像存下来，定期筛选出置信度低的样本和人工复核发现错误的样本，回流到训练集里。然后定期（比如每周或每月）重新训练模型，验证通过后更新到现场。
这个闭环听起来简单，但实际操作中很多团队做不起来，因为缺乏工程化的工具支持。所以我在项目初期就会建议把数据回流和模型管理平台搭起来，哪怕一开始功能简单，也比后期补要容易得多。
5.3 跟产线团队的协作问题
技术问题好解决，人的问题难解决。工业AI项目失败，很多时候不是技术不行，而是跟产线团队的协作出了问题。
产线操作工可能觉得AI系统是来监视他们的，产生抵触情绪。产线主管可能觉得AI系统增加了工作量，不愿意配合。质量部门可能对AI的判定结果不信任，坚持要人工复核。
我的经验是：项目早期就要把产线相关方拉进来，让他们参与需求定义和验收标准制定。上线之后，要提供足够的培训和文档，让操作工知道怎么用、出了问题找谁。同时要建立反馈机制，让产线的人能方便地报告问题，而不是憋着不说。
还有一个细节：AI系统的界面要简单直观。操作工不需要看什么置信度、什么模型版本，他们只需要知道"这个产品OK不OK"。界面设计要以操作工为中心，而不是以算法工程师为中心。
6. 给正在做工业AI项目的你几句实在话
做了这么多项目，我最大的体会是：工业AI不是一个纯算法问题，而是一个系统工程问题。模型只是其中一环，相机、光照、机械结构、上位机、PLC、产线节拍、人员配合，每一环都能决定项目成败。
如果你正在做或准备做工业AI检测项目，我的建议是：
第一，不要贪大。先在一个工位上做到极致，拿到实实在在的成果，再考虑复制。老板说"全产线覆盖"的时候，你要能拿出单工位的详细数据和落地计划，告诉他为什么必须一步一步来。
第二，深入现场。不要坐在办公室里看数据调模型，要去产线看实际情况。很多问题只有到了现场才能发现，比如光照变化、产品姿态、操作工的习惯动作。
第三，重视工程化。模型跑通只是开始，部署、监控、数据回流、模型迭代，这些工程化的工作才是项目长期稳定运行的保障。
第四，跟产线做朋友。技术再牛，产线不配合也白搭。多跟操作工、主管、质量部门沟通，理解他们的诉求，让他们参与到项目中来。
最后说一个我踩过的坑：有一次项目上线后效果一直不稳定，查了很久才发现是相机镜头脏了，没人定期清洁。这种问题在实验室里永远遇不到，但在工业现场就是实实在在的日常。所以，做工业AI，既要懂算法，也要懂现场，更要懂人。
