直接进入正题。在AI视觉和动作生成这个方向折腾了几年，我越来越觉得，把“人体姿态估计”和“动作生成”组合起来做项目，是最能同时满足“出效果”和“学技术”两条线的路径之一。这个“AI格斗项目”就是这么来的，day3的记录，不是那种跑通一个demo就欢呼的进度汇报，而是放慢了速度，把数据、标注、模型、训练这条链路完整吃透的第三天。

这篇内容是我自己实际动手的记录，从环境搭建到模型训练，从数据清洗到推理部署，中间踩了不少坑，也沉淀了不少判断经验。没有藏着掖着，按时间顺序把每一步做了什么、为什么这么做、遇到什么问题、最后怎么解决的，全部摊开来讲。如果你也想做类似的事——不一定是格斗，也可以是动作识别、舞蹈编排、体育辅助分析——那这个过程中的方法论和避坑点，应该能帮你少走很多弯路。

1. 项目定位与整体设计思路

我给自己定的目标是：做一个能从单目视频里提取人体骨骼关键点、识别出格斗动作并生成连续反馈信号的系统。说白了，输入是一段普通摄像头拍的画面，输出是结构化的关键点序列，再通过这些序列去判断动作类型和发力节奏。格斗只是载体，核心能力是“从像素到姿态”再到“从姿态到语义”的完整链路。

1.1 为什么选格斗这个场景

选格斗场景不是为了炫技，而是因为它对模型的要求足够高。普通的走路、挥手这类动作，姿态差异大、速度变化慢，对时序模型来说相当友好。但格斗动作有几个非常明显的特征：发力时间极短、关节角度变化剧烈、肢体容易互相遮挡、单帧信息量不足。这就逼着模型必须把握好“空间特征”和“时间上下文”的配合，否则几乎不可能做准。

换句话说，把格斗这类高动态场景搞定了，再回头处理日常动作，你会觉得轻松得多。这也是我强调“场景难度决定模型上限”的原因。

1.2 从day1到day3的路线演进

day1主要做的是基础准备，包括环境搭建、视频素材采集、Camera标定思路的梳理。day2开始跑关键点提取，简单验证了方案可行性。到了day3，重心从“能不能跑通”转移到“能不能跑稳”，也就是开始认真处理数据质量、模型结构、训练策略和部署性能。

day3的具体目标定得很实际：

• 关键点提取在没有极端遮挡时达到稳定输出，抖动幅度能控制在某个可用范围内；
• 完成一个自定义格斗动作数据集的标注和划分；
• 训练一个能区分三类动作的时序模型，准确率达到可用线之上；
• 在CPU推理环境下，单帧处理时间低于某一阈值，保证基本实时。

这三个目标，难度不算大，但每一项要做到“能实际用”，都需要抠细节。

1.3 技术栈与工具选型逻辑

做AI项目，选工具要基于两点来定：一是你熟悉哪套，二是这套能不能快速迭代。我用的方案是Python生态里比较经典的一套：OpenCV做视频帧处理、MediaPipe或YOLO系列做姿态估计候选、PyTorch做时序模型训练，最后用ONNX做跨平台部署。

为什么不直接用现成的动作识别模型？因为我的需求不是“识别动作类别”，而是“精确到帧级和关节级的过程分析”。通用模型在公开数据集上效果不错，但对自己的场景数据几乎必然会水土不服，且不好调整细节。自己搭模型虽然麻烦，但可控性高非常多，想改哪层、想加什么约束，都随心所欲。

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

这一部分，我按数据、标注、模型、训练、部署五个维度把day3的实操拆开讲。每部分都会说清楚“为什么这么做”和“具体怎么做”，遇到需要选型的细节，也会把判断标准写出来。

2.1 数据采集：角度、时长与覆盖度

数据质量是动作类项目中最容易被低估的一环。很多教程拿现成数据集跑都能出效果，但换到自己的场景就失灵，根源就是数据分布不对。

我这批数据有相对严格的标准：每位采集对象做三组动作，分别是直拳、摆拳和提膝防御，每组动作重复20次，全部用固定机位的摄像头拍摄，帧率为60fps。整个过程尽量保持无遮挡角度，背景简单，光线稳定。

选固定机位的原因很简单——姿态估计算法对视角变化很敏感，训练阶段数据太散，模型很难学到稳定的关键点位置。虽然要兼顾实际部署时的多机位场景，但那是第二步的问题，第一步先保证单一视角下的准确率做到极致。

