企业官网建设流程全解析

1. 从一次意外聊起：跌倒检测为什么值得做，以及为什么选 YOLOv8

先说个我亲眼见到的场景。某高校实验室做智慧养老课题，他们最初用的是可穿戴设备方案——手环、挂坠、腰带里塞加速度传感器。结果落地时发现几个很现实的问题：老人洗完澡忘记戴、晚上睡觉摘下来、设备没电了也不知道，最关键的是，如果老人摔倒时设备不在身上，这套系统就等于零。后来他们转向视觉方案，用摄像头做跌倒检测，才算是把覆盖率这个问题解决了。也正是这个项目，让我开始认真做基于 YOLOv8 的跌倒检测系统。

这套系统说白了就是：用深度学习模型对视频画面进行实时推理，识别画面中的人是否处于跌倒状态，一旦触发就告警。适合谁用？搞智慧养老、医院病房监控、独居老人看护、工地安全监测的人都用得上。对开发者来说，它还是一个非常典型的 YOLOv8 落地练习题——从数据集准备、模型训练、再到 UI 界面封装，整个流程走一遍，你对目标检测项目的完整链路就会非常熟。

为什么最终选 YOLOv8 而不是 Faster R-CNN、SSD 或者其他两阶段模型？几个维度对比下来很清晰。YOLOv8 是单阶段检测器，一次前向传播同时输出类别和框位置，推理速度快，在普通消费级 GPU 上能做到实时；而两阶段模型精度虽高，但速度明显跟不上视频流场景。YOLOv8 的另一个优势是生态成熟——Ultralytics 官方仓库提供了从训练到导出的完整工具链，文档齐全，遇到问题搜一下基本都有答案。还有一点很实际：它把 Anchor-Free 机制、C2f 结构和损失函数优化都整合好了，你不需要自己从头搭网络，拿来改改就能用，这对绝大多数应用型项目来说是最高效的路径。

不过我得先把话说在前头，跌倒检测这个任务，难的不是训练出一个 YOLOv8 模型——现在目标检测模型已经相当成熟，跑通一个 Demo 太容易了。真正的难点是：怎么定义"跌倒"？怎么让模型在真实场景下误报少、漏报少？怎么把模型封装成一个非技术人员也能用的系统？这些才是这个项目真正花时间的地方。这篇文章我就按这个思路来，把数据、训练、界面、部署、避坑，一条线讲透。

2. 数据才是这个项目的地基：跌倒样本的获取与标注策略

很多新手拿到 YOLOv8 第一件事就是 pip install ultralytics 然后跑官方预训练权重，但做跌倒检测不能这么玩。COCO 数据集里的 80 个类别只有 person，没有 fall 这个类别；而且跌倒的形态和正常站立、弯腰、蹲下有本质区别，直接用预训练模型是没法区分这些动作的。你必须有专门的跌倒数据集，或者自己标注，这决定整个项目的上限。

2.1 数据集来源：公开数据集与自采数据怎么搭配

跌倒检测领域有几个公开数据集值得关注，比如 UR Fall Detection Dataset、Le2i Fall Detection Dataset、Multi-Camera Fall Dataset。这些数据集的特点不同，UR Fall 是双视角、传感器和视觉同步采集的，Le2i 有多个场景（办公室、房间、楼梯等），Multi-Camera 则提供了多机位视角。我的建议是：别只用其中一个，最好两个以上混合使用。

混合的原因是单一数据集的场景太单一。UR Fall 的场景背景比较干净，如果没有其他数据辅助，模型到了光线复杂、家具更多的真实环境就很容易误判。Le2i 里包含了一些日常动作的负样本，这对降低误报很关键。我的做法是把 UR Fall 和 Le2i 的部分视频都下载下来，抽帧之后混在一起，再补充一部分自己录的模拟跌倒数据。公开数据集做底座，自采数据做场景适配，这样数据分布会更接近实际使用环境。

自采数据这事听起来麻烦，其实没那么夸张。不需要专业演员，找两三个同学在办公室、走廊、家里不同场景模拟跌倒就行。正常走路、弯腰捡东西、坐下、蹲下、躺在地上、从椅子上滑落，都要各录一些。重点是要把"跌倒"和"类似跌倒但不是跌倒"的样本都覆盖到，因为这些边界样本才是模型后期表现好坏的分水岭。

2.2 标注策略：一个框还是两个框？跌倒状态的判定逻辑

