大家好，我是子衡，嵌入式 AI 工程师，《嵌入式AI：让单片机学会思考》课程主理人，专注AI在MCU上的落地实践。
自从做嵌入式 AI 课程以来，我经常会被问到一个问题：单片机上部署 AI，到底有没有真正有产品价值、又不是只停留在演示层面的应用场景？
如果只选一个最典型、最容易讲清楚、也最适合 MCU 落地的案例，我会优先讲动作识别。
这里说的动作识别，不是摄像头做人像关键点，也不是手机上那种复杂的人体行为分析，而是更贴近嵌入式产品的那类场景：通过加速度计、陀螺仪、IMU 这些传感器，识别设备或人体当前在做什么动作。比如抬手、翻转、摇一摇、敲击、跌倒、走路、跑步、姿态切换，或者某种特定手势触发。
这个场景之所以有代表性，不是因为它"听起来智能"，而是因为它非常符合 TinyML 真正擅长解决的问题：传感器数据连续产生，判断需要在本地快速完成，模型规模可以压得比较小，而且结果通常要直接参与设备交互、状态切换或者控制逻辑。可以参考小编的上一篇文章嵌入式AI落地避坑指南：用6个步骤找到最适合本地AI的产品场景（建议收藏备用）
说得更直接一点，动作识别不是为了给产品加一个"AI 标签"，而是为了让设备在本地多出一层对时序模式的理解能力。
我在另一篇文章中讲解的识别小女孩的动作，是一个非常非常的典型的例子，感兴趣的可以去了解了解。为什么STM32这种MCU也要"跑AI"？怎么跑？
动作识别最难的地方，不在模型，而在数据
如果只看表面，动作识别似乎很容易：采一段 IMU 数据，打个标签，丢给模型训练就行了。真正做过的人就知道，最容易出问题的地方恰恰不是模型，而是前面的数据采集和标注。
最典型的问题，是同一个动作不同人做出来差别非常大。
比如"抬手"，有人动作幅度大，有人动作很轻，有人抬得快，有人动作慢，有人手腕翻转很多，有人几乎只是一个微小抬升。你如果只让一两个人采数据，模型最后学到的很可能不是这个动作本身，而是"这几个人做动作的习惯"。
第二个典型问题，是安装位置和传感器朝向。
传感器固定在手腕、胸前、工具手柄、设备侧面，波形分布都不一样。你要在模型设计之前先把一个基本问题讲清楚：这是一个"固定安装方式"的识别任务，还是一个"安装存在偏差也要兼容"的识别任务。如果这个边界不清楚，后面模型效果经常会在实验室很好，上机后立刻掉下来。
第三个问题，是动作边界。
你到底怎么定义一个动作的开始和结束？中间的过渡段算不算进去？静止背景保留多少？窗口是固定切，还是对齐动作中心切？这些决定了标签质量。动作识别不是拍几段视频看看效果就行，它对时间对齐非常敏感。训练时标签稍微乱一点，模型学出来的边界就会模糊，最后表现出来就是误触发多、识别不稳定、不同批次数据结果差异很大。
所以动作识别真正想做稳，数据采集必须有明确约束。动作要覆盖不同人、不同速度、不同力度、不同使用状态；正常背景要充分采；负样本要足够多，尤其是那些"看起来像目标动作，但其实不是"的干扰动作，更应该重点采。比如你做抬手识别，真正最有价值的负样本不是静止，而是走路、摆臂、快速拿起设备、轻微调整姿态这些容易混淆的动作。模型最后能不能抗误触发，很多时候决定因素不是正样本够不够，而是这些难负样本有没有采够。
模型到底该怎么设计，才更适合 MCU
动作识别落地时，模型设计不是越复杂越好，而是要和输入形式、资源预算、识别目标一起考虑。
如果你的输入是窗口特征，最常见的模型就是小型 MLP。它的好处是结构简单、推理稳定、部署容易，缺点是对原始时序细节利用不如序列模型。对于很多单动作检测、简单活动识别场景，这已经足够。
如果你的输入是原始窗口序列，1D CNN 往往是更合适的选择。因为它对局部时序形态更敏感，能自动从原始波形中提取一些局部模式，同时参数量和推理成本仍然可以控制在 MCU 可接受范围内。相比之下，RNN、LSTM 这类模型虽然在理论上适合序列，但在很多 MCU 场景下不一定是第一优先级，因为资源占用和算子支持通常更麻烦。
这里一定要强调一个原则：动作识别项目里，模型首先要满足资源约束。Flash 放不放得下，RAM 顶不顶得住，推理延迟是否满足交互要求，这些都比"离线精度再涨 1%"更重要。因为对一个产品来说，准确率不是唯一指标。长期在线能不能稳定跑，功耗能不能接受，边界动作会不会误触发，这些同样重要。
因推荐规则变化，多点赞和在看**，我们才能常出现在你的推送里。**