AI机器视觉工业质检实战：从样本采集到模型部署全流程

1. 项目缘起：为什么我盯上了AI机器视觉这条线

生产线的质检环节，一直是工厂里最“吃力不讨好”的岗位。流水线上的产品以每分钟几十甚至上百件的速度流过，质检员需要在几分钟内判断产品有没有划痕、缺损、污渍、装配错位，高强度、高重复，还极度依赖经验。招人难、培训久、人员流动大，更麻烦的是，人工质检的标准根本无法统一——同一个缺陷，早班和中班的判定结果可能就不一样。

我这次接到的项目，就是要把一条日产能过万件的产品线，从人工质检切换成AI机器视觉自动检测。项目启动前的实际状况是：产线上留着两名熟练质检员，一个盯外观，一个盯装配，每天光缺陷复判就要花掉三四个小时。老板的需求很简单——第一，把漏检率压到最低；第二，把质检结果数字化，别总靠纸质表格和口头汇报；第三，最好能把常见缺陷自动归类，方便追溯工艺问题。

这里要先说清楚一个容易混淆的概念：AI机器视觉不等于传统机器视觉。传统视觉方案靠的是人为设计的规则，比如产品尺寸、灰度阈值、边缘特征，写死一套逻辑，遇到光照变化或者新产品形态，规则就崩。而AI视觉的核心，是让算法从大量样本里自己学习“什么是正常”“什么是缺陷”，本质上是在训练一个能看图说话的分类器或检测器，泛化能力远比传统规则强。

为什么选AI而不是继续优化传统视觉？我之前吃过亏。同一条产线最早试图用背光+CCD+阈值分割做玻璃边缘检测，结果换了两次灯源，阴影一变化，误检率直接飙到30%，最后只能当摆设。AI方案虽然前期要花时间采图、标注、训练，但换产品、换工况时，只需要补样本和微调模型，不用改一堆参数。这就是我最终决定走AI路线的主要原因。

这个项目的核心价值，一个是“通用性”，一个是“可追溯”。模型跑通了，不只是这一条产线能用，同类型产线几乎可以平移复制；副产品是数据的积累——缺陷类型、缺陷频率、缺陷分布全部留痕，后续做工艺改进口径就清晰了。更直白地说，工厂老板买的不只是几台检测设备，而是一套能持续产出质量数据的管理工具。

这篇文章的受众，我默认是想把AI视觉引入产线，但还在观望、或者刚起步试水的工程师和管理者。你不用是算法大牛，也不需要精通深度学习底层原理，只要用过Python、知道基本的图像处理概念，照着这个思路走，就能在自有产线上跑通一套可用的视觉质检方案。真遇到卡点，我会把排查思路和解决办法一并写出来，这比任何理论教程都实用。

2. 方案整体设计与硬件选型：先搭好台子再唱戏

2.1 先厘清检测需求，再定技术路线

任何机器视觉项目，第一步都不是急着买相机，而是把检测需求细化成“机器看得懂”的规格。我拿到产品后，第一时间拉了张检测需求表，逐项确认三件事：一是要检什么缺陷，表面划痕、凹坑、毛刺、脏污、装配缝隙不均，还是全部都检；二是缺陷的最小尺寸，如果最小要看到0.1mm的划痕，相机的分辨率和镜头的景深就得对着这个数去配；三是产线的节拍，单件检测时间不能超过多久，这决定算法推理速度和是否需要并行处理。

我把需求表填完后，发现最大的坑在于缺陷种类多、形态差异大——有些缺陷是颜色差异（脏污），有些是深度差异（凹坑），有些是纹理差异（划痕）。这意味着单一的打光方式不可能满足所有检测项。最后我定了一个折中方案：用户外光+同轴光双通道打光，分时采集图像，分别突出颜色信息和表面纹理信息，再合并进检测流程。虽然单件检测时间会略微增加，但相比为了省时间而牺牲检出率，完全值得。

另一个容易被忽视的问题是检测精度与实际产能是否匹配。我见过很多项目一上来就买5000万像素工业相机，觉得像素越高越好，结果处理速度跟不上产线节拍，整套系统成了瓶颈。这次我先用产线的物料流量除以每天可用工时，算出了单件允许的检测窗口，再倒推所需相机帧率和算法耗时，最终选了1200万像素的全局快门相机，配上8mm工业镜头，工作距离30cm左右，既能覆盖最大产品的视场，也留出了算法处理的时间余量。

