从YOLOv5到YOLOv10：农作物病虫害识别系统完整实现指南

1. 为什么总有人把YOLO病虫害识别做成“PPT项目”？

我先说个现象。很多开发者一看到“农作物病虫害识别”这个题目，第一反应就是去网上下一个公开数据集，跑通YOLOv5训练脚本，loss降到0.05，mAP打印出来50多，然后截图发朋友圈。但真把模型拿到田间地头去测，十有八九会翻车——要么把泥土当成病斑，要么叶子背面朝上就完全认不出来，要么光线一暗直接罢工。

这个标题里藏着三个字才是关键：完整实现。我理解的“完整”，不是指你把YOLOv5到YOLOv10每个版本的官方仓库都clone下来跑一遍demo，而是你真正搭建了一个能从“图像输入”走到“诊断结果输出”的闭环系统，包括数据集怎么建、模型怎么选、训练参数怎么调、界面怎么封装、以及部署之后怎么根据真实反馈反哺优化。这中间任何一环断掉，项目就只停留在“能跑”阶段，离“能用”还有十万八千里。

我自己做过接近两年的农业视觉项目，从最初拿通用目标检测模型硬套作物叶片，到后来针对大田场景做数据清洗、弱样本增强和模型轻量化，踩过的坑相当多。这篇文章我会把整个实现路径拆开来讲，包括版本选型、环境搭建、数据准备的完整细节、从YOLOv5迁移到YOLOv10时模型结构变化的实际影响、以及UI界面和推理引擎封装时最容易忽略的几个问题。适合的人群大概是两类：一是课程设计或科研项目中需要交付一个完整演示系统的学生，二是真正想把AI落进农业场景、哪怕只是做一个小范围试点的开发者。

2. 数据集是决定上限的“隐形天花板”，比模型版本更值得花时间

很多人一上来就纠结“我用YOLOv5还是YOLOv10”，这其实是把精力放错了地方。对农作物病虫害识别来说，数据集的分布和标注质量决定了最终精度的上限，模型选型只是在逼近这个上限。我用一个教训来证明：某次做水稻稻瘟病识别，最初用的数据集里病斑图片大多是在晴天的上午拍的，叶片背景干净、光线均匀。模型在验证集上mAP有52，看起来已经可以交差。可一旦把拍摄时间换到傍晚，或者图片里出现泥水反光、杂草遮挡，检测框就飘得到处都是，甚至会把叶脉的纹路误判成病斑条纹。

这说明什么问题？说明病虫害数据集的难点从来不是“图够不够多”，而是图片是否覆盖了真实场景中的光照变化、拍摄角度、叶片重叠、背景干扰。所以我的建议是，你在构建数据集的时候至少要从以下三个维度拆开来看。

2.1 病虫害类别的粒度设计，直接影响标注成本和模型难度

最常犯的错是把“稻瘟病”“稻曲病”这种大类直接当成检测目标。问题在于，同一类病害在叶片上呈现的形态差异极大，而且不同作物、不同生长期的同一种病，颜色和纹理也不一样。如果类别设得太粗，模型就得在内部自己学一个“隐含聚类”，这会显著增加收敛难度。

比较合理的做法是：按照发病部位+典型症状+严重程度把类别拆细。比如水稻稻瘟病，可以拆成“稻瘟-叶部-急性型”“稻瘟-叶部-慢性型”“稻瘟-穗颈”等。这样标注的时候工人更容易达成一致，模型要学的东西也更明确。当然，这会让单类别样本数变少，需要通过数据增强和样本均衡来弥补。我就见过某个团队把类别从8个扩到17个之后，单类mAP反而提升了4个点，因为类别边界清楚了，误检率大幅下降。

2.2 自采数据的拍摄规范，以及怎么把它和公开数据混合

公开数据集比如一些农业病虫害图像集，好处是类别全，坏处是场景单一。如果你完全依赖它训练，拿到真实田间大概率会水土不服。我的经验是至少自采一部分数据，而且拍摄时要有意识地控制变量。

• 同一片病叶，分别拍顺光、侧光、逆光三个角度；
• 同一株作物，分别拍整株远景、单叶近景、病斑微距；
• 在上午、中午、傍晚各拍一轮，模拟不同色温；
• 故意带上泥土、水滴、杂草、其他虫体等干扰物。