关于时长，我没有做长视频训练，而是把每个动作从开始到结束切成单独片段。每个片段大概在0.5到2秒之间，这个时间范围能涵盖发力的前后过渡期，又不会把过多无关背景引入。

2.2 关键点提取与归一化

选MediaPipe作为关键点提取的初始方案，有它自己的逻辑。它检测33个全身关键点，对四肢、躯干、头部的覆盖足够，而且输出相对稳定。在单人、无遮挡的情况下，它的表现足够可用，虽然不是说它是最好，但平衡了速度和精度之后，这是个非常务实的起点。

提取完之后的所有关键点数据，不是直接丢给模型用的，我必须先做归一化。归一化的方式很简单，以左右肩中点和两肩宽度连线方向作为基准，把所有坐标变换到同一坐标空间。这样处理的核心原因是，摄像机的距离、人的身高、体型会导致原始坐标差异很大，不归一化会扰乱模型的注意力。

归一化完成之后，每个样本就是一个形状为“帧数 x 特征维度”的矩阵。我做的是帧数固定为32帧的采样窗口，特征维度取关键点的x、y坐标再加一系列的角度特征。

2.3 角度特征的重要性与计算细节

如果只把关键点坐标给模型，模型能识别出“手的位置”，但很难直观感受“发力角度”和“动作形状”。所以我又手工加了一批角度特征，主要是肘关节角度、肩关节角度、膝关节角度。

角度特征怎么算？以肘关节为例，取肩、肘、腕三个关键点坐标，用二维向量夹角公式计算：

角度 = arccos((v1·v2) / (|v1||v2|))

其中v1是肩到肘的向量，v2是肘到腕的向量。这个值在动作过程中变化非常明显，比如直拳出击前后，肘角从约90度急剧变化到近170度，这组变化的曲线形态对动作分类很有区分度。

加入角度特征之后，模型的输入就不只是纯坐标，而是“位置+几何关系”的组合。实际效果上，模型的收敛速度明显提升，相同迭代次数内准确率能提高大约4到8个百分点。如果只给坐标特征，模型可能过拟合到某个人特定的姿态习惯上，而角度特征对个体差异的抗干扰能力更强。

2.4 标注策略：别在标签上省时间

标注听起来是个“纯体力活”，但设计好标注框架能帮你省掉很多后续麻烦。我没有只标“这是什么动作”这种粗颗粒标签，而是分三层：动作类别、发力起始帧、动作结束帧。

动作类别就是三类基础动作。发力起始帧和结束帧的标注更费功夫，但价值极大——后续无论做时序对齐、训练分割、还是做动作评估，都离不开这些信息。比如我想做一个“出拳速度评估”的功能，没有发力起始帧，就算不出来“从0到最大速度用了几毫秒”这个关键指标。

标注工具可以自己简单写一个，用OpenCV读取视频帧，点击按钮记录关键帧编号。两个小时的视频材料，人工标注大约花了半天时间，这个投入非常划算。

3. 模型架构、训练策略与实现细节

这部分应该是大多数人最关心的。我把模型设计、数据增强、训练配置和评估方法串在一起讲，因为它们互相影响，不能孤立看待。

3.1 模型架构选择：时序卷积还是Transformer时序处理

一开始我考虑过用Transformer处理时序数据，后来还是放弃了。原因不是Transformer不好，而是我当前数据量在千级样本规模，这个量级撑不起Transformer对数据量的要求。而时序卷积网络在处理短时序上效率很高，训练速度快，参数也少得多。

我的模型结构大致是这样的：

• 输入层：32帧 x 特征维度（34个特征）
• 第一层Conv1d：64个卷积核，卷积核大小5，做时序特征提取
• 第二层Conv1d：128个卷积核，卷积核大小5，步长2，做特征压缩
• 第三层Conv1d：256个卷积核，卷积核大小3，步长2
• 全局平均池化
• 全连接层，输出为动作类别数3

这个结构称不上新颖，但非常实用。卷积核大小选5而不是3，是为了在一开始就能覆盖到较长的帧区间，捕捉发力的起承转合过程。步长2的设计是在主动降低时序分辨率，让模型逐步从“帧级细节”抽象到“段级模式”。

有一点我要强调：我没用循环神经网络结构。对32帧这种不算长的时序，时序卷积的并行效率、训练稳定性和表达能力都已经足够了。循环网络的序列依赖特性在这里反而会拖慢训练。