2.2 硬件选型逻辑：光源、相机、镜头一个都不能少

机器视觉有一句老话：“打光决定下限，算法决定上限”。光源选错了，后面再牛的AI模型也救不回来。这次的产线是半封闭环境，环境光变化不小，我坚决不用自然光下直拍的方式——那等于把模型的稳定性寄托在天气上。我选用的是白色LED平板光源+高角度环形光源的组合，前者提供均匀的漫射光，压制产品表面的反光；后者用来突出边缘轮廓和浅划痕。实测下来，环光对玻璃类产品表面的微小划痕确实敏感，平板光对颜色类缺陷的表现更自然，两者切换使用，数据稳定性明显好过单光源。

相机方面，我卡了三个参数：分辨率、帧率、芯片尺寸。检测精度要求0.1mm的缺陷，按视场长度200mm来算，至少需要2000个像素才能保证一个缺陷占据不少于2个像素，所以1200万像素（约4240x2820）解像力是够用的。帧率上按产线节拍每秒一个产品计算，1200万像素相机在通用接口下要保证10fps以上才从容。芯片尺寸影响视场角，1.1英寸的芯片配合8mm镜头，视场刚好覆盖我要求的工作距离，不用额外加延长管，减少了畸变和安装误差。

镜头选型时，我不光看了焦距，还重点关注了畸变率和MTF曲线——畸变大会让边缘检测出现几何误差，MTF曲线代表镜头的解析能力，分辨率再高的相机配个低解像力的镜头也是白搭。这次选的镜头在中心视场的MTF表现优秀，边缘虽有轻微下降，但经过标定后偏差可忽略。顺带一提，镜头和相机之间尽量用C接口直连，避免转接环带来的松动风险。

采集卡和工控机也值得说。我用的是一台自带千兆网口的普通工控机，CPU是i7，内存32GB，GPU选了NVIDIA的入门级专业卡（后期要跑深度模型，没GPU不行，但也没必要上来就买A100这种大卡），配合一张四口千兆网卡接四路相机，可以并行采集。这套配置在国内某电商平台的整机预算控制在两万以内，中欧体育稳定运行半年多了。如果你预算更紧，用两块消费级显卡替代专业卡也能跑，但显存至少8GB，不然训练和推理会卡显存。

2.3 软件框架选择：成熟工具链，别重复造轮子

软件这块，我一开始就定了一个原则：能不开源就不重写，能少改就少改。视觉检测的软件栈大致分为图像采集、图像预处理、模型推理、结果显示与数据上传四层。图像采集直接用了厂商SDK；图像预处理我用的是Python生态里的OpenCV和NumPy，简单高效；模型推理选了PyTorch，不是因为别的，就是社区活跃、示例多，遇到坑能快速搜到解决方案；模型部署在服务端用Flask起了一个轻量HTTP服务，通过一个Restful接口给产线上位机调用，前端的检测界面直接用Python写了个极简的Web页面，用浏览器就能看。

有人可能会问，为什么不直接用现成的商业视觉软件？我知道市场上有不少成熟的AI视觉软件包，比如某品牌的VisionMaster，拖拽式操作、内置大量算法模块，确实适合快速上线。但这类软件的缺点是封闭——一旦涉及特殊的图像处理逻辑或深度模型定制，就只能依赖厂商，费用也不便宜。我倾向于用开源技术栈组合，半年跑下来的感受是：**学习曲线确实陡，但自由度完全不一样，尤其是后面扩展新缺陷类型的时候，闭源软件反而成了累赘。**如果你是刚起步，不排斥“玩玩代码”，强烈建议在开源路线上多花点时间，长期回报率高。

3. 核心环节实现：数据、模型、部署全链路拆解

3.1 数据采集与标注：多一万张图，不如今晚好好布光

这一段是整个项目里最脏、最累、也最值钱的环节，必须单独拎出来说透。

我的训练数据完全来自产线实拍。第一天，我在产线上装好光源和相机，连拍两个班次，每件产品在前后双工位各采集一次，保存全分辨率原图。为什么要拍这么多？因为检测对象虽然是同一种产品，但它在产线上的姿态、光照、反射状态每时每刻都在变。模型要学的不是“某一张图长什么样”，而是“这个产品的各种正常/异常状态长什么样”。样本不充分、多样性不足，后面模型再复杂也白搭。