拍摄时别用过分夸张的美颜滤镜，手机原始相机就行，分辨率建议不低于1280×720。采集完之后统一做一次清晰度筛选，把模糊、过暗、过度曝光的图片删掉，这些图会严重干扰训练。

混合公开数据和自采数据的时候，比例我一般控制在1:1到1:2之间，公开数据不要超过自采数据太多，否则模型会过度拟合公开数据的“棚拍风格”。混合前还要检查一下有没有类别冲突——比如公开数据集把“棉铃虫成虫”和“棉铃虫幼虫”合并成一个标签，而你自己拆成了两个，这时候必须统一，否则label会打架。

2.3 标注工具与标注质量检查：我觉得这一步的值被严重低估

标注工具我试过不少，最终稳定下来的是开源的LabelImg和X-AnyLabeling。前者适合快速画框，后者支持半自动辅助分割和检测，对大图标注效率高很多。标注的时候有两条纪律：

• 框一定要紧贴目标边缘，宁可稍微紧一点，不要留大片背景；
• 遮挡超过50%的目标要么不标，要么标清楚是哪一类，别打“未知”标签糊弄。

标注完成之后，我强烈建议做一次可视化抽样检查，也就是把标注框画回原图，按类别排列浏览一遍。这一步能发现大量“标注框错位”“漏标”“类别标错”的情况。不要迷信标注工人的自觉性，批量检查图才是唯一靠谱的手段。

检查完标的校正之后，再做一次类别分布统计。如果某个类别只有几十张图，直接硬训会导致这个类的mAP极低。处理方法可以是用数据增强加倍该类样本，或者去补充采集，再不行就合并到相近的类别里。还是那句话，类别的样本量差距超过10倍时，模型大概率会忽略弱势类别，这不是调参能解决的问题。

3. 从YOLOv5到YOLOv10：选型不是“越新越好”，而是按部署约束倒推

YOLO系列版本迭代非常快，这个项目标题把v5到v10全列出来了，很多人就以为要每个版本都训一遍然后选个最高的。但在实际项目中，版本选型的逻辑应该是倒推的：先想清楚最终跑在哪里、算力是多少、延迟容忍度是多少，再决定用哪个版本。

拿我自己的部署经验来说：如果最终要做成一个带UI的桌面软件，跑在普通办公电脑的CPU或者入门级GPU上，那YOLOv5s和YOLOv8s就是最稳妥的选择；如果要上无人机或者边缘计算盒子，YOLOv5n或者YOLOv8n绰绰有余；如果是服务器批量处理大量历史图片，YOLOv10的效率和精度优势就体现出来了。

为了直观一点，我把这几个版本在相似配置下的表现列成一张表（基于我自己的实测，不代表官方benchmark）：

模型版本	输入分辨率	参数量	单张推理耗时（T4 GPU）	mAP50水平（农作物病虫害场景）	适合场景
YOLOv5s	640	约7.2M	约3.5ms	44~48	本地桌面应用、CPU弱算力环境
YOLOv6s	640	约9.7M	约3.0ms	46~50	需要吞吐量的批量处理
YOLOv7-tiny	640	约6.2M	约3.2ms	42~47	边缘设备、轻量化部署
YOLOv8s	640	约11.2M	约4.0ms	48~53	桌面应用与中等算力服务器
YOLOv9s	640	约7.1M	约4.2ms	47~51	追求新结构但需要谨慎调参
YOLOv10s	640	约7.6M	约4.8ms	46~50	依赖端到端NMS-free加速的场景

这张表不是让你直接抄，只是说明一个道理：版本带来的收益远没有想象中那么大，真正的差距来自于你对数据的处理和对训练细节的把控。我在项目里选择的是“双版本策略”——训练阶段用YOLOv8s做精度验证，部署阶段用YOLOv5s做轻量化输出，两套权重并存，根据目标机器灵活切换。

3.1 环境搭建最容易踩的坑：CUDA、PyTorch、Ultralytics版本三角关系

每次重装环境，最浪费时间的就是版本不兼容。我现在的做法是建立一套固定的“组合拳”：

• Python 3.10；
• CUDA 11.8；
• PyTorch 2.1.0；
• Ultralytics库固定到某个稳定版本（不建议天天追最新，最新版偶尔会因为API变动导致训练脚本失效）。

安装命令我直接放在这里：

