企业官网建设流程全解析

做了几年农业视觉项目，从温室番茄到果园柑橘都趟过一遍，最深的感觉是：作物识别这类任务，真正卡的往往不是模型本身，而是你对目标物生物学特征的理解深度。最近正好在做一个哈密瓜花朵识别与分类的项目，目标是用YOLOv26把哈密瓜的雄花、雌花分开，同时还想办法从花瓣结构上做细粒度判断。整个项目从数据采集到落地部署踩了不少坑，也有不少值得记录的思路，整理出来分享一下。

1. 项目整体设计与需求拆解

1.1 为什么是哈密瓜花朵识别

先说背景。哈密瓜是典型的异花授粉作物，温室大棚种植时没有自然传粉昆虫，必须靠人工点花或蜜蜂授粉。人工点花的前提是先认准哪朵是雌花、哪朵是雄花——雌花子房膨大，坐果后发育成瓜，雄花只提供花粉。实际作业中，工人每天要在藤蔓间来回巡看，弯腰辨认，效率低而且容易漏。更头疼的是，花期集中时，授粉窗口只有几天，雇人成本高，熟手又难找。

所以这个项目的第一诉求很直接：让一个移动巡检设备或者喷药机器人经过瓜藤时，自动识别画面里有没有花，是哪一性别的花，最好还能根据花瓣成熟度判断能不能授粉。这就是“识别与分类”的完整含义——先检出目标，再做细分类，最后支撑决策。

1.2 需求拆解：识别、分类、花瓣结构三层目标

我把需求拆成三层递进结构：

第一层是通用花朵检测。不论雄花雌花，先把画面里所有花的位置框出来。这层解决的是“有没有”“在哪里”的问题，也是后续一切功能的地基。

第二层是雄花/雌花二分类。在检测框的基础上，进一步判断这朵花的性别。哈密瓜是单性花，雌花和雄花在形态上有差异，但早期花蕾阶段差异不大，需要在模型特征提取上做文章。

第三层是花瓣结构识别。这个需求比较隐蔽。哈密瓜的雌花从花蕾到开放有一个过程，花瓣展开度、颜色饱和度、柱头状态都在变化。客户想通过花瓣结构判断花朵是否处于最佳授粉期，避免对着未成熟或已过盛期的花浪费时间。这一层相当于细粒度分类，在检测框内的局部区域上再提取特征。

1.3 技术选型：为什么用YOLOv26而不是其他方案

模型选型阶段，我对比了三条路线：传统图像处理、目标检测、实例分割。

传统图像处理（颜色阈值、形态学处理）在实验室受控条件下跑得通，但大田环境下光线变化大、叶片遮挡多，颜色特征极不稳定，而且无法同时处理多个目标，直接淘汰。

目标检测里，主流选择是YOLO系列和EfficientDet这类。YOLO系列部署生态好，TensorRT、OpenVINO、NCNN都有现成转换路径，适合后续移动端和边缘设备部署。选YOLOv26具体有几个原因：一是它在小目标检测上有专门优化（花朵在巡检画面里经常只占几十个像素）；二是支持多任务头，可以同时输出检测框和分类结果，正好匹配雄花/雌花分类需求；三是训练和推理速度快，迭代周期短，对农业项目这种数据量不算大、需要频繁调优的场景很友好。

有一个点需要提前说明：YOLOv26听起来是官方版本号顺延，实际上社区里已经有不少基于YOLOv8/v11架构衍生的改版，被称为“v26”是各团队自己的增强版本。我在项目中用的是自己基于YOLOv11结构魔改、命名为“v26”的变体，重点在小目标检测层和分类头上做了调整。大家参考时不必纠结具体版本号，关键是理解我在检测和分类头之间怎么分派任务。

1.4 核心方案架构

整体方案分四个模块：

