基于YOLOv11的人体姿态检测与AI健身分析实战

1. 项目概述：为什么选择YOLOv11做姿态检测

“基于YOLOv11深度学习模型的人体姿态检测系统，AI健身分析，人体姿态估计识别”，这个标题放在一起,其实就是一个完整的落地场景：用最新的YOLOv11模型识别画面中的人体骨架关键点，再基于这些关键点做健身动作的实时分析和计数。简单说，就是让电脑“看懂”你做得标不标准、做了多少个。

这类系统的应用范围其实很广，不止是健身。康复训练里医生需要远程观察病人的关节活动度，体测场景里体育老师想自动统计一分钟俯卧撑个数，智能穿戴配套软件里需要判断深蹲是否到位，甚至舞蹈教学中也需要动作比对。而YOLOv11-pose正好是目前在性价比上非常平衡的一个选择：它单帧能同时输出人体框和17个关键点，一次前向推理搞定，不像传统两阶段方法那样先检测人、再单独跑关键点网络。

如果你是刚入门的开发者，或者手里有一个具体的健身分析需求但不知道从哪下手，这篇内容就是照着做就能跑通的完整路径。我会把模型选型的原因、数据集格式、训练推理细节、角度计算逻辑、计数方案和踩坑记录都拆开讲明白。

可能有人会问，为什么不是MediaPipe、OpenPose或者老牌的YOLOv8-pose？这个问题我当年也纠结过，后面会专门对比。先剧透结论：MediaPipe确实轻量，但关键点稳定性在复杂背景和遮挡下稍弱；OpenPose精度高但是重，单张图要跑两套网络，实时性吃亏；YOLOv8-pose够用但是YOLOv11在特征提取结构上又有改动，速度和精度的平衡更好。经过实际测试，在消费级显卡上YOLOv11n-pose能做到接近实时的推理速度，精度也足够支撑健身动作的角度计算。

搭建这套系统的整体流程是：环境准备 → 数据准备（COCO格式或自有数据集） → 模型训练/微调 → 导出部署 → 编写推理与角度计算逻辑 → 实现健身动作计数和分析。整个过程我会按实际推进的顺序来讲，每个阶段都有可以直接抄的代码和参数。

2. 核心技术选型与原理拆解

2.1 人体姿态估计的两条技术路线对比

在深入YOLOv11之前，有必要先了解姿态估计领域的两大流派。第一条是自上而下（Top-Down），先通过目标检测把人找出来，裁剪出人体区域，再用关键点检测网络在裁剪区域上回归出17个关键点。代表作就是OpenPose的后续变体和HRNet，这类方案精度确实高，但速度是硬伤，因为每个人都要单独过一遍关键点网络，人一多帧率骤降。

第二条是自下而上（Bottom-Up），先检测出所有关键点，再通过分组策略把属于同一个人的点关联起来。OpenPose早期版本用的就是这种思路，它的Part Affinity Fields（PAF）就是用来学习关键点之间连接关系的。这类方案速度比Top-Down快一些，但分组逻辑复杂，精度也容易在多人场景下出问题。

YOLOv11走的是第三条路，本质上属于单阶段（One-Stage）方案。它把人体检测框和17个关键点的回归放在同一个网络中，通过解耦头同时输出目标框、置信度和关键点坐标。这样做的好处是省掉了“先检测再裁剪再回归”的串行流程，GPU利用率更高，端到端延迟更低。在推理性能上，单阶段方案在单人健身场景下的精度已经逼近HRNet，但帧率能拉开好几倍。

我用一个表格来展示这几个方案的实测感受，方便新手按需选择：

对于健身分析这种需要实时反馈的场景，帧率低于15就没法用了，动作稍快就会丢帧、计数错乱。YOLOv11n-pose在普通显卡上跑到50帧以上很轻松，这就是它作为基座模型的核心理由。

2.2 YOLOv11模型结构与关键点回归机制