3.2 数据增强：时序数据也要增强

很多人做图像项目时对增强很重，但做时序数据时反而会忽略。我对时序数据做了三类增强：

• 时序平移：把32帧的采样窗口在原始片段中随机向前或向后移动2到6帧，模拟发力时间点的不确定性；
• 坐标噪声：对关键点坐标添加均值为0、标准差为1到2像素的高斯噪声，模拟姿态估计模型的输出抖动；
• 时序缩放：把片段在时间轴上随机缩放0.9到1.1倍，模拟动作速度的自然波动。

这三类增强合计让样本量从约600条扩展到3000条以上。训练出来的模型泛化性明显提升，尤其是对姿态估计抖动带来的影响，容忍度高了很多。

3.3 训练配置与过程中做对的关键决策

训练配置直接照抄并不明智，因为每组数据的分布都不一样。我的配置是这样的：

• 优化器：AdamW，初始学习率3e-4
• 损失函数：交叉熵
• Batch size：32
• 训练轮数：80
• 学习率调度：余弦退火，最后20轮降到1e-5

运行了20轮左右，训练集准确率已经接近95%，但验证集准确率只有78%，过拟合的迹象很明显。这时候我没急着加大数据增强强度，而是先检查了验证集数据构成，结果发现验证集中某个人的样本在角度分布上跟训练集中其他人的差距过大。

解决方式也简单，把那位采集对象的部分样本重新划分到训练集中，确保验证集中每个类别都覆盖到不同的身体形态和动作习惯。调整之后，过拟合现象明显缓解，验证集准确率稳定到了86%。这个细节，我建议各位在做自己数据的时候也特别注意——划分数据集别只按“随机”，要按“人员”和“场景”分开，否则性能评估就是一场自欺欺人。

3.4 评估维度：准确率之外的三个指标

准确率只能说明“分类对不对”，但对动作类项目来说，分对了还不够。我并行跟踪了三个额外指标：

• 分类稳定度：同一个动作连续重复10次，模型输出类别的变化次数。如果模型在几次之间反复横跳，说明分类边界很脆弱。
• 时间灵敏度：发力起始帧前后，预测置信度曲线的坡度。坡度越陡，说明模型对起手时的动作越敏感。
• 姿态缺失鲁棒性：手动抹去部分关键点后，测试模型输出是否还稳定。这个指标直接关系到实际部署时部分遮挡的可用度。

这三个指标不在理论书里，却是实际项目中最会痛的部位。我见过太多模型在测试集上亮眼，一到真实现场就“变异”，本质上都是在这些维度上没做够功夫。

4. 实操过程与推理部署细节

训练完成只是开始，把模型从训练环境搬到实际应用场景，才会碰到另一批问题。day3的实操下半场，就是在处理推理性能、跨平台转换和实时可视化。

4.1 从PyTorch到ONNX的转换要点

我的目标运行环境不一定有GPU，且可能有不同的推理框架。所以模型从PyTorch转换到ONNX格式是必然路径。转换过程本身很简单，但有几个细节值得注意：

输入尺寸必须是动态或固定的明确值。我选择固定输入为“1 x 32 x 34”的张量，尺寸固定，能最大程度压榨推理引擎的优化空间。

ONNX导出时把opset version设为较高的版本，比如17或18，这样能兼容更多新的算子，避免推理端不支持某些高版本算子。

转换之后一定要做数值比对验证。转换前后模型的输出差异应极小，如果出现明显偏差，优先检查是否有自定义算子或动态控制流。我这次转换后的最大输出差异在1e-4以内，可以认为是无损。

4.2 CPU推理的优化手法

ONNX模型在CPU上的推理，默认配置和优化配置差距很大。我用的是ONNX Runtime，配合以下优化手段：

• 开启图优化级别为全量优化，让推理引擎做算子融合和布局优化；
• 线程数设为物理核数的一半左右，避免线程切换开销抵消并行收益；
• 开启动态形状优化的关闭选项，因为我已经固定了输入尺寸。

这三项操作做完，单帧推理时间从约20毫秒降到了约8毫秒，这个量级已经能支撑实时交互需求。很多人会忽略这些细节，直接默认配置，白丢一半性能，特别可惜。

提示：在自己做推理优化的过程中，每次改动只动一个变量，然后用同一批输入做时间统计。不要同时改线程数和图优化级别，不然出了问题根本找不到是哪一项导致的回归。

