企业官网建设流程全解析

简介：本资源是一套基于YOLOv8的停车场车位状态识别系统完整实现，面向计算机、人工智能、自动化等专业的在校学生与初学者，解决真实场景下车位空闲/占用状态的自动检测与可视化管理问题，特别适合作为毕业设计、课程设计或项目立项演示方案。压缩包共8个文件（3个Python主程序、3个PyTorch模型文件、2个说明文档），总大小15.91MB，涵盖训练、推理、界面交互与评估全流程：包含可直接运行的可视化界面（Visual_interface.py）、视频检测脚本（Detection_video.py）、模型训练代码（train_mode.py）及预训练与最优权重（yolov8n.pt、best.pt），并附详细README与部署指南。已有43人学习下载，所有代码均经实测验证，支持一键运行并自动生成混淆矩阵、F1曲线、PR曲线、验证集预测图及标签分布图等核心评估结果，开箱即用，无需调参即可获得稳定识别效果，是兼具工程完整性与教学实用性的高质量毕设级项目。 车位检测这事儿，我一直觉得是计算机视觉入门到实战之间最舒服的一个跳板。任务本身直观——区分“空车位”和“占用车位”，不像语义分割那样对精度极致苛刻，也不像目标跟踪那样需要处理复杂的时序逻辑，但又完整覆盖了数据集制作、模型训练、推理部署、界面封装的全流程。最近我重新整理了一套基于YOLOv8的停车场车位状态识别系统，包含完整源码、可视化界面、标注好的数据集和部署教程，把环境配好就能直接跑起来，非常适合用来做毕业设计或者课程设计的核心项目。

这套东西做完之后，我的体会是：它最大的价值不在于“识别率有多高”，而在于帮你把目标检测这条技术栈从理论到落地整个走通了一遍。YOLOv8是当前Ultralytics团队维护的最新YOLO系列版本，相比之前的v5和v7，它在C2f模块、Anchor-Free检测头、损失函数等方面都做了改动，训练更稳定，部署也更友好。配合PyQt5写的可视化界面，你不需要懂任何前端知识，双击运行就能看到摄像头画面或者图片/视频里的车位状态实时标注结果。对毕设来说，这已经是“系统完整、功能明确、有技术深度、有演示效果”的合格答卷了。

下文我会把这套系统从部署到训练再到界面使用的完整过程拆开来讲，包括环境版本怎么匹配、数据集怎么整理、训练参数怎么调、界面怎么改、遇到坑怎么排。全程都是实操视角，想直接抄作业的可以跟着做，想搞清楚原理的我也尽量把“为什么这么做”讲明白。

1. 项目整体设计与技术选型思路

1.1 核心需求拆解：停车场车位识别到底要解决什么问题

先别急着跑代码，想清楚需求再动手，这是做任何项目的第一原则。停车场车位状态识别，从产品功能上看要解决三个层面的问题：

第一层是目标检测，也就是“车在哪”。系统需要在画面中把每一辆车用边界框框出来，这是YOLOv8最擅长的事情。第二层是状态判断，也就是“这个车位有没有被占用”。这一层可以有两种做法：一种是把车位本身当作检测目标，训练模型直接识别“occupied”和“empty”两类；另一种是先检测车辆，再把车辆位置和预先划定的车位区域做交并比（IoU）计算，根据重叠程度判断车位状态。第三层是结果呈现与交互，也就是“用户怎么看”。这里需要可视化界面，把检测结果实时显示出来，最好还能统计剩余车位数。

我用的这套系统在设计上选择了第二种思路，也就是“车辆检测 + 车位区域匹配”。为什么这么选？原因有三：

• 车位数量在固定停车场里是基本不变的，但车辆数量和位置是动态的。先检测车辆，再用车辆框和车位框做匹配，逻辑上更接近真实业务，而且车位区域是预先标注好的，不需要在推理阶段重复检测“车位”。
• 分类粒度更细。直接检测“空车位”类别，模型容易把小面积的空位当成背景，或者把远处的空位漏检。而检测车辆是YOLO家族的看家本领，泛化能力更强。
• 数据标注成本更低。只需要标注车辆边界框，车位区域用多边形预先画好即可，不用为每个车位单独标注“空/占”状态，这在数据准备阶段能省很多时间。

当然，第二种思路对车位坐标的精确度要求更高。车位区域标注得准不准，直接决定匹配结果准不准。我在后面的数据集章节会专门讲怎么标注车位区域。

1.2 为什么选YOLOv8而不是Faster R-CNN或其它版本

