企业官网建设流程全解析

帮朋友调试一条金属零部件产线的时候，我才真正确定一件事：工业现场最缺的不是单个算法，而是一条能把图像采集、检测、数据标注、模型训练串起来的完整链路。那天晚上我们对着几百张弹簧片缺陷图一张张筛，旁边相机还在一刻不停抓图，数据从采集到分析完全靠U盘拷贝。后来我把自己积累的这套系统整理好，在gitcc上开源了，包含工业图像采集、智能检测、数据标注、模型训练四大模块，希望给同样在产线里折腾视觉方案的人一个能直接用的起点。

这套系统不是那种只能跑通Demo的研究型玩具。它的目标很直接：让一个不熟悉代码的工艺工程师，也能把一条产线的视觉检测能力从零搭建起来；也让算法工程师不用每次都从相机厂商SDK开始造轮子。下面我不按“项目简介”那种写法介绍它，而是把每个模块当时是怎么设计的、踩了哪些坑、为什么这么选型，统统摊开讲。

1. 为什么要在工业现场“自带干粮”做一套训练系统

1.1 工业场景AI落地的真实痛点

我见过太多做工业视觉的团队，起点完全一样：花两周调通了某个检测模型，在自建数据集上准确率到了99%，结果一到产线现场就崩。原因几乎都出在系统链路断裂。

产线端的数据和算法端的数据通常不互通。车间里一台工控机连着相机，每天产生几千张图像，图像只用来给老师傅回放，没人做结构化归档。算法工程师拿到手的往往是几十张“精心挑选”的缺陷图，没有背景变化、没有光照差异、没有时间戳信息。模型训练出来之后，又发现采集帧率和检测速度对不上，相机的曝光设置和训练数据里的图像风格也不一致。最后整个项目卡在了“算法能用但系统不能用”的尴尬地带。

我在这套开源系统里做的第一件事，就是先把这四个环节定义清楚：图像采集负责把相机画面变成带元数据的标准化图像，智能检测负责在标准化图像上做缺陷分析，数据标注负责把检测结果和人工经验沉淀成训练数据，模型训练负责把标注数据变成新的检测能力。四模块之间通过统一的数据格式和时间戳协作，谁也不用猜上游给过来的文件是什么。

1.2 四模块协作逻辑：不是四个工具拼在一起

有人可能会说，采集用相机厂软件，标注用LabelStudio，训练用Ultralytics，不也能拼起来？能拼，但拼接的成本很高。相机厂软件导出的文件名是乱码，LabelStudio导出的是JSON，训练脚本只吃目录结构，三套体系之间的转化工作最少要花掉一个工程师两周时间。

这套系统把协作逻辑前置到模块设计里。图像采集模块输出的是seq_id + timestamp + camera_id + image_path这样的结构化索引，任何后续环节都可以通过image_id关联到原始图。检测模块的输出也不只是一张画了框的图，而是一份JSON结果，字段里包含缺陷类别、置信度、ROI坐标，同时给出“这个ROI是否被人工复核过”的标记。标注模块读取这份JSON作为预标注结果，人工确认之后直接生成训练集。训练模块训练完又回到检测模块做增量验证。

说白了，这套系统本质是围绕“图像数据资产”设计的，算法只是其中的消费方。这也是为什么我把数据采集放在架构第一位，没有干净、稳定、可追溯的数据源，后面所有训练都是空中楼阁。

1.3 开源的意义：让每条产线都能长出不同的算法

开源这套系统的初衷不是想让大家直接拿去用一个完整产品，而是给每个产线团队一个可拆卸的骨架。不同行业的缺陷长得完全不一样——弹簧件的划伤、电池表面的凸点、织物的瑕疵、药片的外观缺角，底层图像处理逻辑却是相似的：先把目标从背景里分离出来，再判断目标是否异常。

如果这套系统能让一个做纺织检测的团队省掉对接相机SDK的功夫，让一个做PCB检测的团队省掉写标注转换脚本的功夫，让他们把精力全部放在自己行业特有的缺陷特征上，那它的价值就实现了。我在gitcc选择开源，也正是希望这套代码能变成“每个团队二开的基础”，而不是一个封闭的“黑盒成品”。