目标检测的标注在跌倒检测里有个常见分歧：跌倒过程中的中间状态（比如正在倒地的那一瞬）算不算跌倒？有人只标两个类别——person 和 fall，fall 这个类别负责框住倒地的人。有人则会设置三个类别——stand、bend、fall，用姿态动作来区分。我个人的实践结论是：采用 person + fall 两个类别就够了，但要把"跌倒后已倒地"和"正在倒地"都归入 fall 类别，判定逻辑放在后处理里做。

为什么？因为 YOLOv8 是目标检测模型，它本质上是在做"空间上的识别"，不是时序建模。它擅长的是告诉你"这个区域内有一个处于跌倒姿态的人"，而不是判断"刚才那个人是不是摔倒了"。所以你要做的，就是把标注工作做好，告诉模型跌倒姿态长什么样。具体标注的时候有一个技巧：人在画面里面积很大，几乎横躺在地板上，框要尽量贴合人的外轮廓，头顶和脚底都要包住；如果人被椅子或桌子遮挡了一部分，框可以适当放大一些，宁可让 IoU 稍微低一点，也别把肢体切掉。

这里还有一个多数人容易忽略的细节——负样本的标注。所谓负样本是画面里有 person，但并没有跌倒。这类样本同样要标注，类别就标 person。因为如果你只提供跌倒样本，模型会倾向于把所有"躺下"的姿态都识别成跌倒，包括午休躺在沙发上、瑜伽垫上做拉伸。负样本的数量建议占全部样本的 30% 以上，场景越杂越好。

2.3 数据增强：不要过度依赖，但有几个必用的操作

YOLOv8 训练时默认会做马赛克增强、随机平移、缩放等操作，这些默认配置对大多数场景够用。但针对跌倒检测，我额外启用了几个增强：随机亮度对比度调整（模拟不同光线条件）、随机旋转（±15 度以内）、随机裁剪加缩放（模拟摄像头安装高度和角度差异）。HSV 色域增强也建议打开，因为实际部署环境中的摄像头色彩偏差很常见。

有一点要提醒：旋转角度别设太大。跌倒检测对"人横躺在地上"这个姿态的方向性是有依赖的，如果旋转超过 30 度，样本形态会失真，模型反而学坏。我自己走过的弯路就是一开始把角度设成 90 度，训练出来的模型对斜躺的人特别敏感，但正常站着的人稍微倾斜一点就被误报成跌倒。后来把增强参数调温和之后，这个问题就消失了。

标注工具我推荐用 LabelImg 或者 X-AnyLabeling，前者轻量、老牌，后者支持自动标注辅助（用预训练模型先标一遍人工修正），效率更高。数据格式转成 YOLO 的 txt 格式即可，Ultralytics 官方对数据集的目录结构有约定，按它的格式组织就行。标注完记得做一轮数据校验，用脚本检查有没有漏标、框坐标有没有越界，这一步能省掉后面训练时 Debug 的不少时间。

3. 训练环节的把控重点：不至于跑通，关键要跑得稳、测得出

YOLOv8 的训练本身已经非常傻瓜化，一条命令就能启动。但如果只是把官方示例代码改个数据集路径就开跑，大概率会遇到训练收敛不稳定、验证集指标虚高但实际测试一塌糊涂的问题。这一节我讲几个训练里最核心、也最容易被忽略的把控点。

3.1 硬件配置与合理的 Batch Size 选择

YOLOv8n 这种轻量模型，说实话 CPU 也能跑推理，但训练还是建议用 GPU。CUDA 环境配好之后，最关键的一个参数是 batch size。Batch size 不是越大越好，它受显存、学习率、数据集规模三个因素共同制约。我的建议是：显存允许的前提下，batch size 取 16 或者 8 都可以，关键是学习率要跟着调。Ultralytics 默认的 lr0 是 0.01，这个值对 batch size 32 是合理的；如果你的 batch 只有 8，最好把学习率降到 0.005 左右，否则 Loss 曲线会很躁。

很多人会忽略的一个细节是图片分辨率。YOLOv8 默认训练尺寸是 640×640，这个分辨率对跌倒检测够用，但如果你希望模型能识别远距离的小目标（比如监控画面里人比较小），建议把 imgsz 设为 960 或者 1280 训一轮对比一下。代价是训练时间和显存占用明显上涨。我的经验是：先跑 640 的基线，看验证集 mAP，再根据实际部署相机的视角和人体的像素占比决定要不要升分辨率。

3.2 训练轮数与 Loss 曲线的正确解读方式