很多同学问我，既然做毕设，用Faster R-CNN会不会显得更有“学术深度”？我的看法是：除非你的导师明确要求对比实验，否则真的没必要自找麻烦。Faster R-CNN的两阶段结构虽然精度上限高，但训练速度慢、推理速度慢、工程实现复杂，在以“能跑、效果直观”为首要目标的毕设场景里，性价比太低。

YOLOv8的核心优势在于它把“训练-验证-导出-部署”整条链路都做得很顺滑。Ultralytics这个库本身就封装好了train、val、predict、export这些方法，你不需要手写数据加载器，不需要自己实现NMS，不需要关心anchor的聚类计算，只需要准备好数据集，写一个data.yaml，就能开始训练。对于大部分做毕设的同学来说，把精力花在业务逻辑和系统完整性上，比花在复现网络结构上更有实际收益。

另外，YOLOv8在精度和速度的平衡上也处在当前开源模型的第一梯队。用nano版本可以在CPU上勉强跑推理，用small版本在GTX 1660Ti这种中低端显卡上就能达到实时效果，这正好覆盖了绝大多数学生手里的硬件条件。相比之下，YOLOv5的效率当然也不差，但v8在训练收敛速度和Anchor-Free头的设计上更友好，尤其在小目标场景下表现比v5更稳。如果你的课题需要做车位级别的精细检测，v8的改进还是实打实的。

1.3 系统整体架构：从摄像头到界面显示的完整链路

把这套系统拆开看，其实就是一个标准的“感知-决策-展示”三层结构：

• 数据输入层：支持三种来源——本地图片、本地视频文件、实时摄像头（RTSP或USB摄像头）。入口用OpenCV的VideoCapture统一接管，这样后面不管换什么输入源，处理逻辑都不用改。
• 推理决策层：YOLOv8模型对每一帧执行推理，得到所有车辆的边界框、置信度和类别。然后进入车位匹配模块，把车辆框和预设的车位多边形区域做IoU计算，输出每个车位的状态。
• 展示交互层：PyQt5界面负责把推理结果画到画布上，同时显示剩余车位统计、每帧推理耗时等指标。用户可以通过按钮切换输入源，也可以手动设置IoU阈值。

其中第二个模块的匹配算法是整个系统的灵魂。它的逻辑是：对每一个车位多边形，计算其包围盒与所有车辆检测框的IoU；如果一个车位区域与任意一个车辆框的IoU大于设定阈值（默认0.3），就判定为“占用”，否则是“空位”。这里用IoU而不是简单的中心点是否落入，是因为车辆可能斜着停或者部分跨线，单纯靠点判断容易误判，IoU能更鲁棒地反映“该区域是否被物体占据”的实际情况。

2. 环境配置与源码部署：从零到能跑通

2.1 硬件与软件环境要求

先交代一下我这边的测试环境，方便你对号入座：

• 操作系统：Windows 10/11（Ubuntu 20.04/22.04也完全没问题，代码里没有平台相关的内容）
• Python版本：3.8 或 3.10（3.9也可以，但我更推荐3.10，Ultralytics官方对3.10的支持最完善）
• CUDA版本：11.8以上（PyTorch 2.x的默认CUDA版本是11.8或12.1）
• 显卡：我测试用的是一张GTX 1660Ti 6GB，显存不大，但跑YOLOv8s训练batch size 16完全够用；如果只有CPU，也能跑通流程，就是训练会慢不少
• 依赖库：ultralytics库、PyTorch、OpenCV、PyQt5、NumPy

这里有个特别重要的坑要提醒你：PyTorch的版本必须和CUDA版本匹配，否则会出现CUDA unavailable的错误。建议直接到PyTorch官网用生成的命令安装，比如：

# CUDA 11.8 对应的安装命令 pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu118

不要直接pip install torch，那样默认装的是CPU版本，后面跑推理发现速度慢得离谱，还以为代码写错了。

2.2 依赖安装与项目目录结构

源码下载解压之后，我建议你先看一眼目录结构，做到心里有数。一个标准的结构长这样：

parking_lot_system/ │ ├── main.py # 程序入口，启动PyQt5界面 ├── detector.py # YOLOv8推理封装 ├── parking_matcher.py # 车位匹配逻辑 ├── config.py # 全局配置（路径、阈值、模型参数） ├── models/ # 存放训练好的模型权重 │ └── best.pt ├── datasets/ # 数据集目录 │ ├── images/ │ │ ├── train/ │ │ └── val/ │ └── labels/ │ ├── train/ │ └── val/ ├── ui/ # 界面相关代码 └── requirements.txt # 依赖清单