2. 图像采集：把产线画面“可信任”地搬进硬盘

2.1 相机选型：工业相机和普通摄像头之间的差别

图像采集模块支撑两类输入源：一类是真工业相机，一类是普通USB摄像头或本地视频文件。很多人最开始贪便宜，直接买了个几百块的高清摄像头接上去，发现产线上工件一动就拖影，或者画面亮度忽然跳变。原因在于普通摄像头用的是卷帘快门，逐行曝光，运动物体一拍就是斜的；工业相机用的是全局快门，整个传感器同时曝光，高速运行下也能定格清晰画面。

所以如果你要拍的是传送带上的移动工件，至少选一台支持全局快门的工业相机。不需要一上来就上几万块的智能相机，千元级的入门工业相机加一盏合适的工业光源，效果已经能超过多数配置方案。品牌方面，海康、大华、Basler、映美精都很常见，系统里通过厂商SDK做了适配层，枚举设备、初始化、抓帧、停止抓帧这些动作统一封装成接口，换品牌时不需要改上层代码。

帧率这块也得提前算：假设产线节拍是每秒生产5个工件，每个工件需要在视野里停20毫秒，相机只给一个硬触发信号，那么实际需要的帧率不是越高越好，而是要和PLC信号联动。帧率设太高，硬盘空间会疯涨，一张500万像素的BMP图就是十几MB，连续跑一天能产生几百GB数据。合理做法是只在触发信号到来时抓一帧，并保留原始流做一定时间的循环缓存，等确认这一批工件稳定后再决定要不要全部落盘。

2.2 两种接入路径：相机SDK与网络流

相机接入我做了两条路径。第一条是SDK直连，系统启动时通过厂商SDK枚举所有在线设备，用户在下拉列表里选择一个相机开始采集。以海康MVS为例，核心流程可以用下面这段伪代码表达：

# 伪代码：工业相机接入流程 from camera_adapter import CameraFactory cfg = { "brand": "hikvision", "serial_number": "XX123456", "trigger_mode": "hardware", # 硬触发：外部信号到了才拍 "exposure_time_us": 2000, # 曝光时间：2ms，防止拖影 "pixel_format": "Mono8", # 8位灰度，工业检测常用 "save_dir": "/data/2025/01/15/camera01", } cam = CameraFactory.create(cfg) cam.start(record_meta=True) # 每收到一帧，模块自动写入 JPEG + 同名 meta.json # meta.json 里包含时间戳、曝光参数、触发源编号

第二条路径是网络流，比如已经部署好的RTSP摄像头或者历史视频文件。这条路径适合旧产线改造——不需要动现有的相机网络，直接把RTSP地址填入配置，系统就能把画面抓进来。这两种路径最终都统一成内部“帧源”对象，上层检测模块不关心这帧图像来自相机还是来自视频文件，只用统一的接口取帧。

2.3 存储与时间戳：让每张图都可追溯

存储设计是这套系统里最容易被低估的部分。检测做到后面，你会发现大部分时间不是在调模型，而是在追数据：这张图是什么时候拍的？当时曝光多少？是哪个相机拍的？传送带速度多少？如果存储结构里没有这些信息，溯源时只能抓瞎。

我采用的目录结构是日期/相机编号/序号.jpg + 序号.meta.json。meta文件里记录触发时间戳、曝光参数、光源状态、PLC信号对应的工件编号。这样当模型出现批量漏检时，可以快速查出来“是不是那段时间车间换了一盏灯导致亮度偏移”，而不是对着图片发呆。采集模块还内置了环形缓存：图像先写入内存队列，后台线程按磁盘速度落盘，不会因为某一次磁盘写入抖动而丢帧。

另一个细节是图像格式。工业检测对图像质量敏感，但原始BMP存储成本太高。实测下来，高质量JPEG（质量参数95以上）对检测准确率影响很小，存储体积却只有BMP的十分之一，所以系统默认用JPEG落盘。真正需要精细测量尺寸的场景，再考虑无损PNG或RAW格式。

2.4 采集环节最容易踩的坑

第一个坑是拖影。产线传送带速度变化，固定曝光时间很可能拍糊。解决思路不是盲目调高快门，而是要同步提升光源亮度。常见做法是加一个带漫射板的条形光源，让工件表面亮度均匀，这样曝光可以压到1ms以下仍然不暗。

