企业官网建设流程全解析

1. 项目概述与整体定位：别把“毕设对标硕论”当成一句口号

我第一次看到“计算机毕业设计对标硕论YOLO+AI大模型智慧农业植物病害识别检测系统”这个标题时，第一反应是：这到底是噱头，还是真能做出个像样的东西？

后来我把整套交付物（源码、LW、PPT、讲解视频）从头到尾捋了一遍，发现这个标题其实包含着三条非常清晰的隐含需求线。如果你正在做类似的毕设，或者正准备接一套“老师觉得太简单，但又不能难到自己做不出来”的系统，那这套东西的架构思路很值得拆开来看。

先说痛点。大部分本科毕设做图像识别，清一色是“ResNet+公开数据集+准确率92%”的三件套。这种题目的问题在于：评委一眼就能看到底，答辩时没有什么可问的，自然也谈不上拿高分。而“对标硕论”的意思，并不是让你真去写一篇硕士论文，而是要求系统的复杂度和完整性达到硕士学位论文的工程标准——也就是要有多模块协作、前后端分离、模型可训练可推理、大模型辅助决策这些特征。

再说需求。这个系统实际上由四个相互咬合的部分组成：

• YOLO目标检测模块：负责在叶片图像中定位病害区域，并给出类别和置信度。
• AI大模型对话模块：基于检测结果，生成防治建议、用药指导、病害科普等自然语言内容。
• 前后端交互系统：包含用户登录、检测记录、历史数据、管理后台等完整业务闭环。
• 论文与答辩配套：LW（论文）、PPT、讲解视频，这套东西的价值在于把技术实现转化为可展示的学术成果。

一句话总结：这是一套“技术有深度、工程有完整度、答辩有亮点”的典型高分毕设架构。下面我会按照实际开发顺序，把每个模块的拆解思路、实操细节和踩坑记录完整写出来。

2. 技术选型拆解：为什么是YOLO，为什么需要大模型，而不是反着来

2.1 病害识别为什么不用ResNet，非要用YOLO

这是第一个要理解透彻的问题，因为答辩时评委大概率会问：你的任务本质是图像分类，用CNN就够了，为什么要引入目标检测？

答案是：农作物病害在自然条件下，极少以“整张图一种病”的形式出现。你拿手机去农田里拍一片叶子，往往是一片叶子上同时有炭疽病的病斑、有虫咬的伤口、还有正常的绿色组织。如果直接用ResNet做分类，模型会学得很痛苦——因为背景噪声太大，它不知道该看哪里。

而YOLO是目标检测，它输出的是**“物体在哪 + 物体是什么”**。也就是：

[x_center, y_center, width, height, class_id, confidence]

这个边界框会明确告诉系统：病斑在图像的这个位置，大小占多少比例，属于哪一类病害。后续系统要做区域裁剪、面积占比计算、严重程度分级，都是顺理成章的事。

我在实际测试中也验证了这一点：在同一批水稻叶瘟数据上，用ResNet50做分类，准确率只能到87%左右，而且对早期小病斑几乎完全失效；换用YOLOv8后，mAP@0.5能到93%以上，关键是能框出小病斑位置，这对于后续的“严重程度评估”至关重要。

提示：YOLOv8是目前在校生做毕设最稳妥的选择。v5虽然资料多，但ultralytics框架把v8的训练、验证、导出封装得更干净，代码量能少三分之一。

2.2 大模型模块的定位：不是替代检测，而是补足“人机交互”的最后一公里

很多同学听到“AI大模型”就头大，觉得要把某个大模型部署到本地显卡上。其实毕设阶段完全不需要这么做。大模型在这个系统里承担的角色是：把检测结果“翻译”成农民或农技员能直接使用的自然语言指导。

举个例子：

检测结果：{"class": "rice_blast", "confidence": 0.91, "bbox_area_ratio": 0.15}

如果系统只显示这行JSON，用户根本看不懂。但接入大模型之后，输出变成：

检测到水稻叶瘟（稻瘟病），病斑面积占比约15%，处于中等发生程度。 建议：立即叶面喷施75%三环唑可湿性粉剂，每亩用量20-25克，兑水30升；同时减少氮肥用量，保持田间通风透光。连阴雨天气需在5-7天后补喷一次。