我设置了两个采集工位：一个负责外观面，捕获表面划痕、脏污、颜色不均；一个负责装配面，主要捕获结构缺陷，比如卡扣断裂、缝隙过大、螺丝偏位。每个工位的图像单独存目录，文件名带上产品批次、班次、时间戳，方便后续回溯。实际跑了两天后，我统计了一下：有效采集到约8000张图像，其中正常产品约5000张，各类缺陷加起来约3000张。

接下来就是标注。标注工具我用的是LabelImg和CVAT，前者轻量化，适合单机少量标注；CVAT支持多人协作和自动标注，适合量大时并行推进。标注时我用矩形框把每个缺陷圈出来，同时打上类别标签，比如“scratch”“dent”“stain”。这里有个关键点：标注框必须紧贴缺陷边缘。框大了，模型学到的是“缺陷周围一圈也算缺陷”；框小了，模型学到的特征不完整。为了保证质量，我让两个标注员分别标注一遍，再用脚本比对一致性，明显不一致的图拉出来人工复判。

数据增强这一步也不能省。原始8000张图对深度学习来说不太够，我用OpenCV做了随机裁剪、旋转、亮度抖动、对比度变化、高斯噪声，把数据扩到32000张。但是注意，测试集不用增强，保留原始样本，否则评估结果虚高。有一个容易踩的坑是：增强后的图如果形态和真实产线差异太大（比如过度旋转、夸张色偏），模型学会的是“识别这几种增强方式”，而不是“识别缺陷”，效果反而更差。所以增强参数要保守，小角度旋转（±5度）、轻微亮度变化（±10%）就够用。

3.2 模型选型与训练调参：分类、检测还是分割

视觉检测的模型选型，我踩过不少坑。最初只想快速上线，先试了图像分类——把整个产品图扔进ResNet分类成“OK”或“NG”，做法简单，但很快发现不行：一个产品图上同时存在两种缺陷时，分类模型只能给出一个整体判断，没法告诉你是哪种缺陷、缺陷在哪个位置，更没法统计缺陷尺寸和分布，完全不符合追溯需求。

于是我又转向目标检测模型，选了YOLOv8。YOLO系算法是目前工业缺陷检测里最常用的模型之一，理由有三个：速度快（GPU上轻松跑100fps以上）、mAP精度够用、部署方便。实测在我的数据集上，YOLOv8s（s代表small版本）训练100轮后，测试集mAP@0.5能到94%左右，单张推理时间在6-8ms，完全满足产线节拍。如果你愿意多花点时间调参，YOLOv8m或YOLOv8l还能再提两个点左右的精度，代价是推理时间翻倍，一般产线没必要。

如果未来需要精确测量缺陷尺寸（比如客户要求划痕长度<3mm才算合格），那就要考虑实例分割模型了。我当时用YOLOv8-seg做了一版实验，虽然能输出缺陷的精确像素轮廓，但标注工作量翻倍（每个缺陷要画边缘），推理耗时也涨到15ms以上，暂时没必要全量切换。如果你后续真的有定量检测需求，建议优先锁定几个关键缺陷类别做分割，不用全品类都上。

训练参数我直接给一份可参考的配置：

• 图像尺寸：640x640（YOLO默认值，速度与精度均衡）
• Batch size：16（显存8GB够了，没有就降到8）
• 初始学习率：0.01（使用余弦退火调度）
• 优化器：SGD，momentum=0.937，weight_decay=0.0005
• 训练轮数：100轮（我加了早停，50轮没涨就停）
• 数据划分：训练:验证:测试=7:2:1

训练过程没什么魔法，核心看两条曲线：训练损失下降但验证loss在涨，是过拟合，加大数据增强或降模型复杂度；验证loss还在降但mAP不涨，是学习率太小或者数据分布有问题，调整后再看。我实际跑了三版，第一版过拟合严重，因为缺陷样本太少，后来把正负样本比例从1:3调到1:1，并给NG样本增加了更多增强倍数，效果明显改善。

3.3 部署与推理优化：别让模型躺在实验台上

模型训练完，并不是“save权重文件”就结束了。部署阶段有几个容易忽略的问题，我逐一说明。

首先是模型转成TensorRT。PyTorch推理之前在我的工控机上单张图大概是12ms，转成TensorRT加速后能压到5ms左右，将近2.5倍提升。TensorRT需要按目标GPU型号做一次构建，构建过程有可能会因为算子和版本不匹配报错，社区里都有现成solution，无非是换onnx版本或者改opset，不用慌。