建议在项目根目录下新建一个虚拟环境，避免和系统其它项目的依赖冲突。创建和激活虚拟环境用这几条命令：

python -m venv venv # Windows下激活 venv\Scripts\activate # Linux/macOS下激活 source venv/bin/activate

然后安装依赖：

pip install -r requirements.txt

requirements.txt的内容大概是这样的：

ultralytics>=8.0.0 torch torchvision opencv-python PyQt5 numpy

如果安装过程中有网络问题，可以加-i https://pypi.tuna.tsinghua.edu.cn/simple换成清华源。安装完可以用一条命令验证基础环境：

python -c "import torch, ultralytics, cv2, PyQt5; print(torch.cuda.is_available(), torch.__version__, ultralytics.__version__)"

如果输出True 2.x.x 8.x.x，说明环境基本OK。如果torch.cuda.is_available()打印的是False，那就要回头检查PyTorch-CUDA匹配问题了。

2.3 模型权重获取与快速推理验证

环境配好之后，先不急着一股脑训练。项目自带的models/best.pt是一个已经在车位数据集上训练好的YOLOv8s模型，主要识别车辆类别。你可以先用它跑一次推理，验证整套流程是否通畅。在项目根目录执行：

python detector.py --source datasets/images/val/ --weights models/best.pt

正常情况下，会看到每一张验证集图片的推理结果，检测框画在车辆上，并且终端会打印每类别的AP指标和推理耗时。这个过程如果跑通，说明：

• 模型文件完整，没有下载损坏
• OpenCV读取图片正常
• YOLOv8推理链路没有bug

后续再跑可视化界面就不会有“一运行就闪退”的问题了。我特别建议大家养成这种“先验证后端，再启动界面”的习惯，不然出了问题你很难判断到底错在模型层还是界面层。

3. 数据集准备与车位标注：训练的关键一步

3.1 停车场图像数据集从哪来

很多同学卡在第一步：没有停车场图片。这里给你几个实际可用的来源：

• 开源数据集：PKLot数据集是学术界比较常用的停车场数据集，包含不同天气条件下的车位图片，规模不大但足够做毕设。CCPD是车牌数据集，虽然主要是车牌识别，但里面也有大量停车场场景，可以作为背景数据。
• 自己拍摄：找学校操场、小区停车场、商场地下车库，用手机或相机拍个几百张，注意覆盖不同光照条件、不同角度、不同车位类型（平行车位、垂直车位、斜车位）。这个方法的优点是完全匹配你的目标场景，缺点是需要自己标注。
• 网络图片：用爬虫或手动下载的方式从图片网站获取停车场图片，注意版权问题，自己测试用问题不大，但不要公开传播。

我这里整理的数据集使用的是多个停车场场景的混合数据，总共约2000张图片，其中训练集1600张、验证集400张。图片分辨率统一resize到640x640（YOLOv8默认输入尺寸），这个尺寸是速度和精度的平衡点，不建议自行修改。

3.2 YOLOv8数据标注的具体操作

车辆标注用LabelImg或者Labelme都可以，我习惯用LabelImg，因为它导出YOLO格式的txt文件很方便。标注时的注意事项：

• 只标注机动车，行人和非机动车不标注。因为车位占用判断只关心机动车是否占位，误把行人标注成目标反而会干扰匹配逻辑。
• 遮挡严重的车辆也要尽量标注，特别是被柱子或者其它车挡住一半的车。YOLOv8对部分遮挡的目标有一定的鲁棒性，但完全不标会让模型学到“看到一半车身就不算车”的坏毛病。
• 每张图的标注框要贴合车辆边缘，不要留太多空白，也不要裁掉车身的轮胎或后视镜。标注质量直接决定训练效果，这一点值得多花时间。

标注完成后，每个图片会对应一个同名的txt文件，格式是：

class_id x_center y_center width height

注意这四项坐标都是归一化到0~1之间的值，不是像素坐标。框的宽高除以图片宽高，中心点坐标也除以图片宽高。如果你的图片有多个标注框，就多行排列。比如一张图里有两辆车：

0 0.425781 0.531250 0.208594 0.265625 0 0.723438 0.610938 0.182031 0.234375

训练之前请务必检查标注文件是否有越界的情况。网上有现成的校验脚本，也可以用下面的代码做快速检查：

