企业官网建设流程全解析

1. 这套组合为什么值得做成毕设：YOLOv8 + PyQt的业务逻辑

1.1 监考场景对检测算法的要求

现在做计算机毕设，目标检测方向的热度一直很高，但很多同学容易陷入一个误区：上来就跑COCO预训练模型，detect个猫猫狗狗，然后说“我做的是目标检测系统”。答辩老师一眼就能看出来这是不是真东西。智能监考系统之所以是个好选题，在于它把目标检测落地到了一个有明确业务语义的真实场景里——考场里有人玩手机、有人低头疑似作弊、有人离席，这些行为在监控画面里是可以被识别和记录的。

监考场景对算法的要求其实非常具体。摄像头通常架在教室前方或侧面，视角固定但光线变化剧烈，白天窗边强光、傍晚室内偏暗，经常还有投影屏幕的反光。检测目标里，手机属于典型的小目标，在1080P画面里可能只有二三十个像素宽，普通模型很容易漏。人倒是好检测，但难点在于要区分“正常阅读”和“长时间低头”之间的差别，这已经不只是单纯的目标检测问题，还要叠加姿态分析或者时序逻辑。这类约束条件越细，越能体现你作为毕设作者对业务的理解，而不是只会调包。

1.2 选YOLOv8而不是更老的版本，差别在哪儿

现在你去看各大招聘网站的算法岗位要求，YOLO系列几乎成了默认技能。YOLOv8和v5、v7相比，最直观的区别是它在工程化上走得更彻底：统一的ultralytics库封装，训练、验证、导出ONNX或者TensorRT，几行命令就能做完。这对毕设来说非常关键，因为你的时间有限，没有精力去调一堆自定义的配置文件。

另一个选择它的理由是Acceleration。v8把C2f模块和Anchor-Free头结合在一起，同样的推理精度下，速度表现更稳。我之前在普通笔记本电脑上跑yolov8s，摄像头实时推理大概能到25到35 FPS，足够支撑监考这种“不需要极速、但需要稳定”的场景。如果你选yolov8n，帧率还能再往上走，但小目标检测的准确率会掉得比较明显。所以，选哪一档不是越大越好，而是要看你的部署端是什么配置，这就是一个很好的答辩切入点：你能解释清楚为什么用s而不是用n或m。

1.3 为什么界面非要选PyQt

有人问过我说，检测后端用Python，前端为什么不用网页？网页的好处是跨平台，但坏处也很现实：你得搭Flask/FastAPI，写前端HTML，处理浏览器权限，还要考虑跨域和网络问题。答辩现场一旦网络不稳定，整个Demo可能直接翻车。PyQt做桌面端，所有东西都在一台机器上，摄像头直连，模型本地推理，数据存本地SQLite，整套系统自成闭环，演示的时候除了摄像头以外不依赖任何外部条件。

PyQt的另一个优势是它和OpenCV的配合实在太顺滑了。OpenCV读出的是numpy数组，PyQt里一个QImage转换就能上屏，中间不需要序列化、不需要走HTTP、不需要WebSocket。音频提醒用QSound，报警日志用QTableWidget，逻辑都很直接。最重要的是答辩时你能现场演示：打开摄像头，放一部手机在镜头前，界面立刻弹框并报警。这种效果对评委的冲击力，远超屏幕上放一段录好的视频。

2. "智能监考"到底检测什么：任务的重新定义

很多人的毕设PPT到了“系统功能”这一页就写得很空：检测手机、检测人脸、检测异常行为。但答辩老师最喜欢问的一句就是：你怎么定义“异常”？这不是抬杠，这确实是系统设计的核心。我当年做这套系统时，把监考行为拆成了四类具体任务，每个任务都有独立的判定逻辑。

2.1 手机检测：小目标问题

手机检测看起来简单，COCO数据集里也有cell phone这个类，但直接拿预训练权重在考场画面上跑，效果一般都不理想。原因在于：COCO里手机照片以近景自拍为主，而考场监控画面里的手机是远景、小目标，还可能被手遮挡、放在大腿上只露出一角。要解决这个问题，不能光靠换模型，要从数据上补。

我当时的方法是自采了1000多张不同考场光线下的画面，专门把手机出现区域裁剪放大做训练。数据增强里把图片随机缩放、旋转、亮度扰动加满。训练出来的模型，小目标的召回率比直接用COCO权重高了至少20个百分点。这个对比数据在答辩时特别好用，因为它证明了你理解“数据分布决定模型表现”这个原理，而不是单纯把训练跑通。

2.2 低头/夹带行为的折中方案