• 数据采集与标注：用高分辨率相机在真实瓜棚拍摄，涵盖不同光照、不同花期、不同角度，标注框级别数据外加性别标签和花瓣状态标签。
• 模型训练：检测任务和分类任务联合训练。先训练通用检测头，冻结骨干冻结一定轮数后再放开分类头联合微调。
• 推理优化：剪枝、量化、TensorRT加速，保证在边缘设备上跑到实时帧率。
• 决策输出：将检测框、性别置信度、花瓣展开度映射为“建议授粉/等待/跳过”三种操作指令。

2. 数据采集与标注：农业项目最容易翻车的环节

2.1 数据采集的现场条件与拍摄策略

农业视觉项目的数据采集和公开数据集完全是两码事。公开数据集是干净整齐的，现实是大棚里湿度高、反光杂、背景复杂。哈密瓜是藤蔓作物，叶片大而密，花朵藏在叶丛里，部分花朵朝下开，相机常常只能拍到侧面甚至背面。

我的采集策略分三条线并行：

第一条线是固定机位长时间录制。在瓜棚里选有代表性的藤蔓段，用三脚架固定相机，录制从早上七点到下午五点的连续视频，每半小时截帧一次。这样能拿到不同光照角度的样本，还能捕捉光线变化对花瓣颜色呈现的影响。

第二条线是移动巡检模拟。手持相机或者把相机装在移动小车上，沿着瓜沟缓慢移动，模拟将来机器人巡检的真实视角。距离控制在0.3米到1米之间，覆盖近景特写和中景检测两种尺度。

第三条线是针对性补拍。针对雌花子房膨大、雄花花药开裂等关键阶段专门蹲点拍摄。这些是分类任务中最难的正负样本，后期模型效果不好基本都是这种样本不够。

采集设备就是普通的工业相机加上偏振镜。偏振镜这个细节值得说——哈密瓜叶片表面有蜡质层，反光很强，直拍时花瓣和叶子交界处经常过曝，影响标注和训练。加了偏振镜后反光明显减少，纹理细节清楚很多。

2.2 标注体系的层级设计

标注决定模型能力的上限，这在农业项目中体现得特别明显。我设计的标注体系分三层：

• 第一层是目标检测框：把所有可见的花朵框出来，不论性别、不论完整度。
• 第二层是性别标签：每个框给一个类别，雄花（male_flower）或雌花（female_flower）。未开放、特征不明显的花蕾也标，但额外标记一个“unclear”状态作为第三类，避免模型强行判断。
• 第三层是花瓣结构属性：这部分不在YOLO训练标签里，而是作为后续细粒度分类的监督信息。我定义了四个状态——未开放（bud）、半开（half_open）、全开（full_open）、衰败（withered），依据是花瓣展开角度和颜色变化。

标注工具我用的是开源的LabelImg和X-AnyLabeling，前者简单直接，后者支持自动分割和半自动标注，效率高一些。但半自动标注出来的框必须逐个检查，哈密瓜花朵之间遮挡严重，自动框经常只框住露出的花瓣而漏掉整体区域。

2.3 数据增强与样本平衡

采集到的原始数据有个天然问题：雌花数量远少于雄花。哈密瓜本身的生物学特性就是雄花多、雌花少，一株藤上雄花雌花的比例大概在5:1甚至更高。如果不做平衡处理，模型会严重偏向雄花。

我的处理办法分三步：

第一，过采样雌花样本。雌花样本在训练集里重复采样，同时配合旋转、翻转、缩放等基础增强。但不能无脑重复，重复太多会导致过拟合，我控制在原始样本量的三倍以内。

第二，Mosaic增强。YOLO系列自带的Mosaic增强对农业场景特别有用。它把四张图拼成一张，等于强迫模型在小尺寸目标上学习，同时增加目标密度。哈密瓜花朵小，Mosaic后模型能更好地处理小目标。