第二个坑是环境光污染。白天车间窗户照进来的太阳光，会让同一台相机在下午三点和早上九点拍的图灰度分布完全不同。这个靠后期算法做归一化能缓解，但治标不治本。真正可靠的办法是在相机和工件之间加物理遮罩，框定一个相对封闭的拍照空间，把环境光变化挡在外面。数据层面我提供了一个“光照漂移检测”小工具：连续统计最近1000张图的平均灰度，如果变化超过设定阈值，就把告警推到日志里，提醒现场人员检查光源。

第三个坑是弱纹理目标在灰度图下丢失。有些工件是深色塑料件或者反光金属面，普通灰度相机拍出来的目标区域跟背景对比度极低。遇到这种场景，控制台会提示用户优先使用RGB彩色相机或增加偏振光源，而不是把问题甩给后面的算法去硬扛。采集阶段解决90%的图像质量问题，比任何模型都更便宜。

3. 智能检测：先用传统视觉接住90%的活，再让模型做更聪明的判断

3.1 两级检测流水线：规则前置，模型后置

很多开源项目一上来就是“YOLO识别一切”，但真正做过工业交付的人都知道，模型用得太泛，现场调试时往往很痛苦。深度学习模型的问题是“置信度”不完全等于“可信度”，一旦出现训练集没见过的新情况，它经常自信地给你一个错误结果。

这套系统的智能检测模块采用两级流水线设计。第一级是传统机器视觉算子，负责把“候选区域”找出来；第二级是深度学习模型，负责对候选区域做精细化分类。前置规则层跑得快、逻辑透明、任何数值结果都能解释；后置模型层负责处理那些传统算子搞不定的复杂纹理差异。

以弹簧片检测为例，前置层做的是：灰度化→Otsu阈值分割→形态学闭运算→连通域分析→按面积、长宽比筛出每个工件区域。这个步骤把图像从“2000×3000的整张大图”缩小成“若干个小区域”，后续模型只需要看区域内部，检测精度自然提高，计算量也大幅下降。

3.2 为什么不是端到端直接上一张网络

端到端方案听起来简单，实际有几个绕不开的问题。

第一是训练数据成本。YOLO要定位小缺陷，需要大量精确标注的边界框，而传统算子已经能把目标区域稳定框出来，模型只需要学会在区域里判断有没有问题。这样标注需求从“画框”降级为“给区域打标签”，标注成本差一个量级。

第二是算力负载。整张图直接跑检测模型，对GPU或边缘盒子的算力要求都很高。两三百块钱的Jetson Nano这种低算力设备，跑整图YOLO基本跑不动；但如果只是对前置层筛出来的几十个ROI跑分类，CPU都能应付。

第三是可解释性。产线上出了问题，老师傅会问“你为什么认为这个件是NG品”。两级流水线可以回答：因为传统算子在坐标(1200, 800)处找到一个连通域，其纹理特征不满足良品模型。这个回答是能被人工验证的。而端到端模型只能给一个置信度数字，说服力显然不够。

有人可能会问：那YOLO这类模型在这套系统里是不是就没用了？当然有用。它更适合的场景是：目标本身不固定、没有稳定几何规则的件，或者缺陷面积很大、直接整图检测也够用的情况。系统里保留可选的YOLO检测分支，供大家对“大目标缺陷”和“多目标定位”直接使用。对于小缺陷、微弱纹理差异，我的建议始终是ROI分类路线更稳。

3.3 传统视觉算子的合理用法

传统算子不是死板地写一堆“魔法数字”。以弹簧片检测的前置层为例，阈值分割用的是Otsu算法自动计算二值化阈值，而不是人工指定一个固定值。如果现场光照发生缓慢漂移，Otsu会跟随灰度直方图的变化自动调整，比写成固定阈值鲁棒很多。

形态学处理的参数要根据目标物理大小设定。弹簧片在500万像素图像里大约占600×300像素，闭运算的核大小设为5×5足够把工件内部的细小断裂缝补齐，又不会把相邻两个工件粘在一起。这些参数不是靠猜，而是在采集一批现场图像后，把ROI面积分布直方图画出来，看不同参数下的连通域数量变化，取一个能稳定分离目标与噪声的区间。