训练轮数我建议至少 100 epoch。YOLOv8 训练过程中会周期性评估验证集，保存表现最好的权重。很多同学只看最终 mAP 数字，我建议大家把训练过程中的三条曲线拉出来看：box_loss、cls_loss、dfL_loss。如果 box_loss 在最后 20 轮还在明显下降，说明还没完全收敛，加轮数有用；如果已经平了，再加轮数只会过拟合。cls_loss 如果在训练集上降到 0.02 以下但验证集上不降反升，基本可以确定过拟合了，这时候要加数据增强或者调 dropout。

一个很典型的坑是：训练集 Loss 很低，验证集 mAP 也很好，但拿去测真实视频，发现漏检严重。这通常是因为数据集的分布和真实场景差异太大——比如训练数据里人都是完整出现在画面中央，而真实监控里人可能被家具遮挡、视角很偏。解决方法是采集一些"刁钻"样本补充进训练集，而不是盲目调模型参数。

3.3 权重导出与推理前的预处理链

训练完成之后，pt 权重可以直接在 Python 里调用，但为了部署效率，我建议导出成 ONNX 再跑推理。导出命令很简单，model.export(format="onnx", half=True)。ONNX 格式有两个好处：一是你可以用 ONNX Runtime 跑推理，不需要装 PyTorch 全家桶，部署体积小很多；二是后续如果要转到嵌入式设备或者用其他语言调用，ONNX 是中间桥梁。

推理前的预处理有几个固定动作：BGR 转 RGB、resize 到模型输入尺寸（保持纵横比的 letterbox，不是粗暴拉伸）、归一化到 0-1。很多人就在 letterbox 这里栽跟头——如果直接拉伸图片到 640×640，人体比例会变形，检测精度会明显下降。letterbox 的思路是等比缩放后用灰色填充边缘，这样保持画面内容不变形。后处理则需要做 NMS 非极大值抑制，把同一个目标的多余框合并掉，然后根据置信度阈值过滤。YOLOv8 输出的原始张量是 (1, 84, 8400) 这种格式，8400 个候选框，不处理的话没法直接用，这部分代码建议自己手写一遍，对理解模型输出结构非常有帮助。

4. 语义上的"跌倒"与模型输出的"跌倒"：判定策略与边界情况

模型出来的是一个框和置信度，它告诉你画面上这个人已经有很高概率处于跌倒姿态。但作为一套跌倒检测系统，你真正要回答的问题是：这个状态是否值得发出告警？这两者之间有落差，而这个落差就是用后处理逻辑去填的。

4.1 单帧判定为什么不够稳：帧间稳定性与去抖

直接拿单帧的检测结果决定要不要报警，是新手最容易犯的错误。因为单帧检测有天然的抖动：人弯腰系鞋带、从椅子侧面滑下去瞬间、甚至画面里有只大狗俯身，都可能造成某一帧的误检。我更推荐的做法是加一个帧间计数逻辑：连续 N 帧都检测到 fall，且置信度都高于阈值，才触发告警。N 的取值取决于你的视频帧率——25fps 的摄像头，连续 3 帧大概就是 0.12 秒，这个时间足够滤掉大部分瞬时抖动，又不会让报警延迟到不可接受。

再进一步，可以对置信度做一个滑动窗口平均，而不是用单帧的置信度直接判断。窗口内 5 帧的置信度均值高于阈值，就判定为跌倒。这个策略更平滑，但缺点是延迟会略微增加，毕竟要积累 5 帧。我实际项目里用的是"连续 3 帧阈值 + 窗口均值复核"的组合：先用快速路径做初筛，再用平滑路径做确认，测试下来误报率比单帧判断降低了 60% 以上。

4.2 跌倒后的持续性判断：与此前状态对比

还有一种边界情况：人跌倒之后躺在地上不动了，这时候模型仍然会持续输出 fall。那系统是不是要一直报警？这得看产品需求。如果只是"跌倒即告警"，那一帧触发就够了；如果还想知道"人是否长时间倒地不起"，那就需要记录跌倒状态持续的时间，超过设定时间（比如 30 秒）升级为紧急告警，自动拨打急救电话或者通知家属。这个逻辑可以在 UI 层做，也可以在后处理逻辑里做。

我还见过一个有意思的优化思路：判断跌倒前的人体轨迹。如果模型先稳定输出了若干帧 person（正常状态），然后突然变成 fall，这种状态切换比直接出现 fall 更可信。毕竟画面里不可能凭空出现一个倒地的人，正常流程一定是"站着 → 倒地"。用这个状态机的思路做判定，能显著减少那种"画面里本来就有一个人躺在地上"带来的持续误报。