YOLOv11在骨干网络上继承了YOLOv8的CSP结构思路，但把C2f模块升级成了C3k2，同时引入了更多的梯度流分支。通俗点说，C3k2让信息在浅层和深层之间的流动路径更丰富，网络在感受野和特征表达能力之间拿到了更好的平衡。实际表现就是小目标（比如远距离的人）和遮挡情况下的关键点回归更稳。

姿态估计头（Pose Head）是这套系统的关键差异点。检测头负责输出边界框的坐标和类别置信度，姿态头则额外输出17个关键点的坐标和可见性。YOLOv11的姿态头设计上沿用了Anchor-Free的解耦方式，每个格子直接回归关键点相对格子中心的偏移，省去了Anchor匹配的复杂逻辑。训练时的损失函数是分类损失（框的类别）加回归损失（框位置）加关键点损失（关键点坐标）。关键点损失用的是OKS（Object Keypoint Similarity）变体，它考虑了关键点之间的尺度差异——比如鼻子和脚踝的允许误差范围本来就不一样，用统一的MSE反而会把小范围的关键点训练崩。

姿态头输出的17个关键点严格对齐COCO数据集的标注顺序：0鼻子、1左眼、2右眼、3左耳、4右耳、5左肩、6右肩、7左肘、8右肘、9左手腕、10右腕、11左髋、12右髋、13左膝、14右膝、15左脚踝、16右脚踝。这个顺序在做角度计算的时候非常重要，后面对应错一个点，算出来的角度全乱套。

2.3 为什么不用MediaPipe和OpenPose

很多教程一上来就推荐MediaPipe，因为代码简单几行就能出骨架，但真正做健身分析时它有几个坑。第一是MediaPipe的BlazePose模型在侧面视角下左右关键点容易抖动，做深蹲侧向检测时膝盖角度会忽大忽小。第二是MediaPipe对多人同时检测的支持较弱，虽然在健身场景下大多是单人，但如果你后期想扩展成私教课多人同时分析，就得推倒重来。第三是MediaPipe的模型是闭源的，出了问题你没法自己微调，而健身场景的体型差异很大，标准模型对极端身材的适配有限。

OpenPose的问题则是反面：精度是很满意，但部署太重。它的双分支网络结构在CPU上基本跑不动，GPU上实时也需要较高显存。如果你只是做单人健身计数，用OpenPose属于杀鸡用牛刀，还把自己拖进了复杂的依赖配置里。

YOLOv11的优势恰好在这两者之间踩中了：模型开源可以微调，单帧推理速度快，对单人场景的精度足够，部署方式灵活（ONNX、TensorRT都支持）。所以如果你问我当前做什么姿态检测最省心，答案就是YOLOv11-pose。

2.4 数据集准备与标注格式

训练姿态模型之前，得先搞清楚数据格式。YOLOv11的训练格式是基于COCO扩展的，每一行标签对应一个目标实例，格式是：class_id、x_center、y_center、width、height、以及17对关键点坐标和可见性标志。坐标值都归一化到0~1，可见性标志3表示可见且被标注，2表示不可见但可以通过上下文推断，1表示该关键点不在图像内，0表示未标注。训练时通常只使用可见性大于0的关键点参与损失计算。

如果你想用自有数据微调，标注工具推荐用CVAT或LabelMe。CVAT支持关键点标注模式，把COCO格式导入导出都很方便。标注时有个技巧：对于被遮挡的关键点，不要直接不标，而是标成低可见性。这样模型会在训练中学到“这个点虽然看不到但大概在这个位置”的语义信息，推理时更稳。

我自己标注过一套深蹲和俯卧撑的数据集，一个人标了大概2000帧，累归累，但效果比直接拿COCO预训练模型硬跑好很多。如果你没有精力标注，可以先下载COCO2017的person_keypoints数据来预训练，再用少量自采数据（300~500帧就够了）微调，这样能兼顾通用性和场景适配。

3. 环境搭建与模型训练实操

3.1 依赖安装与硬件选择建议

环境这部分不难，但版本坑比较多。先给一套我实测过很稳的版本组合，Python 3.10、PyTorch 2.0.1、CUDA 11.8、Ultralytics 8.2.0以上。Ultralytics从某个版本开始集成了YOLOv11支持，不建议装太老的版本，直接拉最新的稳定版即可。