第三，针对性合成。这个是难点。花瓣结构识别需要大量不同开放状态的样本，但自然条件下很难在恰好的时间去拍到恰好的状态。我用分割出来的花瓣贴图做背景合成——把不同状态的花瓣区域剪切出来，随机粘贴到新的背景图上。合成图不是万能的，但能有效补充rare state的样本量。

有个容易忽略的点：增强参数不能统一套用。目标检测层面，旋转角度可以放开到正负30度；但花瓣分类层面，过度旋转会把花的朝向关系搞乱，让模型学到错误的空间关联。所以我在检测任务的增强管线和分类任务的增强管线里用了不同的参数集，实测对最终精度影响不小。

3. 模型训练：YOLOv26的架构调整与参数调优

3.1 从YOLOv11到“v26”：我改了什么

说清楚一点，我这里的“YOLOv26”不是官方发布的某个版本号，而是我在实际项目中基于YOLOv11结构魔改出来的一个变体，为了项目内部命名方便叫它“v26”。主要改了三块：

第一块是小目标检测层。YOLOv11默认的检测层里，最大的特征图是针对80x80像素网格的，对应原图中约8x8像素的目标。哈密瓜花朵在移动视角下经常只有20到40像素大小，靠原来的P3层不够。我增加了一层从骨干网络更浅层引出的特征融合支路，相当于把P2层也加入了检测头，让模型在原图约4x4像素的尺度上就具备预测能力。代价是计算量增加，后面通过剪枝把推理速度压回来了。

第二块是多任务解耦头。YOLOv11本身有分类分支，但那个分类分支主要做的是前景背景区分。我要的性别分类和花瓣状态分类是另一维度的语义，混在一起效果不好。我把检测头里的分类分支拆成两份：一份管目标类型（花还是非花），一份管属性（性别和花瓣状态）。两个分支共享骨干网络特征，但损失函数分开计算、分开回传。

第三块是注意力机制插入。在骨干网络的最后两个stage后面，我插入了ECA注意力模块。ECA相比SE注意力，参数少、计算轻，对于这种数据量不算大的农业场景更稳，不容易训飞。

3.2 训练策略与超参数详解

数据准备好之后，训练策略上我做了几轮迭代才定了最终方案。

第一轮先做detection-only预训练，用通用花朵检测数据集（自己采的，不含细分标签）训练检测头，目的是让骨干网络先学会提取花朵的通用特征。这一轮用的是大学习率、大batch size，训练到mAP@0.5稳定在85以上再停下。

第二轮做冻结骨干的分类联合训练。把第一轮训好的骨干参数冻结，只更新检测头和新增的解耦分类头。这样做的原因是：性别分类和花瓣状态分类的知识量级小，如果一开始就放开全部参数，模型会很快过拟合到训练集上，泛化能力反而差。冻结阶段让分类头在固定特征空间里“找感觉”，学习率设低，大概训20个epoch。

第三轮做全局微调。冻结解除，所有参数一起更新，学习率降到最初的十分之一，训练到验证集loss不再下降为止。这轮要重点观察分类分支的loss曲线，如果性别分类的accuracy出现反复震荡，说明冻结阶段的学习量不够，要退回第二轮加大迭代轮数。

超参数方面，我最终定下来的配置是：输入分辨率640x640，batch size 16，初始学习率0.01配合余弦退火调度，weight decay 0.0005，momentum 0.937，训练总轮数120轮（三轮加起来）。损失函数上，检测框回归用CIoU，目标分类用BCE，属性分类用CrossEntropy，三个损失按1:0.5:1的权重加权。

有个细节：属性分类的类别不平衡很严重——“未开放”和“衰败”样本天然少。我在CrossEntropy里加了类别权重，衰败类的权重调到正常类的1.8倍，同时配合2.3里说的合成样本方案双管齐下。

3.3 训练过程中的关键曲线与调优信号

训练过程中我重点盯四条曲线：