“低头检测”如果严格做，应该用人体关键点或头部姿态估计，计算头部俯仰角。但纯YOLOv8的目标检测模型只能输出框，输出不了角度。做毕设没必要一上来就啃姿态估计算法，我有一个折中方案：用YOLOv8先检测人头框，然后把人头框中心点和颈部区域的位置关系作为特征，配合连续N帧的头部位置变化来判断是否长时间低头。

更简单一点的做法是单独训练一个head_down类别，专门标注“低头幅度较大”的人头样本来做二分类检测。这里的难点是主观性太强，标注一致性难保证。我的经验是定一个死标准：下巴尖低于画面中桌面参考水平线10个像素以上才算低头，否则不算。有了这种量化标准，标注的一致性提高了，模型训练也收敛得更好。答辩时拿出这套判定标准来，老师的反馈通常是“这个思路可以，落地性好”。

2.3 离席与人数统计

离席检测是三种任务里最简单的，但也是逻辑最容易出错的。简单的做法是，在画面里预设几条检测线或几个座位区域，检测到人框的中心点离开了座位区域，并且连续多帧都不回来，就判定为离席。坑在哪儿呢？人站起来伸懒腰的时候中心点也会偏移，容易被误判离席。所以我的处理方式是加一个“回归冷却时间”：只有当人离开座位区域超过10秒，才触发离席报警。这个10秒是调出来的，不是拍脑袋定的。

人数统计其实可以额外写出一个小的PPT页：检测当前画面中人的数量和预置的应到人数做对比。这个功能本身技术含量不高，但它让“智能监考系统”这个名字更有说服力，同时也能引出你做了哪些数据统计分析，正好呼应“大数据深度学习”这个标签。

2.4 一张表讲清检测任务和踩雷点

这张表我在答辩PPT里直接放出来了。好处是你在讲功能的时候，老师已经能预判到你会踩哪些坑，等到他提问的时候，你正好可以顺着他的预期往下讲，答辩节奏会明显更舒服。

3. 训练一个可用的检测模型：从数据到权重的完整过程

3.1 数据从哪来：公开数据集 + 自采

很多同学做毕设最怕的不是写代码，而是没数据。手机检测的公开数据集确实有，但场景和考场监控差距很大。我的做法是三层结合：第一层，网上能找到的公开手机检测数据集，拿来做预训练底料；第二层，自己用手机拍教室、图书馆、自习室的照片，模拟不同光线下的考场；第三层，从公开监控视频里截帧，虽然是监控视角，但保证了视角多样性。

自采数据时要注意伦理问题，不要拍任何人脸的清晰正脸，拍场景、拍桌面、拍远景就好，用到的图片尽量模糊化处理。毕设项目只要不落地商用，做研究和演示是没问题的，但最好在论文附录里写明数据来源和脱敏方式，这是很多同学容易忽略的地方。

3.2 标注与格式转换

标注工具我用的是LabelImg，纯开源，装好就能用。YOLO格式的标注是txt文件，每行五个数字：类别、中心点x、中心点y、宽、高，全部归一化到0到1之间。转换公式很简单，但有个坑：LabelImg默认导出的路径是相对路径，如果你把图片和标注文件分开放，训练时经常报“no labels found”。我建议从一开始就把数据集组织成固定结构，避免后期返工。

project_root/ ├── dataset/ │ ├── images/ │ │ ├── train/ │ │ └── val/ │ └── labels/ │ ├── train/ │ └── val/ ├── exam.yaml └── runs/

3.3 训练命令与参数怎么选

数据准备好之后，训练本身反而没什么好恐惧的。用ultralytics库，一个命令就能跑起来。我在训练时的配置是这样的：

# exam.yaml path: ./dataset train: images/train val: images/val nc: 3 names: ["phone", "head_down", "person"]

yolo detect train data=exam.yaml model=yolov8s.pt epochs=150 imgsz=640 batch=16 device=0 patience=20

几个参数要解释清楚。patience=20是早停策略，连续20个epoch验证集指标不涨就自动停止，省时间也能防过拟合。imgsz=640不要随意改成1280，显存占用翻四倍，而且对普通场景收益并不明显。device=0是使用GPU，如果你的机器没有CUDA环境，就要去掉这个参数让它在CPU上跑，但训练时间会很长，不如直接去用云端算力。

3.4 评估指标怎么看懂

训练结束后，runs/detect/train目录下会生成results.png，里面有mAP@0.5、precision、recall等曲线。答辩时你要能读懂这些指标，并能针对曲线说明你的调参思路。比如我调参过程中发现recall一直上不去，主要就是head_down类的样本量不够，于是回头扩充了这一类的标注数据，而不是盲目增加训练轮数。