系统里还会自动记录每次前置层的中间结果图像，包括二值图、形态学结果图和候选框叠加图。这样一旦发现候选框漏掉了某个区域，直接看中间图就能判断是哪一步算子丢的，不用反复推理。

3.4 深度模型到底在判断什么

这套系统里的深度模型主力是ResNet34分类网络，专门用来对ROI区域做良品/不良品分类。为什么选ResNet34而不是更大的ResNet50/101？因为工业缺陷分类任务有一个特点：类别通常不超过十个，训练样本往往只有几百到几千张，用几十层的大网络很容易过拟合，训练时间长，推理速度也慢。ResNet34在ImageNet上预训练过，特征提取能力足够支撑多数工业纹理分类任务，配合迁移学习在小样本场景下表现最稳。

对于需要定位缺陷位置的任务，系统里提供YOLOv8的扩展分支。YOLO适合缺陷本身就比较“大”的场景，比如表面明显凹坑、大块脏污；如果缺陷是几毫米的划痕，在整图里只占十几个像素，YOLO的锚框机制对小目标并不友好，这时回归到“ROI裁剪+分类”反而能拿到更高精度。

模型输出的不只是“OK”或“NG”，而是带有概率分布的类别：比如“正常0.92，划伤0.06，毛刺0.02”。我们不看简单argmax，而是让用户设置每个类别的置信度阈值。对于“划伤”这种漏检代价高的类别，阈值可以调低到0.5，宁可多判几个可疑件给人工复检；对于“油污”这种误检代价高的类别，阈值调到0.9，保证不误杀良品。

3.5 一个完整案例：弹簧片表面缺陷检测链路

用一个真实案例把整条链路串起来。产线背景是传送带匀速运动，弹簧片在背光光源下通过检测工位，相机收到PLC触发信号拍摄一张灰度图。

1. 采集模块把图写入检测队列，附带上当前PLC号。
2. 检测模块读取图像，执行Otsu阈值分割，得到掩码。
3. 形态学闭运算消除弹簧片内部因冲压产生的细微断裂伪影。
4. 连通域分析提取所有候选区域，计算每个区域的外接矩形坐标。
5. 通过面积阈值筛掉灰尘、飞溅颗粒等小噪声区域，得到最终候选ROI列表。
6. 每个ROI被裁剪下来，缩放到224×224，送入ResNet34分类器。
7. 分类器输出每个ROI的类别与置信度，模块根据预设阈值判定OK/NG。
8. 检测结果写入JSON，同时把ROI小图和整图缩略图一并保存，方便人工复查。

这个链路的判定逻辑很透明：哪个工件NG、为什么NG、对应哪个区域，每一步都有据可查。把几个方案对比放在一起看，会更清楚为什么我采用两级方案。

4. 数据标注：比训练更耗时间的环节，值得设计一套半自动方案

4.1 标注标准先定好，不然返工到崩溃

数据标注是工业AI系统里最不起眼、最容易返工的部分。我刚做这个项目时，标注规范只有一行字“把坏的图挑出来”，结果两周后训练出来的模型在产线上把一批正常工件误判成NG。复盘才发现，标注员把“带指纹的弹簧片”标成了“划伤”，把“轻微压痕”标成了“正常”。类的边界没定义清楚，标注越多，模型越混乱。

系统里我把标注规范做成了可编辑的文档，并在标注界面上把每个类别的“示例图”和“反例图”挂出来。标注入手前必须完成一轮培训：划伤指的是工件表面呈线条状的摩擦痕迹；压痕是受力导致的局部凹陷；同样的凹坑，如果带油污，就分开建“油污”和“凹坑”两类，不搞合并。类别体系的黄金法则是：宁可类别多一点，也不要让一个类包含两种物理成因，否则模型学到的特征会互相打架。

4.2 半自动预标注：先把人工从画框里解放出来

工业缺陷标注最大的痛点是：正常件好标，缺陷件极难标。正常件整张图点一个“OK”就行，缺陷件要看半天才敢下结论。这套系统利用已有的检测模型做半自动预标注：先用上一版模型对未标注图跑一遍，把置信度高的ROI自动生成候选标签，标注员在界面上只需要确认“对”或“不对”，不对的拖一拖锚点修正位置。

