企业官网建设流程全解析

茶叶病害检测这件事，听起来是农业问题，做起来其实是全栈AI工程问题。我完整做了一个基于YOLOv8/YOLOv10/YOLOv11/YOLOv12与SpringBoot的茶叶病害检测系统，带web交互界面，前后端分离部署，中间接入了DeepSeek智能分析。整个项目跑通之后，我最大的感受是：模型精度绝对不是这个系统的天花板，工程集成的复杂度才是。这篇文章把我完整的技术链路、选型决策、踩坑记录和能直接抄作业的接口设计都写出来，给正在做农业AI或类似目标检测系统的朋友一个参考。

文章适合三类人：第一次做AI项目但没想清楚集成方案的同学；已经在调YOLO但不知道怎么接业务系统的开发者；以及需要在茶企或农业信息化项目里落地视觉方案的技术负责人。我会从需求分析、模型选型、数据集、训练导出、后端集成、大模型接入、部署坑位这几个环节一路讲下来，尽量把每一步的“为什么”也交代清楚，而不只是贴代码。

1. 这个项目到底在解决什么：茶园里的真实痛点

1.1 人工巡检的困境

茶叶病害是影响产量和品质的大问题。传统做法是茶农或植保员定期下园巡检，凭借肉眼确认叶片上有没有异常斑点，再靠经验判断是什么病。这个方法说清楚很容易——一个培训过的植保员能认出茶饼病、炭疽病、轮斑病这些常见病——但问题是量大、时间紧、漏诊率高。一片茶园上千亩，走完一遍要好几天，病害初期的病斑只有针尖大小，很少有人会在第一轮就发现。

我接触这个项目就是因为一个很现实的场景：某地茶企需要一个能随时拍照、快速告诉种植户“这是什么病、严不严重、该怎么处理”的工具。种植户没有专业植保知识，专家又不可能每天盯着手机回答几百人的提问，所以系统化的自动识别是刚需。这个需求不是“做一个Demo展示精度”，而是“让完全不懂技术的人拍张照就能拿到可用结论”。

1.2 为什么是目标检测而不是图像分类

看到“病害识别”这个需求，第一反应很可能是图像分类：给一张图片，输出“得了什么病”。但我做完需求分析之后，把方案改成了目标检测。原因很简单：实际茶园里拍的叶片图，往往不只有一棵茶树、一片叶子，分类模型只能告诉你整张图里“最明显”的问题，却无法定位病斑在哪、有几处、病变面积多大。而检测模型可以画出每个病斑的位置，后续还能基于框的尺寸做严重度分级——这才是生产端真正需要的信息。

举个例子：一张照片里同时有健康叶和十几片带病叶，分类模型很可能因为健康区域占比更大，直接输出“健康”。检测模型则能标出每一片病叶的坐标。这个差别在真实场景里是决定性的。分割模型精度更高，但对标注要求也高得多，考虑到这个项目的落地周期和标注成本，我最终锁定了目标检测。

1.3 系统技术栈全貌

整个系统分成三大块。前端是一个web交互界面，负责上传图片、展示检测结果、查看历史；后端是一个SpringBoot服务，负责用户管理、业务逻辑、调用推理和大模型接口；图像推理部分则是独立的Python服务，跑YOLO系列模型。DeepSeek智能分析放在最后一层，把检测结果翻译成人类看得懂的诊断和防治建议。这样前后端分离、模型与业务分离的设计，是我做完这个项目之后回头验证过的最优架构——每个部分都能独立迭代，互不拖累。

2. YOLO选型对比：v8/v10/v11/v12到底该选哪个

标题里把四个版本都写出来，不是凑数。我在这个项目里真的逐个跑过对比，先说结论：如果你的目标是“稳定上线”，首选YOLOv8；如果想顺便实验新特性，可以加跑YOLOv12做对比。v10和v11我只做了离线实验，没作为主力模型部署。

2.1 YOLO系列版本演进的底层逻辑

YOLO从v5开始，把目标检测从两阶段拉回了单阶段的主流战场。v8把anchor-free和C2f结构做成标配，训练稳定，社区生态最完善。v10提出的方向是去掉NMS的后处理流程，用一对多训练、一对一推理的思路减少推理延迟，但在小目标密集场景下，精度反而吃了点亏，因为少了一层NMS去重，对阈值选择更敏感。

v11在v8基础上重新设计了C3k2等模块，结构更像一个“全面优化版”，推理速度在某些硬件上有提升，但整体能力和v8差距没有拉开。v12是最新版本，引入了新的卷积模块设计思路，潜力大，实测部分场景的召回率确实更好，但社区资料少，部署踩坑要自己填。版本演进的逻辑说白了就一句话：每个版本都在“更准、更快、更好部署”三个维度上做取舍，没有绝对优劣，只有适不适合你的场景。