• mAP@0.5和mAP@0.5:0.95：前者反映整体检出率，后者反映框的定位精度。如果mAP@0.5高但mAP@0.5:0.95上不去，说明框“差不多能框住但不够准”，这时候要去检查标注框的质量，而不是调模型。
• 分类分支的Precision/Recall曲线：性别分类是二分类，重点看Recall——雌花漏判是真正要命的错误，宁可把一些雄花误判成雌花，也不能漏掉真正的雌花。
• 花瓣状态的混淆矩阵：重点关注“全开”和“半开”之间的混淆。这两个状态在视觉上高度相似，而且是实际决策中最关键的两个区分。
• 小目标专属的AP_s指标：YOLO官方工具会按目标尺寸分档统计AP，我专门看small档位。如果AP_s明显低于其余档位，说明小目标检测能力不够，优先去调整P2层融合策略。

实际训练中遇到最典型的现象是：mAP能到90左右，但雌花分类的Recall卡在78%上不去。排查发现主要问题是雌花的“子房膨大特征”在目标太小的时候丢失严重——检测框只有30像素左右时，子房和花瓣在特征图里混成一团。后来我把检测框的最小尺寸下界从原来的20像素调整到40像素，同时把雌花分类的输入RoI区域做了一次2倍双线性插值放大，Recall直接提到了88%。

3.4 剪枝与量化：让模型跑得动

训练完成的模型参数量在千万级别，直接部署到边缘设备是跑不动的。我做了两步压缩：

第一步是结构化剪枝。基于BN层的gamma系数做通道剪枝，把贡献小的通道删掉。这里有个经验：剪枝比例不能一步到位，先剪10%验证精度损失，再逐步加到30%。我最终剪了35%的参数，mAP只掉了约0.8个百分点，分类准确率完全没掉。

第二步是INT8量化。量化后模型体积缩小到原来的四分之一，推理速度提升明显。但量化会导致小目标检测精度进一步下降，所以量化前要先确认AP_s在浮点模型上足够高，留足退化空间。量化校准集要覆盖不同光照条件的数据，只用一个时间段的数据做校准会让量化在另外的光照下表现异常。

最终部署用的模型参数量约330万，在边缘计算盒子上推理一张640x640图像耗时约12毫秒，折算帧率80fps左右，完全够用。

4. 花瓣结构识别：比性别分类更细的活儿

4.1 花瓣结构识别的技术路线

花瓣结构识别这个需求，甲方最初提得很模糊，只说“想通过花瓣形态判断花期”。我把它具体化为一个细粒度图像分类任务，在YOLO检测框中的花朵区域上二次提取特征。

技术路线有两条，我最终结合使用了：

第一条是检测头内嵌属性分类头。YOLOv26的解耦分类头多分出一支，直接在目标检测框内输出花瓣状态概率。好处是端到端部署，不增加新的推理模块；缺点是分类头的感受野有限，对局部细节的抓取能力不够强。

第二条是“检测+二次分类”级联方案。检测框输出后，把RoI区域裁剪出来，缩放到128x128，送入一个轻量的花瓣状态分类网络。这个网络我用的是MobileNetV3的small版，参数量不到200万，单独训练。

为什么两条都要？因为实际场景里两种情况都存在：花朵占画面比例大时，检测头内嵌分类已经够用，走第一条路能省一次前向耗时；花朵占画面比例小、细节不足时，必须裁剪放大后走第二条路。我设计了一个判断逻辑：检测框像素面积小于阈值（比如小于50x50像素）时走级联方案，否则用内嵌分类结果，综合两个头的置信度输出。

4.2 花瓣状态定义的生物学依据与标注标准

为了让模型学到有意义的花瓣结构特征，我先把生物学定义量化成可标注的标准：