4.3 实时推理管道与可视化

为了让模型不只是“离线性能好”，我搭了一条完整的实时推理管道：

• 视频帧采集：OpenCV的摄像头读取
• 姿态估计：MediaPipe跑关键点提取
• 数据预处理：归一化和特征计算
• 模型推理：ONNX Runtime跑分类
• 可视化：置信度显示、关键点连线、动作类别标签

这条管道跑起来的流畅度基本上取决于姿态估计那一步的耗时占比，分类模型本身几乎不构成瓶颈，Model部分200层不到的卷积网络在CPU上的开销有限。姿态估计优化我没有专门深抠，因为当前帧率已经够用。

这段管道代码的设计有个小心得：姿态估计模块和推理模块应该解耦，可以分别测试，也可以单独替换。比如有一天你想把MediaPipe换成别的姿态模型，只需要改一个模块的接口实现，不用动训练和推理逻辑。

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

day3实操里遇到的坑比想象中多，我把相对有代表性的几个记录下来，每个都附上了排查思路和恢复过程。

5.1 关键点抖动幅度过大

现象是姿态估计出来的关键点曲线噪声非常明显，尤其在脚踝和手腕处，单帧之间坐标可以跳动10个像素以上。这个程度的抖动会直接干扰后续特征计算，导致角度特征不稳定。

排查时分了两条线：一条看光线条件，发现逆光场景下检测质量严重下降；一条看帧率因素，低帧率下快速动作的模糊帧明显更多，检测器无能为力。

解决方案是双管齐下：采集端调整了补光，避免强逆光；算法端在关键点提取后加了一组平滑滤波，对置信度低的关键点做插值修正。注意别把平滑强度拉太高，否则真实动作变化也被抹掉了，我花了两小时找到合适的窗口长度和采样策略，平衡了平滑和保真。

5.2 训练损失震荡不收敛

某次调整了特征组合之后，重新训练时发现损失曲线在高位震荡，完全没有下降趋势。一开始怀疑是学习率太高，但调低后依旧震荡。

后来对比代码才发现，问题出在数据加载时打乱了时序样本内部的帧顺序。这就好比是让模型从一篇文章倒着读，当然学不到东西。

这个坑比较基础，但值得一说：对时序数据做任何“打乱”操作时，一定要确认打乱的对象是“样本”，而不是“帧”。加了shuffle的在线加载逻辑时永远要检查维度顺序。

5.3 模型对同一人不同状态的误判

在真实摄像头测试时，同一采集对象换了一件衣服、换个背景，模型从原本识别正确的状态变成了错误分类。这个现象的本质是模型过拟合到了背景纹理和颜色信息，而不是纯粹的动作形状。

我没有走回头路去重新准备一堆新数据，而是先做了个快速验证：把关键点可视化叠加出来，看模型预测时聚焦的区域。观察发现，模型严重依赖了上半身的坐标信息，而下半身的防御动作特征参与度不高。

调整策略是增加下半身特征的权重因子，并额外加了脚踝轨迹相对于髋部的偏移量作为附加特征。调整后误判基本消除。这个经历很直观地说明了，对动作类模型的优化，要结合骨架特征来分析，而不是一味堆网络层数。

5.4 ONNX推理结果与PyTorch不一致

转换后个别样本的分类结果不同。排查了很多环节，最终定位是输入标准化方式不一致——PyTorch训练时用的是每帧单独计算的特征归一化，而推理时不小心把整个序列一起归一化了。这个差异虽然细微，但对数值敏感的CNN来说是致命的。

解决方案很简单：把训练和推理的数据预处理封装成同一个函数，统一调用，从根上规避两类实现不一致的风险。这个经验值得记牢，很多部署翻车都源自训练框架和推理框架里“看起来一样但实则不同”的预处理逻辑。

6. 性能评估与瓶颈分析

模型和管道都有了，不能稀里糊涂说一句“效果不错”。我把我采用的量化评估方式、瓶颈分析和后续优化空间整理一下，方便你们直接参考。

6.1 关键指标一览

从这张表能看出一个很典型的瓶颈分布：姿态估计耗时是模型推理耗时的大约2.5倍。分类模型本身已经做得够轻了，进一步优化端到端帧率的空间主要在于替换更轻量或更高效的姿态估计方案，而不是继续缩小分类模型。