4.3 置信度阈值怎么调：平衡漏报与误报的实用方法

置信度阈值是每个做检测系统的人都要面对的取舍。阈值设高了，误报少，但真跌倒时可能检测不到；设低了，漏报少，但经常误响。我的调参方法是：先拿 20 段真实场景视频做测试集，里面既有正常活动，也有模拟跌倒。阈值从 0.2 开始，每步加 0.05，分别统计漏报率和误报率，画一条曲线，找两者交叉点附近的值。根据我自己的项目经验，0.4-0.5 之间通常是比较合理的区间，具体要看部署环境的光线条件和摄像头安装高度。光线暗的场景建议阈值调低一点，因为黑暗中模型的置信度普遍偏低；光线好的室内，阈值可以调到 0.5 以上减少误报。

UI 界面里可以把这个阈值做成一个可调的滑杆，不要写死在代码里。部署到现场之后，维护人员可以根据实际情况随时调整，这是非常实用的设计。

5. UI 界面与系统集成：把模型变成非技术人员也能用的工具

模型训练好了、判定逻辑写完了，但如果你只交付一个跑在 Jupyter Notebook 里的脚本，那这项目基本没法落地。真正的交付物应该是一个图形化界面的应用，操作人员打开就能看到摄像头画面、看到检测结果、收到报警通知。这部分的工程量不亚于模型本身，很多人恰恰在这个环节翻车。

5.1 技术栈选型：PySide6 + OpenCV + ONNX Runtime 组合

UI 我推荐用 PySide6（Qt for Python），它是 LGPL 协议的，商用友好，控件丰富。配合方案是：PySide6 负责界面，OpenCV 负责视频流读取和画框，ONNX Runtime 负责模型推理，pyttsx3 或 QSoundEffect 负责报警音。这套组合的好处是所有库都是 Python 生态的，不需要跨语言编写，后续维护和扩展都很灵活。

选 PySide6 还有一个重要原因是它自带 QThread 机制。视频推流和模型推理都是重操作，如果直接放在主线程里会导致界面卡死、摄像头画面一帧一帧地跳。正确做法是：主线程只处理界面事件，视频采集和推理放到后台线程，通过信号（Signal）把检测结果传给主线程刷新画面。QThread + Signal/Slot 是 PySide6 的标准解法。

5.2 界面布局与核心交互逻辑

我的界面布局通常是这样的：左侧占画面的大部分，是实时视频显示区域（QLabel 渲染，用 OpenCV 处理后的帧转 QImage 显示）；右侧是控制面板——包含摄像头源选择（本机摄像头或者 RTSP 网络流）、置信度阈值滑杆、报警开关、日志信息区；底部是状态栏，显示当前检测帧率、模型推理耗时、是否处于报警状态。

交互逻辑上，一个重点是报警触发后的状态表现：检测到跌倒时，视频画面里目标框变为红色，同时弹窗或者闪动报警提示，并播放警报音。这里有个细节：报警要有"确认"按钮，点击确认后停止当前报警。这个按钮很关键——如果没有人工确认机制，报警会持续触发，维护人员会被报警音逼疯。我见过有项目的报警音没法关闭，最后现场直接把电源拔了，系统形同虚设。

日志区别忽略。建议把每次检测的帧号、时间、置信度、报警标志都记录下来，存成 CSV 或者 SQLite。这个日志有两个作用：一是后续分析误报率、漏报率时有据可查；二是如果用户投诉"系统误报了"，你能直接追溯是哪一帧触发的，大大提升系统的可信度。

5.3 多摄像头与视频流的扩展思路

单摄像头版本是起点，但实际项目里经常要接多路视频。我的处理方法是把每个摄像头抽象成一个CameraWorker线程对象，内部维护自己的推理队列，检测结果独立推送。UI 层用 QTabWidget 或 QGridLayout 的网格布局来展示多路画面。这里要注意：每路视频流的推理是独立的，线程数不要无脑开，要看 CPU/GPU 的算力上限。消费级 GPU 上 YOLOv8n 推理一帧大约 5-10 毫秒，接 4 路 25fps 的流没问题，但如果是 8 路以上，建议在采集端降低帧率（比如每 2 帧推理 1 帧），否则算力会成瓶颈。