2.2 四个版本的横向对比

2.3 为什么主力用v8

三个原因。第一是生态成熟度：v8从训练、导出、量化、剪枝到部署都有大量现成资料，出了问题能搜到答案，v12的问题只能自己啃源码。第二是部署资料：转换ONNX、适配TensorRT这些环节，v8的坑基本被填平了，v12很多工具链还没来得及跟进。第三是团队熟悉度：一起协作的开发者对v8的API更熟，新版本带来的收益在生产项目中，抵不过兼容成本和资料缺失的代价。

这里我想强调一个观点：不要用新版本炫技。业务系统追求的是稳定可复现，模型A比模型B高0.3个点mAP，在真实茶园里远不如“部署环境稳定、接口不炸”重要。

3. 数据集这一步卡了我最久：采集、标注与划分

如果让我重新做一遍，我一定从数据采集的第一天就开始写标注记录。数据质量决定了后面精度的上限，模型结构和损失函数只能决定你离这个上限有多近。

3.1 数据从哪来：手机拍照也能用

采集方式不用迷信专业设备。我用手机在不同天气、不同时段、不同角度拍了大量照片，再结合一部分公开的农作物病害数据集做补充。这里有个重要细节：拍摄距离要拉开梯度。既要有整株茶树的远景——模拟用户离得很远随手拍；也要有单片叶子的特写——模拟用户凑近拍病斑。远景和特写的目标尺度差异很大，模型只在单一尺度训练的话，换一个距离表现立刻崩。

另外，数据的地域性很强。不同产区的光照条件、叶色背景、种植密度都不一样。我一开始用别人现成数据集训练，拿到自己茶园里测，准确率明显下降。后来补了将近三分之一的本地现场图，结果明显改善。如果你做类似项目，这个“本地化补数据”的步骤千万别省。

3.2 标注规范：bbox画到什么程度

标注工具我推荐X-AnyLabeling，支持辅助检测模型做预标注，人工只需微调，速度能快不少。但真正决定数据质量的不是工具，而是画框的规范。茶叶病斑有几个特殊性：

• 病斑边缘模糊，标大了会混入健康组织，标小了又会漏掉扩散区域
• 一张叶片上可能同时有多个病斑，需要每个都画框
• 同一片叶子上可能有两种病，不要勉强画一个大框包住，分开标
• 健康叶片也必须有标签类别，否则模型会把所有叶子都当成病害

遇到病斑小、密集、重叠的情况，我的经验是“宁大勿小，但要统一标准”。因为检测框稍微大一点，通过置信度阈值还能过滤；如果框小了，NMS之后很可能整个目标就被丢弃了。全项目所有标注人员先用几十张图片对齐一遍标准，再开工是最值得花的时间。

3.3 类别设计与增强策略

最终类别我定为：茶饼病、茶炭疽病、茶轮斑病、茶赤星病、茶芽枯病、健康叶片，一共六类。健康叶片放进训练集非常关键，否则系统上线后会把画面里的所有叶子都框出来当成病害，闹出“满屏都是病”的笑话。

数据增强方面，Mosaic增强对小目标识别帮助很大，它把多张图拼成一张，等于强制模型去关注更小的目标。但色彩增强要克制。因为真实叶片颜色本身就是诊断的重要依据，你要是把绿色叶片增强成红褐色，模型会学到错误关联。我只用了小幅度的亮度、对比度和噪声扰动，没做大幅色偏。

3.4 划分策略：防止数据泄漏

划分集合最容易犯的错，是随机按图片划分train/val/test。同一来源同一时间拍的照片，光照和背景几乎一样，随机划分会让模型在验证集上“作弊”——它见过同一场景的高度相似图，指标虚高，一到现场就露馅。

正确做法是按图片来源分组划分：同一个采集点、同一天的图片全部进同一个集合。这样验证集真正代表“没见过的场景”，测出来的指标才有参考价值。我的划分比例是train:val:test大约7:2:1，最后用test集做了额外的人工盲测，而不是只看训练时自动输出的验证集指标。

4. 训练与导出：那些指标背后到底发生了什么

4.1 训练配置与超参

我用的主力配置是YOLOv8s，输入分辨率640x640，训练轮数150到200之间，batch size 16，初始学习率0.01，优化器用SGD配余弦退火。说一下为什么不用Adam：在小数据集上SGD的训练曲线虽然看起来抖，但收敛后的泛化性往往更好，Adam前期容易冲得快、后期容易过拟合。当然这不是绝对规律，但我在几组对照里确认了SGD配温和的学习率调度对这个场景是稳的。