• 未开放（bud）：花瓣完全聚拢，看不到花药或柱头，整体呈球形，颜色偏绿。
• 半开（half_open）：花瓣开始分离，花药若隐若现，雌花柱头可见但不完全外露。这个状态持续约半天，是授粉的关键窗口期。
• 全开（full_open）：花瓣完全展开，花药或柱头充分暴露，颜色达到最鲜亮。这个状态持续约半天后开始衰败。
• 衰败（withered）：花瓣边缘卷曲、颜色发暗、出现水渍状斑点，柱头变色。

这四种状态和授粉决策有直接对应关系：半开和全开的雌花可以授粉，未开放授粉会导致坐果率低，衰败后再授粉基本无效。

标注操作上有个细节：状态判断单纯看二维图像会出现歧义。比如两朵花重叠时，后一朵花的花瓣被遮挡一半，标注人员会犹豫算半开还是算未开放。我定的规则是：只要花朵总面积的30%以上被遮挡或不可见，就标为“ignore”，不参与花瓣状态分支的训练。检测框层面仍然保留，但属性分类loss对这个样本的权重置零。

4.3 花瓣表面纹理与颜色特征的提取

模型实际从图像里学什么？这一点我做了可视化分析。用Grad-CAM热力图叠加到原图上，发现在花瓣状态分类任务中，模型注意力主要集中在三个区域：花瓣边缘的卷曲度、花朵中心区域的颜色饱和度、以及花瓣基部的纹理变化。

这给了两个启发：

第一，光照一致性很重要。哈密瓜大棚里光线分布极不均匀，棚膜接缝处、遮阳网边缘都会造成局部色差。同一朵花在强光和阴影下，花瓣颜色饱和度差异巨大，模型容易把这个差异当作状态差异。我的对策是在预处理阶段做一次局部直方图均衡化，让花瓣颜色在不同光照下更一致。注意是局部的而不是全局的，全局直方图均衡会在画面里同时有大片叶子和花朵时产生过度增强。

第二，图像分辨率直接决定分类上限。128x128的输入对花瓣边缘的卷曲度表达是够用的，但如果部署设备摄像头分辨率太低（例如一些低端巡检机器人只输出720p画面），检测框画出来再裁剪，有效信息可能只有三四十像素，这时候要么强制走内嵌分类头，要么就得在采集端就用变焦镜头固定近距离拍摄。

5. 部署与应用：从模型到田间可用系统

5.1 硬件选型与推理框架

部署平台选了两档：

第一档是边缘计算盒子，CPU加轻量GPU的组合。这类设备在农业大棚里常见的原因是无风扇、防尘、支持宽温，同时能跑到模型要求的推理速度。实测在这个平台上，剪枝量化后的模型推理时间约12到15毫秒每帧，加上前后处理，整体端到端延迟约40毫秒，满足实时巡检需求。

第二档是手持巡检终端，纯CPU推理。这一档是为了工人拿着设备在棚里走动时扫查。CPU推理没有GPU快，单帧延迟到了120毫秒左右，但胜在功耗低、便宜、操作灵活。针对CPU推理，我把之前128x128花瓣分类网络的输入降到96x96，精度损失约1.2%，但CPU推理时间从40毫秒降到了22毫秒。

推理框架选了TensorRT。工程部署上要特别注意：TensorRT的Engine文件和模型版本是绑定的，换一个训练版本就得重新生成Engine。我踩过的坑是在项目中期改过一次模型结构，结果忘了重新生成TensorRT engine，直接推理崩了，排查了半天才发现是Engine和模型结构不匹配。

5.2 现场运行流程与交互设计

系统跑的流程是这样的：

1. 摄像头捕捉画面，预处理（缩放、归一化、局部直方图均衡化）。
2. YOLOv26检测，输出所有花朵的框、性别置信度、花瓣状态置信度。
3. 按置信度阈值过滤。检测置信度阈值0.5，性别分类置信度阈值0.75，花瓣状态置信度阈值0.7。
4. 针对每个框，根据4.1里的尺寸判断逻辑决定用哪个花瓣分类头。
5. 综合判断输出建议：雌花且花瓣状态为半开或全开，输出“建议授粉”；雌花但未完全开放，输出“等待”；雄花则输出“可采集花粉”或者直接忽略。

