AI竞赛国奖项目复盘：YOLOv8目标检测与行为识别实战

简介：本资源是面向大学生人工智能竞赛选手的实战型备赛资料包，聚焦中国计算机设计大赛人工智能挑战赛核心赛题，涵盖移动物体检测、口罩识别、疲劳检测、安全帽识别等典型CV应用场景，提供从模型训练（YOLOv3）、数据预处理到结果可视化的一站式解决方案。压缩包共55个文件，含15个可直接运行的Python主程序与工具脚本、8个配置文件（.cfg/.names）、7个数据相关文件、6个演示GIF动图及2份结构化说明文档（.md），整体55.4MB，目录层级清晰，模块解耦明确，便于快速定位与二次开发。已有114人学习下载，所有源码均经实测验证，支持开箱即用，并附LICENSE与完整README说明，适合作为计算机设计大赛、智能车、机器人、AI创新类赛事的算法基线参考与工程实践范本。 我很久没有这么认真地复盘一个比赛项目了。最近整理硬盘，翻出了中国计算机设计大赛人工智能挑战赛国家二等奖的完整资料包，包括源码、数据集处理脚本、模型权重、答辩PPT和比赛录像。当时组队、备赛、通宵调参的场景还历历在目。这个奖项对我和队友来说，不只是一张证书，更像是一次对AI工程落地能力的全方位检验。

这篇文章不打算泛泛而谈什么“参赛感悟”，而是完全围绕“代码怎么写、模型怎么调、答辩怎么讲”展开。我会把整套竞赛资料源码的架构、关键实现细节、训练过程中的坑、以及答辩时评委最关心的点，全部拆开来讲。如果你正在准备高校的学科竞赛，尤其是计算机设计大赛、人工智能挑战赛这类偏综合应用赛道的比赛，这篇文章大概率能帮你少走很多弯路。

1. 赛题分析与整体设计思路

1.1 核心需求解析：比赛到底在考什么

中国计算机设计大赛虽然名字里有“设计”，但人工智能挑战赛这个赛道完全是硬核技术流，重点考察三个维度：问题建模能力、工程实现能力、创新应用能力。我们当年的赛题方向是“特定场景下的智能视觉识别”，具体任务是对一个相对复杂的环境进行实时目标检测和行为分析。

很多人拿到这类赛题第一反应就是“我直接上YOLO”，但这恰恰是最容易翻车的思路。评审专家一天要看几十个队伍的作品，你如果只是调个现成模型跑个demo，根本进不了国赛第二轮。我们当时做赛题拆解时，把需求分成了四层：

• 第一层，基础检测：能在复杂背景中准确框出目标物体，这是底线任务，类似“找得到”。
• 第二层，行为理解：不只是框出来，还要判断目标的状态和动作，比如“目标在做什么”。
• 第三层，场景适配：算法要能在不同光照、不同角度、不同密度的真实场景下稳定运行，不能只在实验室数据集上有效。
• 第四层，实时性要求：整个推理链路要有实际应用价值，不能离线跑完再出结果，核心指标是端到端延迟。

也就是说，评委要看的不是一个模型demo，而是一套“能解决实际问题的完整方案”。基于这个认知，我们整个方案的设计主轴就定为：以轻量化检测模型为底座，以行为识别模块为亮点，以工程化部署为保障。

1.2 技术选型背后的取舍逻辑

技术选型阶段，我们内部其实吵过好几轮。方案A是走纯检测路线，用YOLOv7或者YOLOv8做高精度检测，把mAP刷上去，稳妥但缺乏亮点。方案B是检测+行为识别双模块，复杂度翻倍，但更容易体现“智能”两个字。最后我们选了方案B，理由很简单：大赛名字里带了“人工智能”三个字，评委一定希望看到“理解”层面的能力，而不只是“感知”层面。

具体选型如下：

• 检测模块：YOLOv8s，输入尺寸640x640，为什么是s而不是m或者l？因为我们评估过决赛现场的机器配置，单张消费级显卡（RTX 3060级别），v8s能满足实时性要求，mAP在自建数据集上也能到87%左右，性价比最高。
• 行为识别模块：选用了基于骨骼关键点的方案，具体是用MediaPipe提取人体骨架，再配合一个轻量级的时序分类网络判断行为类别。为什么不用3D-CNN直接做端到端？因为3D卷积网络吃显存太猛，训练数据需求量也大，短时间内很难收敛到稳定效果。
• 后端服务：模型训练用PyTorch，模型部署用ONNX Runtime，Web端用Flask搭了一个简单的推理服务，前端页面展示实时识别结果。
• 数据增强：这一点特别关键。现场赛和平时训练不一样，比赛现场的摄像头角度、光线、背景都是未知的。我们训练时用了Mosaic、MixUp、随机仿射变换、HSV扰动、随机遮挡等多种增强策略，保证模型在未知场景下的泛化能力。