实测下来，一个500张的批次，纯手动标注大约需要5到6个小时，用预标注流程后压缩到1.5小时左右。这提升不是模型有多准，而是减少了标注员从零开始的“决策时间”。系统支持多人同时标注，每个标注员的意见会记录到审计日志里，出现分歧时项目负责人可以回溯到具体某张图，做最终的仲裁。

4.3 小样本困境与数据增效策略

工业现场有个残酷现实：缺陷样本永远非常少。一条稳定运行的产线，一天可能只产生10个缺陷件，其中还有5个是重复缺陷。训练集里正常样本几千张，缺陷样本只有几十张，模型很容易偏向预测“正常”，漏检率极高。

系统内置了针对小样本的数据增强工具，重点不是花哨的生成对抗网络，而是先做物理合理的扰动：

这些增强手段不是随便叠加，每一项都要保证“增强后的图像在产线上真的可能出现”。如果产线光照很稳定，亮度增强幅度就小一点；如果相机有震动，模糊增强就多一点。增强只是采样策略，核心还是把原始样本的质量控制好。

另外，我还加了一个缺陷合成工具：把真实的瑕疵区域从标注样本中抠出来，通过透明度混合粘贴到不同背景的正常工件图上。这样模型学到的是“局部纹理异常”，而不是“背景记忆”。大量实践证明，合成样本做辅助训练能显著降低误检，但不能完全替代真实样本，合成比例一般控制在30%以内。

4.4 标注格式统一：LabelStudio导出后还要做一层转换

工业项目里标注工具的选择，我推荐LabelStudio，原因很简单：支持多人协作、支持JSON导出、支持分类、矩形框、多边形等多种标注类型，部署也方便。打开热词里提到的“labelstudio 编译”我知道有团队想从源码编译安装，我之前也折腾过，结果卡在Node和Python的依赖版本匹配问题上。实际没必要死磕源码编译，直接跑官方Docker镜像或者用打包好的预编译版本最省事，数据一样能导出，折腾源码不是核心需求。

不过LabelStudio导出的JSON格式和训练脚本要求的格式并不直接兼容。我在标注模块里写了一个转换脚本，把LabelStudio导出结果统一转换为系统内部的中间格式，再进一步转成分类训练目录或YOLO的txt格式。这一步的代码逻辑不复杂，但价值很高，它让团队可以随时换标注工具而不影响训练流程：

# 伪代码：LabelStudio导出JSON 转分类训练目录 import json, shutil from pathlib import Path # label_studio_export.json 是标注平台导出的原文件 with open("label_studio_export.json", "r", encoding="utf-8") as f: data = json.load(f) for item in data: img_id = item["id"] src_path = Path(item["file_upload"]) # 找到标注结果里类别字段，生成 标签/图片名 的结构 for label, bbox_list in collect_labels(item).items(): out_dir = Path("train_data") / label out_dir.mkdir(parents=True, exist_ok=True) shutil.copy(src_path, out_dir / f"{img_id}.jpg")

5. 模型训练：迁移学习为主线的训练方案与训练参数经验

5.1 先想清楚训练目标：分类还是检测

很多人一上来就问“能不能用YOLO”，但我的经验是，先回答两个问题再选模型：你只需要知道工件有没有问题，还是需要知道问题在哪里？只需要判断“这个弹簧片是否NG”，分类模型就够了；如果要指导机器人做飞料剔除、标注缺陷位置，才需要目标检测模型。

这两个目标对应完全不同的训练流程。分类训练的成本低、样本要求低、推理快，往往能满足产线95%的需求。检测训练需要画框标注、NMS后处理、mAP评估，复杂度直接上一个台阶。所以在这套系统里，模型训练模块默认以ResNet34分类为主，YOLO检测作为可选扩展。这个选择不是技术上的保守，而是从项目长期维护成本里得出来的经验。

5.2 迁移学习：小样本工业项目的救命稻草