6.2 场景复杂度的影响

测试了三种典型场景：室内固定光源、室内混合光源、带部分遮挡（肢体偶尔被沙袋挡住）。分类准确率从最理想条件下的86%下降至遮挡场景的71%。部分遮挡场景下，膝盖点丢失频率最高，这直接破坏了防御动作的特征输入。

针对这个现象，我的后续计划不是增加模型的复杂度，而是在数据层面做更多遮挡模拟。把人工合成的随机遮挡块覆盖在关键点区域，模拟真实场景中的数据缺失，让模型学会“缺了也能猜”。这个方向虽然训练期会变长，但效果一定比事后补模型要靠谱得多。

6.3 对部署平台的扩展考虑

目前按PC平台的CPU推理来看，性能是足够的。但如果要挪到移动端或用更低功耗的设备跑，还需要做模型量化。我尝试过静态量化方案，模型大小从约9MB压缩到3.2MB，推理精度下降小于2%，但推理速度并没有明显提升。原因是当前模型本身已经很小，计算量天花板比较低，量化带来的收益自然没那么显著。移动端的真正瓶颈还是在姿态估计这部分，后续如果要移植到嵌入设备，这一步必须换更极致的方案。

7. 复盘与改进方向

这一部分不是空泛的展望，是我在day3收尾时真实做的复盘。几个判断和结论是比较笃定的，写下来供参考。

7.1 当前方案的局限性

现在的模型只能处理“单人”“固定视角”“三类动作”，离一个真正可用的格斗动作分析系统还有明显差距。其次是时域建模的跨度有限，32帧窗口大约只能覆盖0.5秒左右的动作过程。对连续组合动作，比如“直拳接摆拳再接提膝防御”，当前方案会切碎分析，丢失动作之间的过渡关系。

时序窗口的扩大虽然可以缓解这个问题，但会引入更多噪声帧，同时增加类间模糊性。更合理的解法应该是把“动作分割”和“动作分类”做成两个阶段，让分割模型先定位动作边界，再对每个边界内的段做分类。

7.2 短期可落地的改进

我在复盘里排出了接下来要做的几件事，按投入产出比排序：

• 把动作采样窗口从固定改为动态——通过检测关键点速度突变量来判断动作的起始帧和结束帧，自适应截取动作段；
• 加一个时序注意力模块——让模型在分类时更关注发力的前中后期特征，而不是均匀对待整个窗口；
• 补充下半身角度特征——尤其是髋关节和膝关节之间的角速度变化，这对防御动作的识别提升效果最直接；
• 数据层面，增加更多不同身高的采集对象，并加模拟遮挡增强，提升真实场景鲁棒性。

这些改进不涉及根本性框架的更换，是在现有方案上做迭代，成本可控，预计效果明确。

7.3 对同类项目的通用建议

如果看到这里，你也在做类似的动作分析类项目，我给你几条基于这次实操总结的建议：

• 数据的“标注层次”要超过模型所需的最基本要求。宁可多标一些暂时用不上的信息，也不要后面回头翻工。
• 不要把模型训练和部署割裂开，train时用的预处理、归一化、采样逻辑，必须和inference完全一致，最好直接共用函数。
• 性能评估不要只看“分类对错”，要拆成时序稳定度、遮挡鲁棒性、端到端延迟等多个指标，分开卡关。
• 项目day3是最好的“后悔时间点”——这时候重做数据标注还来得及，等模型训完再回头看数据问题，代价会大得多。

注意：如果你是新手想参考这个项目，我建议别一开始就急着端到端复刻，先跑通单帧姿态估计，再跑通分类模型，再把两者拼接。一步到位出问题的概率极高，且到时候你根本说不清楚问题出在了哪一环。

8. 最后一点个人体会

说句实话，day3这个节点，项目中还看不到那种“哇”的效果。不会有模型在擂台上做炫技般的预测，也没有光鲜的UI界面。但这三天的推进，让我对这个项目的“底座”把关越来越有把握：数据是可信的，模型是稳定的，管道是可用的。这些东西呢，恰恰是后面一切花哨功能的地基。

最有价值的不是模型本身，而是“数据-标注-训练-复盘”这个完整闭环跑顺的节奏。节奏对了，后续加动作类别、加视角、加场景，都只是按部就班地重复这个流程而已。希望这篇day3的记录，能帮你在自己的AI动作分析项目里，少踩几个我踩过的坑。