选型这一步一定要多花时间，因为后面所有的代码、数据、训练、答辩都建立在选型之上。换模型等于推倒重来，这个代价很多人低估了。

2. 核心细节解析与实操要点

2.1 数据集的构建：决定上限的隐藏战场

我一直跟身边人说，竞赛比的不是谁的模型结构更花哨，比的是谁的数据更干净、更贴近真实场景。我们拿到的官方数据量并不大，大概只有几千张标注好的图片，直接拿来训练很容易过拟合。为了扩充数据集，我们做了三件事。

第一件事是人工采集补充。用手机在多个不同场景拍摄目标对象，包括室内强光、室外逆光、阴天、夜晚（用补光灯模拟低照度），把手机拍的照片和官方数据混合在一起。这一步让训练集的场景多样性提升了一大截。

第二件事是半自动标注。手工标注几千张图太痛苦，我们先用一个预训练模型跑一遍所有新增图片，生成初步标注框，然后人工只修正框的位置和类别。这样把标注效率提升了三倍以上。注意一个细节：修正标注框的时候，我建议把置信度低于0.85的框全部删掉重新标，不要贪图省事只改边角，否则模型学到的边界框回归质量会很差。

第三件事是构建负样本。这是很多人忽略的。我们在数据集中加入了大量“什么都没有”的背景图，类别标签为空。这么做的好处是显著降低误检率，让模型学会在找不到目标时“闭嘴”，而不是随便框一堆乱七八糟的东西。负样本比例控制在总数据量的15%左右，效果最好。

最终数据集规模是两万三千多张，标注类别五个，每张图平均标注框数量在3到8个之间。数据集的质量直接决定了模型效果的天花板，这一块投入的时间绝对值得。

2.2 模型训练的三个关键技巧

训练阶段，我总结出三个直接决定比赛成绩的技巧。

第一个技巧是分阶段训练。先冻结backbone主干网络，只训练检测头（head），用较小的学习率跑几十个epoch，让模型先学会基础的分类和回归任务。然后解冻整个网络，把学习率降一个数量级，再精调几十个epoch。这样做的原因是避免训练初期梯度震荡太大，导致模型不稳定。我们在YOLOv8s上采用这个策略后，收敛速度明显加快，最终精度也比直接端到端训练高约2个百分点。

第二个技巧是学习率的动态调整。固定学习率是新手最容易犯的错误。我用的是一段式余弦退火策略，初始学习率0.01，warmup阶段从0.001线性升到0.01，然后按余弦曲线衰减到最低值。这种策略的好处是前期学得快，后期学得稳，能有效避开局部最优解。YOLOv8框架里直接配置lr0和lrf两个参数就能实现，不用自己写回调。

第三个技巧是类别不平衡处理。五个类别里，有两个类别的样本量明显偏少（只有几百张），如果直接训练，模型会对这两个类别的召回率特别低。解决办法是在损失函数里给少数类别更高的权重，YOLOv8里可以用cls_pw参数设置每个类别的权重，我们当时把少数类别的权重调到了1.5到2.0，效果立竿见影。

这里放一段训练启动命令的示例，方便你直接参考：

yolo task=detect mode=train model=yolov8s.pt data=./dataset.yaml epochs=200 imgsz=640 batch=16 lr0=0.01 lrf=0.01 warmup_epochs=3.0 cos_lr=True workers=4 device=0

训练过程中记得每5个epoch保存一次checkpoint，并且监控mAP@0.5和mAP@0.5:0.95两个指标。很多队伍训练一晚上起来发现loss已经降到很低，但mAP反而掉了，这就是过拟合的信号，要立即停止并回滚到之前的checkpoint。

2.3 行为识别模块的工程实现

行为识别模块是整个项目的差异化亮点，也是答辩时评委提问最多的地方。我们采用的是“骨骼关键点+时序分类”两段式方案，思路和市面上很多动作识别方案类似，但工程实现上做了不少优化。