其次是与产线PLC的通讯。怎么把检测结果送给产线控制系统？我用的是Modbus TCP。检测结果通过工控机转换为布尔量（OK/NG），再写到PLC的保持寄存器里。PLC根据这个值决定产品流向——OK的去包装线，NG的推到返修区。Modbus的寄存器地址、字节序这些细节要提前和电气工程师对齐，否则每次联调都在扯皮。这块项目周期里最容易拖时间，一定要在前期并行推进。

再提一下系统看板。我用Grafana搭了一个质检看板，接MySQL数据库，每次检测结果都会同步写入，按小时、按班次统计缺陷数量和缺陷类型分布。屏幕上能实时看到当天的趋势，老板不用再等日报。这一步看着不起眼，但效果特别好——管理人员对这个数字化的感知度极高，项目验收的“成交率”就在这个看板上。

还有一点，模型更新机制。产线跑久了，会出现新类型的缺陷，老模型自然失效。我的做法是每周人工抽检一批被判定为NG的图片和部分OK的图片，通过一个简易标注工具去新增标签，重新训练30-50轮，再把新权重文件推送到生产部署环境。这套流程整体走下来，从发现新缺陷到模型上线，控制在两天以内，对产线来说完全可接受。如果你有技术余力，可以把模型版本管理、回滚机制也加进来，能少掉很多头发。

4. AI质检全流程实操：从采集到部署的一步步实录

4.1 确定检测项与布光参数

实操第一步，不是接相机，而是拿几件典型样品到实验室里“摆拍”。我用一块黑色亚克力板做背景，把产品放上去，打开光源，先手动调了几个角度和亮度，拍出来的图在屏幕上放大看——划痕是否清晰、反光是否刺眼、纹理细节有没有丢掉。

这块一定要耐心。我调光源参数花了两天时间，不是光源不够亮，而是不同缺陷对光照方向的要求完全不同。浅划痕在低角度光下很明显，正面光下完全消失；脏污则相反，均匀光下最清楚。最终我用了多光源方案：一个高角度环形光源负责划痕，一个低角度面光源负责脏污，再加同轴光补充反光区域。相机参数上，曝光时间设定为800微秒，光圈定在F5.6，ISO固定为100。这个三件套组合，让同一台相机通过切换光源就能得到两种“不同视角”的图像，给模型喂了双重信息，鲁棒性瞬间提高。

4.2 图像采集与自动触发

相机装好之后，我开始配置图像采集触发。产线上的产品走到检测工位时，会遮住一个光电传感器，传感器给出一个上升沿信号，传给PLC，PLC通过IO卡触发相机采集。这里的关键是触发延时。产品到达工位和相机实际曝光之间存在一段机械延迟，需要实测几次调整延时参数，确保捕捉到的是产品完全进入视场的画面。延时设置不准，拍出来的图是半截产品，模型推理结果基本没有意义。

触发方案稳定后，我先跑了300件产品的预采图，直接在屏幕上逐张看，发现几个问题：

• 个别产品因为姿态没摆正，拍出来有阴影；
• 某些反光材质产生了光斑；
• 输送线的振动导致轻微运动模糊。

解决方式分别是：增加定位导向条（机械上解决姿态问题）、改用偏振片（消除反光光斑）、把曝光时间从800微秒压到500微秒（减少振动影响）。这些问题如果不提前发现，等模型上线后就是批量误检的根源，所以预采集阶段无论如何不能跳过。

4.3 模型训练与推理测试

图像采集完成后，我执行了下面这段训练脚本（简化版），供参考：

# 安装ultralytics库 pip install ultralytics # 训练YOLOv8s模型，数据配置见data.yaml yolo train data=config/industrial_defect.yaml model=yolov8s.pt epochs=100 imgsz=640 batch=16 lr0=0.01 device=0

我写好的industrial_defect.yaml大致是这样的：

train: ./datasets/images/train val: ./datasets/images/val test: ./datasets/images/test nc: 3 names: ['scratch', 'dent', 'stain']

训练完之后，我不会只盯mAP数字，还会跳出指标，把验证集上的预测框逐张可视化出来，直接用眼睛看几个问题：有没有把背景纹理误检成缺陷？有没有把密集缺陷合并成一个框？边界框是不是紧贴缺陷边缘？这些问题只靠mAP体会不到，必须人工看。我在这一层发现了两次模型把光斑当缺陷的情况，后来通过把光斑样本加进训练集，并且去掉光源反射过强的图片，才压制住。

推理阶段，我用OpenCV写了个很小的封装函数：