# 创建虚拟环境 conda create -n yolo_agri python=3.10 -y conda activate yolo_agri # 安装PyTorch（CUDA 11.8版本） pip install torch==2.1.0 torchvision==0.16.0 --index-url https://download.pytorch.org/whl/cu118 # 安装Ultralytics pip install ultralytics==8.1.0 # 安装辅助库 pip install opencv-python pyqt5 pandas labelimg

装完之后跑一行测试代码，确认GPU可用：

import torch print(torch.cuda.is_available()) print(torch.cuda.get_device_name(0))

如果torch.cuda.is_available()输出False，大概率是CUDA工具包和PyTorch版本没有对齐。有一个技巧：先去PyTorch官网看Prebuilt Binaries列表里有没有对应你机器CUDA驱动版本的wheel，再决定装哪个，而不是盲选最新版。

3.2 从YOLOv5迁移到YOLOv8/10时，需要注意的结构变化

很多人以为YOLO系列改版只是“换了个主干网络”，但实际上每个版本在训练逻辑、推理逻辑、甚至标签格式上都有调整。最典型的有三个：

1. 标签格式：YOLOv5时代默认label是class cx cy w h，归一化到0~1。YOLOv8和v10沿用了这个格式，但Ultralytics库会自动识别数据集文件结构，路径一旦写错就报错。我建议目录结构严格按下面这样组织：

dataset/ ├── images/ │ ├── train/ │ └── val/ ├── labels/ │ ├── train/ │ └── val/ └── data.yaml

2. Anchor机制：YOLOv5是Anchor-Based，YOLOv8改成Anchor-Free，YOLOv10又进一步用了NMS-Free。这意味着你在v5上精心调的anchor尺寸，在v8、v10里完全用不上。不过对使用者来说反而是好事——少了一个调参项。需要适应的反而是后处理逻辑：v5要做NMS，v8默认也做，v10直接输出无重复框的结果。

3. 损失函数细节：v8、v10在分类损失和回归损失的权重配比上和v5有明显不同，直接表现是train loss的绝对值没有可比性。千万别看到v8的loss比v5高就觉得模型变差了，换个版本一定要重看验证集指标。

这些差异带来的实际感受是：从v5切到v8，几乎不用改代码，只需要改数据集路径；从v8切到v10，要重新评估你的应用需不需要端到端推理的加速收益。v10的NMS-Free设计在某些场景下非常香，比如你需要用TensorRT在边缘设备上部署时，少了NMS算子可以让推理管线更简洁，但代价是v10在极度密集的小目标场景下偶尔会出现框体重叠控制得不如NMS精确的情况。

4. 训练一批高可用的病虫害检测模型，核心参数我劝你这样调

这部分才是真正的“内功”。很多教程直接把官方默认参数往那一扔，train一跑就完事。但病虫害图片有个极其鲜明的特点——目标尺度差异巨大。病斑可能只有几十个像素，但整株作物又可能占满画面。这直接挑战了YOLO的多尺度预测能力。

4.1 imgsz、batch size和epoch的互相制约关系

先说输入尺寸。我见过太多人为了“适配”YOLO默认的640，硬把2000×2000的高清叶片图缩到640再送去训练。这么做非常亏——很多病斑的纹理细节在缩小过程中直接没了，模型学不到关键特征。我的建议是：如果你的显卡显存允许，尽量用768或者896作为训练尺寸；如果显存只有8G，那就开AutoBatch，让系统自己去计算满足显存限制的最大batch size。

batch size不是越大越好。物理学角度讲，batch太大会让梯度方向过于平滑，病虫害这种类别特征差异小的数据集容易陷入局部最优；batch太小则梯度噪声大，需要更小的学习率来稳定。我实测过，在单张12G显存的卡上，训练YOLOv8s用imgsz=896，batch size设在8~12之间比较合适。

epoch的数量我也不建议盲跑300轮。一般做法是先跑100轮看验证集曲线，如果mAP还在明显上升就继续，如果开始震荡就提前停止。Ultralytics自带EarlyStopping，但我总感觉默认的patience=50太长，我会主动把它调到20，省电省时间。

4.2 数据增强参数是病虫害识别的“隐藏胜负手”

病虫害识别最大的痛点之一就是叶片位置、角度、光线千变万化。针对这个特殊性，我强烈推荐重点开这几个增强项：