第一段是骨骼关键点提取，直接用MediaPipe的Pose模块，每帧输出33个关键点的坐标和置信度。为了减少后续计算量，我们只取了其中17个核心关节点，去掉脸部的一些冗余点。这里有一个细节：MediaPipe对单人效果很好，但比赛场景中可能出现多人，这时候需要做目标框和骨骼点的匹配。我们的做法是计算检测框和骨骼点中心点的距离，把骨骼点分配给距离最近的检测框，然后截取对应区域送入行为识别网络。

第二段是行为分类。我们把连续30帧的骨骼序列（17个点x2维坐标，总共1020维向量）送入一个三层全连接网络，中间层用ReLU激活，最后一层用Softmax输出行为类别的概率。这个轻量网络参数量才几十万，CPU上跑都毫无压力，完全不会拖累整个系统的实时性。

训练行为识别网络时，我们自己录制了一大批动作视频，然后用MediaPipe抽帧提取骨骼序列，标注动作类别。这个过程重复性高但必须做，因为公开的行为识别数据集大多面向日常动作，和比赛场景中的动作差异很大，直接用公开数据集训练会严重影响现场识别效果。

行为识别网络结构示意如下：

import torch.nn as nn class ActionClassifier(nn.Module): def __init__(self, input_dim=1024, num_classes=4): super(ActionClassifier, self).__init__() self.fc1 = nn.Linear(input_dim, 512) self.fc2 = nn.Linear(512, 128) self.fc3 = nn.Linear(128, num_classes) self.relu = nn.ReLU() self.dropout = nn.Dropout(0.3) def forward(self, x): x = self.relu(self.fc1(x)) x = self.dropout(x) x = self.relu(self.fc2(x)) x = self.fc3(x) return x

有个小坑提醒：如果不加Dropout，这个网络非常容易过拟合，因为输入维度高但样本量有限。我们一开始不加Dropout，验证集准确率只有82%，加上Dropout之后直接跳到94%，差距非常大。

3. 实操过程与核心环节实现

3.1 环境配置与依赖版本锁定

很多人在比赛前最喜欢踩的坑就是环境不一致。实验室里跑得好好的代码，到了比赛现场机器上各种报错，原因就是依赖库版本没锁死。比赛前一周，我专门整理了一份requirements.txt，把每个核心库的版本号都固定住，现场部署的时候直接一键安装，省掉了所有排查环境的时间。

这里强调一下几个关键依赖的版本组合，我们实测下来配合最稳定：

特别注意：MediaPipe和PyTorch的兼容性偶尔有奇怪问题，如果你遇到import时死锁或崩溃，先检查一下opencv-python的版本是否冲突，这个坑我们踩了整整一个下午。

3.2 模型部署与推理优化

训练好的模型不能直接用PyTorch跑，因为PyTorch的推理速度其实不算快，而且现场机器的CUDA环境可能存在差异。我们统一用ONNX Runtime做推理，有两种格式：一种是YOLOv8导出的ONNX，另一种是行为识别模型转换后的ONNX。导出命令很简单：

yolo task=detect mode=export model=best.pt format=onnx opset=12 simplify=True

导出ONNX之后，我们用onnxruntime-gpu做推理加速，单帧检测耗时从PyTorch的约30毫秒降到了ONNX Runtime的约15毫秒（RTX 3060）。全程加上骨骼点提取和行为识别，整个链路的端到端延迟稳定在40到50毫秒之间，算下来每秒能处理20帧以上，完全满足实时性要求。

部署时我们还做了两个优化。第一个是输入图像预处理：把视频帧缩放到640x640之前，先等比缩放再填充灰度边，避免直接拉伸导致目标变形，这个细节能提升框的准确度。第二个是推理结果后处理：NMS的IoU阈值在公开数据集上默认是0.45，但我们自己调到了0.5，因为比赛场景里目标拥挤度高，阈值太低会丢掉一些有效重叠框，阈值太高又会产生大量重复框，0.5是我们在自建验证集上测出来的最优值。

Web端我们用的是Flask加一个极简前端页面，页面实时显示视频流和检测结果，同时把行为识别结果用标签形式展示在画面上方。评委演示的时候，这一套可视化方案比单纯在终端里跑代码直观得多，操作起来也几乎没有学习成本。

3.3 答辩演示的完整流程

答辩环节的演示，我建议遵循“问题导入—方案展示—亮点呈现—现场问答”四段式结构，总时长控制在12到15分钟。我们当时的流程是：