工业缺陷训练集通常只有几百张图，从头训练一个ResNet34几乎不可能收敛。这里必须有迁移学习：加载ImageNet预训练权重，把模型在1亿张自然图像上学到的纹理、边缘、形状基础特征迁移到工业场景。训练阶段分成两轮：

• 第一轮冻结backbone，只训练最后的全连接分类层，学习率设为1e-3。目的是让分类头先适配工业数据的类别分布。
• 第二轮解冻最后几个残差块，这一次学习率降到1e-4，用很小的步长微调前面的特征层，让模型逐渐适配工业图像的纹理差异。

实际操作时，两轮训练要用同一个验证集严格监控，防止第二轮在小样本上过拟合。如果第一轮验证集准确率已经很高（95%以上），第二轮微调的收益就有限，可以大胆省略。如果第一轮准确率不到90%，说明前置采集或者标注质量有问题，这时候不要急着调模型，回去看数据。

如果你要训练的是文字、字符类缺陷，系统里预留了OCR模型的扩展接口，可以用EasyOCR开源模型做微调。但我的建议是：OCR类需求先评估一下有没有必要，很多产线只需要判断字符是否清晰、是否错印，这个用普通分类也能做，OCR反而引入了语言模型的复杂度。

5.3 训练配置：一份可复现的模板

为了让训练过程可复现，系统把训练超参统一放在YAML配置文件中，任何人拉到项目后都能通过同一份配置复现训练结果：

model_type: resnet34 num_classes: 4 pretrained: true training: epochs: 50 batch_size: 32 lr: 0.001 lr_scheduler: cosine optimizer: adamw weight_decay: 0.0001 val_ratio: 0.15 freeze_backbone_epochs: 10 early_stop_patience: 10 augmentation: brightness_range: [0.8, 1.2] rotation_degree: 10 blur_kernel_size: [3, 5]

batch size这块要特别说下：batch size受显存限制，小显卡用8也没问题，但学习率要相应下调。经验公式是学习率与batch size的平方根成正比，batch size从32降到8，学习率大致降到原来的0.5到0.6，保证收敛轨迹相近。另外工业场景样本类别极不平衡，统计指标不能只看准确率，要同时看每类的recall和precision。我的目标通常是：在保证recall不低于99%（漏检代价高）的前提下，尽量提高precision降低误检。

对于“正常类占95%、缺陷类占5%”这种分布，我会在损失函数里给少数类加权，交叉熵的class weight按样本数反比设置。这个不那么“干净”的操作，能有效防止模型把所有样本都预测成正常类。

5.4 前向传播与反向传播的直观理解

训练过程中的“前向”和“反向”经常被当成黑话，我用一个简单的类比说明。前向传播就是模型做一次“答题”——图片输入后逐层提取特征，最后输出一个“它是划伤”的概率。反向传播就像老师批改作业——拿模型预测结果和真实标签对比，算出差异（损失），然后沿损失下降最快的方向调整模型的参数，让下一次答得更接近正确答案。

训练epochs就是反复“做题-批改-订正”的过程。50个epoch的意思是把整个训练集重复过50遍。刚开始模型会很快收敛，到后面就会出现验证集指标不再上升甚至下降的情况，这就是过拟合信号，说明模型开始死记训练集里的噪声了，这时候早停机制会把模型回滚到验证集表现最好的那一个检查点。

理解这个概念有什么实际意义？它帮你在训练出问题时定位根源：验证集和训练集指标都低，说明模型欠拟合，要加大训练轮次或调整结构；训练集指标高、验证集指标低，说明过拟合，要加正则化、增强或者减少特征层解冻幅度；两个指标都不稳定，说明数据本身有问题，比如标注噪声太大或者类别边界不清。

5.5 ONNX导出与部署推理：容易翻车的几个细节

模型训练完成后，我一般都会导出为ONNX格式再部署，而不是直接在训练框架里做推理。ONNX的优势是跨平台、跨语言，不管后续用ONNXRuntime、TensorRT还是OpenVINO，都能无缝加载。但导出过程中有几个细节特别容易出错：

归一化方式必须完全一致。训练时用ImageNet的mean和std做归一化，部署时如果忘了导入或者顺序填反，图像输入分布就会偏移，推理准确率可能掉好几个点。导出前我习惯用同一张图在训练框架和ONNXRuntime各推一次，比对中间层输出是否一致，误差控制在1e-5以内才算通过。