交互端做成了两类输出：屏幕叠加显示（框颜色区分性别：绿色雌花、蓝色雄花、黄色未定；框角标签显示花瓣状态），以及语音提示播报（“前方0.3米处发现可授粉雌花”）。语音提示在工人实际操作中比屏幕显示更实用，因为工人视线集中在藤蔓上，不可能一直低头看屏幕。

5.3 光照变化的运行时鲁棒性

白天不同时段的光照对模型影响非常明显。早上阳光斜照时，花朵处于逆光状态，花瓣半透明，特征丢失严重；中午光线直射，叶子反光强，花瓣容易过曝；下午棚内阴影变多，花朵明暗对比强烈。

针对光照问题，运行时做了三层防御：

第一层是自动白平衡校准。摄像头每隔五分钟对画面整体色温做一次统计，以叶片绿色为参考基准，把画面色温校准到接近标准值。这个方法在温室场景可行性好，因为叶片面积大且颜色稳定。

第二层是多光照模型的集成。训练阶段按光照条件分桶训练了三个变体模型：强光模型、弱光模型、阴影模型。推理时场景分类器先判断当前光照类型，再路由到对应模型。这个做法的效果比单模型好不少，代价是三倍显存占用。如果设备资源紧张，可以用两个模型（强光和弱光），阴影当作弱光的子情况。

第三层是时间窗口平滑。花朵状态变化是缓慢的，不会一帧之间从半开变成全开。如果模型连续帧输出不一致，取过去五帧的平滑结果。这个后处理极大减少了单帧检测异常带来的误报，特别是避免把叶片晃动误判成花朵出现又消失。

6. 常见问题与排查技巧实录

6.1 问题速查表

项目过程中遇到的典型问题整理成一张表，按排查顺序排列：

6.2 若干坑的详细复盘

坑一：标注框与分类标签不一致。项目中期发现雌花分类不准，排查到标注层面才发现问题——有一部分雌花框里同时框进了相邻的雄花花瓣，导致分类头同时看到了两种性别的特征，训练时模型学到的关联关系是错乱的。后来要求标注人员做严格检查，凡是框内包含超过10%面积的其他目标，必须调整标注框或者标记为ignore。

坑二：Mosaic增强引发的定位偏移。Mosaic增强有一个副作用，它把多张图缩放到拼接图的不同区域时，目标相对原图的位置关系会被打乱。花朵检测这种本来就要靠上下文（比如花朵邻近的藤蔓走向）辅助判断的任务，学到的位置先验会被Mosaic破坏。最终解决方案是Mosaic增强只用在后30%的训练轮数，前70%用普通单图训练，让模型先建立稳定的空间感知。

坑三：夜间补光的颜色偏移。客户后来要在夜间巡检（哈密瓜授粉有时需要在夜间低温环境进行），补光灯开启后花瓣颜色明显偏紫，白天训练出来的模型夜间表现很差。这个问题的根源在于补光灯色温和自然光差异大，我让客户换了色温更接近日光的LED补光灯，同时采集一批夜间数据联合训练，才算稳定住。

坑四：TensorRT量化与动态尺寸冲突。部署阶段需要支持不同分辨率输入，但TensorRT INT8量化后的Engine一般只支持固定的输入尺寸。方案是预先定义三档输入尺寸（640x640、736x736、832x832），分别生成三个Engine，运行时按画面内容自动切换。这样既保持精度又保留灵活性。

6.3 独家的实用小技巧

根据个人项目经验，有几点常规文档里不会写但确实管用的技巧：