硬件上，单张消费级GPU就能训练，显存紧张就把batch降到8、把分辨率降到512测试。我第一次跑的时候把分辨率开到了960，显存直接爆炸，后来意识到茶叶病斑虽然有针尖大小的，但大部分目标在640分辨率下已经足够表达，堆分辨率解决不了本质问题。

4.2 正确看待指标

mAP50是“框得准不准”的主要参考，但因为茶叶病斑有的很小，mAP50-95更能反映多尺寸下的稳定性。我训练完的指标大概是：v8s在验证集上mAP50到了0.91左右，mAP50-95接近0.63。单独看不算差，但拿到真实茶园里一测，问题立刻暴露：强光下的叶片反光、阴影里叶片发暗、沾着露水的叶子表面有高光，都会让检测框不稳定。指标只能说明模型在测试集上的表现，真实的鲁棒性必须靠现场盲测验证。

这里我建议你用“最难样本集”来做复测：专门挑那些低光照、过曝、叶片重叠严重的照片塞成一堆，看模型在这些坏样本上的表现。比盯着mAP数字有用得多。

4.3 导出与推理封装

训练好的.pt权重需要转成ONNX格式才能接到推理服务。注意导出时要固定动态输入尺寸的选项，如果不小心导出了动态尺寸，有些推理框架的性能会明显下降。我最终固定到640x640输入，推理前在Python侧做letterbox预处理——就是等比缩放加灰色填充，避免非等比变形导致目标形变。

推理服务我没有用TorchServe，觉得太重了。直接用FastAPI包装一份推理逻辑，内部维护一个全局模型实例，所有预测请求复用同一份内存中的模型。核心细节有三个：letterbox预处理要在请求里记录缩放比例和填充量、输出解码要把相对坐标还原成原图坐标、NMS之后按置信度阈值过滤掉低分框。这三步任何一步偷懒，前端画出来的框位置都会偏移。

5. SpringBoot后端架构：它不是简单调个接口

5.1 服务分层

这个系统最值得写的不在模型，在后端怎么把模型编排成产品。项目模块划分很清晰：前端Vue3单页应用，后端Spring Boot 3.x加MyBatis-Plus和MySQL，Python推理服务用FastAPI独立部署。业务流就像一条流水线：前端上传图片，SpringBoot保存文件并记录到数据库，然后调用FastAPI做检测，拿到结果后调用DeepSeek分析接口，最后把结构化结果返回给前端。

为什么不让SpringBoot直接加载ONNX模型跑推理？我试过，Java生态跑ONNX Runtime不是不行，但预处理、后处理、NMS全要在Java里重写一遍，调试成本和模型迭代成本都高。模型迭代频次很高，Python侧改了权重，Java侧只要调HTTP接口完全不用动。这个决策把“算法团队”和“后端团队”的耦合彻底解开了。

5.2 接口设计：从上传到结果返回

把上传和分析拆成两个接口，是我做完V1之后优化的。为什么拆？因为检测加大模型分析加起来可能要好几秒，前端如果一直卡在同一个请求上，用户不知道是死机了还是在工作。拆开之后，前端先拿到detectId，立刻展示“图片上传成功，正在识别中”的中间状态，等第二个接口返回再渲染结果，体验好很多。

5.3 调用Python推理服务的工程细节

服务间通信我选了HTTP，走内网，简单可控。这里有几个不起眼但很重要的配置：连接超时设置成1秒，读超时设置成15秒，因为检测本身很快，但推理服务可能在并发时排队；连接池要开，否则高并发下每次请求都重新建立TCP连接；失败重试只对“网络抖动”重试，不能对“检测成功但返回格式异常”盲目重试。

还有一点，FastAPI侧一定要做并发控制。我一开始没加限制，前端一次上传十几张图，Python服务端直接内存撑满。后来在FastAPI里用信号量限制了最大并发推理数，超出的请求排队等待，内存问题就解决了。

5.4 同步还是异步

第一版我的方案是同步：前端上传后一直等结果。这个方案在并发很低时最简单，代码量最少，排错也容易。但并发一上来，同步请求会把连接占满。我的建议是：如果目标用户只有几十个人，同步流程完全够用；如果面向公众开放，必须改成异步——上传后返回taskId，前端轮询状态接口，推理完成后再拉结果。这个判断标准很朴素，别为不存在的性能问题提前过度设计。

6. DeepSeek智能分析接入：让系统不止会“框出来”

6.1 为什么要在检测后面加一层大模型分析

检测输出的是坐标框和类别概率，这种东西只有做技术的看得懂。种植户需要的是：“这是什么病、严重程度如何、该喷什么药、注意什么天气条件”。这个转化过程，传统做法是写死规则映射，但规则写多了就变成一团乱麻，而且不够智能。我接入DeepSeek，就是让它在检测结果的基础上做一层“自然语言翻译”，把结构化结果变成有温度的诊断报告。