# 训练配置节选 train: hsv_h: 0.015 # 色调变化，应对拍摄色温差异 hsv_s: 0.6 # 饱和度变化 hsv_v: 0.5 # 明度变化，应对逆光与过曝 fliplr: 0.5 # 水平翻转 flipud: 0.0 # 垂直翻转不建议开，作物朝上生长有方向性 scale: 0.4 # 尺度变化，模拟不同拍摄距离 translate: 0.2 # 平移，模拟目标不在画面中心 mosaic: 0.8 # Mosaic增强，混合四张图，增加上下文 mixup: 0.2 # MixUp增强，适合小样本类别

这里有个细节很多人不知道：垂直翻转flipud对于叶片类目标不一定安全。因为植物叶片有明确的形态朝向，你把叶片上下翻转之后，叶尖叶基的位置关系会发生语义错乱，模型会学到“这种病斑长在任意方向”，在实际检测时反而容易把正常的叶脉走向当成病灶蔓延方向。

Mosaic增强我起初是不太敢用的，因为它会把四张图硬拼在一起，切割边缘会产生很多“半截目标”，给标注带来误差。后来我发现，只要把mosaic的值控制在0.6~0.8之间，并且在最后一个epoch关闭它（Ultralytics会自动做这一点，叫mosaic概率线性衰减到最后为0），效果可控且收益明显。

4.3 训练与验证：loss曲线之外的“体检指标”

训练过程中别只盯着loss。我习惯每10个epoch保存一次验证集的预测可视化图，直接看模型在不同场景下的真阳性、假阳性、假阴性分布。具体来说，我会把验证集图片按“简单/中等/困难”分三档，简单档是干净背景下的典型病斑，困难档是逆光加上叶片重叠，然后分别统计检测结果。这个做法比单纯看mAP数字管用得多，它能告诉你模型到底是在“背书”还是在“理解”。

如果发现简单档表现很好但困难档一塌糊涂，先别急着加训练数据，优先去检查困难档图片里是不是有大量漏标。我遇到过一种情况：验证集困难档的图像里，好几个人工标注员都漏掉了角落里的初期小病斑，导致模型明明检测出来了，但因为与标签不一致被当成误检。这时候需要做的是修标注，而不是调参数。

训练完成后，导出的权重格式也要注意。如果只是桌面端推理，导出PyTorch的.pt文件就够；如果需要跨平台或高性能部署，记得用Ultralytics的export命令导出为ONNX或者TensorRT格式。TensorRT格式跑GPU上的推理速度提升非常可观，以YOLOv8s为例，在T4上从约4.0ms能压到2.0ms左右。

5. UI界面与模型推理的“最后一公里”：从pyqt5窗口到实时检测

模型训练好了，下一步就是把模型“包”成一个让人能用起来的系统。这一步在课程设计里往往是最容易水过去的，但恰恰是评委和用户最能直观感知到的东西。我采用的方案是PySide6（也就是PyQt6的官方版本），因为它在Windows、Linux上打包都比较方便，而且信号槽机制对多线程推理的支持很成熟。

5.1 界面功能拆解：单张检测、批量检测和实时视频流

一个完整的农作物病虫害识别UI，至少要包含五个功能模块：

1. 图片选择与预览区：支持jpg、png、bmp格式，点击后能在界面上显示原图和检测结果图；
2. 模型加载与切换区：可以手动加载不同版本的权重文件，方便对比YOLOv5和YOLOv8的效果；
3. 检测参数面板：confidence阈值滑块和iou阈值滑块，这两个参数要给用户留调节空间，因为真实使用场景中用户对“漏检”和“误检”的敏感度不一样；
4. 检测结果列表：用表格展示每个目标的类别、置信度、位置坐标，还应该支持导出为CSV或者JSON；
5. 批量导出功能：能把一个文件夹里的所有图片跑一遍，并把标注叠加图保存到指定目录。

UI和推理代码之间我采用了模型类与界面类分离的模式。模型推理部分放在一个单独的Detector类里，用QThread跑到后台线程，否则大图推理时界面会直接卡死，用户拖都拖不动。代码大概长这样：

class Detector(QThread): result_ready = pyqtSignal(object) def __init__(self, model_path, conf_thres=0.35, iou_thres=0.5): super().__init__() self.model = YOLO(model_path) self.conf = conf_thres self.iou = iou_thres def run(self): # 从队列取图像，循环推理 while not self.stop_flag: if self.queue.empty(): time.sleep(0.01) continue img = self.queue.get() results = self.model.predict( source=img, conf=self.conf, iou=self.iou, verbose=False, device='cuda' if torch.cuda.is_available() else 'cpu' ) self.result_ready.emit(results)