一个小技巧：训练完成后，拿训练集里最难的几张图出来手动预测，看看检测框的质量。很多问题在mAP曲线上看不出来，但一眼看图就能发现——比如“远处小手机漏检”“两个离得近的人合并成一个框”。这些视觉层面上的错误，比指标更能帮助你决定下一步优化方向。

4. PyQt桌面端集成的核心架构：线程、视频流和报警日志

4.1 界面布局怎么设计

PyQt界面我没有做得花哨，走的是“监控软件”的传统三段式：顶部工具栏，中间主画面，右侧报警面板。主画面用QLabel放视频帧，右侧用QTableWidget放实时报警列表，下面加一个QTextEdit做日志输出，底部放置信度滑条和模型选择下拉框。

推荐再放一个实时统计区域，用简单的QLabel显示“当前人数、今日手机报警次数、低头报警次数”。这个小东西做起来不难，但答辩演示时，老师看到数字在跳，就会认为你的系统有“数据感知能力”，而不是一个只会画框的Demo。

4.2 真正的关键：线程模型和信号槽

很多第一次写PyQt项目的同学，最容易犯的错误是直接在GUI主线程里cap.read()和model.predict()。结果一检测，界面就卡死，拖动窗口都费劲。原因很简单：GUI主线程被阻塞了，事件循环无法处理鼠标键盘消息。

正确做法是用两个工作线程：采集线程负责读摄像头，推理线程负责跑模型，两个线程通过queue.Queue传递图像帧，再通过PyQt的signal/slot把结果抛回主线程更新UI。

class Worker(QThread): frame_ready = pyqtSignal(object, object) # image, results def __init__(self, cap, model): super().__init__() self.cap = cap self.model = model self.running = True def run(self): while self.running: ret, frame = self.cap.read() if not ret: continue results = self.model(frame, verbose=False) self.frame_ready.emit(frame, results)

这里有一个容易被忽略的细节：model(frame, verbose=False)里的verbose=False一定要写。不写的话，每次推理控制台都会刷一条推理日志，长时间运行会把内存越堆越大，最后无端崩溃。这种小坑不在代码里踩一次，很难想到。

4.3 图像从OpenCV到Qt实现

把OpenCV的BGRnumpy数组显示在界面上，最常用的代码是：

rgb_image = cv2.cvtColor(bgr_frame, cv2.COLOR_BGR2RGB) h, w, ch = rgb_image.shape bytes_per_line = ch * w qt_image = QImage(rgb_image.data, w, h, bytes_per_line, QImage.Format_RGB888) self.video_label.setPixmap(QPixmap.fromImage(qt_image))

这串代码有几个坑，值得单独说。一是QImage构造时传的是rgb_image.data，如果后续numpy数组被重新赋值，QImage会变成野指针，画面出现花屏。解决方法是先转成QPixmap再显示，或者每帧都重新构造QImage。二是如果直接拿BGR模式去构造Format_RGB888，画面会偏蓝偏红，必须先用cvtColor转成RGB。三是如果原始画面是1920x1080，直接塞进一个800像素宽的QLabel，会比较占CPU，建议先cv2.resize到合适尺寸，能明显降低界面卡顿。

4.4 报警与日志落库

报警不能只靠画面弹框，系统还必须留下可追溯的记录。我设计的报警逻辑是滑动窗口策略：检测到手机类目标的连续帧数超过3帧，才算一次有效报警，并在右侧表格里追加一条记录。单帧报警不触发，因为摄像头偶尔会出现一帧抖动噪声。

记录内容我用SQLite存一张alarm_log表，字段包括：时间戳、考场编号、报警类型、置信度、报警截图路径。到答辩演示“数据分析”那一段时，直接从库里查数据，用pandas按小时聚合报警数量，画成柱状图展示“哪个时间段手机报警最频繁”。这个可视化虽然简单，但把“大数据深度学习”里的“数据”二字落到实处，比PPT里贴一堆词有用得多。

5. 实测踩坑实录：这些坑比训练还折磨人

5.1 推理速度的隐形损耗

我最初的版本直接逐帧调用model.predict(frame)，结果同样的模型在官方Demo里能跑30FPS，到我的程序里只有15FPS。查了半天发现，问题出在每次调用predict时模型都在重新做前处理和后处理的初始化。换用model(frame, verbose=False)这种直接传入numpy数组的方式之后，帧率立刻回升。

另外一个隐形损耗是，程序运行时把置信度阈值设置在了0.1，导致大量低置信度的框参与NMS计算，帧率被拖慢。把阈值提到0.35之后，速度和误报率都改善了不少。这个看似很小的参数，实际上是速度和准确率的平衡点，务必写到论文的实验对比里。

5.2 摄像头崩溃与线程退出