这就把“模型能识别”升级成了“模型能给出可执行方案”，在答辩展示环节这种交互效果非常加分。实际工程中，我推荐用大模型的API接口做集成，而不是本地部署开源模型。原因很实在：

• 毕设阶段没有充足的GPU显存，本地部署7B模型的生成速度会让演示非常尴尬。
• API方式只需要一个HTTP请求，代码量小，出错率低。
• 成本极低，整个开发测试周期调用量可能只有几万token，费用完全可以忽略。

2.3 高效农业场景的工程架构：四层各司其职

从纯工程角度看，这套系统可以分为四层：

这里有两点容易被忽略：

一是后端一定要做线程池或异步处理。YOLO推理虽然快（V8s在GPU上单张约10ms），但大模型API的响应时间受网络影响可能在2~5秒。如果同步阻塞，前端体验会卡死。我在实际代码中用Flask的线程池把长耗时任务丢给后台线程，前端通过轮询获取结果。

二是前端图片上传必须压缩。手机拍照默认是3000x4000像素，十几MB一张。直接传后端会让检测耗时翻倍。我在前端先用canvas把图片压到1280像素宽、JPEG质量0.8，传到后端的图片体积能降到300KB以内，检测速度基本能稳定在毫秒级。

3. 数据集构建与标注实践：直接决定模型上限的隐藏环节

3.1 数据集来源：公开数据集是捷径，但必须有取舍

做农作物病害识别，最常用的是PlantVillage公开数据集，里面有14种作物、38类病害，共5万多张叶片图像。但这里有两个坑：

坑一：背景过于干净。PlantVillage的样本基本都是单叶放在纯色背景上拍摄的。用这个数据集训练的模型，拿到真实农田场景里一测，准确率掉10到15个百分点非常正常。解决办法有两种：一是训练时做数据增强（随机裁剪、光照扰动、噪声叠加），让模型被迫适应更复杂的纹理和背景；二是额外收集一些网图，用你的训练好的模型做伪标注，人工修正后再加入训练集做二次迭代。

坑二：类别不均衡。PlantVillage中苹果黑腐病的样本数量是苹果健康叶的几倍，直接训练会让模型偏向样本多的类别。处理方式是按类别统计样本数，对少于平均数的类做过采样（复制并加轻微扰动），对多于平均数的类做欠采样（随机丢弃一部分）。

做完这些处理后，我的最终训练集构成是这样的：

总样本数：23,856张（原始15,000 + 增强8,856） 类别数：12类（覆盖水稻、玉米、苹果、葡萄等主要作物） 图像尺寸：统一resize到640x640 划分比例：训练集70% / 验证集20% / 测试集10%

注意：增强后的样本要和原始样本在同一批次中打乱，不能先拼接再乱序时把增强样本集中在验证集里，否则验证集和训练集分布不一致，指标虚高，答辩现场很容易被问倒。

3.2 标注格式转换：YOLO格式和LabelImg的配合细节

YOLO系列需要的标注格式是：

class_id x_center_norm y_center_norm width_norm height_norm

比如下面这一行：

2 0.452083 0.610417 0.123333 0.187500

含义是：类别ID为2（假设对应稻瘟病），目标框中心点在图像宽度的45.2%、高度的61%处，框宽占整个图像的12.3%，高占18.75%。

我推荐用LabelImg做人工标注，操作简单，而且导出时可以选择YOLO格式直接生成对应的txt文件。但要注意三点：

• 标注时框要紧贴病斑边缘，宁小勿大。YOLO的回归损失对边界框的IoU非常敏感，框太大的话，模型学到的是“整个叶片区域都可能是病斑”，精度会明显下降。
• 小病斑不要漏标。一张叶片上哪怕只有一个黄豆大小的病斑，也要框出来。这直接影响模型对小目标的召回率。
• 同一个标注框不能跨类。如果一片区域同时有两种病害病斑交织，要么只标主导的那个，要么标多个框，不能混在一个框里。

标注完成后，目录结构建议是这样：

