先聊一个我见过的真实场景某试点河道的运维团队每天要靠人工一张张翻看无人机拍回来的照片两千多张看下来眼神都是飘的最后真正捞上来的垃圾反而靠的是群众举报。这个项目就是冲着这种痛点去的——为智慧河道巡检搭建一套基于 YOLOv12 的河面塑料垃圾检测方案让无人机在巡检过程中自动识别水面漂浮物并生成带位置信息的告警。整套方案从数据集构建、模型训练到边缘部署都有完整的落地路径。如果你正在做环保信息化、智慧水利或者无人机行业应用这篇文章可以给你省下不少试错时间。项目标题虽然很长核心其实就三件事一是把无人机航拍水面垃圾这个场景数据化二是训练一个能落地的目标检测模型三是把模型接进巡检业务流程。YOLOv12 在这套方案里承担的是目标检测引擎用来回答“画面里哪个位置有什么类型的漂浮物”。很多人一开始喜欢纠结模型选型我的看法是YOLOv12 的优势在于实时性与精度之间比较容易拿捏而且周边工具链成熟无论训练、导出还是部署坑都相对少。下面我按一条尽量可复现的路径把它拆开讲重点放在数据治理、训练调参和部署融合这三段最容易翻车的环节上。1. 项目拆解河道塑料垃圾检测到底在解决什么问题1.1 人工巡检的痛点与AI巡检的切入点河道巡检这事儿听起来简单做起来很让人头疼。传统方式无非三种人站在岸边看、坐船巡、或者靠固定点位摄像头。这三种方式都有同一个问题——覆盖密度不够。一条河几十公里真正容易堆积垃圾的往往是桥洞、回水湾、水草聚集区这些“视野死角”岸边看一眼根本看不全。固定摄像头更不用说了只能盯着一个点而且水面反光、雨雾天气都会让画面质量迅速下降。无人机加入之后视角问题解决了但又冒出一个新问题数据量暴涨。以前摄像机是固定机位现在飞机一次出勤能拍几千张照片如果还靠人盯着屏幕看那跟没有无人机区别不大。这时候就必须把目标检测模型加进去让算法先做一轮筛查把含有疑似漂浮物的画面挑出来再交给人工复核。这整条链路才是智慧河道巡检真正的形态无人机解决“能不能看到”AI 解决“看了以后认不认得”人工解决“确认之后管不管”。这个项目把识别范围聚焦在“塑料垃圾”和“水面漂浮物”上表面上是在做垃圾分类本质上是在搭建一套低空视觉感知系统。模型输出的不是一张标注图而是“什么东西、在哪个位置、大概多大”的结构化信息。有了这个信息河道保洁队伍才能从“全网撒网式搜索”变成“精准点位打捞”。1.2 YOLOv12 在无人机航拍场景里的优势选 YOLOv12 不是因为它名字最新而是因为它刚好卡在无人机巡检的刚需上实时、轻量、精度可用。无人机航拍水面垃圾这个场景有几个特有的难点第一是目标小一个塑料瓶在二十米高度拍下来可能只占画面的几十个像素第二是背景复杂水纹、反光、浪花、岸边水草都会干扰判断第三是视角变化快飞机转弯、俯仰的时候目标形状会剧烈变化。YOLO 系列算法经过这么多代迭代在“小目标检测”和“实时推断”这两个维度上积攒了不少设计经验。YOLOv12 在结构上相比前代做了不少调整推理速度依然很快同时在小尺度特征的提取上更友好。相比两阶段检测器它的速度优势很明显相比同类型一阶段算法它的工程化程度和社区资料又更成熟。对于河道巡检这种需要机载端快速处理画面的场景我更愿意选这种“中等体积、高吞吐、易部署”的模型。另外还有一点很实际YOLOv12 的生态支持做得不错训练好的模型导出 ONNX、TensorRT 都很顺畅后期要搬到边缘设备上跑不用重写太多代码。这对做项目交付的人来说非常关键因为模型再准如果没法低成本部署到现场那落地价值就打折了。1.3 为什么自建数据集是关键河道垃圾检测最大的门槛其实不在模型而在数据。公开数据集里针对“无人机俯拍水面垃圾”这种垂直场景的样本非常少。你能找到常规的物体检测数据集但里面大多是自然场景、街景、自动驾驶视角几乎没有反光水面上的小塑料瓶。如果直接拿通用数据集训练出来的模型去飞河道结果大概率是“什么都检不出来”或者“把水纹当垃圾”。所以这个项目的第一步也是最耗时的一步就是自建无人机河道垃圾数据集。需要用无人机真实飞行采集视频再抽帧、清洗、标注最后变成 YOLOv12 能直接训练的标准格式。数据质量直接决定模型上限。我见过不少团队把大量时间花在调参上最后发现瓶颈是训练集里有效样本太少或者标注框很多标错标漏模型怎么调都在原地打转。1.4 项目整体技术链路把完整链路画成一段话就是这样无人机按规划航线飞行航拍视频通过抽帧工具转为图片图片经过初筛和清洗后用标注工具画边界框生成 YOLO 格式的标签再把图片和标签按比例划分为训练集、验证集和测试集组织成 data.yaml 配置随后用 YOLOv12 预训练权重做迁移学习在训练集上迭代多轮验证集上评估 mAP 和召回率反复调整输入尺寸、数据增强策略最终把 best.pt 导出为 ONNX 或 TensorRT 引擎部署到 Jetson 或其他边缘设备上无人机巡检时推理结果叠加无人机的 GPS 和姿态数据换算成垃圾点位的经纬度推送到告警平台。每一步看起来不复杂但每一步都有细节后面我会逐一展开。2. 数据集构建从无人机航拍到标准标注集2.1 飞行采集参数怎么定数据集的源头是航拍素材这一步的采集质量直接决定后续一切。我用项目里常用的行业级四旋翼无人机来举例不必纠结具体品牌市面常见的机型操作逻辑基本一致。飞行高度我建议控制在 20 到 60 米之间。飞高了视野大但目标太小一个塑料袋只有指甲盖大模型根本学不到有效特征飞低了目标清楚但单张覆盖范围太窄巡检效率太低而且对飞行操控要求很高。云台角度建议下压接近垂直俯视最好。垂直视角能最大程度避免岸边的树影、建筑倒影遮挡垃圾目标。如果拍得太倾斜漂浮物看起来就是一条细线边界框画起来很痛苦模型也不容易学。拍摄时还要注意航线规划相邻两张照片之间保持一定的重叠率一般 60% 到 70% 左右这样既可以方便后续抽帧也能避免目标正好卡在画面边缘。光照和气象条件也要挑。我一般避开正午强光因为这时水面反光最厉害塑料瓶和泡沫会被一片白亮盖住。上午九点到十一点、下午三点到五点通常光线柔和一些。微风天气最好水面平静漂浮物形状稳定风太大时浪花反光会严重干扰模型。当然为了训练模型适应恶劣条件我也会刻意收集一些阴天、多云、逆光的素材让模型不至于只在晴天工作。2.2 抽帧与数据清洗无人机飞一趟可能录回来几十 GB 的视频。如果全部按帧存下来不仅存储吃不消里面还有大量重复画面。我通常的做法是按秒抽帧或者按键抽帧配合人工初步浏览先删掉大量无效片段比如纯水面没有垃圾、画面抖动模糊、飞机起飞降落阶段的画面。抽出来的图片还要再做一轮筛选。优先保留有目标的图片、目标大小变化丰富的图片、以及光照和水面纹理复杂度高的图片。那些目标比一个像素大不了多少的人工都认不出来的就不要保留了强行保留只会给标注带来痛苦还给模型制造噪声。数据分布也要尽量覆盖多样化的水域场景。城市河道、郊野河道、工业区外河、汛期排水渠它们的垃圾类型和水体颜色差异很大。我在项目里把采集点分散到不同类型水域并且按季节分批采集确保训练集里既有夏季暴雨后的垃圾聚集照片也有冬季低水位时裸露河岸的场景。这一步看起来很土但恰恰是最能提升模型泛化能力的做法。2.3 标注类别与规范类别设计上我建议先少后多一开始不要贪多。这个项目把类别定成 4 类就够了塑料瓶、塑料袋、泡沫、其他漂浮物。塑料瓶和塑料袋是河道里最常见的白色污染泡沫多为泡沫饭盒和包装碎片其他漂浮物则用来兜住树枝、水草、鞋子等杂物。类别太多会加大标注难度也会让模型在小目标场景下更难区分。关于边界框的标注有一条原则只标能认出来的。假如一个塑料袋被水草遮住了一半那就按可见部分画框不要凭想象去补全因为模型学习的是“露出来的那一半长什么样”如果目标太小小到人眼要贴近屏幕才看见这种样本可以暂时放弃等模型成熟后再做小目标专项优化。标注时还要保持一致性同样的塑料瓶在不同图片里框的范围不能一会儿紧一会儿松否则模型学到的目标形状是抖的。标注工具用过好几种现在比较顺手的是半自动标注工具。先用一个大一点的通用检测模型做预标注人工再逐张修正。预标注能省掉不少从零画框的时间但绝不能直接信任河面反光造成的误检很多必须人工过一遍。标注完成后还需要做一轮交叉审核让另一个同事按同一套规范抽查至少 20% 的图片对分歧大的样本要做讨论和修订。2.4 数据增强与小目标处理水面垃圾检测很典型的小目标问题尤其是几十米高度下拍到的塑料瓶可能只有十几个像素。这类目标在 640x640 的输入尺寸下会被严重压缩模型根本学不到细节。处理方式有两种一种是直接把训练输入分辨率提到 1280增加小目标在原图里的相对尺寸另一种是把大图切成小块比如把 5472x3648 的原图切分成若干 640x640 的 tile这样小目标在每个 tile 里就变成了“中目标”。我实际项目里是两种结合先切块扩充样本再用 1280 输入训练。数据增强方面YOLO 自带 Mosaic、MixUp、HSV 扰动、随机翻转等。Mosaic 把四张图拼成一张可以增加每张训练图里的目标密度特别适合数据量不足的情况。HSV 扰动可以模拟不同季节、光照和不同水体颜色下的色偏对提高夜间和阴天的鲁棒性很有帮助。水平翻转对航拍场景完全适用因为垃圾不会在乎镜像方向。垂直翻转要慎用因为无人机俯拍时天空偶尔会入镜翻转后可能导致图片语义错乱。类别不平衡也是一定要处理的。项目里通常塑料瓶和塑料袋样本较多泡沫和其他漂浮物较少。最简单的做法是给少样本类别增加重复采样或者用数据增强把少样本类的图片多生成一些变体。如果不做处理训练出来的模型会明显偏向高频类别泡沫经常漏检。3. YOLOv12 模型训练实战3.1 环境准备Python、PyTorch 与硬件选型训练环境老生常谈但还是要踩过坑才知道版本匹配有多重要。我建议直接用 Python 3.8 或 3.10配上与当前 PyTorch 版本兼容的 CUDA 版本不要盲目装最新版。YOLOv12 通常基于 PyTorch 实现装好依赖后先跑一次官方的 demo 训练确认环境没问题再上自己的数据这样能隔离大量软件环境问题。硬件方面训练阶段建议至少 8GB 显存起步显存越小batch size 越受限训练越慢。我实际用过 8GB 显存跑 YOLOv12-S 配 640 输入勉强可以但要跑 1280 输入或更大模型16GB 以上显存会从容很多。如果条件允许优先上 24GB 的卡省下来的调参时间远大于硬件成本。推理部署则可以另说后面章节详细讲边缘端的选型。3.2 数据集格式与配置文件YOLOv12 训练要求的格式非常清晰。图片和标签分离存放每张图片对应一个同名 txt 文件txt 里每行代表一个目标格式是类别序号和归一化后的中心点坐标、宽高。项目里我习惯把目录组织成这样dataset/ images/ train/ val/ labels/ train/ val/ data.yamldata.yaml 的写法也很直观path: ./dataset train: images/train val: images/val nc: 4 names: 0: plastic_bottle 1: plastic_bag 2: foam 3: other_float这里最容易犯的错误是类别顺序和后端读到的顺序不一致。比如你在标注工具里定义的顺序是“塑料袋、塑料瓶、泡沫、其他”但 data.yaml 里写的顺序反了模型就会把所有预测的类别对应错。这种错一开始复现不出来等到现场部署时才发现检测框在手机上显示的名称全乱了排查起来非常痛苦。所以在准备数据集的时候最好写一个小脚本统一校验一遍标签文件里的类别编号是否都在合法范围内同时统计各类别的目标数量做到心里有数。3.3 预训练权重与输入尺寸选择训练从零开始几乎没必要。YOLOv12 官方会提供在大型数据集上预训练好的权重我们只需要基于这套权重做迁移学习。预训练权重的好处是模型底层已经学到纹理、边缘、形状这些通用特征只需要在河面垃圾数据上做微调即可这样大大减少了训练时间和数据需求。输入尺寸的选择要综合考虑目标大小和部署效率。如果边缘端对帧率要求高那就训练时用 640配合切块处理小目标如果设备性能余量大、对精度要求高那就直接 1280。我用 1280 输入训练出来的模型相比 640 输入对小塑料瓶的 mAP50 提升非常明显代价是推理耗时涨了一截。所以实际部署前要在检测率和帧率之间做个取舍。项目里我通常先训练一版 1280 精度的模型用于离线分析再训练一版 640 或 960 的模型用于实时巡检两套模型各司其职。训练过程的超参数我的基准配置大致是batch size 16 或 32、epochs 300、初始学习率 0.01、权重衰减 0.0005、优化器用 SGD。虽然 AdamW 也常用但我在 YOLO 系列上还是习惯 SGD配合预热阶段和余弦退火稳定性更好。训练命令大致长这样yolo train modelyolov12s.pt datariver_plastic.yaml imgsz1280 batch16 epochs300 device0如果是用官方源码仓库也可以直接调 train.py逻辑类似。关键是训练过程中不要只跑不看。3.4 训练监控与调优训练开始后我要看几个关键指标训练 loss 是不是平稳下降、验证集的 precision 和 recall 曲线、mAP50 和 mAP50-95。mAP50 衡量的是检测框和真实标注框的 IoU 超过 50% 时模型整体识别得有多准mAP50-95 则是更严格的综合评估。河道巡检场景我更看重 recall也就是“该捞的垃圾有没有漏掉”。漏检意味着保洁队要白跑一趟相比之下偶尔误报还能接受。如果训练到后期发现 loss 降不下去优先怀疑几个方向训练集里标注质量差、正负样本不平衡、学习率太高或太低。我遇到最典型的问题是验证集 loss 回升说明模型开始过拟合了。解决手段不外乎加大数据增强、增加样本量、降低模型的复杂度或者提前停止。YOLOv12 训练一般 300 个 epoch 足够不用硬跑上千轮。如果 mAP 不差但现场误报率高问题往往不在数据而在后处理。可以适当调高置信度阈值从默认的 0.25 往上提比如 0.35 或 0.4还可以调整 NMS 的 IoU 阈值减少重叠框。这些参数在离线测试集上多试几组找到漏检率和误报率之间的平衡点。3.5 评估指标怎么解读和向业务方汇报模型跑完光有 mAP 数字还不够业务方关心的是“你们这套东西到底能不能把人替下来一半”。所以我会额外做一次模拟巡检评估拿一段无人机新拍但没参与训练的视频让模型从头跑一遍统计检测到多少次漏了多少次误报了多少次。尤其是误报因为一旦误报太多保洁队员就不再信系统推送了整个闭环就废了。真实项目里河道水面塑料垃圾检测的 mAP50 往往能做到 80% 以上看上去不错但一落到小塑料瓶上漏检率可能还是偏高。所以我跟业务方沟通时会明确把“目标尺寸”和“信噪比”这两个变量讲清楚一个矿泉水瓶在 30 米高度下的可视尺寸很小这种漏检是客观限制不是模型缺陷但如果模型连大块泡沫都漏那才是要认真修的问题。4. 无人机接入与智慧河道巡检落地4.1 边缘端还是云端推理模型训练好只是万里长征走了一半。真正的挑战是把模型装进巡检链路让它“在路上”干活。推理位置有两种选择边缘端和云端。边缘端通常是把模型部署到无人机机载计算机或挂载的边缘盒子比如 Jetson 系列设备识别过程不依赖网络云端则是无人机把图像通过 4G/5G 或自组网回传到服务器由 GPU 服务器做推理。河道巡检场景建议优先考虑边缘端因为很多河段在郊区网络不稳定如果每次识别都要等图传回云端实时性基本没法保证。边缘端推理通常只需要几百毫秒配合机载 GPS可以做到“飞到哪里识别到哪里”。云端方案也不是没用。当无人机采集的数据量很大、需要用更重的模型做精细识别时我通常采用“边缘初筛云端复核”的混合架构边缘端用轻量模型快速标注可疑画面只把可疑截图和定位数据回传云端再用大模型二次确认。这样既节约网络带宽又能提高整体准确率。4.2 与大疆等无人机厂商的联动流程和无人机联动时数据链路常见有两类。一类是实时图传行业级无人机通过 RTMP 或 RTSP 将视频流推送到边缘计算盒子盒子里的推理服务对视频流逐帧或跳帧做检测。另一类是离线处理无人机执行完航线后把照片导入设备或服务器再进行批量识别。离线方式的好处是不受算力约束可以用高分辨率大模型坏处是没法做到“飞着发现、降落之前就出报告”。在实际项目里我更推荐把两条链路都做上。实时链路负责快速响应比如发现大面积垃圾聚集时可以立即上报离线链路负责当天的整体巡检报告每个点位的垃圾密度、分布规律一目了然。关于无人机操作本身我就不展开说了但有一个建议巡检航线务必固定化、自动化。不要每次出勤都靠飞手手动遥控否则拍摄角度、高度、重叠率每次都不一样检测结果的对比价值会大打折扣。用航线规划功能按河道的实际走向设置若干航点保证每次巡检都沿同一条路径飞行这样后续的数据对比才科学。4.3 GPS 坐标换算从像素到经纬度检测模型输出的中心点坐标是像素坐标但业务上需要的是垃圾点位的经纬度。航拍图像上的每个像素都可以根据无人机当前的 GPS、高度、云台朝向和相机内参换算到地面坐标这个过程叫单应变换。项目里最常用的做法是把相机标定好获取水平和垂直视场角再结合飞行高度算出每个像素对应的地面尺寸从而把像素偏移量转成地理偏移量。听起来挺复杂实际写代码时就是几个矩阵运算。这里最容易翻车的是无人机云台角度不是 90 度完全垂直时透视带来的偏差会很大。我的建议是如果对定位精度要求不是特别高可以把云台尽量锁在接近垂直的角度用中央区域的结果做定位边缘区域只做检测不精确定位。这样精度损失不大逻辑也简单很多。如果要求更高可以引入 Aruco 标记点或地面控制点做校正但普适性会差一些。4.4 告警闭环与业务落地检测到垃圾之后完整的服务流程至少包括这几个环节生成事件截图、类别、置信度、经纬度、时间、推送告警工作群/平台、人工复核判断是否真的需要出勤、派单处理保洁人员去现场打捞、反馈归档打捞完拍照上传。我在项目里把告警推送做得很“轻”——只推可疑画面截图和坐标链接避免一长串技术参数让人看不懂。人工复核环节坚决不能省。哪怕模型已经跑得不错了总会有极端情况白色水纹被识别成塑料袋倒影被识别成漂浮物。如果系统直接派单保洁队出勤又多又空跑很快就会对系统失去信任。更好的做法是系统先做初筛值班人员在手机端快速浏览图片点“确认”或“误检”确认后自动生成工单。这套人机协作流程看着不“全自动”但实际运维效率反而是最高的。4.5 实测效果与场景限制在一次试点中我们用这套方案连续巡检了某段 5 公里的河道飞行高度 30 米单架次大约 20 分钟采集照片 600 余张。离线识别后模型标记出 40 多处疑似漂浮物人工确认后超过八成是与垃圾相关的目标其余误检主要是白色反光和水纹。相比以前纯人工看照片同等工作量下筛查速度至少提升了四五倍。但也要给各位泼点冷水。这个方案目前能处理的场景仍然有限雨雪天气不能飞行夜间没有可见光相机基本失效大风天水面浪花太大会导致误检率飙升另外单块电池的续航一般也就 20 到 30 分钟覆盖长河段需要多组电池或多机接力运维上是有成本的。做任何智慧巡检项目都要把这些物理限制前置讲清楚否则产品上线时会给业务方造成不切实际的预期。5. 常见问题与排查技巧实录5.1 数据相关的问题数据集阶段最常见的坑是格式不统一。我从不同来源收集素材有的图片是 JPG有的是 PNG还有的是 EXIF 信息被处理过的YOLO 训练本身对此容忍度还行但一旦标签文件和图片名对不上训练就会报错而且报错信息不一定直接告诉你哪张图片少了标签。我的建议是训练前跑一个校验脚本把每张图片对应的标签是否存在、是否符合格式全部列出来缺的一个个补上。另外一个数据坑是“视觉死角”航拍图里垃圾常常被桥墩、河岸、水草遮住一部分标注者容易凭印象把它标完整。这类样本放进训练集后会让模型对遮挡目标的形状产生错误预期推理时遇到半遮挡反而检测不到。解决方式前面提过按可见部分标注必要时单独收集一些遮挡样本做成专项训练集。5.2 训练相关的问题训练不收敛是让我最抓狂的问题之一。排查思路按顺序走先确认学习率是否过大过小再确认 batch size 是否合适然后检查数据增强的强度。尤其是学习率如果设定太高loss 曲线可能直接飞掉设定太低loss 又磨磨蹭蹭地降不动。YOLOv12 自带预热机制能缓解这个问题但初始学习率调成 0.001 和 0.01 的效果差异真的很大多试几组才能找到手感。另一个高频问题是验证集与训练集分布不一致。比如我的训练集里晴天照片占到八成验证集里阴天水纹照片占了一半那模型在验证集上的指标就会被“整体错位”掩盖看起来很差其实不一定是模型的问题。正确的做法是验证集样本分布要和真实巡检场景尽量一致或者按照不同工况晴天、阴天、顺光、逆光分组评估这样才能发现模型真正的短板。5.3 部署相关的问题把一个跑通的 PyTorch 模型搬到边缘设备最常见的坑有两类。第一类是精度损失。用 TensorRT 做 FP16 量化后推理速度上去了但检测率可能掉几个点尤其对深色塑料袋或者小目标影响明显。我的做法是量化后重新在测试集上评估一遍如果掉了超过 3 个点就考虑用 FP32或者只量化模型的部分层。第二类是软件依赖冲突。Jetson 这类 ARM 设备上装环境比 x86 台式机麻烦得多PyTorch、CUDA、TensorRT 的版本经常互相咬合不上。我的经验是固定一套经过验证的版本组合写成一键部署脚本并且把依赖版本记录在文档里。宁可环境老一点也别为了追新版本把现场搞崩。5.4 问题排查速查表现象可能原因解决思路训练 loss 下降缓慢学习率过低 / 数据噪声大调高初始学习率检查标注质量训练后期 val loss 回升过拟合增加数据增强 / 增加样本量 / 提前停止推理时漏检小目标输入尺寸太小 / 小目标样本不足切块训练 / 提高 imgsz / 单独增强小目标误检水纹和反光背景干扰样本不足增加阴天 / 逆光 / 浪花样本调高置信度量化后精度明显下降FP16 量化损失改用 FP32 或局部量化边缘端推理速度慢模型太大 / 设备算力不足换轻量模型 / TensorRT 加速 / 降低输入分辨率检测框类别错乱标签顺序与配置不一致核对 data.yaml 与标注元数据排查问题时我习惯先怀疑数据再怀疑训练配置最后怀疑代码。数据层面的问题占了我实际踩坑的一半以上。别一上来就调网络结构那样大概率是白费力气。6. 实操心得与后续还能怎么扩展6.1 几条值得记住的经验第一先做出一个能跑通的最小闭环再谈精度。很多团队一开始就追求 mAP 90% 以上结果数据标注搞了两个多月还没飞过一趟。我更建议先用少量数据把“采集-标注-训练-部署-告警”整个链路跑通哪怕模型漏检多一些至少业务方能看到完整流程。之后再逐步加数据、调精度迭代速度反而更快。第二数据质检投入再多时间都值得。一次标注不规范带来的模型问题后面可能需要数倍的训练时间来补救。我每次标注完都会随机抽样 100 张图自己对着原图看一遍标注框对不齐的立即退回重标。这个动作虽然枯燥但效果立竿见影。第三别只盯着 mAP要重点关注误报率。业务方可以接受偶尔漏几个小塑料瓶但非常讨厌系统一天弹十几次误报。实际操作中与其把模型阈值调到激进不如在业务侧加“误检反馈”机制把人工确认结果回传再定期增量训练让系统越用越准。6.2 后续扩展方向这套方案后续能做的扩展其实很多。类别层面可以加入水葫芦、油污、大面积水生植物这些都是河道治理的高频关注点。数据层面可以根据水位、季节建立分时模型汛期用一套权重枯水期用另一套权重精度会更稳。硬件层面可以结合无人机机巢实现定时自动出勤、自动充电、自动上传巡检报告真正把人工从重复工作中解放出来。关于 YOLOv12 本身的迭代我也建议大家保持关注但别被模型版本裹挟着跑。项目要解决的是“水面漂浮物识别”这个业务问题模型只是工具。今天用 YOLOv12明天如果有更适合低空小目标检测的模型出现只要数据链路和部署框架搭好了换模型就是几天的事。这才是这套方案留给你的最大资产。