接入 RTSP 流时，OpenCV 的cv2.VideoCapture直接拉流偶尔会卡顿，解决办法是设置缓冲区和超时参数。代码写法是：

cap = cv2.VideoCapture(rtsp_url, cv2.CAP_FFMPEG) cap.set(cv2.CAP_PROP_BUFFERSIZE, 1) cap.set(cv2.CAP_PROP_OPEN_TIMEOUT_MSEC, 5000) cap.set(cv2.CAP_PROP_READ_TIMEOUT_MSEC, 5000)

把缓冲区设为 1 表示只保留最新一帧，避免延迟累积——这对于实时监控非常重要。

6. 实测环节与避坑实录：训练很顺利，部署才是真考验

模型训练完之后，我拿着做好的系统到真实环境里去测，结果问题比想象中多得多。这里我挑几个最典型的踩坑过程完整复现一遍，每一个都是血泪教训，你在做类似项目时大概率也会遇到。

6.1 问题一：画面里的人物被误判成跌倒，原因居然是人的比例问题

第一次实测时，镜头安装在 3 米高的墙角，俯视角度大约 30 度。模型对画面中央的跌倒检测正常，但每当有人从镜头正下方经过时，系统就疯狂报警。排查了很久，才意识到问题出在"透视比例"上——正下方经过的人，在画面的成像里身体被严重压缩，加上俯视角度导致头肩比例看起来怪怪的，模型把这种"压缩的人形"误判成了跌倒姿态。

解决思路有两个方向。一是从数据侧解决：在训练集里加入一些俯视角度、近距离大比例的人体样本，让模型见过这种形态；二是从后处理侧解决：利用 bounding box 的宽高比做约束，正常站姿的人宽高比接近 0.3-0.5，跌倒横躺的人宽高比会大于 1，如果检测框的宽高比明显不符合跌倒的特征，就降低该帧的判定权重。我把两者都做了，误报率才真正降下来。这个案例说明了一个道理：模型输出永远只是参考，产品逻辑必须建立在对场景的深度理解上。

6.2 问题二：OpenCV 窗口显示卡顿，帧率掉到 10fps 以下

项目最初版本是在主线程里直接做"读取帧 → 推理 → 画框 → 显示"这套循环。跑起来之后性能惨不忍睹，推理本身只要 15ms，但界面帧率却只有 8fps。拆解之后发现瓶颈在imshow这个函数——它没有双缓冲机制，每次刷新都要等图像数据从后台线程拷贝到 UI 线程，再加上 Qt 的事件循环和 OpenCV 的 HighGUI 窗口互相抢资源，表现就是画面不断闪烁、卡顿。

我后来彻底放弃了cv2.imshow，改用 PySide6 的 QLabel 渲染。思路是：后台线程把带标注的帧转成 RGB 格式，再用 QImage 封装后通过 Signal 发给主线程，主线程槽函数里label.setPixmap更新画面。这个改动看起来不起眼，但性能提升非常明显，25fps 的视频流可以稳定跑到 22fps 左右，界面也顺滑了。各位如果在做类似项目，千万记住：显示环节不要用 OpenCV 原生窗口，它在 Qt 应用里是个坑。

6.3 问题三：导出 ONNX 后推理结果和 PyTorch 不一致

用 ONNX Runtime 推理时发现同样的输入图片，ONNX 输出的检测结果竟然比 PyTorch 差了很多——该检出的框没检出，置信度也低了一截。排查过程比较折磨：先怀疑是预处理不一致，代码一行行对比；又怀疑是 NMS 参数不同，也调了；最后发现是letterbox 的填充方式问题。PyTorch 的 Ultralytics 推理里使用的是灰色 114 填充，但我在预处理代码里写成了 0 填充，导致输入分布偏移，模型表现自然变差。

这个问题非常隐蔽，因为模型不会报错，只会静默地变差。建议大家在写预处理代码时，一定要去查官方实现里用了什么填充值、什么归一化方式，逐行对齐。我最终是把 Ultralytics 的预处理逻辑完整扒出来对照着写，才算彻底解决。

7. 性能优化与部署落地：从能跑到跑得稳、跑得快

系统能跑通只是第一步，离"能部署"还差得远。真实场景对稳定性、延迟、资源占用都有要求。这里整理几个我在优化过程中最有参考价值的实践。

7.1 推理加速：用 TensorRT 还是 ONNX Runtime？