import os label_dir = "datasets/labels/train" img_w, img_h = 640, 640 # 根据实际图片尺寸改 for f in os.listdir(label_dir): with open(os.path.join(label_dir, f)) as fp: lines = fp.readlines() for line in lines: _, cx, cy, w, h = map(float, line.strip().split()) if cx - w/2 < 0 or cx + w/2 > 1 or cy - h/2 < 0 or cy + h/2 > 1: print(f"标注越界: {f} -> {line.strip()}")

这个坑我踩过，当时有一批从网上下载的图片尺寸没有统一，标注时用了原始分辨率，但训练时YOLOv8做了resize，导致部分框超出边界，训练loss一直降不下去，白白浪费了一下午。

3.3 车位区域标注与配置文件

车辆标注解决的是“车在哪”的问题，而车位区域是预先定义在画面中的，不参与模型训练。一句话概括这套系统的核心逻辑：模型负责找出所有的车，车位坐标负责判断这些车把哪个位置占了。

车位区域用一张标注好的JSON文件或者Python列表存储。对于每个车位，记录它的多边形顶点坐标。比如一个矩形车位的四个顶点：

PARKING_SPOTS = [ { "id": 0, "points": [(50, 200), (150, 200), (150, 300), (50, 300)] }, { "id": 1, "points": [(160, 200), (260, 200), (260, 300), (160, 300)] }, ]

如果你的场景是固定的摄像头视角，用这种硬编码方式最简单。但如果你希望系统更通用一点，建议做一个“手动标定模式”，界面加载一张背景图，让你用鼠标画车位多边形，然后把坐标保存到配置文件里。这样即使摄像头角度变了，也不需要改代码，重新画一遍车位就行。

数据集的data.yaml文件是YOLOv8训练时的配置文件，内容如下：

path: datasets train: images/train val: images/val nc: 1 names: ['car']

nc代表类别数量，这里只有“car”一类。如果你的场景需要检测卡车、公交车，可以相应增加。但注意，增加类别意味着你需要为每个类别标注足够多的样本，否则训练效果会变差。

4. 模型训练与调参：让YOLOv8在你自己的数据上收敛

4.1 训练启动与参数说明

环境、数据都齐了，下面开始训练。命令行方式最直接：

yolo train data=datasets/data.yaml model=yolov8s.pt epochs=100 imgsz=640 batch=16 device=0

这条命令会以yolov8s.pt为预训练权重，在你的数据集上微调100轮。几个关键参数的解释：

• model=yolov8s.pt：预训练权重在COCO上训练过，迁移学习能极大加速收敛。如果你想看随机初始化效果，改成yolov8s.yaml，模型结构不变但权重随机，通常需要更多轮次才能收敛。
• epochs：车位检测任务相对简单，100轮足够。如果训练时间紧张，50轮也能得到一个可用的模型。
• batch：根据显存来定。6GB显存跑yolov8s的话，batch=16没问题；如果显存不够，把batch降到8或者4，配--workers 4让数据加载并行化。
• device=0：使用第一块GPU。如果你的电脑只有CPU，改成device=cpu，但训练时间可能是GPU的几十倍，不建议。
• patience：早停参数，例如patience=20表示验证集指标连续20轮不提升就自动停止，能省不少时间。

4.2 训练过程监控与常见异常

训练开始后会显示一个进度条，每轮结束后会更新box_loss、cls_loss、dfl_loss以及precision、recall、mAP50、mAP50-95这些指标。我建议你重点关注mAP50，车位检测使用场景对框的精确度要求不那么变态，mAP50在0.9以上说明模型已经很好地把车都找出来了。mAP50-95则是对框定位的更高要求，一般能到0.7以上就不错了。

如果你的训练过程中发现loss不降，或者训练日志里出现nan，先不要急着加大学习率或者换模型，最常见的几个原因按顺序排查：

• 数据集中存在全黑、全白或者严重模糊的图片，导致归一化后出现异常值
• 标注文件越界，有框的位置不在图片内
• batch size设得太大，显存不够导致OOM中断，训练日志里会有CUDA out of memory

有一个小技巧是训练时开plots=True，Ultralytics会自动生成训练过程中的预测图，你可以直观看到模型在验证集上的检测效果。训练完成后，runs/detect/train/weights/目录下会生成best.pt和last.pt，前者是验证集表现最好的权重，后者是最后一轮的权重，部署时用best.pt。

4.3 训练结果评估：怎么看模型到底行不行

训练结束后，Ultralytics会生成results.png和confusion_matrix.png等一堆评估图。作为非学术项目，我建议只看三样东西：