监考系统要长时间运行，摄像头却不是一个稳定设备。USB摄像头用久了可能会断开，笔记本合盖后摄像头也会失效。如果cap.read()返回False，你的线程还继续跑，程序会直接崩溃。我的处理方式是在采集线程里加一个重连机制：

if not ret and self.reconnect_cnt > 10: self.cap.release() time.sleep(1) self.cap = cv2.VideoCapture(self.source) self.reconnect_cnt = 0 else: self.reconnect_cnt += 1

关闭程序时还有个经典坑：如果你直接关窗口，摄像头资源没释放，下一次打开摄像头时会报device busy。所以窗口关闭事件里，一定要先停止线程、再release()摄像头、最后再退出应用。顺序错了，电脑上留给你的就是一只打不开的摄像头。

5.3 小目标漏检的暴力解法

前面我说过，手机在考场画面里是小目标。小目标漏检最直接的解法不是换大模型，而是“切图推理”。把1920x1080的画面切成四块，每块分别推理，再把结果坐标映射回原图。这样等于把小目标放大了四倍，检测效果立竿见影，代价是推理次数变成原来的四倍。

如果觉得四倍太慢，我后来采用了一个变通方案：整图推理保留，同时对画面中心区域（通常是考生桌面附近）做一次单独的裁剪推理。中心区域单独推理只需要增加一次算量，整机FPS还能维持在20以上。答辩现场把这两版速度对比摆出来，老师会觉得你具备工程权衡能力，而不是只会调用一个模型。

6. 答辩前必须搞懂的追问：能讲清楚才不会被问倒

6.1 演示脚本比功能本身更重要

毕设答辩最危险的场景不是功能太少，而是功能没有按顺序被准确呈现。我建议写一页“演示脚本”，刚才我自己用的时候就吃过大亏：答辩现场光线太亮，手机在桌上反光，前一分钟模型一直没检出来，场面一度很尴尬。后来学乖了，演示前先把摄像头对准一个暗一点的位置，或者把手机拿在手上靠近桌面一点再放下来。

演示脚本的大致顺序是：系统启动 → 摄像头画面出现 → 正常状态无人报警 → 把手机放到桌面上 → 界面弹窗和声音报警 → 模拟低头动作 → 触发低头报警 → 打开报警记录面板 → 导出当天日志Excel → 展示报警统计图表。整个过程控制在三到五分钟，每一步都要预先演练至少十遍，尤其是报警触发的那一下，要让评委看到明显的延迟反馈。

6.2 高频追问参考与回答思路

我整理过答辩老师最常问的几个问题，提前准备好答案会让心态稳很多：

• 为什么用YOLOv8而不是Faster R-CNN？回答要点：YOLOv8是单阶段检测器，推理速度快，适合实时监考，Faster R-CNN精度高但速度慢；从部署角度考虑，PyQt桌面端的实时需求决定了选型。
• 置信度和NMS是什么？回答要点：置信度是框内有目标的概率，NMS是去除重复框的算法，保留置信度最高且IoU满足条件的框。
• 误报怎么降低？回答要点：通过连续帧滑动窗口过滤单帧噪声，通过提高置信度阈值减少低质量候选框，通过扩充难例数据增强模型鲁棒性。
• 这套系统能用于实际考场吗？回答要点：目前是原型验证阶段，实际部署需要针对考场环境调整模型，加入人脸识别确认考生身份，加入目标跟踪处理遮挡问题。

每个问题都要能讲出“我实测过什么”“我改了什么参数”“效果怎么样”，而不是背定义。老师想听的是你踩坑后得出的判断，不是百度百科。

6.3 你想不到的加分点：行为统计与可视化

如果你还有精力，可以考虑在系统里加一个“考试违规态势”页面，把报警记录按时间轴、按座位号、按类型做可视化聚合。用pyqtgraph或者matplotlib画几张图，不需要做得很复杂，关键是要能讲出“为什么这个可视化对监考员有用”：一场考试结束，监考员不可能盯着回放看两小时，但一张“15:20到15:30手机报警集中暴增”的热力图，能直接告诉老师哪个时段出现了异常。

我自己的体会是，毕设拿高分不一定要解决多难的算法问题，而是要让老师感觉到你把一个真实问题完整地闭环了：从数据采集、模型训练、桌面端集成、报警记录到统计分析，每个环节都有自己的思考和取舍。这套智能监考系统技术上并不算深，但它把一个深度学习模型真正用了起来，而且在答辩现场能稳定跑给别人看，这就已经赢过不少只会放PPT的同学了。

最后再分享一个小技巧：答辩前一天，把摄像头、模型文件、依赖环境全部在答辩教室里实测一遍。灯光换一盏，画面亮度就完全不同；Wi-Fi有没有，都不影响你本地推理。把意外都留在正式答辩之前，你的演示就会非常顺畅。