5.2 推理速度优化的一个实用技巧：用letterbox预处理避免尺寸失真

使用YOLO时最容易被忽略的是推理时的图像预处理。如果你的UI直接把一张1920×1080的图片缩放到640×640再送进模型，画幅比例会变形，检测框位置和大小都会出现系统性偏移。正确做法是用letterbox——也就是等比例缩放图片，短边不足的部分用灰色填充，保证输入长宽比和训练时一致。Ultralytics库的YOLO.predict()接口在传入numpy数组时会自动处理letterbox，但如果你把代码改成了通过ONNX Runtime自己拼推理管线，就必须手动实现这一步。

letterbox的实现不难，核心代码如下：

def letterbox(img, new_size=640): h, w = img.shape[:2] scale = min(new_size / w, new_size / h) nw, nh = int(w * scale), int(h * scale) resized = cv2.resize(img, (nw, nh), interpolation=cv2.INTER_LINEAR) canvas = np.full((new_size, new_size, 3), 114, dtype=np.uint8) x_offset = (new_size - nw) // 2 y_offset = (new_size - nh) // 2 canvas[y_offset:y_offset+nh, x_offset:x_offset+nw] = resized return canvas, scale, x_offset, y_offset

推理完成之后，坐标要映射回原图，也就是把偏移量和缩放比例反向乘回去。这一处如果你不处理，测试时会发现“检测框位置偏了一点但又说不清偏在哪”，非常磨人。

5.3 用PyInstaller打包时的依赖坑与处理建议

做UI项目的最后一步往往是打包成exe交付给人打开就能用。PyInstaller打包PySide6+YOLO的坑特别多，我归纳一下最常见的三个：

• Ultralytics资源文件缺失：模型初始化时需要加载一些配置文件，打包时容易丢。解决方式是在spec文件里用datas手动把ultralytics/cfg目录包含进去；
• 动态导入问题：PyTorch在打包时如果用了--onefile，经常出现解压时间很长、甚至杀软误报的情况。我的选择是改用--onedir模式，生成一个文件夹，虽然文件多，但启动快、报错少；
• cv2的插件加载报错：OpenCV在部分Windows机器上会报can't open camera的错，这在打包后容易出现。解决方法是把OpenCV的opencv_videoio_ffmpeg*.dll一并打包进路径。

打包这个过程极其容易劝退人。我的建议是不要等整个项目写完才打包，而是搭好一个空窗口就去试着打包一次，确认基础环境没问题之后，再逐步加入模型和推理逻辑。否则最后一口气调试，你会被几十个报错淹没。

6. 大田实测中的“隐藏关卡”：光线、叶背、小目标，一次讲透

模型在实验室验证集上精度很漂亮，但拉到地里一测，总会冒出一堆“你没想到”的情况。我自己踩过的坑大概有三类，每一个都值得展开说。

6.1 光线变化导致的系统性漏检与误检

大田环境里最难搞的其实不是病虫本身，而是光线。晴天中午的阳光会让叶片高光区域直接过曝，病斑被淹没在白色反光里；傍晚的低色温则让整个画面偏黄，模型学到的颜色特征全部失配。解决这个问题的思路分两步：

• 推理端做一次简单的自适应亮度校正，比如用直方图均衡化或者CLAHE（对比度受限的自适应直方图均衡化）预处理；
• 训练端靠数据增强里的HSV变化来补充，但要注意幅度不能调太大，否则会生成“假颜色”样本，让模型学到不真实的特征。

我的实操经验是：在部署时给UI加一个“低光增强”开关，用户点一下就能切换。它本质上是调用一次cv2.createCLAHE(clipLimit=2.0, tileGridSize=(8,8))把图像的LAB空间的L通道做一次增强。这一步对暗光下的病斑检出提升非常明显，代价是推理时间增加大概2~3毫秒，完全可以接受。

6.2 叶片背面的目标怎么检测？

农作物病虫害检测里，有一个极其致命的场景：很多害虫和病斑是从叶片背面开始的。你对着叶片正面拍照，就是看不见。这已经不是目标检测算法能单独解决的问题了，它涉及的是“采集端需要翻转叶片”的物理操作。所以在做系统的实际应用方案时，我不建议只做一个纯图片识别UI，而是建议配合一个“正反面双图像输入”功能：用户拍完正面，再翻过来拍背面，系统把两张图的结果合并，输出综合诊断。这样的召回率会显著高于只拍正面。