import cv2 from ultralytics import YOLO model = YOLO("best.pt") def inspect_image(img_path): img = cv2.imread(img_path) results = model.predict(img, conf=0.45, imgsz=640) detections = results[0].boxes return len(detections), detections.xyxy.cpu().numpy()

4.4 与产线PLC通讯及看板展示

推理结果怎么给到产线？我选了Modbus TCP写寄存器，简单稳定。下面是一段核心功能码示例：

from pymodbus.client import ModbusTcpClient client = ModbusTcpClient("192.168.1.20", port=502) client.connect() # 寄存器地址1存OK计数，地址2存NG计数 client.write_registers(1, ok_count) client.write_registers(2, ng_count)

PLC侧只要周期性读取保持寄存器，就能把信号转换为输出继电器，驱动分流挡板。这里的调试点主要是通讯周期。我最初设置1秒刷新一次，但产线速度高，1秒的延迟可能让几十件产品跑过检测工位，后来改成PLC主动读取工控机里存储的最新检测结果，刷新周期压到100ms，才满足现场需求。总结一句：通讯方案越简单越可靠，别搞复杂协议。

看板方面，我用Grafana连接MySQL，按分钟聚合数据，显示当前班次的实时产量、缺陷率、缺陷排行，以及历史趋势曲线。看板部署在工控机上，通过局域网内任意电脑浏览器访问，产线班组长和管理人员随时能看，完全没有障碍。这一层虽然技术含量不高，但对项目价值的直观体现帮助极大，老板进车间一眼就看到了“AI带来的变化”。

4.5 性能调优与流程固化

系统跑通之后，我启动了一个为期一周的“影子运行”模式——AI视觉正常输出，但产线仍以人工判定为主，AI结果并排展示不参与实际分流。这一周的目的，是拿到AI和人工判定的一致率。我设定了一个容忍线：AI和人工在缺陷类型判定上的一致率必须达到95%以上，否则就分析分歧样本，决定是调阈值、补数据还是改算法。

一周影子运行下来，一致率约96.3%，算过了关。之后才真正接入分流机构。上线首周，漏检率从原来人工的0.8%降到0.2%以内，误检率控制在2%以下，产线单件检测节拍1.2秒，满足原本的1.5秒节拍要求，效率直接拉满不是夸张。整个项目从调研到稳定运行，一共用了约两个月，我把它固化成了三份文档：安装调试手册、模型迭代SOP、异常处理流程，后面即使换人维护也不慌。

5. 实战中踩过的坑：问题现象、排查思路与解决实录

5.1 缺陷样本不足，模型漏检新高发

第一个阶段，模型对划痕的召回率很高，但有一类“隐形缺陷”——装配缝隙过大，模型几乎完全没抓到。查了训练数据发现，这类缺陷在样品里占比极低，只有不到2%，模型根本没看过几个。

解决思路有三条：一是定向采集，手动做了一批带有装配不良的样品，专门补拍；二是数据增强，对这类已有样本做更强的随机形变，模拟不同角度的缝隙变化；三是阈值调整，因为这类缺陷信号本来就弱，我单独把该类别的置信度阈值从0.45降到0.35。三管齐下，虽然整体误检率略有上升，但漏检问题明显改善。这类“冷门缺陷”处理，核心原则就是别一刀切用统一阈值，按类别差异化配置是必要的。

5.2 环境光干扰，检测稳定性和光照强相关

项目上线第三周，有两天早上产线的误检率突然飙升，从2%跳到8%。排查后发现，产线窗户方向朝东，早晨阳光直射进车间，导致被测物体表面出现了不规则光斑，模型把光斑当成了脏污或划痕。

这个问题的根源是环境光的不可控。我除了建议车间拉上遮光窗帘之外，还在算法层做了一个“光照补偿”预处理：每次开始检测前，先采集一张当天空背景图，用当前图像减去背景图的均值偏差，再进行推理。这样相当于动态把环境光的偏移给校正掉了。这一步改动之后，误检率从8%压回2.5%以内。如果你无法完全控制环境光，这个办法强烈建议加上。

5.3 模型推理速度变慢，帧率跌到不足5fps

部署一段时间后，某天突然发现单张图推理时间从6ms涨到190ms，产线不停报警。检查一圈发现，是因为系统更新时把CUDA和PyTorch的版本升了，TensorRT引擎没有重新构建，导致模型自动回退到CPU推理模式。这类问题通常在系统升级后出现。解决方案很粗暴：回滚到旧版本依赖，重新生成引擎；同时给工控机设置了更新白名单，只允许安装经过测试的依赖版本，避免再次发生。