conda create -n yolopose python=3.10 conda activate yolopose pip install torch==2.0.1 torchvision==0.15.2 --index-url https://download.pytorch.org/whl/cu118 pip install ultralytics

硬件方面，如果是新手学习阶段，一张显存6GB以上的显卡就够跑了。YOLOv11n-pose训练时batch size 16在6GB显存上勉强能行，如果显存不够就把batch size降到8或4。推理阶段更宽松，甚至CPU也能跑，只是帧率会掉到个位数。

3.2 使用COCO-pose预训练模型快速上手

如果你不想从头训练，最快的方式是直接用Ultralytics提供的COCO-pose预训练权重跑推理。这段代码就能在视频上输出带骨架的检测结果：

from ultralytics import YOLO # 加载预训练姿态模型，n是最轻量版，s精度更高但稍慢 model = YOLO("yolo11n-pose.pt") # 视频推理，直接保存带骨架绘制结果的视频文件 results = model.predict( source="input_video.mp4", save=True, conf=0.4, device=0, project="outputs", name="pose_demo" )

第一次跑的时候会自动下载权重文件，大概几MB到几十MB不等。如果网络不稳定，可以手动从Ultralytics官方GitHub Release页面下载后放到当前目录。

刚才这个代码只做了“看到骨架”这一步，离“AI健身分析”还差一口气。真正核心的是拿到关键点坐标后做角度分析和动作计数，这个后面专门讲。

3.3 自有数据微调的完整命令与参数解释

yolo pose train \ model=yolo11n-pose.pt \ data=my_pose_dataset.yaml \ epochs=100 \ imgsz=640 \ batch=16 \ lr0=0.001 \ lrf=0.01 \ patience=20 \ device=0

data文件的内容格式要注意，指向你标注好的数据集目录，并列出训练和验证集的图片路径。一个完整的my_pose_dataset.yaml是这样的：

path: ./dataset/pose_dataset train: images/train val: images/val kpt_shape: [17, 3] names: 0: person

这里的kpt_shape必须写对，[17, 3]表示17个关键点，每个点有[x, y, visible]三个值。如果写错，训练会直接报形状不匹配。

训练时的关键参数：imgsz一般用640就够了，追求更高精度可以到960，但显存占用和推理耗时都会涨；lr0初始学习率不要给太高，用预训练权重微调时0.001是安全区间；patience是早停轮数，验证集loss连续20轮不降就自动停，省时间。

训练完成后，模型权重会自动保存到runs/pose/train/weights/目录下。best.pt是根据验证集指标选出的最优权重，last.pt是最后一轮的权重。部署时只用best.pt。

3.4 模型导出为ONNX或TensorRT加速推理

离线验证完成后，下一步是导成更轻量、推理更快的格式。导出ONNX是最通用的一步，代码只要一行：

model = YOLO("best.pt") model.export(format="onnx", imgsz=640, opset=12)

ONNX的好处是可以脱离PyTorch环境运行，用ONNX Runtime在不同平台上做推断。如果目标平台是NVIDIA Jetson或者有TensorRT的服务器，还可以进一步导出成TensorRT引擎，推理速度能比PyTorch原生再快一倍以上。导出TensorRT的代码也简单：

model.export(format="engine", imgsz=640, half=True)

half=True表示开启FP16精度推理，显存占用和延迟都进一步下降。实测在消费级显卡上，YOLOv11n-pose用TensorRT FP16推理，单帧耗时能从12ms降到7ms左右。

有一点值得提醒：导出的engine文件是和显卡型号绑定的，换一台不同架构的显卡要重新导一次。不要试图把A卡的TensorRT文件拷到另一台机器上直接用，会直接加载失败。

4. AI健身分析的核心：从关键点到动作判断

其实姿态检测只是前菜，健身分析的灵魂在于“语义理解”。拿到17个关键点之后，你要把它翻译成“手肘角度多少度”“膝盖有没有超过脚尖”“动作做到第几个”，这里面的逻辑才是整个系统的技术含量所在。