• 利用YOLO的objectness分支做误检过滤。农业场景里枯叶、蔓须、滴灌喷头都长得像花朵，单独靠分类分支过滤不干净。把目标检测的objectness得分和分类置信度相乘作为最终置信度，误检率下降明显。

• 用聚类分析辅助标签质量检查。训练前把标注框对应的特征向量提出来做聚类，如果某个簇里混着明显不一样的图片，基本可以定位到标注错误。我在800张图上做了这个检查，找出15处标注问题，避免模型带着错误标签训完整轮。

• 花瓣分类不依赖整朵框的时候。有时候花朵只有一半在画面内，此时整朵框的RoI裁剪结果很差。我在后处理里增加人工凸包修正——对花瓣区域做边缘检测提取凸包，用凸包区域替代原始检测框区域去做RoI裁剪，状态分类准确率能再提升两三个点。

• 训练时随机失活一部分精细标签。花瓣状态标签的标注质量参差不齐，某些图片上状态模糊。我不完全删掉这些样本，而是以3%的概率随机把它们的状态标签置为ignore，让模型学会在输入不确定时输出保守判断，降低误报带来的实际损失。

7. 扩展思路与实际体会

7.1 后续可扩展的方向

项目做到后期，有几条扩展路线已经在规划中：

第一是坐果期果实识别。哈密瓜雌花授粉成功后子房膨大，几天内就能看到小瓜雏形。基于现在的检测模型稍作调整，就可以把“花朵检测”扩展成“花朵->幼果->成熟果”的时序追踪，对产量预估很有价值。

第二是授粉机器人联动。当前系统的输出是建议指令，下一步可以直接把检测框坐标和分类结果传给授粉机械臂，实现“发现雌花->判断花期->机械臂对准->自动点花”的闭环。我和机械臂团队做过接口模拟，检测框到机械臂坐标的转换用简单的相机标定就能完成，精度在厘米级，足够对准花朵。

第三是多作物迁移。哈密瓜和西瓜、黄瓜同属葫芦科，花朵形态结构有很高的相似性。模型在哈密瓜上训好的骨干网络，迁移到西瓜花朵检测上只需要替换分类头重新训少量数据，成本很低。如果有跨产线的需求，这套架构可以直接复用。

7.2 项目落地的几点体会

做完这个项目，感触比较深的有几点：

一是农业AI项目的难点多数在场景理解上。一样的YOLO代码，用在自动驾驶和用在瓜棚里差别巨大。数据采集条件、光照变化、目标生物学特性这些看似“不技术”的因素，恰恰决定了模型的上限。你在实验室里把Backbone换得再花哨，不如到大棚里把数据拍好、标好。

二是和领域专家对话要趁早。做花瓣状态识别之前，我先找了种植哈密瓜的老师傅聊方案，他告诉我“授粉窗口就那半天，你最好上午九点之前判断完”这句轻描淡写的话，直接决定了系统延迟指标的设计方向——端到端必须控制在100毫秒以内，而不是相机性能提不上去就完事。

三是检测和分类是两码事，不要混在一起追求完美。很多项目一上来就想要一个模型干所有事，检测、性别、成熟度一把抓。实际工程中，检测精度和细粒度分类精度往往是矛盾的，解耦设计、单独调优、按需融合，才是稳健路线。这次项目里检测头和两个分类支路的独立训练、按尺寸路由到特定分类头，都印证了这点。

四是模型压缩的收益是真金白银。农业项目的落地设备往往成本敏感。同样一个模型，从2000万参数压到330万参数，精度损失不到两个点，但设备成本从几千块降到了几百块，这个账很好算。做农业AI，时刻要记着客户是在田里算成本的人，不是实验室里刷榜的人。

这项目做下来，最大的收获不是把YOLOv26调得多好，而是明白了把作物生物学、环境约束、设备成本和模型性能放在同一张桌子上权衡的那种工程感觉。希望这篇记录能给正在做类似农业视觉项目的同行一些参考，少走几个我已经趟过的坑。