• results.png中的val/box_loss和val/cls_loss是否持续下降且没有大幅震荡，判断模型是否过拟合
• confusion_matrix.png中的对角线数值是否明显高于非对角线，判断是否有大量误检
• 随便拿几张验证集图片用model.predict()测试一下，肉眼判断检测结果是否合理

我个人在使用中最常遇到的问题是模型把“后视镜或者车尾的一部分”识别成完整车辆，导致两个检测框挤在同一辆车上。这是因为标注时有的框没有扣紧车身边缘。解决办法是提高NMS（非极大值抑制）的IoU阈值，在推理参数里加一行iou=0.5，让相近的框合并得更彻底。

训练完的模型如果精度仍然不够，优先考虑两个改进方向：一是增加数据量，尤其增加目标场景下的数据；二是做数据增强，Ultralytics默认开启了马赛克增强、随机翻转、色彩抖动等，不需要额外配置。

5. 可视化界面与推理系统：把模型能力变成可用的产品

5.1 PyQt5界面功能拆解

很多人觉得界面是这个项目里最“花架子”的部分，但我恰恰觉得它是最能体现“系统思维”的地方。一个完整的可视化界面应该包含以下功能：

• 图像显示区域：实时显示当前帧的检测结果，车辆框和车位状态都画在上面。占用车位用红色显示，空车位用绿色显示。
• 输入源控制：下拉框选择“图片模式”、“视频模式”或“摄像头模式”，配合“打开文件”、“开始检测”等按钮操作。
• 状态统计面板：显示总车位数、已占用数、剩余数。这个数据是整个系统的核心输出，对停车管理场景来说，用户最关心的就是“我还有没有位置停”。
• 参数调节区：IoU阈值、置信度阈值这两个参数可以在运行时动态调整，方便用户根据场景灵活配置。
• 日志输出区：记录推理耗时、帧率、异常信息。这部分对调试帮助极大，不是摆设。

界面布局方面，我建议用左中右三栏结构：左侧是参数和输入控制，中间是视频画面，右侧是统计信息和日志。这样用户在调整参数的时候能实时看到画面变化，交互体验最顺畅。

5.2 推理代码的核心实现

推理部分的核心逻辑在detector.py里。初始化YOLOv8模型、执行推理、解析结果、车位匹配，每一步都不复杂但每步都关键。我摘几段核心代码说明：