4.1 三维角度计算的正确姿势

对于单目摄像头，我们能拿到的只是二维画面坐标，所以严格意义上算出来的是“二维投影角度”，不是真实的三维关节角。但健身动作判断对精度要求没那么苛刻，二维角度在正面和侧面视角下已经足够区分动作质量。

计算角度的标准方法是向量夹角公式。比如算左肘关节角度，涉及三个点：左肩、左肘、左手腕。以肘为顶点，肩到肘是一个向量，肘到腕是另一个向量，夹角余弦就是两个向量的点积除以模的乘积。对应的NumPy实现如下：

import numpy as np def calculate_angle(a, b, c): """ 计算三个关键点构成的角度，b为顶点 a: 第一个点坐标, b: 顶点坐标, c: 第三个点坐标 """ ba = a - b bc = c - b cosine_angle = np.dot(ba, bc) / (np.linalg.norm(ba) * np.linalg.norm(bc) + 1e-6) angle = np.arccos(np.clip(cosine_angle, -1.0, 1.0)) return np.degrees(angle)

注意加了个1e-6防止分母为零报错，np.clip限制余弦值在-1到1之间，否则arccos在浮点误差下会返回nan。这两个都是实际运行中很容易踩到的坑。

比如一个人做俯卧撑，手肘角度就是肩、肘、腕三个点算出来的夹角；深蹲看膝关节角度，就是髋、膝、踝三个点；检测身体是否倾斜看肩、髋连线和水平线的夹角，这需要再配合一个水平参考向量来计算。

4.2 俯卧撑自动计数逻辑设计

俯卧撑计数是健身分析最经典的功能，它的难点不在识别动作，而在判断“什么时候算完成一次”。常见做法是检测两个状态：撑起和下降。用身体中心点到地面的高度变化来判定状态切换。更稳妥的做法是用手肘角度的变化来定义阶段转换。

我实际跑通的逻辑是：定义三个状态——UP（撑起）、DOWN（下降）、COUNTED（已计数）。当手肘角度大于160度时进入UP状态，降到小于60度时进入DOWN状态，从DOWN回到UP的瞬间计数加一。加一个COUNTED状态是为了防止同一动作重复计数，只在“从DOWN到UP完成”的时刻计数一次。

真正的实现中没有真状态机那么复杂，用两个布尔标志就能搞定，核心逻辑如下：

counter = 0 is_down = False for frame in video_frames: angle = get_elbow_angle(frame) if angle < 60 and not is_down: is_down = True if angle > 160 and is_down: counter += 1 is_down = False

用前后帧保持的is_down标志来记忆状态，比用连续帧的差分判断更抗噪。因为单帧抖动经常导致角度突变，直接做差分会多计数或漏计数。

4.3 深蹲动作质量分析

深蹲的质量分析就更有意思了。除了看膝盖角度，还要同时监控三个点：膝盖弯曲是否超过90度、膝盖有没有内扣、重心有没有过分前移导致脚跟离地。

膝盖内扣的判定比较微妙，用二维图像来看，就是把左髋、左膝、左脚踝三个点连成两条线，计算膝盖处向内侧偏移的距离。这个指标在正面视角下特别敏感，如果左膝和右膝之间的水平距离明显变小，基本就是膝盖内扣了。

实际编码时，我用的是一组并列条件来给深蹲打分级评分：

hip_knee_ankle_angle = calculate_angle(hip, knee, ankle) knee_hip_distance_ratio = knee_x - hip_x # 水平偏移量判断内扣 torso_angle = calculate_angle(shoulder, hip, knee) # 躯干倾斜度

如果膝盖角度小于120度且躯干倾斜度在合理范围内，就算标准深蹲一次；如果膝盖角度大于160度，说明蹲得太浅；如果膝盖角度小于70度，说明蹲得太深有受伤风险。这套规则在训练时可以直接给出反馈，比单纯计数有信息量得多。

4.4 推理坐标到角度坐标的坐标系问题