如果部署环境有 NVIDIA GPU，TensorRT 的推理速度比 ONNX Runtime 快很多，实测下来 YOLOv8n 在 TensorRT FP16 模式下推理一帧只需要 2-3 毫秒，相比 ONNX 的 8-10 毫秒是质的提升。代价是 TensorRT 的 engine 文件跟 GPU 型号绑定，换一台机器就得重新构建，部署稍微麻烦。如果视频路数不多、帧率要求也不高，ONNX Runtime 其实就够了，毕竟它能直接用 CPU 跑，兼容性最好。

我的经验是分场景选择：给客户演示用 ONNX Runtime（省事，哪里都能跑），正式上线且服务器 GPU 型号固定的，用 TensorRT。YOLOv8 官方导出命令支持 TensorRT，model.export(format="engine", half=True)，但前提是你得装好 TensorRT 的 Python 包。还有一个选择是 OpenVINO，如果你的部署环境是 Intel CPU，它的加速效果很明显，而且不需要 GPU。

7.2 内存与线程：长时间运行的稳定性保障

视频监控系统通常要 7×24 小时跑，内存泄漏是最大的隐形杀手。Python 里最典型的内存泄漏来源是：OpenCV 的 Mat 对象没有及时释放、Qt 的 QImage 反复创建没有回收、日志文件句柄没关。我的做法是：每处理完一帧，显式del掉不再使用的数组，定期用gc.collect()回收；QImage 创建后及时释放；日志用 logging 模块的 RotatingFileHandler，按文件大小轮转，防止日志无限膨胀。

另一个常被忽略的问题是线程的异常处理。后台线程如果在推理时抛了异常，线程会直接挂掉，而界面还显示正常，但画面已经冻住。我建议在线程的run方法里包一个 try-except，捕获异常之后通过 Signal 发回主线程并弹窗提示，同时自动重启该工作线程。这种兜底逻辑看着不起眼，但真正救了无数次现场。

8. 扩展方向：跌倒检测只是起点

这套系统做完之后，我发现它其实是一个通用的"人员行为分析"框架。换数据集、换检测类别，就能迁移到其他场景。有几个方向我觉得特别值得延伸。

8.1 从识别跌倒到识别跌倒过程：引入姿态估计

YOLOv8 系列里有姿态估计模型（YOLOv8-pose），如果把它和检测模型同时跑，可以提取出人的 17 个关键点坐标。有了关键点，判断跌倒可以比单纯依赖检测框更精准——比如通过髋关节和肩关节连线的角度变化、头部中心点的垂直下落速度，来判断"是否正在摔倒"。这个思路不但能做跌倒检测，还能做跌倒预警：在老人重心开始失稳的瞬间提前告警，给干预争取时间。当然，两个模型同时跑的算力开销更大，落地前得做权衡。

8.2 从单人场景到多人、多楼层场景

很多实际项目是养老院整层楼部署，一个镜头里可能同时出现多人。这个不难，因为 YOLOv8 天然支持多目标检测，它会同时输出画面里的所有人。真正的难点是多人互相遮挡时的判定——A 挡了 B 的一半身体，B 的框不稳定，导致检测结果跳变。常规做法是加上目标跟踪（比如 ByteTrack 或 DeepSORT），给每个检测到的目标分配 ID，让判定基于"这个 ID 的历史状态变化"，而不是每一帧重新判断。跟踪一上来，系统就从一个"检测器"升级为"监控系统"了。

8.3 边端部署：从 PC 到嵌入式设备

如果最终目标是装在家庭环境里，不可能每户人家都配一台带 GPU 的 PC。更合理的方案是把模型部署到边缘设备上。YOLOv8n 模型本身很小（大约 6MB），经过量化之后可以部署到很多边缘计算设备上。把推理跑在边缘端，只把告警结果推送到手机或者平台端，这样既保证了实时性，又保护了隐私——视频流不出本地，这对家庭场景来说是极大的加分项。如果对边缘设备部署感兴趣，可以往这个方向深入研究。

我在做这个项目过程中的体会是：YOLOv8 确实把目标检测的门槛拉得很低，但把它做成一个真正能用的系统，工夫全在模型之外——数据的边界、后处理的策略、UI 的交互设计、部署的稳定性。每一个环节都有自己的学问，没有哪个可以真正跳过。

最后分享一个小技巧：项目调试阶段，把所有检测结果（包括置信度、框坐标、帧号）都保存下来，定期回放错误案例，调整阈值和逻辑。这套"数据反馈 → 策略修正 → 再验证"的闭环，比任何参数调优都有效。