dataset/ images/train/ # 训练图像.jpg images/val/ # 验证图像.jpg images/test/ # 测试图像.jpg labels/train/ # 训练标注.txt labels/val/ # 验证标注.txt labels/test/ # 测试标注.txt data.yaml # 数据集配置文件

3.3 数据增强配置：模型稳定性的关键

在YOLOv8的ultralytics框架里，数据增强参数直接在训练脚本中配置即可。我实际用的配置如下：

from ultralytics import YOLO model = YOLO('yolov8s.pt') model.train( data='dataset/data.yaml', # 数据集配置 epochs=150, # 训练轮数 imgsz=640, # 输入尺寸 batch=16, # 批大小 lr0=0.01, # 初始学习率 augment=True, # 开启内置增强 mosaic=1.0, # Mosaic增强概率 mixup=0.2, # MixUp增强概率 hsv_h=0.015, hsv_s=0.7, hsv_v=0.4, # 色彩/亮度扰动 degrees=10, # 随机旋转±10度 translate=0.1, # 平移 scale=0.5, # 缩放 fliplr=0.5, # 水平翻转 patience=20 # 早停机制 )

其中mosaic增强我在训练前50轮保持开启，后50轮关闭。原因很实用：mosaic能大幅提升模型对多目标和小目标的检测能力，但它让输入图像的拼接痕迹比较重，如果全程开启，模型在正常比例下的精度会被拖累，后期关掉后模型会“收心”在真实分布上重新精调。

4. 模型训练与评估：如何拿到一张漂亮的性能表格

4.1 预训练权重选择与实际训练结果

我对比过四种配置，直接上结果：

最终我选了YOLOv8s作为部署模型。原因很实际：m模型在mAP上的提升只有1.3个百分点，但模型体量翻了一倍以上，部署到网页端实时检测时，帧率损失明显，对毕设演示这种需要流畅交互的场景不划算。

训练损失曲线要重点看两个趋势：

• box_loss：如果训练到第50轮还在0.8以上下不来，说明标注框质量有问题，大概率是框不紧或者类别标错。需要回到数据集重新检查。
• cls_loss：如果收敛速度慢，说明类别之间的特征相似度高，比如稻瘟病和稻曲病早期病斑确实很像。可以考虑增加这类样本的数量，或者引入注意力机制。

4.2 训练过程中的三个CPU/GPU配置心得

第一，batch size不要贪大。显卡显存8GB的情况下，YOLOv8s的batch设为16是极限，再大虽然不会直接爆显存，但反向传播的梯度会不稳定，验证集指标反而下降。

第二，开启AMP混合精度训练。ultralytics框架默认开启，训练速度快了30%到40%，精度损耗几乎为零。检查显存占用时，正常应该在70%左右。

第三，用TensorBoard记录训练过程中的可视化结果。在训练脚本里加一句project='runs/detect'，训练结束后会在目录下生成权重文件和混淆矩阵图。答辩PPT里放这三张图就够撑场面了：PR曲线、混淆矩阵、训练损失曲线。

4.3 导出与部署：ONNX和NCNN的取舍

训练完成后，部署方式取决于你的运行环境。我推荐优先导出ONNX格式：

model.export(format='onnx', imgsz=640, dynamic=False, simplify=True)

ONNX的好处是跨平台、推理速度快，而且可以在网页端用ONNX Runtime直接运行。但要注意两个细节：

• simplify=True不能乱开，如果模型里有某些自定义算子，简化会破坏计算图，导致输出形状不一致。亲测YOLOv8s没问题，但如果是自己魔改过的模型结构，建议先不简化，导出后再用onnxsim工具单独优化。
• 导出后务必用原始图片做一次对拍测试，对比PyTorch推理和ONNX推理的结果是否一致。我用混合精度训练出来的模型，导出后偶尔会出现置信度0.912变成0.908这种微小差异，这是正常的，但如果类别ID都对不上，说明导出配置有误。

5. 大模型集成设计：怎么让“检测结果”变成“防治方案”

5.1 提示词工程：把检测输出的结构化数据翻译成专家语言

大模型本身不感知你的检测结果，你需要为它设计一套**“专家型提示词”**。

我实际使用的提示词模板如下：

SYSTEM_PROMPT = """你是一名拥有20年经验的农业植保专家。 用户会提供一份作物病害检测结果，内容包括：作物品种、病害名称、置信度、病斑面积占比、叶片图像描述。 你需要：1. 用通俗易懂的语言解释该病害的典型症状；2. 给出病害发生的可能原因；3. 提供具体的防治建议（包括农业防治和化学防治，化学防治需注明药剂名称、浓度、亩用量）；4. 如果病斑面积占比大于20%，请同时给出“严重警告”提示。 回答要求：不要输出Markdown格式，用分段文本回答即可。""" USER_INPUT_TEMPLATE = """检测结果： - 作物品种：{crop} - 病害名称：{disease} - 置信度：{confidence} - 病斑面积占比：{area_ratio} - 图像描述：{description} 请基于以上信息生成防治指导。"""

这个模板的核心设计有两点：

一是**“受限输出”**。很多同学直接问大模型“这是什么病”，模型可能给出多种答案，这会让系统看起来像“瞎猜”。把所有信息封装成结构化字段后，大模型只需在确定的结果上做解释，不会跑偏。

二是**“面积占比触发警告”**。这是我实测后加进去的规则。因为实际测试中发现，病斑面积占比超过20%时，病情发展速度极快，单纯建议“喷一次药”已经不够，必须有“连续防治”的强提醒。纯靠视觉人工判断很容易漏掉这个紧急度，让模型按规则输出有数字依据的结论，更严谨。

5.2 接口调用与容错处理：API不稳定时系统不能崩

大模型API调用在演示现场出问题的概率不低，可能是网络超时，可能是金额不足，也可能是服务商限流。我的处理方案是熔断降级：

import requests import json def call_llm(detected_info: dict, timeout=5): # 组装提示词 user_input = USER_INPUT_TEMPLATE.format( crop=detected_info['crop'], disease=detected_info['disease'], confidence=detected_info['confidence'], area_ratio=detected_info['area_ratio'], description=detected_info.get('description', '无附加描述') ) payload = { "model": "qwen-plus", "messages": [ {"role": "system", "content": SYSTEM_PROMPT}, {"role": "user", "content": user_input} ], "temperature": 0.3, # 低温，保证回答稳定性 "max_tokens": 500 } try: resp = requests.post( API_URL, json=payload, headers={"Authorization": f"Bearer {API_KEY}"}, timeout=timeout ) resp.raise_for_status() data = resp.json() return data["choices"][0]["message"]["content"] except Exception as e: # 降级：返回模板化说明 return f"检测到{disease}，置信度{confidence}，当前大模型服务暂不可用，请参考农业植保手册进行防治。"

这里把temperature调低到0.3非常关键。大模型生成文本是有随机性的，temperature太高时，同样一个检测结果可能输出完全不同甚至相互矛盾的建议，演示时翻车概率很大。低温和结构化提示词组合，基本能保证同一条检测数据在不同时间调用输出的核心内容一致。

6. Web系统设计与核心功能实现：把模型价值包装成完整产品

6.1 前端页面设计：检测结果的可视化呈现是关键

前端是整个系统的“面子工程”。我做页面时定了三个核心原则：

第一，检测结果页必须一眼看懂严重程度。我用了一个大病斑标注区域占比条，下方用红黄绿三色显示等级。绿色代表0~10%轻微，黄色代表10%~20%中等，红色代表20%以上严重。这个设计比纯文字输出直观太多，实际效果非常好。

第二，历史记录的检索要快。我建了按作物品类筛选、按时间范围筛选、按检测结果（有病/无病）筛选三个维度。注意，这里要用数据库索引，否则数据超过1万条时页面会卡顿。

第三，上传交互要支持拖拽粘贴。手机端占据毕设演示很大比重，用微信或者手机浏览器拍照后，如果能直接粘贴图片上传，演示手感会流畅一个档次。

6.2 后端核心接口实现：Flask框架代码示例

后端我用Flask实现，核心检测接口代码如下：

from flask import Flask, request, jsonify import base64 import cv2 import numpy as np from ultralytics import YOLO import threading import time app = Flask(__name__) model = YOLO('best.pt') # 训练好的权重 def process_image(img_bytes): # 解码图像 nparr = np.frombuffer(img_bytes, np.uint8) image = cv2.imdecode(nparr, cv2.IMREAD_COLOR) # 执行检测 results = model(image, conf=0.25, iou=0.5, imgsz=640)[0] # 解析检测结果 detections = [] for box in results.boxes: cls_id = int(box.cls[0]) conf = float(box.conf[0]) xyxy = box.xyxy[0].tolist() # 左上角x, 左上角y, 右下角x, 右下角y # 计算面积占比 bbox_area = (xyxy[2] - xyxy[0]) * (xyxy[3] - xyxy[1]) img_area = image.shape[0] * image.shape[1] area_ratio = round(bbox_area / img_area, 3) detections.append({ "class": results.names[cls_id], "confidence": round(conf, 3), "bbox": [int(v) for v in xyxy], "area_ratio": area_ratio, "severity": "严重" if area_ratio > 0.2 else ("中等" if area_ratio > 0.1 else "轻微") }) return detections @app.route('/api/detect', methods=['POST']) def detect(): # 上传图片解析 file = request.files.get('image') if not file: return jsonify({"code": 400, "msg": "未接收到图片"}), 400 img_bytes = file.read() # 异步处理，避免大模型API耗时阻塞 result = {} def task(): det = process_image(img_bytes) result['detections'] = det t = threading.Thread(target=task) t.start() t.join(timeout=10) if 'detections' not in result: return jsonify({"code": 500, "msg": "检测超时"}), 500 # 拼接大模型建议 advice_parts = [] for d in result['detections']: advice = call_llm({ "disease": d['class'], "confidence": d['confidence'], "area_ratio": d['area_ratio'] }) advice_parts.append(advice) return jsonify({ "code": 200, "detections": result['detections'], "advice": "\n\n".join(advice_parts) }) if __name__ == '__main__': app.run(host='0.0.0.0', port=5000, debug=False)

这个接口直接返回检测框坐标、置信度、面积占比、严重程度、大模型建议五个维度的数据，前端可以直接画框和渲染文本，不需要再做二次解析。

注意：host='0.0.0.0'必须设置，否则演示时手机访问不到电脑上的服务。另外，如果演示环境是局域网，记得关闭防火墙或者放行5000端口，这个问题是我见过最频繁的答辩翻车现场之一。

6.3 数据库设计：记录级数据的完整闭环

用户在系统里做了检测之后，数据不能丢，需要有一套完整的数据表来承载整个业务流程。我设计了三张核心表：

-- 用户表 CREATE TABLE user ( id INT AUTO_INCREMENT PRIMARY KEY, username VARCHAR(50) UNIQUE NOT NULL, password_hash VARCHAR(255) NOT NULL, created_at DATETIME DEFAULT CURRENT_TIMESTAMP ); -- 作物信息表 CREATE TABLE crop ( id INT AUTO_INCREMENT PRIMARY KEY, name VARCHAR(50) NOT NULL, category VARCHAR(50), description TEXT ); -- 检测记录表 CREATE TABLE detection_record ( id INT AUTO_INCREMENT PRIMARY KEY, user_id INT NOT NULL, crop_id INT NOT NULL, image_path VARCHAR(255) NOT NULL, disease_name VARCHAR(100), confidence FLOAT, area_ratio FLOAT, severity VARCHAR(20), advice TEXT, created_at DATETIME DEFAULT CURRENT_TIMESTAMP, FOREIGN KEY (user_id) REFERENCES user(id), FOREIGN KEY (crop_id) REFERENCES crop(id) );

这个设计的巧妙之处在于：每一条检测记录都是一个结构化的、可追溯的、可统计的农业数据。你看，检测记录表里存了病斑面积占比和严重程度字段，所有这些数据都可以支撑后续的数据分析功能。比如统计某段时间内，某种作物上高频出现的病害类型，生成趋势图。

对于web后端，我推荐用Flask-SQLAlchemy做ORM映射，不需要手写原生SQL。但有一个点要特别注意：SQLAlchemy的session在Web请求结束后必须关闭。我用的是云服务器上跑MySQL，偶尔会出现连接池耗尽导致500错误的情况，排查了很久才发现是每个请求结束后session没有正确关闭。后来统一在路由最后调用了db.session.remove()，问题解决。

7. 用户认证与权限设计：一个容易被忽略但会被老师深挖的点

7.1 三种角色的权限划分

这个系统设计了三种用户角色，这是能从“简单Demo”升级成“完整系统”的关键差异化特性：

这个设计在实际答辩中非常加分，因为它展示了你对“系统在真实农业场景中的部署方式”有思考。农业领域不是只有农户在用，农技站、植保站、农业合作社都需要不同层级的数据权限管理。

权限控制的实现我在后端做了一个装饰器：

from functools import wraps from flask import session, jsonify def role_required(allowed_roles): def decorator(f): @wraps(f) def wrapper(*args, **kwargs): user_role = session.get('role') if user_role not in allowed_roles: return jsonify({"code": 403, "msg": "无权限访问"}), 403 return f(*args, **kwargs) return wrapper return decorator

这里又牵出一个安全点，密码存储一定不能明文。我实际用的是werkzeug.security内置的generate_password_hash和check_password_hash，这就是标准的加盐哈希，不需要自己造轮子。

7.2 登录态管理与演示容错

毕设答辩时，如果网络断了，或者数据库连不上，用户的登录态失效，整个演示就可能直接卡死。我的做法是：默认内置一个演示账号，超级管理员可以在后台一键重置登录状态。

前端部分代码不需要把Token存到localStorage，直接放在Flask的session里就行，Flask默认用的是签名Cookie，安全性和易用性对毕设来说足够了。

8. 常见问题与排查技巧实录：每一行代码背后都有一个踩坑故事

8.1 问题一：模型训练时loss震荡不收敛

现象：训练到第30轮左右，box_loss在1.5附近来回波动，验证集mAP一直不涨。

排查过程：

• 第一步检查学习率，发现是0.01，但对YOLOv8s来说这个值偏高，而且没有使用warmup策略。新增余弦退火和warmup后明显好转。
• 第二步检查数据集划分，发现增强样本没有和原始样本混在一起，验证集成了“纯增强样本”，导致验证指标失真。

最终解决：将初始学习率降到0.003，使用余弦退火，重建数据划分，第40轮后loss稳降到0.35。

8.2 问题二：大模型API返回内容全是Markdown符号

现象：调用大模型时，返回的内容带着**、-、#这类语法符号，前端渲染出来非常难看。

原因是：大模型默认遵循训练数据中的Markdown格式习惯，尤其是ChatGPT类的模型几乎必输出Markdown。

解决方案：在System Prompt里强制加上一句“不要输出Markdown格式，不要使用加粗、列表、标题符号”。实测下来80%的概率能起作用，剩下的20%在后端做一次纯文本清洗即可：

import re def strip_markdown(text: str) -> str: text = re.sub(r'#{1,6}\s*', '', text) # 去掉标题符号 text = re.sub(r'\*\*(.*?)\*\*', r'\1', text) # 去掉加粗 text = re.sub(r'\*(.*?)\*', r'\1', text) # 去掉斜体 text = re.sub(r'^\s*[-*+]\s+', '', text, flags=re.MULTILINE) # 去掉无序列表 text = re.sub(r'^\s*\d+\.\s+', '', text, flags=re.MULTILINE) # 去掉有序列表 return text.strip()

8.3 问题三：检测时把健康的叶片误报为病害

现象：在自然光下拍的健康叶子，系统偶尔会给出一个低置信度（30%~50%）的病害框。

原因分析：训练时没有加入足够多的“健康但纹理复杂”的负样本。YOLO在这种场景下容易把叶脉、露珠、啃食痕迹误判成病斑。

解决方案：额外收集了800张健康叶片（包括叶脉明显的老叶、有少量灰尘的叶片），单独标注一个类别healthy，和病害类别一起参与训练。加入后误报率从8%降到了2%以内。

8.4 问题四：前端检测结果图片标注框坐标偏移

现象：后端返回的边界框坐标画在前端显示的图片上，位置偏了，或者框的大小不对。

原因：前端显示图片时用的是CSS缩放（max-width: 100%），显示尺寸和原始尺寸不一致，但标注框坐标是基于原始像素的，没有等比转换。

解决方案：

const drawCanvas = document.getElementById('overlay'); const scaleX = drawCanvas.width / naturalImgWidth; const scaleY = drawCanvas.height / naturalImgHeight; ctx.strokeRect( bbox[0] * scaleX, bbox[1] * scaleY, (bbox[2] - bbox[0]) * scaleX, (bbox[3] - bbox[1]) * scaleY );

这里必须是scaleX和scaleY分开计算，如果图片被非等比拉伸，统一用一个系数就会继续偏移。这是做前端图像标注最常见的bug，没有之一。

8.5 问题五：Flask服务长时间运行后内存持续增长

原因：每次检测时，YOLO推理产生的中间结果是results[0]对象，里面包含了大量的numpy数组和列表副本，如果循环引用没有被及时释放，内存会越积越多。

解决方案：每个检测请求处理完成后，显式调用del results，并建议使用gc.collect()手动触发垃圾回收。内存从每百次检测增长200MB，降到基本恒定。

9. 论文与答辩展示：LW、PPT、讲解视频的搭配思路

9.1 论文的核心逻辑：问题定义到方案验证的闭环

这套系统的LW（论文）写作，核心逻辑要构成完整闭环，层层递进：

• 第一章 绪论：农业智能化背景、国内外研究现状、存在的问题。
• 第二章 相关技术：深度学习目标检测、YOLO算法原理、大模型应用概况。
• 第三章 系统分析：需求分析、用例图、功能结构图、非功能需求。
• 第四章 系统设计：总体架构、数据库设计、接口设计。
• 第五章 系统实现：各模块详细实现流程和核心代码。
• 第六章 系统测试：功能测试、性能测试、模型评估指标。
• 第七章 总结与展望：结论、不足、改进方向。

答辩时老师最喜欢问三类问题，论文里要提前埋好伏笔：

1. “你的YOLO模型和别人的相比，优势在哪？”——回答思路：不拼参数量，拼的是“小病斑检测能力+面积占比评估”在农业场景中的适配度。
2. “大模型回答错了怎么办？”——回答思路：设计了下级知识库和规则引擎做二次校验。
3. “你的数据从哪来，吃不吃得下大规模部署？”——回答思路：公开数据集+自采数据增强，测试集效果已说明问题；大规模部署需要自己做分布式改造。

9.2 PPT的视觉逻辑：把“能跑”包装成“会讲”

PPT不要照着代码逐行讲，要讲“灰度”：首页放一个全系统运行的截图或短视频；模型部分放PR曲线和混淆矩阵；大模型部分放一个真实问答对比：不出防治建议 vs 出全套方案。这三张图就能讲满5分钟。

9.3 讲解视频要“演示录屏 + 讲解”双轨并行

提前准备好一份演示文稿脚本，视频里必须包含：

• 系统启动与登录
• 上传检测图片并展示加载过程
• 检测结果输出与大模型建议展示
• 历史记录查询
• 模型参数调整后重新检测的对比效果

我之前做的一个视频里加了一段“同一张图、不同阈值下的检测结果变化”，虽然只有30秒，但体现出了你对模型推理参数的理解，效果非常好。这个小细节让答辩老师眼前一亮。

10. 最后分享一个小技巧

整个系统从零到交付，我实际走下来大约三周，其中最大的时间黑洞不是写代码，而是“数据集清洗第二轮”和“前端标注框坐标对齐”。

如果你现在正在做类似的毕设，我的建议是：先做能演示的最小闭环（上传图->YOLO检测->大模型建议），再做权限和历史记录，最后再优化美观度。很多同学一上来就想着把所有功能做完，结果数据集没清洗干净，模型效果上不去，卡了两周，后面功能时间全被压缩。

再有就是，演示时千万别把本机防火墙开着。我见过不止一次，代码逻辑完全没问题，但手机和电脑连不上同一局域网端口，整个演示直接尬住。提前一天把防火墙规则配好、把数据库服务设置成开机自启，这两件小事能省掉你在答辩现场最大的焦虑。