YOLOv11输出的关键点坐标是归一化坐标，范围在0到1之间，基于640x640的推理尺寸。但OpenCV的视频帧尺寸往往不是640x640，可能在预处理时已经被缩放。所以拿到的坐标要乘上原始帧的宽高才能映射回原图坐标。

raw_x, raw_y = keypoint[0], keypoint[1] orig_x = int(raw_x * orig_width) orig_y = int(raw_y * orig_height)

这个转换看起来简单粗暴，但很容易被忽略。如果原始帧是1920x1080，你直接把归一化坐标画到原图上，骨架会画到左上角很小的范围内。处理方式有点讲究：Ultralytics在推理时内部已经做了letterbox处理，所以拿到的关键点实际上已经是映射回原始坐标空间的，不用手动转换。但如果你用ONNX Runtime自建管线，就得自己处理letterbox和坐标还原。

5. 完整落地流程与代码实现

5.1 系统整体架构设计

一个可用的AI健身分析系统不只是一段推理脚本，它需要包含数据采集、推理引擎、逻辑分析、结果展示几个模块。我当时的工程结构是这样的：

AI-Fitness-Tracker/ ├── models/ # 存放导出的模型文件 │ └── best.engine ├── utils/ # 工具模块 │ ├── angle_calculator.py # 角度计算函数 │ ├── pose_analyzer.py # 动作分析逻辑 │ └── counter.py # 计数状态机 ├── inference.py # 主推理入口 ├── streamlit_app.py # 可视化交互界面 ├── requirements.txt └── config.yaml # 配置文件

配置文件里定义模型路径、置信度阈值、角度判断阈值、视频来源等所有可调参数。把参数从代码里拆出来的好处是，给不同动作调阈值的时候不用改代码重新部署，只改配置文件就能生效。

5.2 端到端推理与姿态分析主程序

主程序的核心流程是：打开视频或摄像头，对每一帧做推理，提取关键点，计算角度，写入逻辑判定结果，在画面上叠加绘制骨架和文字信息。下面的代码就是完整的循环：

import cv2 from ultralytics import YOLO from utils.angle_calculator import calculate_angle model = YOLO("models/best.engine") # TensorRT引擎 cap = cv2.VideoCapture(0) # 摄像头输入 counter = 0 is_down = False while True: ret, frame = cap.read() if not ret: break # 模型推理 results = model(frame, conf=0.4, verbose=False) for r in results: if r.keypoints is None or len(r.keypoints) == 0: continue kpts = r.keypoints.xy[0].cpu().numpy() # 17个关键点坐标 # 检查置信度，低于阈值的关键点不参与角度计算 confs = r.keypoints.conf[0].cpu().numpy() # 取左手肘角度，索引7 if confs[5] > 0.5 and confs[7] > 0.5 and confs[9] > 0.5: angle = calculate_angle(kpts[5], kpts[7], kpts[9]) # 动作计数逻辑 if angle < 60 and not is_down: is_down = True elif angle > 160 and is_down: counter += 1 is_down = False cv2.putText(frame, f"Elbow: {angle:.1f}", (30, 30), cv2.FONT_HERSHEY_SIMPLEX, 1, (0, 255, 0), 2) cv2.putText(frame, f"Reps: {counter}", (30, 80), cv2.FONT_HERSHEY_SIMPLEX, 1, (0, 0, 255), 2) # 绘制骨架 annotated = r.plot() if 'r' in locals() else frame cv2.imshow("AI Fitness Tracker", annotated) if cv2.waitKey(1) & 0xFF == ord("q"): break cap.release() cv2.destroyAllWindows()

这里最需要注意的地方是判断关键点置信度。r.keypoints.conf返回的是一个17元素的数组，对应每个关键点的置信度。如果某个点在画面中完全被遮挡，模型会输出一个低置信度的坐标，如果你不加筛选直接拿去做角度计算，结果会是一个看似合理但完全错误的数字，然后计数逻辑就会乱套。

实际运行时，我一般把参与角度计算的三个关键点置信度阈值都设在0.5以上。如果三个点中任何一个低置信度，就跳过这一帧的角度计算和计数，既不误计数也不漏判。

5.3 单人场景下的关键点置信度筛选策略