实际使用中效果要比我预想的好：大模型不仅能复述检测结果，还能根据病斑数量、置信度分布给出风险等级判断，甚至能结合茶园常见管理场景补充防治建议。等于给系统加了一个“虚拟植保员”。

6.2 Prompt设计与结构化返回

接入大模型最关键的是Prompt设计和输出约束。我用了这样一段Prompt：

你是一名茶叶植保专家。请根据以下目标检测结果生成诊断报告： 检测类别：茶炭疽病 置信度：0.86 病斑数量：12 病斑平均尺寸：小 请严格输出JSON格式，包含四个字段： 1. disease_name：病害名称 2. severity：危害程度，可选值轻微/中等/严重 3. advice：具体防治建议 4. note：注意事项

输出格式必须用JSON约束，不能让它自由发挥。第一版我没约束，它返回一段自然语言，前端解析就是一场灾难。现在改成JSON结构化返回，后端直接存库，前端直接渲染，还能做历史记录的二次归档和分析。另外，Prompt里要加上“不要编造置信度”“不要给出超出检测结果的结论”这类限制性指令，否则大模型会一本正经地编一个数据。

6.3 前端交互：从上传到报告的完整链路

前端用的Vue3加Element Plus，整体流程是：上传组件选了压缩选项，把手机上动辄几兆的图片先压到两兆以内再传，后端检测速度会快不少。检测结果展示利用Canvas在原图上画框，画框颜色随置信度变化，置信度低于0.5的用灰色标注，降低用户对可疑检测的困惑。

右边是分析报告卡片：病害名称、置信度、病斑数量、严重程度、防治建议、注意事项。历史记录页面直接展示过往每一次的检测图片和报告JSON，支持重新查看。整套交互的核心原则是“先给结论、再给理由、最后给操作建议”，符合种植户的使用习惯。

7. 上线踩坑记录与扩展建议

7.1 我踩过的五个真实坑

1. 标注一致性翻车。最开始几个人标注标准不一样，导致模型分不清“茶炭疽病”和“茶轮斑病”，验证集上每个类别的精度都虚高，但实际使用中两者频繁混淆。解决方式是把混淆的图片拉出来统一复核，重新修正标注，模型重训后才恢复。
2. 强光照和阴影误检。太阳直射的叶片反光会被模型框成赤星病。后来在增强里加了高斯光照扰动，并补了一批反光严重的负样本，误检率才降下来。这个教训说明，数据增强要针对真实环境失败样本去设计，不是越随机越好。
3. FastAPI推理服务内存缓慢增长。排查发现是每次请求都会调一次模型的预热推理，等于重复加载了推理状态。改成启动时加载一次并复用一个session对象后，内存曲线平稳下来。
4. 大模型API超时导致整条链路失败。检测已经成功了，但分析超时，前端直接报错。后来我把两个步骤解耦：检测结果先落库返回，分析结果异步更新到报告；用户先看到检测框，分析报告稍后渲染，体验反而更好。
5. MySQL连接池爆掉。并发上传时数据库连接被抢光，后来加了连接池参数限制并增加连接排队逻辑，问题解决。

7.2 部署与性能优化建议

推荐部署组合是：SpringBoot和FastAPI都跑在Docker容器里，有GPU的机器跑推理服务，普通云服务器跑业务和数据库。推理对GPU的依赖很强，CPU推理在640分辨率下速度只有GPU的十分之一左右，如果预算有限，可以把输入分辨率降到480配合CPU跑，换速度。静态图片不要经过Java服务中转，直接走对象存储或Nginx静态目录，减少带宽压力。

历史查询要加索引，检测表按照创建时间做分表或分区。统计功能接口合并，避免前端为了画一个饼图发好几个请求。

7.3 还能怎么扩展

这个架构的扩展潜力比想象中大。换到其他作物只需要重新采集数据、重新训练模型，后端和分析层完全不用动。病害严重度分级可以在检测框尺寸和数量的基础上做规则判断，再交给大模型润色描述。接入气象数据后，可以联动预测高发病害风险。做小程序端也只是复用同一套后端API。边缘设备部署可以考虑把模型转成TensorRT或openvino格式，不太需要改后端协议。

这个项目做完之后，我的最大收获是：模型之外的系统集成才是决定落地效果的关键。一个精度稍低但稳定、可维护、用户看得懂的系统，远比一个精度很高但只在实验室跑得动的系统有价值。如果你也在做类似的农业AI项目，建议一开始就把数据采集规范、接口边界、前后端分离这些工程问题想清楚，这些才是真正决定项目能不能从Demo走到生产的东西。