强烈建议大家把部署环境的版本依赖锁死，用Docker或conda环境做隔离。产线环境最重要的是稳定，“升级一时爽，产线火葬场”这句话，搞过生产系统的人都懂。

5.4 检测结果上报延迟，PLC侧判定滞后

联调第三天，PLC反馈说“产量的计数器有时候不涨”。排查后发现工控机侧写入寄存器的周期是500ms，但PLC的程序扫描周期只有50ms，期间寄存器可能会被覆盖多次。我在写入端加了互斥锁，并改用先读后写的方式，保证PLC端每次读取到的都是同一批次的最新结果。其实最稳妥的方案是工控机给PLC发一个“检测完成”脉冲，PLC再主动读取数据，这样可避免乱序。这个改完后，通讯一次都没再出问题。

5.5 标注不一致，模型学习目标混乱

标注环节我特意虚惊了一次。让两个标注员同时标注同一批500张图，比对后发现有将近60张图的标注框位置或标签不一致。原因很简单：某些浅缺陷肉眼确实不明显，但机器的成像又很清楚。最终解决办法是制定了一版标注规范，写明每类缺陷的最小标注尺寸、边界框覆盖范围，以及模糊样本的仲裁流程。规范的标注比标注工具本身重要得多，我强烈建议前期花两小时把标注规范写明确。

6. 项目落地后的实际效果与个人心得

6.1 效率提升与质量数据的直接价值

系统正式运行三个月后，我做了一次完整复盘。数据直接说话：漏检率从人工阶段的0.8%~1%压到了0.1%；误检率稳定在1.5%左右，返工和浪费大幅减少；单件检测节拍1.2秒，和产线“无缝衔接”；质检员从两个岗位减到一个复判岗，人员的劳动强度显著下降，而薪资不变的情况下工作满意度反升，因为不再需要盯屏半小时就疲劳。

更深层的价值在质量数据。过去工厂只知道“今天有多少产品不合格”，但现在能看到“这几个缺陷集中在哪个工位、哪个时段、哪种批次”。有一周数据表明，划痕类缺陷主要集中在周二下午，排查后发现是某台设备的润滑油漏滴造成的。这个发现直接驱动了一次预防性维护，避免了批量报废。这就是“AI质检”从检测工具升级为质量管理工具的过程——它不只是一个传感器，而是整条产线质量的“CT机”，把隐性问题显性化。

6.2 对智能制造和AI Agent的再思考

回看这个项目，我深刻体会到“智能制造”不是买几台机器人、接几个传感器就算了。真正让产线“智能”起来的，是数据闭环：感知层（相机采集）、认知层（模型判断）、决策层（分流控制）、行动层（返修或追溯）。这一闭环跑通后，才谈得上持续优化和自适应。现在很多人开始讨论AI Agent在工业场景的潜力，我觉得质检恰好是很好的切入点——它任务边界清晰、数据天然产生、结果可量化，非常适合未来引入AutoML自动训练、自动调参，甚至自动生成检测方案的智能体。你在产线上攒下来的图像数据，就是训练这些智能体最好的养料。

6.3 给后来者的几点建议

第一，先跑通流程，再追求精度。不要想着一口气把模型调到99.9%，那是无底洞。框架通了、数据通道顺了、界面能看了，后面优化都是迭代的小事。第二，坚持所有改动可追溯。模型版本、训练参数、数据集版本、部署时间都必须能查得到。我做了一个简单的版本记录表，每次模型更新必然填写更新说明，这个习惯在项目后期排查问题时帮了我大忙。第三，不要忽视非技术因素。产线工人的接受度、管理层的期望管理、跨部门沟通，这些“软问题”比算法难搞十倍。我在上线前专门开了两次培训会，让产线工人知道这套系统是帮他们减负的，而不是来抢饭碗的，后面配合度完全不一样。

最后分享一个小技巧：每天下班前，花半小时看一眼当天的检测数据分布。哪类缺陷变多了、哪些缺陷集中出现在某个时段，都能从图像里看出端倪。这个习惯帮我提前发现过两次工艺异常，比领班发现问题还早。AI机器视觉这套东西，落到产线上不是为了取代谁，而是把人的精力从重复劳动里解放出来，去做真正需要判断力的事情。这也是我做这个项目最大的成就感来源。