简介：一套基于YOLOv8的航拍图像分析系统，面向深度学习、目标检测方向的毕业设计或课程设计场景，适合计算机、人工智能、自动化、电子信息等专业学生快速搭建可用项目，也适合初学者进阶参考。资源包含完整源码、配套数据集、可视化界面与部署说明，代码经测试可运行，能输出核心指标曲线、混淆矩阵、F1分数曲线、精确率-召回率曲线、验证集预测结果及标签分布图，可直接支撑毕设答辩展示。压缩包共97个文件，其中以70个Python脚本为主体，覆盖模型训练、检测推理、可视化页面和工具函数；另含12个pyc编译文件、5个xml配置、4个pt权重模型、2个txt说明及1个mp4演示视频，整体仅24.21MB，目录结构清晰，便于按模块学习。已有62人学习下载。从数据准备、模型训练到指标评估的完整闭环，配合README与演示视频，可帮助读者快速复现并理解YOLOv8航拍检测流程，也能在现有框架上扩展功能，适合课程设计、项目初期立项或毕业设计二次开发。
1. 航拍图像分析这个毕设方向，为什么都绕不开 YOLOv8
拿到《基于YOLOv8的航拍图像分析系统》这类 zip 包的场景，我在不同阶段见过不下十次：有人是毕设开题刚从学长手里拷来的，有人是课程设计从资源站打包下载的，共同点是解压后直接双击 main.py 等着出界面，结果不是缺包就是黑窗口一闪而过。标题里说的"简单部署即可运行"是相对从零开发而言的，并不是说解压就能跑。YOLOv8 负责的是整条链路里最重的检测部分：加载模型、对航拍画面里的车辆、船只、建筑做定位与分类；数据集、可视化界面、部署教程则是把它串成完整系统的另外三块。这篇文章就顺着这类项目包的目录结构，把环境、数据、训练、界面、踩坑一条线讲完。
2. 拿到 zip 先别急着跑：YOLOv8 航拍项目的包结构与检测难点
2.1 这类 zip 里通常有哪些东西，缺了什么要自己补
这种毕设包的结构大同小异，解压后在根目录一般能看到五六类东西：主程序入口（detect.py、ui.py 或 main.py）、模型目录（models/ 里放着训练好的 .pt 权重）、数据集目录（datasets/ 或 data/，按 train 和 val 分好）、界面目录（UI/ 常见是 PyQt5 写的）、训练输出（runs/ 里是验证集预测图和 results.csv）、说明文件（requirements.txt 和 README.md）。
| 目录/文件 | 典型内容 | 拿到手要确认什么 |
|---|---|---|
| main.py / ui.py | 程序入口，调用模型做推理并展示结果 | 是否引用了本地不存在的绝对路径 |
| models/ | .pt 权重文件 | 训练轮次是否足够，是 yolov8n 还是 s/m |
| datasets/ | 图片加标注 txt | 标注类别是否与你检测目标一致，路径是否写死 |
| runs/ | 验证集预测图、results.csv | 看 mAP 和 loss 曲线，判断模型是不是"半成品" |
| requirements.txt | 依赖清单 | 版本是否和你的 Python 匹配，有没有多余高版本 |
这里必须说实话：网上流传的包，权重和标注经常对不上。比如 models 里放的是从 COCO 上迁移过来的预训练权重，只能检出 person、car 这些通用类别，而 datasets 里的标注是航拍数据集自己标的（车型、船只、储油罐），类别编号根本对不上，跑出来的结果自然一塌糊涂。所以拿到包的第一步不是跑，而是打开 data.yaml 看类别，再和模型权重里的类别名做一次对齐。
我一般会写一小段代码验证两边的类别是否一致：用 yaml.safe_load 读数据配置，再通过 model.names 读权重类别，做交集比对。这个检查能避免后面训练时最麻烦的标注错位问题，比直接跑训练命令省时间得多。如果发现对不上，优先用项目自己训练出来的 best.pt，而不是官方预训练权重继续当结果用。
2.2 航拍图和普通场景图的检测差异：为什么 YOLOv8 也要改参数
航拍图像分析系统的模型选型几乎都落在 YOLOv8 上，原因很直接：检测速度够、精度可接受、改造成本低、中文资料多。但航拍图和平常手机拍的图是两个世界。无人机俯视视角下，目标尺度普遍小，一辆轿车在 6000×4000 的原始航拍图里可能只占 20×40 像素；目标密度还特别大，停车场里几十辆车挨在一起；树冠、阴影、屋顶纹理又和车辆外观相似，误检也多。公开的 DOTA、VisDrone 这类航拍数据集里，超大图和密集小目标都是标准配置，和普通目标检测数据集差别明显。
这几个特点直接影响 YOLOv8 的用法。YOLOv8 默认输入尺寸是 640×640，直接把航拍大图压到 640，20 像素的小目标再缩就几乎没特征了。所以航拍项目里最常见的调整是输入尺寸放到 1280，或者换带 P2 小目标检测头的结构。而"能不能吃下 1280 的输入"又取决于显存，这里就带出一个配套问题：毕设机器往往是 1660ti 这种 6G 显存的卡，训练批次、模型规模、输入尺寸都得跟着显存重新算，第四章训练参数里我会给一组能落地的具体数值。
除此之外还有一个方向性维度：航拍图如果带地理坐标，检测结果往往要输出去重之后做密度统计，比如把车辆检测框落到网格里生成热力图，这是毕设答辩里"功能完善"的一个加分点。坐标去重和密度统计的方法在第六章展开。
2.3 运行前的最小检查清单：三分钟判断包能不能用
与其解压后乱试，不如按固定顺序做三个检查。第一步核对 Python 版本，YOLOv8 依赖的 ultralytics 工具包要求 Python 3.8 以上，建议直接用 3.9 或 3.10；很多包 README 里还写着 3.7 就照抄的，直接忽略，版本太低装不上新版 torch。第二步看 requirements.txt 里 ultralytics 和 torch 的版本，用 pip list 对比本机，差距太多会出现 API 对不上的报错，比如 torch.load 的 weights_only 参数问题。
第三步最重要：不跑界面，先跑纯推理。命令行进入虚拟环境，用最朴素的代码加载 models 里的 .pt，对 datasets 里的一张图推理并保存结果，看能不能正常出框。如果这个最小流程通了，说明模型和环境没问题，再回头碰界面；如果不通，问题大概率是权重文件损坏或 torch 与 CUDA 版本错配。这一套检查做完，基本能筛掉八成"包本身有问题"的情况，剩下的就是环境细节，第三章开始把环境完整走一遍。
3. 环境搭建与第一次推理：在 CPU 和 GPU 上把航拍图跑起来
3.1 conda 环境与 torch 安装：CPU 版和 GPU 版两条路线
写环境配置前先明确一个原则：推理和界面展示这两步，CPU 也能做，只是慢；训练建议有 NVIDIA 显卡，没有也不是不能训，只是时间成本翻好几倍。热词里"ubuntu20.04搭建yolov8环境cpu版本"被搜得多，说明大批毕设机器其实是 CPU-only 的，这条路线单独讲清楚。
安装我建议用 conda，不要往系统 Python 里直接塞，因为 torch、opencv 这一堆包版本敏感，隔离环境出问题直接重建，成本最低：
conda create -n aerial python=3.10 -y conda activate aerial pip install ultralyticsCPU-only 机器注意：不要用默认命令装 torch，默认会带 CUDA 依赖，体积大而且装完发现用不上；按官方 CPU 索引装，量级差很多：
pip install torch torchvision --index-url https://download.pytorch.org/whl/cpu pip install ultralytics说明一下为什么这么装：ultralytics 会把 torch 作为依赖自动拉进来，CPU 机器如果先装 ultralytics 再补 torch，容易装成 CUDA 版本占掉好几个 G，运行还更慢。先装好 CPU 版 torch 再装 ultralytics，依赖检查发现 torch 已满足，不会重复下载。装完用一段小代码确认 torch 能看到什么计算设备：
import torch print(torch.__version__) print(torch.cuda.is_available()) # CPU-only 机器返回 False 是正常的GPU 路线反过来：先确认显卡驱动装好，再按 CUDA 版本装 GPU 版 torch，ultralytics 会自动调用。用 nvidia-smi 看驱动版本，只要 CUDA Toolkit 版本不高于驱动支持的版本都能用。1660ti 这类 6G 显存的卡，训练时 batch 建议不超过 16；imgsz 开到 1280 时 batch 要减到 8，这是后面训练参数制度的由来。
3.2 第一次推理：加载模型、跑航拍图、保存结果
环境通了的标志性动作，是把模型对一张真实航拍图跑通。毕设包一般会在 datasets 里带测试 JPG，这里以预测脚本为例：
from ultralytics import YOLO model = YOLO("models/best.pt") results = model.predict( source="datasets/test/aerial.jpg", imgsz=1280, conf=0.25, iou=0.5, device="0", # 没有 GPU 改成 device="cpu" save=True, ) r = results[0] print(r.names) # 当前权重支持的类别名逻辑说明：imgsz=1280 对航拍小目标才是合理输入尺寸，默认 640 会漏掉密集的小车；conf=0.25 是置信度门限，航拍场景误检多，想要干净的结果可以提到 0.4，代价是可能漏掉真实小目标；iou=0.5 是 NMS 阈值，密集排列的车辆出现大量重叠框时，适当降到 0.4 能让输出更干净。device="0" 表示用第 0 块显卡，没有显卡改成 cpu。
参数说明：ultralytics 的 predict 接口返回一个 Results 列表，每个元素对应一张输入图。save=True 会把画好框的结果写到 runs/detect/predict 目录，比在屏幕上 show() 更适合先做通验证，因为很多操作系统环境没有桌面弹窗，远程命令行里根本看不到窗口。第一次跑通后，打开保存的预测图，确认框的位置和类别符合预期，再进入下一步。
3.3 模型再确认：这个 .pt 到底是哪个 YOLOv8 型号
跑通推理后，我还会执行一个检查，确认手上的权重是哪个规格。毕设包里的模型有三种情况最多：官方预训练的 yolov8n.pt、项目自己训练过的 best.pt、以及改动过结构后的定制权重。三种情况在代码里看起来一样，但性能差别很大。
from ultralytics import YOLO model = YOLO("models/best.pt") print(model.model.yaml) # 打印网络结构定义 print(model.task) # detect / segment / classify如果你拿到的模型打印出来的 yaml 带了 P2 层，说明这是改过结构的定制模型，训练它所用的数据配置要一并拿到才有意义。最怕的情况是包作者把官方预训练模型改个名当自己的结果交差，检查方式也简单：在验证集上跑一遍，car 类别的框全部正常而其他类别全乱，基本可以断定是预训练原样冒充。航拍场景通常目标类别就三五类，类别越少越要警惕这种"结果完美但类别对不上"的情况。
跑通推理意味着链路通了第一步，下一步就是把自己的数据集换成项目要求的格式，重新训练一个能用于答辩的权重。
4. 训练自己的航拍数据集：标注整理、data.yaml 与参数调优
4.1 把 labelme 标注转成 YOLO 格式：转换脚本与两个边界坑
毕设包里自带的训练数据，标注格式十有八九不是 YOLO 原生 txt，而是 labelme 的 json 或者 VOC 的 xml。labelme 是热词榜上的常客，因为它在 Windows 上有图形界面、对新手友好，标注结果是一个 json 文件，里面存着多边形坐标。YOLO 训练要的是每张图对应一个同名 txt，每行格式是 class_id x_center y_center width height，全部归一化到 0~1。
我一般会写一个批量转换脚本，顺手把两个边界坑处理掉：
import json from pathlib import Path def labelme2yolo(json_path, out_dir, class_map): with open(json_path, "r", encoding="utf-8") as f: data = json.load(f) img_w, img_h = data["imageWidth"], data["imageHeight"] lines = [] for shape in data["shapes"]: class_name = shape["label"] if class_name not in class_map: continue # 忽略没有纳入类别的标注 cls_id = class_map[class_name] if shape["shape_type"] == "rectangle": (x1, y1), (x2, y2) = shape["points"] else: # polygon 取外接矩形 xs = [p[0] for p in shape["points"]] ys = [p[1] for p in shape["points"]] x1, x2, y1, y2 = min(xs), max(xs), min(ys), max(ys) cx = ((x1 + x2) / 2) / img_w cy = ((y1 + y2) / 2) / img_h bw = (x2 - x1) / img_w bh = (y2 - y1) / img_h lines.append(f"{cls_id} {cx:.6f} {cy:.6f} {bw:.6f} {bh:.6f}") out_path = Path(out_dir) / (Path(json_path).stem + ".txt") out_path.write_text("\n".join(lines), encoding="utf-8") class_map = {"car": 0, "truck": 1, "person": 2} for jf in Path("datasets/labelme").glob("*.json"): labelme2yolo(jf, "datasets/labels/train", class_map)逻辑说明：脚本里最关键的是分别处理 rectangle 和 polygon 两种 shape_type。labelme 画矩形框时 points 是两个对角点，直接算中心点和宽高；画多边形时要把所有顶点合成外接矩形。很多人的转换脚本只处理多边形，遇到矩形框就崩，这是第一个坑。
参数说明：class_map 决定了类别编号，必须和后面 data.yaml 的 names 顺序保持一致，错了就是整体错位。第二个坑是归一化坐标必须除以原图宽高，不能除以压缩后的尺寸；如果 json 里的 imageWidth/imageHeight 和实际图片像素对不上，所有标注都会系统性偏移。转换完随机抽三张图，把 txt 读回来的坐标画到原图上比对，确认框贴合目标再开始训练，这一步不能省。
4.2 data.yaml 与训练命令：核心训练参数逐个说
数据准备好之后，用 YOLOv8 训练自己的航拍数据集只需要一个 yaml 文件和数据路径。注意中文类别名在部分环境里会引发编码问题，稳妥起见用英文，界面展示时再做中英映射。
path: datasets/aerial # 数据集根目录 train: images/train # 训练图片相对 path 的路径 val: images/val # 验证图片路径 names: 0: car 1: truck 2: person说明这三项的作用：path 是根，train 和 val 是相对路径，ultralytics 会自动拼接完整路径；names 的索引必须和标注 txt 第一列完全一致，索引错一位整个训练就废了。第一次跑可以先取 100 张图做 smoke test，确认 loss 在下降，再把全部数据放进去。
训练命令：
yolo detect train \ data=data.yaml \ model=yolov8n.pt \ epochs=100 \ imgsz=1280 \ batch=8 \ patience=20 \ lr0=0.0005 \ device=0逐个参数讲。model=yolov8n.pt 表示在官方预训练权重基础上继续训练。航拍数据集通常几百到几千张，从零初始化效果远不如迁移学习，预训练权重里学到的边缘和纹理特征对小目标帮助很大。epochs=100 对毕设是合理范围，轮次再多小数据集容易过拟合。imgsz=1280 对应第二章的分析，是航拍小目标能检出的关键，显存吃紧就退回 960 甚至 640。batch=8 和显存挂钩，6G 显存同时开 imgsz=1280 时，8 是最稳的，16 会爆显存。patience=20 是早停轮数，验证集指标连续 20 轮不涨就停。lr0=0.0005 是我在航拍小数据集上的保守值，比官方默认 0.01 低很多，因为数据少时大学习率容易把预训练特征冲掉。
训练输出在 runs/detect/train 目录，里面会出现每轮的权重 best.pt 和 last.pt。毕设答辩和后续界面调用都用 best.pt，last.pt 只是断点恢复用。
4.3 看训练曲线判断有没有训歪：损失函数曲线与 mAP
训练完成不等于训练成功。跑完先看 best.pt 在验证集上的指标，再看曲线图。ultralytics 在训练目录下会自动生成损失曲线和混淆矩阵，热词里"yolov8画损失函数曲线图"搜得多，说明不少人被这一步卡住。
其实不需要额外写画图脚本，训练过程产生的 results.csv 里已经按轮记录了 box_loss、cls_loss、dfl_loss 和 mAP50、mAP50-95。用 pandas 读出来画更灵活：
import pandas as pd import matplotlib.pyplot as plt df = pd.read_csv("runs/detect/train/results.csv") plt.plot(df["epoch"], df["train/box_loss"], label="train box loss") plt.plot(df["epoch"], df["val/box_loss"], label="val box loss") plt.legend() plt.xlabel("epoch") plt.ylabel("loss") plt.show()判断标准就一句话：train loss 和 val loss 都在下降，且最后趋于平缓才算训成。train loss 一直降、val loss 先降后升，是过拟合信号，往回减 epochs 或加大数据增强。val loss 从头到尾不掉，多半是数据集路径配错、或者标注类别和模型结构对不上，优先回头检查 4.1 生成的 txt 内容。
mAP 这块需要懂一点：mAP50 看框定位的粗准确率，mAP50-95 更苛刻。航拍密集小目标场景本来 mAP50-95 就不会高，毕设答辩也不要求它好看，重点看 mAP50 能不能到 0.7 以上，小数据集能到 0.8 已经很不错。
5. 航拍检测翻车现场：小目标漏检、界面卡死等 5 个常见坑
5.1 小目标漏检严重：车明明在图上，就是不出框
现象：用训练好的权重跑航拍测试图，大块建筑和树木都有框，停车场里密密麻麻的小车完全没反应；把图片放大三倍后，又能检出一部分。
原因：两个因素叠加。一是推理输入尺寸还在 640，小目标下采样后特征图可用的像素太少；二是训练时目标尺度分布不均，大目标样本偏多，模型学出来的感受野偏大。航拍数据里目标尺度差异可以达到几十倍，单尺度模型天然吃亏。
解决：训练和推理都统一到 imgsz=1280，先把输入这头修好。如果仍不满意，换带 P2 检测头的结构，ultralytics 提供了 p2 系列 yaml 结构配置，训练时 model 指向该 yaml，也可以直接用整理好的 p2 权重路径。P2 层对应 4 倍下采样特征图，小目标分辨率高，代价是计算量上涨和训练略不稳定，属于航拍检测最实用的结构改动。
5.2 训练时 loss 出现 nan，或者前几轮 loss 高得离谱
现象：训练命令敲下去，前 20 轮 loss 正常，第 30 轮突然变 nan，之后一直 nan；或者第一轮 loss 就到 30 以上，怎么都降不下来。
原因：nan 一般是学习率过大，或 AMP 混合精度在部分显卡上的兼容问题；loss 异常高大概率是标注文件出错。最常见的是归一化坐标里出现了大于 1 的数值，比如 4.1 转换脚本里除的尺寸用错；还有一类是标签类别 ID 超出 names 长度，训练读到非法值直接毁梯度。
解决：nan 问题先加一个参数排查，把学习率降下来并关掉 AMP，命令写成这样：
yolo detect train data=data.yaml model=yolov8n.pt epochs=50 imgsz=1280 batch=8 lr0=0.0001 amp=False这个命令把 lr0 降到 0.0001 且关闭 amp，是排查 nan 的标准动作。如果恢复正常，再逐项放回去，找到元凶。loss 高的问题先做数据检查：随机挑 50 个 txt，写个脚本统计坐标范围是否都在 0~1 内，类别 ID 是否小于 names 数量，宽高为 0 的框直接删掉。
5.3 CPU 机器跑推理慢到怀疑人生，一张图要好几秒
现象：CPU-only 笔记本上跑训练好的权重，单张 1280 航拍图推理 5 秒以上；界面里切换图片，风扇起飞画面一卡一卡。
原因：imgsz=1280 在 CPU 上的计算量本身大，加上界面如果对每帧都推理，等于把高负载操作塞进交互循环。航拍原图往往不止 1280，实际是五六千万像素的大图，界面上显示时还涉及缩放，CPU 扛不住是必然。
解决：推理和界面显示分开。界面上用小尺寸缩略图，检测用 1280 尺寸，直接对原始大图推理是性能灾难；模型规格用 nano 级别。另一个有效手段是转 ONNX 再配合 OpenVINO 做推理，Intel CPU 上通常能快一倍以上，毕设做部署演示时这个优化很出效果：
yolo export model=best.pt format=onnx imgsz=1280ONNX 文件生成后用 OpenVINO 的 runtime 加载，和原模型在验证集上对比 mAP，确认没有明显损失，再接到界面。导出和验证的细节建议同步写进部署教程，否则交付后换个机器跑不动还是白搭。
5.4 可视化界面点一下开始检测就卡死，窗口转圈或者白屏
现象：PyQt 界面正常启动，点"开始检测"按钮后整个窗口无响应，过很久才恢复；或者在检测过程中拖动窗口直接黑块。
原因：这是最典型的 UI 线程被推理任务阻塞。加载模型和检测都是耗时操作，直接写在按钮的点击槽函数里，Qt 的事件循环被占住，界面自然假死。
解决：把推理放到 QThread 子线程，通过信号把结果传回主线程更新界面。模型加载放到窗体构造函数里，不要等点击时才 load，减少按钮点击瞬间的阻塞时间。下面是一个最小可用的 PyQt5 线程骨架：
from PyQt5.QtCore import QThread, pyqtSignal class DetectThread(QThread): finished = pyqtSignal(object) # 传回检测结果 def __init__(self, model, img_path): super().__init__() self.model = model self.img_path = img_path def run(self): results = self.model.predict(source=self.img_path, imgsz=1280) self.finished.emit([r.boxes.xyxy.cpu().tolist() for r in results])界面上按钮只负责启动线程并等待 finished 信号更新标签，自己不再执行推理。这个改动能把卡死从根上解决，也是答辩演示时最影响观感的一环。如果还出现界面更新慢，把结果图片的缩放也放到子线程里，主线程只负责显示小尺寸结果图。
5.5 用自己数据训练后 mAP 反而比官方预训练还低
现象：标注数据 500 张，训练 100 轮，验证集 mAP50 只有 0.3；而直接拿官方预训练权重在测试图上跑，肉眼效果还更像样。
原因：数据规模太小配不上 100 轮训练，模型过拟合到训练集背景特征；或者标注里类别分布严重不均衡，car 占九成，boat 只有十几个样本，少样本类别几乎学不出来。还有一个隐蔽因素：新增类别和预训练类别完全不重叠时，新类别需要更多数据才能收敛。
解决：把 epochs 降到 50 到 60 轮并配合早停，迁移学习阶段用小学习率，也可以冻结前 10 层特征提取部分，做微调而不是全量重训。类别不平衡可以按类别比例做采样调整，或者给少数类复制样本到 100 张以上再训。数据量低于 300 张时，我会加大 mosaic、模糊等增强的比例，让模型学到目标形状而不是背景记忆。判断有没有过拟合，回看 4.3 的曲线：val loss 明显上翘，就是过拟合信号。
6. 把检测结果做成可视化界面：一个能交差的 PyQt 骨架
6.1 界面最小骨架与信号传递
训练出权重之后，项目包里的可视化界面就是门面。不管原包用的是什么框架，常见做法无非 PyQt5 或 Flask 网页两种；本地毕设演示用 PyQt5 最直接，因为它不依赖浏览器和网络。界面核心只有三件事：选图、出框、展示，外加一个可选的保存结果按钮。
骨架代码里最需要注意的是耗时任务必须走线程，5.4 已经讲了这个坑，这里直接给完整的最小骨架：
import sys from PyQt5.QtWidgets import QApplication, QLabel, QPushButton, QVBoxLayout, QWidget from PyQt5.QtGui import QPixmap from ultralytics import YOLO from DetectThread import DetectThread # 复用 5.4 的线程类 class MainWindow(QWidget): def __init__(self): super().__init__() self.model = YOLO("models/best.pt") # 提前加载，不要在点击时才 load self.label = QLabel("选择航拍图开始检测") self.btn = QPushButton("选择图片") self.btn.clicked.connect(self.on_click) layout = QVBoxLayout(self) layout.addWidget(self.label) layout.addWidget(self.btn) self.thread = None def on_click(self): path, _ = QFileDialog.getOpenFileName(self, "选择航拍图") if not path: return self.thread = DetectThread(self.model, path) self.thread.finished.connect(self.show_result) self.thread.start() def show_result(self, boxes): self.label.setText(f"检测到 {len(boxes)} 个目标")模型在构造函数里就加载好，检测放到子线程，主线程只负责更新文字。界面上再补一个保存预测图的按钮，配合 runs 目录下的原图结果，答辩演示就够完整了。
6.2 从界面到交付：验证、加分方向与部署注意
界面跑通之后，不要直接拿去答辩，先做一轮验证：拿 50 张没参与训练的图像，统计 mAP50 和平均推理耗时，把结果截图放进论文的测试章节，这是最有说服力的部分。加分方向有两个：一是把检测框按坐标网格做密度统计，输出热力图，航拍分析系统一旦能回答"哪里车最多"，功能完整性立刻上一个台阶；二是把权重导出成 ONNX，在 RK3588 这类开发板上跑板端推理，部署教程里加上模型转换和板子适配的说明，就覆盖了从实验到落地的完整链路。
我自己的习惯是每切换一个数据集环境，就把 data.yaml、训练命令和验证结果存在同一个目录里，编号管理，避免答辩前找不到当时训练用的配置。模型效果不行时，优先怀疑数据而不是模型结构，毕竟航拍标注的边界坑比网络结构多得多。希望这篇笔记能帮你把这个项目从"能跑"推到"能讲"，少走我当年走过的弯路。
本文还有配套的精品资源，点击获取