有一种特殊情况：多人同时出现在画面里，模型会输出多组关键点。对于AI健身分析，大多数情况下只关心离摄像头最近的那个人。这时候可以在结果里过滤一下：取检测框中面积最大的一组关键点作为目标用户。

best_idx = 0 best_area = -1 for i, box in enumerate(r.boxes.xyxy.cpu().numpy()): w = box[2] - box[0] h = box[3] - box[1] area = w * h if area > best_area: best_area = area best_idx = i

然后只取这一组关键点做分析。这种策略在健身房里特别实用，因为背景里会有其他人在走动，如果不对目标做选择，系统会随机分析某个人，计数会变得非常混乱。

5.4 实时视频流处理与性能调优

实时视频流的处理延迟和帧率是一对矛盾。要想帧率高，无非是减少单帧处理耗时。常用的优化手段有这么几个：

第一是降低输入分辨率。用640x640推理和用320x320推理，速度能差4倍以上。健身场景下人体占画面比例大，320x320的关键点精度下降不明显，但帧率可以轻松翻倍。

第二是跳帧处理。视频流30帧，不需要每一帧都分析和计数。可以每3帧分析一次，中间两帧直接丢给绘制模块处理，或者干脆跳过不绘制。计数逻辑对时间间隔不敏感，因为它判断的是状态变化不是速度，所以跳帧不会影响计数。

第三是开启TensorRT FP16推理。前面说过，engine格式的推理延迟能降低40%左右，这是最直接的提速手段。

第四是用多线程或异步队列把视频采集和模型推理分开。视频采集是一个轻量操作，模型推理是重操作，如果串行处理，帧率会被推理时间卡死。把视频帧放入队列，另一个线程从队列取出推理，效率会好很多。

5.5 可视化反馈：骨架绘制与动作提示

交互体验的关键是把分析结果直观展现出来。Ultralytics自带的r.plot()方法就能画骨架和检测框，但如果你想加入健身分析特有的提示信息，比如“膝盖内扣”“蹲深不够”“完成第5个”，就需要自己画坐标文字。

建议把提示信息放在画面右侧，用不同颜色区分不同状态：绿色是标准动作，黄色是接近标准但有轻微偏差，红色是错误动作。颜色编码比文字更快传达信息，特别是用户在运动中瞄一眼屏幕时，绿色意味着继续保持，红色意味着纠正姿态。

如果你要做一个完整的系统，建议用Streamlit搭一个简单的Web界面，把视频流、实时计数、角度数值、历史曲线一起展示。Streamlit的好处是纯Python就能写UI，不用单独写前端。

import streamlit as st st.title("AI 健身姿态分析") run = st.button("开始分析") frame_placeholder = st.empty() counter_placeholder = st.text("当前次数：0") if run: # 在这里调用推理主循环，把帧和计数写入占位组件 pass

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

6.1 关键点抖动导致角度不稳

我刚开始做的时候发现，明明人静止站着，计算出的手肘角度一直在160到175之间跳。后来排查发现原因有两个：一是模型对小幅度移动本来就敏感，二是绘制和分析没有被低通滤波。

解决方法有两个，一个是关键点坐标做平滑，常用的是一阶指数滑动平均（EMA）：

smoothed_kpt = alpha * current_kpt + (1 - alpha) * previous_smoothed_kpt

alpha取0.4左右比较合适，太小会滞后，太大滤不掉抖动。另一个是角度值做滑动窗口均值，取最近5帧角度的平均值作为当前角度。这两种方法叠加之后，角度曲线会平滑很多。

但是滤波参数也要小心，alpha太大会导致动作开始和结束的响应变慢，计数出现明显延迟。这个需要根据自己的摄像头帧率来调：60帧的摄像头可以适当提高延迟容忍度，15帧的低帧率摄像头最好只用滑动窗口不用EMA。

6.2 侧面视角下左右关键点混淆

健身摄像头常见的摆放位置是正前方偏侧面，这时候画面里的左肩和右肩可能在视觉上重叠或接近。模型有时会把左肩的位置突然跳到右边，导致使用前一个左肩坐标和当前右肩坐标计算出的角度出现异常跳变。

