老年人跌倒这事儿真不是小概率事件。我家里有长辈独居最怕的就是接到电话说摔了一跤——但更怕的是摔完之后没人知道。卧床一小时和一整夜后果完全两码事。所以当时我给自己定了个小目标搞一套能实时盯着、跌倒自动报警的东西。调研一圈下来决定用AI视觉方案具体就是 YOLOv8-Pose 做人体姿态估计再从姿态序列里判断跌倒行为。这篇就从头到尾聊聊这套系统怎么做出来的模型怎么选跌倒怎么判部署在什么硬件上以及那些不跑一遍绝对不知道的坑。YOLOv8-Pose 是 Ultralytics YOLOv8 系列里专门做姿态估计的模型它能从图像里同时检测出多个人体框和每个人 17 个关键点的坐标。拿它做跌倒检测的好处很直接不需要老人佩戴任何设备摄像头覆盖范围内被动识别而且是看到姿态变化来推理不是靠红外或者雷达猜。这套方案适合想做智慧养老、独居老人看护、医院或养老院风险区域监控的朋友也适合想在边缘设备上跑实时视觉检测的开发者。下面内容我会从方案选型、模型结构、跌倒判定算法、工程实现到实测数据和避坑经验按一条完整的落地链路来讲保证你照着能复现出来。1. 为什么我不选穿戴设备、红外传感器最终锁定AI视觉方案先说结论不是穿戴设备不好而是它解决不了老人不戴这个终极难题。市面上很多手环、项链式跌倒报警器理论上一键呼救、自动检测都挺成熟但实际用起来老人洗澡要摘、睡觉要摘、嫌硌不戴、忘了充电各种情况下来设备在关键时候压根不在身上。我身边就有真实案例家里给老人配了手环结果老人摔倒那天手环正放在床头柜上充电。红外传感器和雷达方案我也对比过。被动红外PIR只能探测有没有人动一旦老人倒地不动它反而判定为无人毫米波雷达能测姿态和微动但价格偏高而且对非视距环境下的姿态细节还原能力有限把人倒在地上和人蹲下捡东西区分开的精度目前还不太够。所以最终锁定了AI视觉方案核心原因有三个非接触式部署摄像头装在天花板或墙角老人没有佩戴负担不用改变生活习惯。信息维度足够相比雷达点云或红外热像RGB图像能提供最丰富的人体姿态线索关键点坐标可以精确到四肢、躯干、头部。可解释性强通过关键点计算的中心点高度躯干倾角头部速度等特征每一条告警都能回溯到具体画面方便家人确认减少误报带来的狼来了疲劳。而且视觉方案里我特意选了姿态估计Pose Estimation而不是直接做跌倒检测的分类模型核心逻辑后面细说。1.1 传统方案的软肋可用性比精度更致命做老人看护类产品最怕的不是系统不够灵敏而是用户不用。穿戴设备的佩戴率和充电习惯直接决定了系统真实可用性。我见过不少项目方在PPT里写识别率99%但现场一问老人在家根本不戴那些设备识别率再高都是零。视觉方案也有自己的前提需要安装摄像头涉及隐私问题。这个必须在部署时跟老人和家属说清楚——只做姿态分析和跌倒告警画面可以做本地化处理甚至人体关键点渲染模式而不是一直把视频传到云端。后面工程实现部分我会讲怎么在保护隐私的前提下做实时分析。1.2 姿态估计比端到端跌倒分类强在哪一开始我也想过更省事的方案直接训练一个二分类模型输入视频帧输出跌倒/正常。但实际做下来发现几个绕不开的问题跌倒本身是个长尾事件真实跌倒视频数据极度稀缺端到端模型容易过拟合到某个场景的跌倒换个房间就不灵了。没有中间语义信息出误报时完全不知道模型为什么判定跌倒没法调试。端到端方案通常输入要连续多帧3D-CNN、Transformer结构在边缘设备上算力开销大实时性很难保证。姿态估计路线是先理解再判断先用 YOLOv8-Pose 把每帧每个人的关键点坐标提取出来然后基于关键点序列构建几何特征高度、角度、速度再交给一套人工设计的判定逻辑或轻量分类器去判断跌倒。这样每一步都可解释、可调试、可优化而且关键点提取模型可以复用——不仅能做跌倒检测还能做久坐提醒、异常姿态等更多延伸功能。2. YOLOv8-Pose网络结构拆解那些关键点坐标是怎么从图像里长出来的要真正用好 YOLOv8-Pose不能只停留在调库跑demo的层面得搞清楚它内部是怎么把一张图变成一组关键点的。这样后面做推理加速、模型裁剪和精度调优才有的放矢。2.1 Backbone Neck Decoupled Head 三段式YOLOv8-Pose 的整体结构延续了 YOLOv8 的通用设计分成三部分Backbone主干网络默认是 CSPDarknet 结构负责从原始图像中提取多尺度特征图。YOLOv8 把旧版 C3 模块换成了 C2f 模块C2f 借鉴了 ELAN 的思想通过更多分支的跨层特征融合来提升梯度流动在相同算力下特征表达能力更强。简单理解Backbone 就是把图像翻译成一层层越来越抽象的特征图——浅层特征关注边缘、颜色深层特征关注这是一个人的手臂这是一个头这种语义。Neck特征融合层采用 PAN-FPN 结构把 Backbone 提取的多尺度特征从下到上、从上到下反复融合。为什么要融合因为人体有大有小——老人坐在沙发上时目标很小靠近摄像头时目标很大只有把浅层细节和深层语义结合起来才能同时保证大小目标的检测和关键点定位精度。Head检测/姿态头YOLOv8 最大的变化之一是把之前的耦合头换成了解耦头Decoupled Head分类分支和回归分支分开。YOLOv8-Pose 的 Head 在目标检测的基础上额外增加了一个姿态回归分支输出每个检测框内人体的关键点坐标和可见性。每一层特征图上的每个位置都有预设的 anchor-free 预测机制直接回归目标框的中心点、宽高和关键点偏移。有个特别有意思的细节YOLOv8-Pose 的损失函数里分类分支用的 BCEBinary Cross Entropy回归分支用的 DFL CIoU而关键点分支用的是 OKS 变体的损失。这意味着模型在训练时会综合权衡检测框准不准、关键点位得准不准而不是只优化其中一个。2.2 17个关键点定义了一个人COCO 数据集的 17 个关键点可以看作人体姿态的通用语义骨架编号关键点编号关键点0nose鼻子9right wrist右手腕1left eye左眼10left hip左髋2right eye右眼11right hip右髋3left ear左耳12left knee左膝4right ear右耳13right knee右膝5left shoulder左肩14left ankle左踝6right shoulder右肩15right ankle右踝7left elbow左肘16right pelvis右盆骨8left wrist左手腕这里需要提一句Ultralytics 实际输出时最后一个关键点是 pelvis也就是盆骨中心点它是根据左右髋部插值得到的一个虚点这个点在做跌倒判定时非常有用因为髋关节高度直接反映了人体重心的大致位置。每个关键点输出 (x, y, confidence)其中 confidence 表示模型对这个点位置的置信度。实战里我会利用这个置信度做预处理——如果一帧里某人的关键点平均置信度低于 0.5基本可以认为检测质量不可靠宁可跳过这帧不参与判定也不能因为它触发误报。2.3 模型尺寸选择n/s/m/l 怎么选YOLOv8-Pose 提供了几种尺度的模型区别主要在 Backbone 和 Head 的通道数、层数直接决定了速度与精度的平衡模型输入分辨率参数量算力GFLOPs适合场景YOLOv8n-pose640x640约3.3M约9.6树莓派、手机、低功耗边缘盒YOLOv8s-pose640x640约11.2M约29.6Jetson Nano/NX、普通CPU服务器YOLOv8m-pose640x640约26.4M约79.3Jetson Orin、中端GPUYOLOv8l-pose640x640约53.9M约167.8高性能GPU服务器我做这套跌倒检测系统时最终选的是 YOLOv8s-pose 在 NVIDIA Jetson Orin Nano 上跑——模型不大不小还能剩出算力做其他预处理。如果只是在家里用一台普通电脑跑实时检测也可以从 YOLOv8n 起步。一个经验不要一上来就用最大模型先跑通流程再逐步升级看精度收益是否值得。3. 跌倒判定核心算法从一条条关键点坐标变成可靠告警模型输出 17 个关键点的坐标之后真正难的来了怎么从这些坐标判断这个人是不是摔了一开始我天真地想是不是中心点高度突然降到很低就是跌倒真跑到实际画面里试才发现老人弯腰捡东西、坐在沙发上、蹲下系鞋带中心点高度也会瞬间下降如果只按中心点高度阈值判那每天能误报几百次。3.1 几何特征提取把关键点翻译成物理量我设计姿态特征时参考了学术界跌倒检测论文里常用的人体运动学特征同时结合工程可计算性做了简化。核心特征整理如下人体中心点髋部中心的世界坐标近似取左右髋部关键点的中点 (hip_x, hip_y)再取左右肩部中点 (shoulder_x, shoulder_y)两者连线中点作为人体主干中心。这个点受四肢摆动影响小比直接用包围盒底部中心稳定得多。头部相对高度nose 关键点的 y 坐标与髋部中心的 y 坐标的差值这个值可以描述人是不是还在直立状态。正常站立时这个差值很大头高脚低倒地时这个差值急剧缩小。躯干倾角肩部中点和髋部中点连线的向量与垂直方向的夹角。站立时接近 0 度倒地时接近 90 度。这是判断躺平最直接的几何量。中心点下降速度连续两帧之间人体中心点的竖直方向位移除以帧间隔时间。跌倒发生时这个速度远大于正常坐下或弯腰的速度。髋部相对地面的高度在不标定的情况下用髋部 y 坐标在画面中的位置结合检测框高度做归一化得到一个 0~1 的相对高度。不同摄像头安装高度、俯仰角下这个值需要做一次性校准。3.2 多帧状态机为什么单帧判断必死无疑跌倒不是一个状态而是一个过程。正常行走的人某一帧的包围盒宽高比也可能突然变化比如抬手、突然蹲下但不会出现完整的站立-快速下降-倒地保持链条。所以我把判定逻辑做成了一个有限状态机分四个状态STABLE稳定态人体中心点高度在正常范围躯干倾角小速度低。系统处于正常监控状态。FALLING下降态检测到人体中心点竖直速度大于阈值且躯干倾角在快速增大。此时系统进入观察窗口连续跟踪后续帧不立刻告警。DOWN倒地态在观察窗口内人体中心点高度下降到低于阈值并且躯干倾角大于某个角度阈值比如 60 度且该状态持续了 1~2 秒。RECOVER恢复态在倒地态之后如果人体重新站起来中心点高度回升倾角变小则撤销告警。这个状态机用 Python 实现大概就是下面这个逻辑简化版class FallDetector: def __init__(self, fall_speed_thresh1.5, down_height_ratio0.4, down_angle_deg60, confirm_time1.5): self.state STABLE self.fall_speed_thresh fall_speed_thresh self.down_height_ratio down_height_ratio self.down_angle_deg down_angle_deg self.confirm_time confirm_time self.fall_start_time None self.down_start_time None def update(self, features, timestamp): # features: dict包含 center_y, vertical_speed, trunk_angle_deg, height_ratio h features[height_ratio] # 髋部相对高度0-1 speed features[vertical_speed] angle features[trunk_angle_deg] if self.state STABLE: # 重心快速下降可能是跌倒开始 if speed -self.fall_speed_thresh: self.state FALLING self.fall_start_time timestamp elif self.state FALLING: # 检查是否进入倒地状态 if h self.down_height_ratio and angle self.down_angle_deg: self.state DOWN self.down_start_time timestamp # 速度恢复且高度没降下去说明是弯腰等非跌倒动作 elif speed -0.3: self.state STABLE elif self.state DOWN: # 持续倒地超时才正式告警 if timestamp - self.down_start_time self.confirm_time: self.state CONFIRMED_FALL # 触发告警逻辑 self.trigger_alert() # 检测到起身 if h self.down_height_ratio 0.15: self.state STABLE # RECOVER/后续逻辑略 return self.state代码本身不复杂但里面几个经验值得展开说为什么速度阈值用负值表示下降因为我定义竖直向下为正方向时垂直向下运动会得到负的速度所以代码里判断speed -threshold才是向下快速移动。为什么倒地确认要持续 1.5 秒因为老人跌倒后如果还能自己爬起来那可能只是轻微摔倒系统可以先提示检测到跌倒但人员已起身而不必向子女发紧急告警。真正需要告警的是倒地持续不动的情况。恢复态判断用了h down_height_ratio 0.15的滞回值是为了防止人在倒地边缘反复横跳时系统颤振——高度刚超过阈值就恢复结果人又躺下去告警会来回触。3.3 低速滑倒和静止倒地怎么补还有一种情况老人不是速度快地摔倒而是先是缓慢坐下然后从椅子上滑落到地上。这种情况下 FALLING 状态可能因为下降速度不够而没有被触发。我在系统里加了一个补充机制——周期健康扫描即使没有检测到快速下降只要人体中心点高度持续低于阈值比如 5 秒以上同时躯干倾角大于阈值也判定为倒地。这个机制代价是会有一小段延时5 秒但是换来的是对滑倒坐空等低速跌倒也有效。我实际测试下来对于老人看护场景5 秒的延时完全在可接受范围毕竟告警的及时性核心是摔倒后几分钟内有人回应而不是摔倒后 0.5 秒内通知。4. 实时系统工程化落地摄像头画面怎么变成一条告警推送模型选好了判定逻辑写好了接下来才是工程上的硬仗要把这套逻辑塞进一个 7x24 小时实时运行的系统里不能崩、不能卡、延迟还不能太高。这部分我细讲一下整个链路以及每个环节的取舍。4.1 视频流采集与抽帧策略视频源方面我用了 RTSP 协议的 IPC 摄像头这是目前安防摄像头最通用的协议。Python 里用 OpenCV 的cv2.VideoCapture可以直接读但这里有个大坑阻塞式读取会导致帧堆积视频延迟越来越高最终画面和实时事件差好几秒。更稳的做法是独立采集线程加队列import cv2 import threading import queue from collections import deque class RTSPCapture: def __init__(self, url, queue_size4): self.url url self.frame_queue queue.Queue(maxsizequeue_size) self.stop_flag False self.thread threading.Thread(targetself._reader, daemonTrue) self.last_frame_time None self.fps_history deque(maxlen30) def _reader(self): cap cv2.VideoCapture(self.url) cap.set(cv2.CAP_PROP_BUFFERSIZE, 1) # 关键减少内部缓冲 while not self.stop_flag: ret, frame cap.read() if not ret: continue # 如果队列满了丢弃最旧的帧保证实时性 if self.frame_queue.full(): try: self.frame_queue.get_nowait() except queue.Empty: pass self.frame_queue.put(frame) cap.release() def get_frame(self, timeout1.0): try: return self.frame_queue.get(timeouttimeout) except queue.Empty: return None这里两个关键细节CAP_PROP_BUFFERSIZE设 1 是减少 OpenCV 内部缓存避免读到几十帧前的旧画面队列大小限制在 4 帧满了丢旧帧优先保证实时性而不是完整性。处理连续帧时如果检测耗时较长就直接丢帧——反正跌倒是个过程中间少一帧不影响判断。4.2 推理加速TensorRT、FP16 和批处理YOLOv8-Pose 官方导出格式支持 ONNX、TensorRT、CoreML、TFLite 等。我在 Jetson 上用的是 TensorRT FP16 精度推理速度比原始 PyTorch 快了不少且精度损失极小。导出和推理的大致流程# 1. 导出 ONNX yolo export modelyolov8s-pose.pt formatonnx opset12 # 2. 在 Jetson 上转 TensorRT trtexec --onnxyolov8s-pose.onnx \ --saveEngineyolov8s-pose.engine \ --fp16如果用 Ultralytics Python 包直接推理也可以用from ultralytics import YOLO model YOLO(yolov8s-pose.engine) # TensorRT engine 文件 results model(frame, device0, halfTrue)如果想要更高的推理效率需要把预处理resize、归一化、letterbox从 Python 端挪到 TensorRT 的预处理层或者手动控制减少 host-device 数据拷贝。对实时系统来说数据拷贝往往比计算更浪费时间。这一点在 Jetson 上尤其明显——CPU 内存和 GPU 显存之间带宽有限一次大图拷贝能吃掉不少延迟预算。4.3 告警触达微信推送比短信更实际告警模块我最终选了企业微信机器人 邮件双通道。企业微信机器人的 webhook 非常简单几行请求就能把文字和图片推送到群里而且免费、稳定、不需要审核比自建 App 的成本低了一个数量级。import requests import base64 def send_alert(image_path, text): # 推送文字图片到企业微信群 img_b64 base64.b64encode(open(image_path, rb).read()).decode() data { msgtype: image, image: {base64: img_b64, md5: } } # 实际使用时需要计算图片 md5并替换为你的机器人 webhook requests.post(WEBHOOK_URL, jsondata)需要注意的是告警动作必须做去重和冷却同一个人的跌倒事件30 分钟内最多推送一次防止家人半夜被同一事件反复轰炸。我的做法是维护一个事件字典索引是摄像头ID人员跟踪ID每次告警后冷却 1800 秒。同时推送文案里附带一张标注了关键点和人体框的截图家人打开微信就能看到家里客厅疑似有人摔倒比冰冷的文字告警安心得多。4.4 人员跟踪与多目标管理YOLOv8-Pose 输出的是当帧所有检测到的人要判断谁一直在画面里就得做跨帧跟踪。我在工程里用了一个轻量方案不需要挂 DeepSORT直接基于关键点的中心点坐标做最近邻匹配——相邻帧之间同一个人的中心点移动距离通常不大用简单的贪心匹配就够。如果两帧之间中心点距离小于某个阈值比如 50 像素就认为是同一个人否则新开一个跟踪 ID。实测发现这个方案对跌倒检测场景足够了画面里一般就 1~2 个人没有复杂的交叉遮挡不需要上 SORT 或者 ByteTrack 这种完整框架。跟踪 ID 还有一个额外价值如果某个 ID 已经在倒地状态那么该 ID 对应的状态机状态可以跨帧保持防止因为检测闪烁导致状态机重置。5. 部署硬件选型与实测效果对比算法和工程逻辑都清晰之后最难的一步是选硬件。我前后测过三类设备普通家用电脑、Jetson 边缘盒子、以及纯 CPU 的低功耗设备。下面表格是完整的对比。硬件平台推理后端分辨率平均帧率功耗成本适用场景i5 台式机GTX 1660PyTorch/ONNX640x64030 FPS200W中开发调试、实验室Jetson Orin Nano 8GBTensorRT FP16640x64025~30 FPS7~15W较高家庭/养老院单路部署Jetson Nano 2GBTensorRT FP16320x32010~15 FPS5~10W较低低成本单路监控树莓派 4BNCNN/ONNX320x3203~5 FPS5W极低原型验证不建议生产实测下来我最推荐的是 Jetson Orin Nano 8GB 版本。它在 640x640 输入下跑 YOLOv8s-pose TensorRT FP16稳定在 25~30 FPS同时功耗只有十来瓦可以长时间挂机。整机要注意散热——不主动散热的 Orin Nano 在持续推理时很快会过热降频帧率会掉到 20 以下。我是在外壳上加了一个 5V 风扇对着散热片吹实测温度稳定在 60 度左右。如果预算有限用 Jetson Nano 2GB 跑 320x320 的 YOLOv8n-pose 也有机会。但这里要提醒一句分辨率和精度是强相关的320x320 输入下人脸和四肢细节会损失很多小目标肢体关键点容易漏检对跌倒判定这种需要精确关键点坐标的任务来说我建议至少用 640x640 输入。树莓派 4B 我也试过接 USB 摄像头跑 ONNX Runtime CPU 推理单帧推理大概 200 多毫秒勉强能做到 3~5 FPS。这个帧率做跌倒检测不是不行但对快速跌倒过程的捕捉会有风险——帧间隔太大可能正好错过关键的下降过程。所以我只推荐用树莓派做原型验证不推荐直接用于老人看护生产环境。6. 实际部署中踩过的坑与调优经验最后这部分聊聊真正让这套系统从demo变成可用系统的经验。这些坑都是在实际运行中一点点发现的比模型选型更重要每条背后都是真实的线上事故。6.1 摄像头安装角度顶装比壁装更可靠一开始我在客厅靠墙位置装了摄像头45 度俯视角度。结果发现当老人面朝沙发坐下时身体躯干会被沙发靠背遮挡关键点置信度直线下降。后来改成顶装天花板垂直向下躯干和四肢的可见性大大提高——因为人在室内天花板视角天然避开了大部分家具遮挡。跌倒检测的最佳安装角度是垂直俯视。虽然这会让人体姿态看起来有点奇怪头大身子小但关键点几乎不会丢失。6.2 夜间低照度补光灯比红外模式更稳带红外夜视的摄像头在夜间会自动切换到黑白模式。实际测试发现红外模式下 YOLOv8-Pose 的检测性能明显下降尤其是深色衣物和阴影区域关键点经常漏检。我对比过几种方案最后选择了带白光补光的全彩摄像头或者用普通的室内照明灯支持全彩夜视的摄像头。老人看护场景夜间开个小夜灯全彩模式姿态检测效果比红外好太多。另外提一句红外对人眼的影响有些老人对红外光敏感卧室里不建议使用大功率红外补光改成低亮度白光暖光补光既不影响睡眠也不影响检测。6.3 遮挡和运动模糊放弃低置信度帧老人跌倒的动作有时候很快在低帧率或运动模糊下模型可能输出一堆低置信度的关键点。我在代码里加了个过滤逻辑如果一帧里某个人的关键点平均置信度低于 0.5就跳过这一帧不让它参与状态机更新。宁可漏掉中间一帧也不能拿错误数据给状态机喂毒。这个策略在实际表现非常关键——没有置信度过滤的时候状态机经常被假关键点触发出现站着突然判下降的误报。加上过滤后系统稳定性高了一个档次。6.4 误报重灾区宠物、影子、电视里的人画面里出现猫狗时模型偶尔会把他们误检成人特别是侧躺的宠物和婴儿姿态相似。家里的扫地机器人、窗户上的光影、电视里播放的人物画面都可能造成误检。我做了三层防护最小检测框面积限制去掉太小和太大的目标过大是离镜头太近的异物过小是远景噪声。同类目标连续出现时间过滤如果某个跟踪 ID 存活时间不足 2 秒且没有跌倒过程特征不参与状态机。兴趣区域ROI裁剪在画面里把沙发、窗户、电视区域手动标出来这些区域检测到跌倒直接忽略。虽然有点一刀切但在固定摄像头场景下非常有效。6.5 用假跌倒数据测试不可信要找真人模拟网上能下载的公开跌倒数据集比如 UR Fall Detection、Le2i场景和摄像头视角跟实际部署环境差别很大模型在你家摄像头下的效果最终还是要靠真人现场模拟。我找亲戚朋友做了几十组模拟跌倒——正着摔、侧着摔、滑倒、坐空、原地躺下覆盖各种姿态和速度。这些模拟数据对调整阈值帮助非常大。举个例子真实模拟测下来我发现老人跌倒时躯干倾角并不总是立刻到 90 度——很多是身体侧倾到 60~70 度就倒地了倾角阈值设太高会漏报。最终我把阈值调到了 50 度做倒地带判定条件之一。6.6 隐私保护本地化推理关键点模式我们做的这个系统本质上是把监控摄像头变成姿态传感器而不是视频直播。在工程上我做了两个隐私保护措施一是推理完全本地化视频流不出本地网关只有告警时的裁剪截图推送到手机二是提供关键点渲染模式——画面中只显示人体骨架线条不显示原始摄像头画面。这样既能完成跌倒检测又最大限度保护老人隐私。实际部署时很多家属和老人对只看到骨架看不到画面这个设计非常认可安装阻力小了很多。7. 这套系统后续还能扩展的方向跌倒检测只是姿态估计在养老场景的一个起点。我把这套系统跑通之后发现同样一套关键点数据流可以顺带实现很多别的功能久坐/久卧提醒检测到老人长时间处于坐姿或卧姿且活动量极低可以提醒家属关注。睡眠质量分析通过夜间关键点变化频率粗略判断起夜次数、翻身频率异常时提示。复健动作评估老人在做康复训练时通过关键点角度变化评估动作是否标准辅助远程康复指导。多人姿态行为分析如果家里有护工和老人可以通过多人关键点匹配分析交互行为比如老人从轮椅转移到床上时是否摔倒。当然这些都是后话。核心是先把跌倒检测这条链路做扎实这步走稳了后面的扩展就是水到渠成的事。做这套系统的过程中我最大的体会是做一个 AI 落地项目算法训练只占三分之一工程稳定性占三分之一另外三分之一是对真实用户场景的理解。模型选再牛摄像头角度不对、晚上看不清、误报频繁、隐私说不清都是白搭。反过来只要把每一个环节都打磨到位一个看似简单的 YOLOv8-Pose 模型也能成为真正守护老人安全的可靠防线。