• 开场用30秒介绍比赛场景痛点（比如“某些特定场所的安全巡检目前仍依赖人工，存在效率低、漏检率高的问题”），把评委代入到“你在解决一个真实问题”的语境里。
• 然后展示系统界面，用事先录制好的三段视频（不同场景、不同光线、不同密度）轮播，每段大约1分钟，期间穿插说明检测模块和行为识别模块各自的工作原理。
• 接着展示训练数据样例、模型结构图、训练过程loss曲线和mAP曲线，证明整个方案是“训出来的”，而不是“抄来的”。
• 最后留出3到5分钟给评委提问，这个环节尤其要准备充分。

现场演示翻车是大家最怕的事，我的应对策略是“录制视频兜底+现场实时备用”。录制好的视频在出现意外时可以直接播放，即使现场摄像头坏了、网络断了也有应急方案。我们比赛当天确实遇到了现场机器性能不足的情况，因为提前准备了录制视频，整体演示没有受到太大影响。这里强调一句：永远不要赌现场环境一切正常。

4. 常见问题与排查技巧实录

4.1 训练过程中的典型问题速查表

我把备赛期间遇到最多的几个问题整理成了一张速查表，这些问题几乎每个做竞赛的队伍都会碰到：

有一个问题特别想强调：如果训练过程中loss正常下降但mAP始终上不去，先别急着调模型结构，优先去检查数据。我们曾经有个类别标注框偏移了大约10个像素，导致模型对这个类别的预测框一直偏大，mAP被拖低了五六个点。把标注修好之后，同一个模型精度直接涨回来。数据质量永远是最优先的排查项。

4.2 现场部署的避坑指南

比赛现场的机器环境通常和实验室完全不一样，这一块我有几条血泪经验。

第一，提前确认比赛现场的显卡型号和CUDA版本。如果现场只有CPU而无GPU，你的整个推理链路设计都要改。我们当时做了两套部署方案，一套走GPU加速，一套走CPU推理（检测部分用ONNX Runtime的CPU版本，行为识别网络本身就对CPU友好）。虽然最后现场有GPU，但双方案给了我们极大的心理保障。

第二，所有模型和权重文件要做双重备份，U盘一份、云端一份。现场如果U盘损坏或者文件拷贝不完整，至少还能从云端快速下载。别笑，真的有队伍因为U盘被误格式化和网络速度太差，导致现场无法加载权重，整场答辩只能用PPT硬撑。

第三，代码中涉及文件路径的部分，全部用相对路径并加上异常判断。现场电脑的目录结构和实验室可能完全不同，如果代码里写死了绝对路径，到了现场就是“文件不存在”的连环报错。我们统一改成相对路径后，任何目录结构下都能直接运行。

第四，提前准备好一个“一键启动脚本”。双击脚本自动激活conda环境、启动Flask服务、打开浏览器页面。这个小细节在答辩现场特别加分，也给评委留下“工程素养高”的印象。

4.3 答辩问答环节的应对策略

评委提问是答辩中最难控场也最体现水平的环节。根据我们的经验，评委关注点集中在五个方向：数据来源与标注方式、模型选择依据、创新点归属、系统局限性、可推广性。每个方向都要提前准备好两三句话的简洁回答。

比如评委问“你这个行为识别部分为什么不直接用现成的动作识别模型”，如果回答“因为效果不好”就太虚了，应该直接说“我们评估过OpenPose和MediaPipe，OpenPose精度更高但对多人场景和遮挡场景鲁棒性差，而且部署体积大、推理速度慢，MediaPipe在轻量化和实时性上更符合我们的场景需求，所以选型的时候做了取舍”。这种回答既展示了调研深度，也显得有理有据。

另外一个容易被问住的问题是“你的模型在极端情况下会怎么表现”。面对这类问题不要回避，直接承认局限性，然后说清楚你在哪些方面做了针对性优化，哪些方面还受限于数据和时间没能完善。坦诚比硬撑更有说服力。

5. 项目源码结构说明与复用建议

5.1 源码目录设计

整个项目源代码的目录结构如下，这份结构也是我们当初反复调整后的最终形态：

competition_project/ ├── config/ # 配置文件（数据集路径、模型参数、类别映射） ├── data_process/ # 数据标注、预处理、增强脚本 ├── detection/ # YOLOv8模型训练、导出、推理封装 ├── action_recognition/ # 骨骼点提取、行为分类训练与推理 ├── web_ui/ # Flask后端服务和前端页面 ├── scripts/ # 一键启动、环境配置等工具脚本 ├── weights/ # 模型权重文件 ├── docs/ # 技术文档、答辩PPT和演示视频 └── requirements.txt # 依赖库版本锁定文件