from ultralytics import YOLO import numpy as np class Detector: def __init__(self, weights_path, conf_thres=0.5, iou_thres=0.45): self.model = YOLO(weights_path) self.conf_thres = conf_thres self.iou_thres = iou_thres def detect_vehicles(self, frame): results = self.model.predict( source=frame, conf=self.conf_thres, iou=self.iou_thres, classes=[0], # 只检测car类 verbose=False )[0] boxes = results.boxes.xyxy.cpu().numpy() # 左上右下坐标 confs = results.boxes.conf.cpu().numpy() return boxes, confs

而车位匹配逻辑在parking_matcher.py里。判断一个车位是否被占用，关键就是计算车辆框和车位多边形的IoU：

def polygon_iou(vehicle_box, parking_polygon): """计算车辆框和车位多边形的交集面积 / 并集面积""" from shapely.geometry import Polygon, box vehicle = box(*vehicle_box) spot = Polygon(parking_polygon) if not spot.is_valid: return 0.0 inter = vehicle.intersection(spot).area union = vehicle.area + spot.area - inter return inter / union if union > 0 else 0.0 def match_vehicle_to_spot(boxes, parking_spots, iou_threshold=0.3): status = [] for spot in parking_spots: occupied = False for box in boxes: iou = polygon_iou(box, spot["points"]) if iou > iou_threshold: occupied = True break status.append({"spot_id": spot["id"], "occupied": occupied}) return status

这段逻辑里有个细节值得注意：IoU阈值取多少合适？如果设置太高，比如0.5，那么一辆车跨了两个车位边缘的时候，两个车位都判定为空，逻辑上就错了。设置太低，比如0.1，又会出现车辆后视镜扫过隔壁车位就把它判定为占用的误报。经过多轮测试，0.25到0.35之间比较合理，我默认用的0.3。

5.3 界面运行与演示操作

界面启动很简单，在项目根目录运行：

python main.py

启动之后，建议按这个顺序操作演示：

1. 打开一张停车场的静态图片，先看整体检测效果
2. 切换到视频模式，观察连续帧的稳定性，看是否有车位状态频繁闪烁
3. 切换摄像头模式，用手机当USB摄像头顶着停车位拍一下，感受实时检测

整个系统目前能够做到在GTX 1660Ti上运行YOLOv8s模型，视频流推理帧率稳定在25-35 FPS左右，完全满足实时监控需求。如果你的显卡只有CPU或者核显，可以换成YOLOv8n模型，预处理时间和推理时间都会明显下降，代价是精度略有下降。

6. 常见问题与避坑实录

6.1 环境与部署问题速查表

这里整理了我实际运行中遇到的高频问题，按出现的概率排序：

6.2 车位状态误判的排查思路

车位状态识别最容易出现两类误判：空位被判定为占用，或者占用被判定为空位。排查时不要一上来就调参数，按这个顺序走：

先检查车位区域标注是否有误。我见过有同学标注的车位多边形尺寸明显地比实际车位大了一圈，导致旁边车道的车稍微压线就触发了占用判定。对策是把车位多边形往里缩几个像素，或者用shapely.buffer(-2)做内缩处理。

再看车辆检测框的质量。如果置信度阈值太低，墙上的影子、地面的反光也可能被当成车。把conf_thres提到0.6以上，误检会明显减少。如果车辆检测框太大或者重叠严重，调高NMS的IoU阈值。

最后考虑相邻车位之间的关联。如果一辆车确实停歪了，压了两个车位，那么它占用了两个车位，这在算法上是“合理”的，但从业务上不一定是“正确”的。要处理这类问题，需要额外的车位约束逻辑，比如“同一时间只有相邻车位中IoU更大的车位判定为占用”，这属于系统优化方向，毕设做到这个程度已经是加分项了。

6.3 性能优化：把帧率从卡顿到流畅

如果你手上的电脑配置一般，运行过程中发现画面卡顿，可以按优先级尝试这几个优化手段：

• 换更轻量的模型。yolov8n.pt比yolov8s.pt体积小一半多，推理速度提升一倍，显存占用也更少。把detector.py里初始化模型的路径换成yolov8n.pt即可，其它代码不用改。
• 降低输入分辨率。在predict里设置imgsz=480，虽然检测精度会略降，但推理速度能提高30%以上。
• 跳过视频帧。不是每一帧都需要参与推理，可以设置“每隔2帧推理一次，中间帧直接复制上一帧的结果”。这种方式对停车监控这种低频变化的场景特别有效，帧率能直接翻倍。
• 开启TensorRT或ONNX导出。如果后续有部署需求，model.export(format="engine")可以导出TensorRT加速引擎，在支持显卡上推理速度还能再上一个台阶。但这一步对毕设来说不是必须的，属于锦上添花。

7. 项目扩展方向与个人心得

做完这套系统之后，如果你的时间还有富余，我建议在下面几个方向挑一个做扩展，无论是写在论文里还是面试时聊起来都会很有分量：

• 增加车位引导功能。在统计到空位后，用算法给出“距离入口最近的空位”推荐，这需要加入路径规划或者简单的BFS寻路，从纯检测变成了应用决策。
• 增加数据库存储。把每一帧的剩余车位数据存入SQLite或MySQL，按时间段分析车位利用率，生成统计报表。这个方向让系统从“演示工具”变成“管理平台”，功能性跃升了一个档次。
• 增加Web端展示。用Flask或FastAPI把检测结果封装成HTTP接口，前端用一个网页展示实时画面和车位状态。这一改动能让系统具备远程访问能力，答辩演示时用手机就能看到效果，比在现场跑来跑去有说服力得多。
• 换一个应用场景。这套代码框架最大的价值在于它的通用性：把车位多边形换成“工位区域”“球场场地”“教室座位”，把车辆检测换成对应目标，就能迁移到另一个实际场景中。这种“举一反三”的能力，比单做一个项目更能表现出你的工程能力。

最后再分享一点个人体会。很多同学拿到源码的第一反应是“能不能直接不改就交”，我特别不建议这么做。倒不是说要推翻重写，而是你至少要把每一个模块都读懂、能在代码里定位到对应位置、能回答出“如果我想增加一个卡车类别应该改哪里”“如果我想改变车位判定阈值应该改哪里”。答辩时老师最喜欢问的就是这类问题。这套系统的设计初衷也不是让你拿去做一个“黑盒演示”，而是希望通过它把目标检测的完整工作流串起来——当你跑通训练、部署、界面、调优这一整套流程之后，再去看其它的视觉项目，思路会清晰很多。

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