6.3 高分辨率大图上的小目标策略：切片推理

大田环境拍回来的图往往分辨率很高（比如5000×3000），病斑却只有几十像素。直接resize到640检测，小目标几乎等于不存在。这个时候有两个方案：

• 一是把大图切成若干640×640的小块，重叠率设为20%，逐块推理，最后再把坐标拼回原图。这个方案我用过很多次，效果稳定，缺点是推理时间翻倍；
• 二是直接用更高分辨率（比如1280）推理，但前提是你的GPU显存扛得住，同时模型在训练时也用了相近分辨率。

考虑到这是一篇“全系列实战”文章，我建议把切片推理做成UI里的一个可选功能，默认关闭，用户需要处理大图时再开启。实现上不复杂，核心就是cv2的裁剪和坐标映射。

7. 版本迭代的“效率升级”：v8到v10在不同硬件上的实测取舍

讲了这么多实操细节，最后我再把YOLOv5到YOLOv10这个系列在“实际项目交付”视角下的取舍策略补完整。不是每个版本都值得深玩，但每个版本都有自己的“甜点场景”。

7.1 YOLOv5：稳定性的代名词，适合直接落地

到今天为止，YOLOv5依然是很多生产环境的首选。它的推理代码极其成熟，PyTorch、ONNX、TensorRT、OpenVINO等导出链路都非常完善，社区问题也基本都有人回答。如果你的部署机器是别人的旧电脑，没有GPU，只靠CPU跑，YOLOv5s配合OpenVINO导出后在Intel CPU上能轻松跑到30~40ms一帧，完全够用。所以我认为课堂上从v5开始学是对的，它让你理解YOLO的基础范式，之后再切换到v8、v10会轻松很多。

7.2 YOLOv8：精度上限高，适合有GPU的科研演示

YOLOv8在病虫害这个数据集上的优势主要是精度上限更高，尤其是带注意力机制的结构对纹理特征的捕捉更细腻。但代价是训练时间变长，部署包变大。如果项目允许你在一台带独显的机器上运行，而且你对系统实时性要求不高，我推荐直接用v8s，不需要为迁就边缘设备去换成nano版本。

7.3 YOLOv10：端到端加速，适合边缘计算与批量处理

YOLOv10最大的变化是取消了NMS。这意味着你的推理管线可以更干净，TensorRT部署时能省掉一个后处理算子。但由于v10的迭代时间还不算太长，社区积累的“调参攻略”相比v5、v8要少很多。遇到疑难杂症（比如某些类别重复检测、输出框置信度分布异常）时，排查工具和方法相对有限，新手容易卡住。我的建议是：如果你第一次做YOLO项目，别直接选v10当主力，先跑通v5或者v8，等整个流程熟悉了，再把同一个数据集丢到v10里对比，这时候你对“模型输出了什么、哪里不对劲”会有更敏锐的判断。

8. 一套可以复用的“训练+评估+部署”闭环清单

最后，我根据做这个项目的流程，整理出一份可以直接照着执行的清单。这不是什么高深的东西，是我踩坑踩出来的动作顺序，照着做至少能帮你省掉两周的混乱时间。

1. 花两天时间把数据分布盘清楚：类别数量、每类样本量、图片分辨率和场景多样性；
2. 统一标签格式，做一次全量可视化检查；
3. 按7:2:1划分训练、验证、测试集，测试集单独留出一部分“田间实拍图”用来做最终效果评估；
4. 从YOLOv5s开始跑第一版基线，记录验证集指标和推理延迟；
5. 用同样的数据切分去跑YOLOv8s，对比精度收益；
6. 判断最终部署环境，选择是否需要导出到ONNX或TensorRT；
7. 写UI界面，先实现单张推理，再补批量处理和视频流；
8. 打包测试，争取交付给一个“非技术使用者”去实测，收集反馈；
9. 根据反馈修数据（不是修代码），补充弱样本，重新训练一轮。

我刚做农业项目的时候，总觉得“只要模型够强，系统就一定好用”，做了几轮之后才明白，真正决定系统口碑的往往是数据处理和交互细节。用户不会关心你用的是YOLOv5还是YOLOv10，他们只关心“拍一张病叶照片，能不能告诉我这是什么病、严不严重”。把这句话记在心里，方向就不会错。