遇到这个问题，一个有效的处理办法是引入空间先验：人体的肩膀宽度是有限的，左右肩之间的像素距离在连续帧中不可能瞬间变化太大。增加一条判断规则，如果左右肩距离突变超过某个阈值，就认为这一帧的左右关键点发生了交换，把左右坐标对调回来。

这个方法在单人固定摄像头的场景下非常有用，实测可以把左右切换导致的误计率降到一个很低的水平。

6.3 远距离人体目标关键点丢失

如果摄像头离人太远，人体在画面里的高度可能只有一两百像素，这种情况下的关键点定位精度会急剧下降。因为YOLOv11的训练数据里虽然包含不同尺度的人体，但小目标的回归难度始终比大目标高。

实际项目里，如果遇到蹲下起身动作时膝盖关键点经常丢失，第一反应应该是检查人体框尺寸占整个画面的比例。如果占比太小，就得调整摄像头位置或视角，尽量让人体占画面的60%以上。如果你一定要用远距离摄像头，可以尝试把推理分辨率调到960，代价是帧率下降约30%。

6.4 模型误检与置信度阈值调节

调试过程中最容易遇到的问题是模型把背景里的广告牌人像当成真人，或者把画面角落里路过的人算进了分析目标。这时候需要把conf阈值从默认的0.25往上调到0.4甚至0.5。过高的阈值能滤掉假目标，但也会导致真正的人被漏检，特别是当人穿着与背景相近的衣服时。

如果只调阈值不够，还可以利用人体框的位置信息做限制：只在画面中心区域的某个ROI（Region of Interest）框内检测目标。比如把分析区域限定为画面中央的80%区域，角落里的干扰目标直接忽略。这个策略在固定机位的健身场景里非常可靠。

6.5 角度计算出现NaN值的排查思路

运行中偶尔会出现角度显示为nan的情况。原因多数是分母为零，即两个关键点坐标完全重合。比如手肘和手腕在特定动作下确实可能重合，比如手掌贴着肩膀的时候。

代码里加1e-6只是兜底，真正的处理应该是：如果三个关键点中有两个完全重合，就跳过这一帧的角度判断。更好的做法是增加距离判断，比如肩到肘的距离小于5个像素时，说明这个关键点组不可信，直接跳过。

6.6 常见问题速查表

7. 经验总结与后续扩展方向

这套系统从零开始跑到稳定，个人的最大体会是：姿态检测模型的精度已经把门槛降得很低了，真正的工程难点全在“把坐标变成决策”这一层。很多人以为装了YOLO模型就万事大吉，实际上十个项目里有八个死在角度计算的细节上——坐标没有映射回原图、左右关节搞混、置信度没有过滤、计数状态机写成了简单的阈值跳变。

如果后面要继续扩展这个方向，我觉得有几个很值得做的点：

第一个是多视角融合。单个摄像头的二维坐标在判断深蹲深度时永远是近视眼，如果加一个侧面的摄像头，两路关键点信息做三角测量，能算出更接近真实的三维关节角度。这在康复评估里价值极高。

第二个是用户历史数据记录。把每次训练的角度曲线、次数、完成质量存到数据库里，做一个趋势分析。比如这周相比上周，深蹲的最小膝盖角度有没有下降，曲线有没有更平滑，这就是一个完整的进步追踪系统了。

第三个是动作分类的扩展。现在只能分析俯卧撑和深蹲这类固定动作，如果要做动作库，比如哑铃弯举、引体向上、平板支撑，需要针对每个动作定义不同的角度规则和状态机。这个扩展成本主要在规则设计上，模型本身是通用的。

最后再提醒一句关于部署的事：如果你要部署到实际环境中，不要只盯着训练精度看，一定要在部署环境的帧率、光照变化、人群遮挡这些条件下重新评估模型表现。实验室里跑得很稳的模型，换个昏暗的灯光可能就崩了。建议在开始时就收集和你的实际使用场景接近的测试数据，这会省掉后面大量的返工时间。