输入尺寸必须固定。ONNX导出时输入张量是固定的224×224，部署端resize时要注意插值方法和训练时保持一致。ResNet训练用的是双线性插值，如果你部署端用最近邻插值，小目标缺陷的细节就会受伤。

YOLO扩展分支导出时，后处理阶段（NMS）在不同版本里差异很大。有的版本把NMS封装在模型内部，导出时直接给你一组过滤后的框；有的版本需要你在外部自己实现。我在项目里做了一个兼容层，检测部署前会把两种后处理模式都测一遍，确保输出格式一致，避免“训练时检测很准，部署后框位置全乱”的诡异问题。

6. 开源之后：项目管理要让别人能“搬走就启动”

6.1 项目目录结构与上手路径

代码写得再好，README不清楚，别人也很难用起来。这个开源项目我按照四模块划分目录，每个模块自带README和测试用例，保证一个新团队克隆代码后，10分钟内能跑通一条最小链路：

industrial-ai-training-system/ ├── collector # 图像采集模块 │ ├── camera_adapters/ # 海康/大华/USB/RTSP适配层 │ └── storage/ # 图像落盘与元数据管理 ├── detector # 智能检测模块 │ ├── rule_engine/ # 传统视觉算子 │ ├── roi_classifier/ # ResNet34分类推理 │ └── yolo_detector/ # YOLO检测扩展 ├── label_workspace # 数据标注模块 │ ├── conversion/ # LabelStudio格式转换 │ └── prelabeling/ # 半自动预标注 ├── trainer # 模型训练模块 │ ├── configs/ # YAML训练配置 │ └── scripts/ # 训练/评估/导出脚本 ├── deploy # ONNX导出与推理示例 ├── docs └── tests

上手测试建议先用tests目录里提供的几张示例图片跑一遍检测链路，确认环境没问题后，再开始接入自己的相机。直接接相机调试报错时，很难分清是SDK问题还是系统问题，先用示例数据排除干扰是最高效的方式。

6.2 开源许可证选型：不是随便勾一个

开源不是把代码往仓库一丢就完事。许可证选型直接决定别人能不能放心用你的代码。Gitee上创建仓库时经常问“开源许可证选什么”，我见过不少项目随便选了GPL，结果企业客户看了直接放弃，因为GPL的传染性要求基于它做的修改也要开源，很多工厂的产线程序涉及商业机密，根本不敢碰。

这个项目我用的是Apache 2.0。原因很简单：我希望企业客户在接入这套系统时没有合规顾虑，他们改造后的检测逻辑可以不开源，但必须保留对原始部分的版权声明。这样既保护了代码最基础的权益，也不会把潜在的企业用户挡在门外。

6.3 给打算改成自己产线系统的人几点建议

最后分享几条代码之外的经验。第一，上线前先在产线旁边跑一周“影子模式”，也就是系统照常采集、照常检测，但不参与任何自动剔除动作，只把结果记录下来跟人工判定的结果对比。这一步能积累大量真实环境数据，同时避免一上线就出事故。

第二，新产线接入时，不要指望一次把所有缺陷类型都搞定。先选一个误检风险最低、现场最重视的缺陷类型跑通，再逐个增加新类别。每增加一个类别，都要重新标注、重新训练、重新Shadow验证，形成固定的升级节奏，而不是一次性塞给模型一堆杂乱数据。

第三，整个产线系统一定要做离线回放。采集模块支持将产线视频保存为回放文件，检测模块可以读回放文件进行复现。这样遇到现场问题时，不用停机调参，离线把那一段图像导入系统，反复修改参数和阈值，确认效果后再上产线验证。这个工作流让调试效率提升了至少一倍，也让我在远程支持项目时能直接复现现场问题。

我在做这个开源项目的过程中最深的一点体会是：采集的数据比模型权重值钱得多。一套靠谱的图像采集系统，配合可追溯的标注规范和透明的检测链路，就已经解决了工业AI落地一半以上的问题。剩下的模型训练，反而是在一个稳定地基上轻松盖楼的过程。希望这套系统的代码和思路，能帮每一位在产线现场摸索的人少走几步弯路。