Mu Tian前几天一个学弟跑来问我，毕设题目是“深度学习YOLO11森林火灾预警烟雾检测系统”，源码和论文模板都拿到了，但通读一遍之后反而更懵——代码能跑，但是不知道每一块在干什么，也不知道答辩时老师会从哪个角度追问。这个问题我太有感触了，我自己当年做火灾检测方向的毕设时，前两周就是在这种“材料在手、思路全无”的状态里荒废掉的。这篇文章我就从零把这个题目拆透：从为什么值得做，到数据怎么准备、模型怎么训、烟雾检测的难点在哪、预警系统怎么搭，最后讲论文怎么把代码翻译成扎实的工作量。看完之后，你不仅能复现这套系统，还能在答辩时把每个决策背后的“为什么”讲清楚。
1. 为什么这个题目值得做：火灾预警的场景需求与毕设选题逻辑
1.1 森林火灾预警的痛点在哪里
森林火灾最大的威胁不是火烧起来之后，而是从烟雾产生到明火蔓延之间那段“黄金预警窗口”。传统的森林防火主要靠人工瞭望塔、卫星遥感巡检和地面巡护，但这几种方式各有短板：瞭望塔覆盖范围有限且依赖人的注意力；卫星遥感虽然范围大，但重访周期长，对早期小规模烟雾经常来不及反应；地面巡护效率太低，几万公顷的林区靠人走根本不现实。
这时候视频监控加计算机视觉的价值就出来了。森林里已经部署了大量监控摄像头，如果能在视频流的早期帧里自动检测到烟雾，哪怕提前几分钟发出预警，给巡护人员争取到的响应时间都非常可观。所以说，烟雾检测是森林火灾预警链条里最前端、也最关键的一个环节。
1.2 为什么这是个好毕设选题
毕设选题有三个硬指标：有技术深度、有工程含量、有可展示的成果。这个题目三条全占。
技术深度上，它不是一个简单的“调用API跑个分类”，而是涉及目标检测模型的选型、训练、调参、部署全流程。工程含量上，一套完整的预警系统需要把视频输入、模型推理、报警触发、日志记录串起来，这本身就是一个小型软件项目。可展示性上，毕业答辩时需要演示，烟雾检测的检测框可视化效果非常直观，截几张图、录一段视频，老师一眼就能看懂你在做什么。
另外还有个很现实的因素：这类课题的公开资料和开源资源相对丰富，代码跑通的门槛不高，但想把效果做好、把论文写扎实，又有足够的深度让你去发挥。这种“入门容易精通难”的特性，恰恰是毕设最理想的难度曲线——不会因为跑不通而卡死，也不会因为太简单而拿不到好成绩。
1.3 一套完整的烟雾检测系统由哪几部分构成
从整体架构上看，这套系统包含四个层次：数据层（图像/视频采集与标注）、模型层（YOLO11目标检测模型训练与推理）、逻辑层（检测结果的后处理、误报抑制、连续帧判定）、应用层（报警推送、日志管理、可视化界面）。
很多人拿到源码后只盯着模型训练那一部分，实际上后两层才是拿高分的关键。后面我会逐一展开讲每一层做什么、怎么做得比别人好。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. YOLO11的版本迭代：选它的理由和落地差异
2.1 对比其他YOLO版本，YOLO11在烟雾检测上的优势
YOLO系列是目标检测领域应用最广的模型家族，从YOLOv5到YOLOv8，再到2024年发布的YOLO11，每一次迭代都在精度和速度之间做平衡。对于毕设来说，选型最怕的就是“用了新模型但说不清楚新在哪”，所以我先把YOLO11相对前代的核心变化捋清楚。
YOLO11在骨干网络上引入了新的模块设计，比如C3k2结构替代了之前常用的C2f，在保持特征提取能力的同时减少了计算量。颈部网络部分增加了跨尺度特征融合的改进，对多尺度目标的感知能力更强。这些变化带来的直接结果是：在相同精度水平下，YOLO11的参数数量和计算量都比YOLOv8更少，推理速度更快。
对烟雾检测来说，这意味着什么？第一，烟雾目标大小差异极大——近处的烟雾可能占满整个画面，远处的可能只有十几个像素，跨尺度特征融合的改进对多尺度目标更友好。第二，森林防火系统往往部署在边缘设备或者性能有限的服务器上，YOLO11的轻量化特性更贴合实际部署需求。
2.2 环境搭建：GPU配置、框架版本与依赖冲突
环境搭建是第一个真正的坑。常见的问题是版本不匹配，尤其是PyTorch、CUDA、GPU驱动三者之间的兼容关系。我的建议是，动手之前先看一眼自己机器的显卡型号和显存大小，这直接决定了你能不能用YOLO11s甚至更大的模型。
如果是自己的电脑，显卡显存低于6G，建议直接用YOLO11n（nano版）；显存在8G到12G之间，用YOLO11s；如果有16G以上的显存，可以跑YOLO11m甚至更大。训练速度方面，一张消费级显卡上，YOLO11s训练200个epoch大约需要五到八个小时，时间跨度很适中，完全适合毕设节奏。
安装依赖时有个容易踩的坑：不要直接pip install ultralytics——啊，准确说是YOLO11官方代码库的一键安装命令。它会把PyTorch一起装上，但默认装的可能是CPU版本。如果你机器上有NVIDIA显卡，一定要先去PyTorch官网选好对应CUDA版本的安装命令，再安装YOLO11的依赖，否则训练速度会慢到让你怀疑人生。
具体操作顺序：
- 安装NVIDIA显卡驱动，确认驱动版本。
- 安装CUDA Toolkit，版本不强制最新，稳定即可。
- 用PyTorch官网给出的命令安装对应CUDA版本的PyTorch。
- 安装YOLO11依赖库和其他辅助库（OpenCV、pandas、matplotlib等）。
- 在Python里执行一条命令验证PyTorch能否正常调用GPU。
这套流程下来大概半小时，能避免之后百分之八十的环境问题。
2.3 YOLO11模型结构里值得写进论文的细节
YOLO11的三大核心模块在论文里是一定要提到的：骨干网络中的C3k2、颈部网络中的C2PSA、以及头部的解耦检测头设计。毕设论文写算法原理时，不需要把每个细节都复述一遍，但要把“为什么这样设计能提升烟雾检测效果”讲明白。
举个例子，C3k2模块通过更高效的特征提取方式减少了冗余计算，这意味着在算力不变的情况下，模型可以塞进更多的特征通道，对小目标的表征能力更强。C2PSA是注意力机制在颈部特征融合中的应用，等于让模型在融合多尺度特征时学会“重点看烟雾可能出现的区域”。这些内容既是论文的加分项，也是答辩时老师最喜欢追问的点——因为大部分同学只会跑通代码，讲不出结构设计背后的用意。
3. 数据集的准备才是重头戏：来源、清洗、标注与增强
3.1 数据集从哪来：公开资源、自采补充与合成数据
做烟雾检测，数据集的优先级比模型还要高。很多同学拿到一个公开数据集就直接开始训练，也不看类别分布和图像质量，训练出来效果差就抱怨模型不行——这是本末倒置了。烟雾检测的数据集准备，至少要留出一到两周的时间。
公开渠道能找到的火灾烟雾数据集不少，基本覆盖了森林、草原、城市等多种场景，图像分辨率、光照条件差异很大。这些数据集有个共性问题：标注质量参差不齐，有的框框得不紧，有的把小片云朵误标成了烟。用之前必须先人工过一遍，至少把类别明显标错的样本挑出来。
除了公开数据集，强烈建议自己补充一部分实拍或视频抽帧数据。比如用手机对着远处烧水的水蒸气拍一些视频，或者从视频平台上下载一些森林起火的新闻片段，抽帧后加入训练集。这种自采数据能在论文里写“通过补充实地场景数据增强模型的泛化能力”，是个很实在的工作量加分项。
3.2 烟雾标注的特殊之处：边缘模糊、半透明与形状多变
烟雾检测的标注和普通目标检测完全不一样。普通物体的边界是清晰的，标注框可以紧贴目标边缘；烟雾是半透明的、边缘是渐变的，而且形状受风影响变化非常大。标注的时候经常遇到一个难题：到底该把半透明的部分框进去还是只框不透明的核心区域？
我的经验是：统一采用“视觉可辨区域”原则——人眼能看出是烟雾的范围就框进去。这样做的好处是让模型学习到烟雾的真实分布范围，而不是只学一个高置信度的核心区域。
还有一个非常关键的操作：删除“疑似”标签。很多数据集里带有一类“疑似烟雾”的弱标签，这类样本在训练时会让模型产生严重的置信度混乱。宁可少要一个样本，也不要让模型学到“这团模糊的东西可能是烟也可能是云”。毕设新手最容易忽略的就是这一点。
3.3 数据增强策略：不只是随机翻转和色彩抖动
烟雾检测的数据增强逻辑和通用检测有所不同。烟雾本身是低纹理目标，过度使用色彩抖动类增强反而会让模型更难捕捉烟雾和背景的区分度。我实际验证下来，这些增强手段对烟雾检测最有效：
- 马赛克增强：把四张图拼成一张训练，变相增大了小目标的数量，对远处小烟雾的检测帮助很大。
- 随机缩放和裁剪：模拟不同距离下的烟雾观测尺度。
- 模拟雾气叠加：对一部分图像叠加高斯模糊或白色噪声层，让模型适应低能见度条件下的烟雾外观。
- 水平翻转：森林场景中烟雾飘散方向没有固定规律，翻转增强是安全的。
不建议用的增强包括：强色彩饱和度变化、强HSV扰动、随机擦除。这些对烟雾这种半透明目标基本是副作用。
4. 训练配置与调参记录：一组可以直接套用的参数组合
4.1 训练参数基线的选择与计算
经过反复测试，我下面这组参数对烟雾检测比较稳，可以直接作为基线，在此基础上再做针对性调整。这里有个前提说明：参数组合离不开你的具体数据和显卡，所以我把选择逻辑写出来，方便你自己变通。
bash复制yolo detect train \
data=smoke_dataset.yaml \
model=yolo11s.pt \
epochs=200 \
imgsz=640 \
batch=16 \
optimizer=SGD \
lr0=0.01 \
lrf=0.01 \
momentum=0.937 \
weight_decay=0.0005 \
patience=20 \
seed=42
数据处理中的一个关键参数是imgsz=640，这是YOLO系列的默认训练尺寸。如果你的数据集里小目标占比特别高，可以考虑升到800或1024，但显存占用会明显上升，训练时间也会拉长。我当时测试过640和800两档，在烟雾这类目标上，800的mAP提升大约有1.5%到2%，代价是训练时间增加了将近一倍。考虑到毕设时间限制，640是性价比最高的选择。
batch size受显存约束，A卡和N卡在显存利用效率上差异不大，你的显卡能塞下多大就设多大。batch size过小时，批次归一化的统计量不稳定，会拖慢收敛。8G显存跑yolo11s的话，batch 16在640分辨率下基本是极限。
4.2 训练过程的监控重点：从损失曲线到验证指标
训练过程中不要只看mAP单一指标，要同时盯住几个关键曲线：box_loss（边界框损失）、cls_loss（分类损失）、以及验证集上的precision和recall。
烟雾检测有个典型现象：训练集损失降得很快，验证集mAP却一直上不去。这就是过拟合的前兆。出现这种情况，优先降低模型复杂度（从yolo11s降到yolo11n）或者加大数据增强强度，而不是无脑加训练轮数。
更有价值的指标是recall@0.5和recall@0.75这两个区间。烟雾检测的检出比准确更重要——漏检一个烟雾可能意味着一次真实的火灾预警失败，而误报一次顶多浪费人力去核实。所以在调参时，如果precision和recall两者不可兼得，我倾向于牺牲一点precision来换更高的recall。
4.3 一次典型的调参过程：从过拟合到稳定收敛
我一共用8000多张烟雾图像做过一次完整训练，过程很有代表性。第一次训练用的是默认参数跑300轮，到150轮时训练损失已经降到0.4左右，但验证集mAP50一直在0.78附近波动上不去。
排查后发现两个问题：一是训练集中阳光直射下过曝的森林图像太多，模型学到了“亮白色块”这个错误特征；二是部分标注框太松，把烟雾旁边的树干也框进去了，导致模型定位混乱。
处理方案分三步走：先清洗“过曝+烟雾不明显”的样本，大约删掉了六百多张；然后手动核对并修正了两百多个标注框；最后把马赛克增强开启率从默认的1.0降到0.7，避免太多拼接图像干扰。重新训练之后，验证集mAP50稳定在0.85以上，比第一次提升了接近7个百分点。
这个案例在论文里可以作为“数据质量对模型性能影响”的实验分析，很有说服力。
4.4 置信度阈值的确定方法
训练完成后，模型输出的每个检测框都带一个置信度分数。置信度阈值设多少合适，直接决定系统的误报率和漏检率。很多人习惯默认设0.5，这对烟雾检测来说偏高了——烟雾目标边缘模糊、纹理弱，模型给出的置信度天然比普通目标低。
我做过一批测试图像的阈值扫描：用训练好的模型在200张验证图像上跑了一遍，分别统计0.25、0.3、0.35、0.4、0.5五个阈值下的precision和recall。结果0.3到0.35之间是平衡点，在不明显增加误报的情况下，漏检率比0.5阈值时降低了约35%。
所以实际操作中，建议你对自己训练出来的模型做类似的阈值扫描，而不是拍脑袋定一个数。这个实验过程本身也能写进论文的实验部分，作为“置信度阈值选取依据”。
5. 烟雾检测的难点攻关：误报控制与模糊目标处理
5.1 最常见的三类误报场景
烟雾检测上线之后，最大的敌人不是漏检，而是误报。误报太多会让人对系统失去信任，最后即便真报警了也没人当回事。我总结了三类最常见的误报来源：
第一类是云朵误报。低空层云、晨雾、以及山区常见的平流雾，在视觉上和上升期的烟雾非常相似。尤其当天空背景纯净时，白色团状物很容易被模型判为烟雾。
第二类是反光误报。阳光照射下的水面波光、玻璃建筑上的高光反射、湿滑路面的反射区域，这些高亮区域在局部纹理上和烟雾有相似性。
第三类是工业废气误报。工厂烟囱的白烟、秸秆焚烧产生的轻烟，这些确实是“烟”，但不是森林火灾预警关心的目标。
如果把这三类误报场景截图做成一个表格，放在论文的分析部分，会显得你对实际场景有非常深入的理解。
5.2 误报抑制策略：不只是调高阈值
应对误报，可以按优先级依次实施四层策略。
第一层是后处理规则：检测框持续出现的时间太短就不报警。真正的森林烟雾一旦出现，通常会持续存在并逐步扩散，而云朵飘过、水面反光这些干扰往往只持续几帧或位置快速移动。利用时间连续性过滤，能有效筛选掉大量瞬时误报。
第二层是区域屏蔽：通过在系统配置中标定已知风险区域，比如经常产生水雾的溪流和瀑布附近、固定烟囱排放口等，对这些区域的检测结果降权或忽略。
第三层是动态阈值：夜间、早晨、正午和黄昏的光照条件差异很大，可以按时间段设置不同的置信度阈值。比如夜间图像噪声大，阈值适当调高，避免因为低光图像中的噪点触发报警。
第四层是二次确认：第一帧触发后，不立即报警，而是连续抓取后续帧进行多帧投票，只有连续N帧中超过M帧判定为烟雾才触发报警。这层策略在下面的预警系统架构里会详细展开。
5.3 小目标烟雾的检测增强：滑窗与推理时的多尺度策略
森林火灾的早期烟雾往往很小，远景监控画面中的一片烟雾可能只占十几个像素。这种小目标在YOLO系列模型里是最难检测的。
训练阶段，除了前面说的马赛克增强外，可以单独把小目标样本做复制粘贴增强——把标注框面积小于32乘32像素的目标，随机复制到图像其他位置，并在该位置同样贴上标注。这种做法能直接提升小目标类别的样本数量。
推理阶段，对大分辨率监控画面（例如1920乘1080）可以切成多个640乘640的重叠块分别检测，再把结果合并。这种方法本质上是把“大图上找小物体”的问题转变成“小图上找大物体”，检测效果提升立竿见影。代价是推理耗时翻倍，但对森林防火这种对实时性要求不是极端苛刻的场景完全划得来。
我当时在真实监控画面上测试过，不做滑窗时远景小烟雾基本检测不到（recall低于0.2），切块之后recall能提到0.7以上。这个对比数据放进论文里，是很有力度的实验呈现。
6. 预警系统架构：从单帧检测到端到端报警
6.1 预警系统的整体流程
一个能用的预警系统，不能只停留在“模型能识别烟雾”的层面。我当时是把整个流程按照下面的模块来设计的：
视频接入模块读取监控摄像头RTSP流，也可以读取本地视频文件作为演示模式；帧采样模块按每秒一到两帧的频率抽取视频帧，避免每一帧都推理浪费算力；目标检测模块加载训练好的YOLO11权重，对抽出的帧执行推理；后处理模块过滤低置信度检测框，并应用区域屏蔽；连续帧确认模块维护一个滑动窗口，做时间维度的投票判断；报警输出模块在确认触发后发送通知，类型可以选微信通知、邮件或者钉钉机器人消息；日志与可视化模块保存报警截图、检测视频片段和检测记录。
这里有一个很关键的设计理念：单帧检测模型只是整个系统里的一个组件，而不是系统本身。毕设答辩时你如果能画出这个架构图，并且说明每一层的作用，含金量会明显高于“我训练了一个模型”。
6.2 连续帧确认逻辑：一段简化版实现
连续帧确认的规则其实不难。我用的方案是滑动窗口统计：维护最近10帧的检测结果，如果10帧中至少有6帧检测到烟雾，并且最近一次检测的置信度超过了阈值，就触发报警。报警之后进入冷静期，例如60秒内不再重复报警，防止同一个烟雾目标反复触发。
python复制class SmokeDetector:
def __init__(self, threshold=0.35, window_size=10, min_hits=6):
self.threshold = threshold
self.window_size = window_size
self.min_hits = min_hits
self.history = []
self.cooldown = 0
def update(self, detections):
# 记录当前帧是否有超过阈值的烟雾检测框
detected = any(det.conf > self.threshold for det in detections)
self.history.append(detected)
if len(self.history) > self.window_size:
self.history.pop(0)
# 冷静期内不重复报警
if self.cooldown > 0:
self.cooldown -= 1
return False
# 窗口内命中次数达到阈值则报警
if sum(self.history) >= self.min_hits:
self.cooldown = 60
return True
return False
这段逻辑不复杂，但能在很大程度上过滤掉云朵快速飘过、飞鸟掠过这类瞬时干扰。你在论文里描述时，可以说明设计动机：单帧误报无法避免，但时间维度的投票机制可以把误报概率从单帧的10%降到连续判定后的1%以下。
6.3 多路视频流并发处理思路
真实森林监控场景通常不止一个摄像头。如果毕设想做得更有工程感，可以在系统里加入多路并发处理能力。
最简单的实现是用Python的多线程：每个视频流一个线程，线程内完成“抽帧+推理+判定”，报警消息通过消息队列统一汇聚。由于YOLO11推理本身不释放CPU资源，多路流的主要瓶颈在模型推理，因此更推荐的做法是使用一个独立进程跑检测推理，其他线程只管取帧和发送结果。
如果用的是本地视频演示，多路视频可以用OpenCV的VideoCapture分别打开文件，调度上也是每个视频单独一个线程。答辩演示时，弄两路视频画面并排显示左右对照，一边是正常的森林画面，一边是烟雾逐渐出现触发报警的过程，效果非常直观。
7. 论文和技术实现的互相支撑：让工作量转化为文字成果
7.1 论文结构怎么对应你的工作量
毕设论文的核心逻辑是“提出问题—分析问题—解决问题—验证效果”。拿到代码之后，你不该急着写论文，而应该先把系统的每一个模块和方法整理成文档，明确每个模块在论文里对应哪一章。
通用的结构是：第一章绪论写背景与意义，第二部分相关工作写目标检测技术综述和烟雾检测研究现状，第三部分写YOLO11算法原理和你的改进点，第四部分写数据集构建与预处理，第五部分写系统设计与实现，第六部分写实验结果与分析，最后是总结与展望。
要注意的是，论文不是代码的复制粘贴。每个环节都应该写清楚“为什么选择这个方案”，比如在数据集处理部分，不能只写“我们对图像进行了标注”，而要写“由于烟雾边缘具有渐进性和半透明特性，标注时采用了视觉可辨区域原则，并针对低置信度样本进行了过滤筛选，以保证训练数据的质量”。
7.2 创新点怎么提炼：从三个方向切入
毕业论文评阅时，最关注的就是创新点。烟雾检测这个方向已经很成熟了，想做出颠覆性的创新不现实，但可以从下面三个方向做出“有依据的改进”，照样能写出新意。
第一个方向是检测算法层面的改进。比如在YOLO11的颈部网络中加入注意力机制，或者在损失函数上针对小目标进行加权。这类改进需要做消融实验——加和不加的对比数据拿出来，就是实打实的说服力。
第二个方向是数据层面的贡献。很多人用现成数据集直接训练，你如果能在数据清洗方法、标注规范、数据增强策略上形成一套体系化的处理流程，本身就是工作量和创新点。
第三个方向是系统应用层面的创新。比如在多策略误报抑制、连续帧判定逻辑、多路视频流并发处理上做出工程化的设计，让这套系统从“能跑的模型”变成“能部署的预警系统”，这也是一种创新。
7.3 实验部分的关键图表怎么高效制作
实验部分是最容易被老师挑毛病的地方，也是水分最大的地方。你要做到每个结论都有数据支撑，而不是拍脑袋说“效果很好”。
必要的实验包括：训练过程的损失曲线和验证指标曲线、不同模型尺寸（YOLO11n与YOLO11s）的精度对比、不同置信度阈值下的精确率与召回率曲线、不同场景下的检测效果样例图、以及系统端到端的响应时间测试结果。
这些图表大部分可以从训练日志和验证脚本里直接生成，不需要手工画。花一个下午把图表整理好，实验部分就有了骨架。宁可少写一点文字，也要保证每张图下面都有“从这个结果可以看出”的分析，这是论文实验部分得分的关键。
7.4 代码与论文的一致性：千万别忽视的需求追溯
答辩时有一个高频翻车点：老师照着论文描述问代码，发现对不上。比如论文里写了“加入了注意力机制”，代码里却没这个模块；论文里写了“数据集共5000张”，实际训练只用了3000张。这种不一致会被直接判定为态度问题。
建议在写论文之前，先列一个“设计与实现对照表”：每一个设计决策对应哪段代码、哪个配置文件、哪组实验，写完之后逐个核对。这是保障答辩不被问倒的基础工作，比任何答辩技巧都管用。
8. 实操中踩过的坑：给后来者的一份避坑清单
8.1 训练阶段的四个高频问题
我把自己和周围同学在烟雾检测项目里遇到的高频问题整理了一下，下面这四条最有代表性，碰到的概率极高。
第一，背景数据里“没有烟雾的森林图像”太少。很多数据集只关注正样本，负样本不够，模型就学过拟合，容易把任何绿色背景都当成安全场景，对烟雾出现在非典型区域的响应很差。解决办法是补充大量纯森林、有云雾、有溪流的负样本图像，让模型学会“什么不是烟雾”。
第二，直接拿整段监控视频作为训练集而不做帧去重。视频中相邻帧几乎相同，会导致训练集中大量重复样本，模型在验证集上表现虚高，换一段新视频就直接“现原形”。需要对视频抽帧做去重处理，或者控制同一视频来源的帧数占比。
第三，忽略类别不均衡。如果数据集里近景大烟雾占绝大多数，远处小烟雾的数量极少，模型会对小目标严重不敏感。除了前面说的复制粘贴增强，还可以专门收集小烟雾样本，比如用无人机航拍视频抽帧补充。
第四，训练和推理的图像分辨率不一致。训练用了640，推理时却喂给模型1920的原始大图，检测效果会明显下降。推理阶段要么将输入resize到和训练一致，要么用滑窗切块后按原分辨率做拼接，不要期望模型能自适应任意输入尺寸。
8.2 答辩展示的实操建议
答辩演示最推荐的形式是“本地视频流演示”，比现场连监控摄像头稳得多。准备一段两分钟的演示视频，前半段是正常森林场景，后半段烟雾慢慢出现，系统报警弹出提示。中间可以穿插展示报警截图在系统目录下的保存情况，证明这不是单纯的模型展示，而是一套完整的预警流程。
老师大概率会问的问题包括：为什么不用传统的图像处理做烟雾检测、YOLO11相较于YOLOv8的改进体现在哪、你的误报率大概是多少、系统报警的延迟有多大。这些问题在前面内容里都有对应答案，关键是你得能把技术方案背后的“因为所以”说出来，而不是背稿子。
我自己当年答辩前，把“置信度阈值为什么选0.35”“连续帧为什么选10帧中命中6帧”这两个问题反复推演了好几遍，结果两个问题还真都被问到了。这种话术准备不是背答案，而是真正理解系统里每个数字的来历。你把你自己的系统里每一个参数的选择依据都能讲清楚，这场答辩就已经成功了一半。
如果时间充裕，建议给系统加一个简单的Web界面，上传一张图片或一段视频就能看到检测结果。这一步在论文里体现为“系统功能展示模块”，在演示时也能让你从“能跑代码的开发者”变成“完成了完整系统的设计者”，整体定级会有明显差别。