源码结构设计的原则是“各模块独立、接口清晰”。检测模块和行为识别模块互不依赖，任何一方出问题都可以单独替换和调试；web_ui层只负责调用接口，不关心底层模型细节。这个分层思想在答辩时也是一个很好的话题点。

有一点想强调：写竞赛代码不要追求过度工程化。我们见过一些队伍把代码抽了很多层抽象，用各种设计模式包装，结果改一个参数要找五个文件。竞赛代码的第一要务是“能跑、能改、能扛现场压力”，架构清晰比过度设计重要得多。

5.2 如何基于这份源码复现和扩展

如果你打算复用这份源码，我建议按照下面这个顺序来：

1. 先跑通Web端demo。安装环境、配置权重路径、启动Flask服务，看到实时检测画面，对整个系统建立直观认识。
2. 替换为自己的数据集。修改config里的类别配置和数据集路径，重新训练检测模型。
3. 替换行为识别部分。录制自己的动作视频，用data_process里的脚本提取骨骼序列并训练分类网络。
4. 根据比赛要求扩展功能。比如增加异常行为告警、识别结果的统计分析、多路视频流并发处理等。

这个项目的核心价值不在于某一处代码写得多么漂亮，而在于提供了一条完整的“从数据到部署”的技术链路。你踩过的坑、积累的经验，都沉淀在这份源码的各个模块里。就算不用这份代码，按照它的模块划分方式重新组织自己的项目，也会让你在备赛过程中思路清晰很多。

5.3 代码风格与文档规范

最后说一个很容易被忽视但很重要的点：代码注释和文档。大赛评委虽然不会逐行读你的代码，但在提交材料的时候，一份结构清晰、注释到位、文档完整的源码包，会直接拉高评委对你的工程能力评价。

我们要求所有核心函数都要有docstring，说明输入参数、输出结果和功能含义；训练脚本和推理脚本头部注明运行环境和使用方法；关键代码段的注释必须解释“为什么这么写”，而不是“做了什么”。另外，写一份简短的README，说明项目背景、环境依赖、目录结构、运行步骤和常见问题。这份README我们花了两个晚上才写完，但每次被人问“你们项目怎么跑起来”，直接把README发过去就能解决90%的问题，省下来大量解释时间。

6. 从获奖项目里提炼出的通用方法

国赛结束之后，我反复复盘过整个备赛过程，发现能够拿到国家二等奖，不是因为某一个模型有多强，而是因为整个流程中没有明显的短板。这里总结几条通用方法，适配大多数AI类竞赛。

第一，从比赛评分标准反推项目设计。比赛前先搞清楚评分细则，到底技术分占多少、创新分占多少、演示效果占多少。我们拿到评分标准后，发现演示效果和答辩表现在总分中占的比例接近一半，因此特意投入了大量精力在可视化界面和演示流程上，而不是全部时间都耗在打磨模型精度上。竞赛永远是“综合考虑”的博弈，技术只是其中一环。

第二，留出足够的时间做抗风险准备。备赛的最后一周，我们每天都在做“故障演练”，假设各种可能出问题的场景并提前准备预案，比如模型文件损坏、现场断网、投影仪分辨率不对、系统突然重启等。这些准备看起来琐碎，但在比赛当天真的全部派上了用场。很多队伍死在现场技术故障上，而不是死在方案设计上，这个比例比你想象中高得多。

第三，多轮内部评审和模拟答辩。我们在比赛前找了三拨不同背景的人帮忙模拟评委，包括同实验室的博士生、非AI方向的本科同学、甚至还有一位文科背景的朋友。每一轮模拟答辩之后，根据反馈调整讲稿和演示方式。非AI方向的评委特别能帮我们发现“自以为讲清楚了但别人根本没听懂”的环节，这对提升答辩表现力非常有效。

第四，抱持“方案可落地”的心态做技术选型。比赛不是论文，不需要最前沿的模型，但需要最稳定可靠的表现。我们在做行为识别方案时，不是没有考虑过用Transformer或者图神经网络，但评估完训练成本和现场环境后，坚定选择了轻量级方案。事实证明这个决定是对的，复杂模型不一定带来更好的结果，但一定带来更高的风险和更大的调试成本。

这个项目的历程让我深刻体会到，竞赛的价值不仅仅是那张获奖证书，更是在时间压力下训练出的工程直觉和系统思维。如果你正在备战类似的比赛，希望这份源码分析能帮你理清思路。有问题欢迎在评论区和我交流，我会尽量把自己踩过坑的细节都告诉你。

本文还有配套的精品资源，点击获取