家好，我是子衡，嵌入式 AI 工程师，《嵌入式AI：让单片机学会思考》主理人，专注AI在MCU上的落地实践。
我的上一篇文章，嵌入式AI落地避坑指南：用6个步骤找到最适合本地AI的产品场景（建议收藏备用）主要讲了大家应该如何判断自己的应用场景适合做本地AI。下面罗列出来，哪些常营不适合做本地AI？
一、不需要实时判断的场景，通常没必要做本地AI
先看最常见的一类误区：业务本身并不要求设备立刻做判断，却还是想把模型放到本地。
比如一些系统只是每天汇总一次数据，生成日报、周报、趋势图，或者做离线统计分析。这类任务的核心不是"马上出结果"，而是"后面统一分析"。既然动作不着急，就没有必要把推理过程前移到设备端。放在云端或者后台系统中处理，通常更省事，也更容易维护。
还有一种情况，是输入数据本身就不连续。设备不是持续产生高频数据，而是隔很久才上报一次状态量、计数值或者简单事件。在这种场景下，本地 AI 最重要的几个优势基本发挥不出来。因为本地部署最适合处理的，往往是连续流式数据，比如音频、振动、图像帧、时序波形。只有数据持续产生，本地"边采边判"的价值才明显。如果数据本来就稀疏，实时推理往往只是看上去很先进，实际并没有解决关键问题。
二、数据条件不成立的场景，不适合急着上本地AI
很多项目最后失败，不是因为芯片不够强，也不是因为模型不够先进，而是因为数据本身就不具备建模条件。
最典型的问题，就是拿不到稳定标签。你连什么叫正常、什么叫异常、什么叫触发、什么叫不触发都说不清楚，模型自然也学不清楚。
还有一些场景虽然表面上有标签，但实际上并没有可验证标准。比如某些设备状态，本来就依赖老师傅经验判断。或者这些判断就像领导的"左右脑互博术"（今天说这样算异常，明天又说那样也算异常，团队内部都没有统一标准）。这类场景也不适合做本地AI。
所以，任何本地 AI 项目在立项前都要先问一句：这个任务到底有没有清晰、稳定、可重复的输入输出关系？如果这件事本身说不清楚，就不应该急着谈部署。
三、设备资源明显撑不住的场景，不要硬做
本地 AI 不是没有边界。尤其是 MCU、低功耗边缘节点、传感器终端这类设备，资源限制一直都在。
如果一个场景必须依赖很大的模型，必须使用复杂算子，或者推理时还要占用大量 RAM、Flash、带宽和供电预算，那它从一开始就不适合做本地推理。（为啥不适合，自己想去吧，贺老师不在此重复）
很多人评估一个本地 AI 场景时，只盯着模型精度，这是远远不够的。真正该看的，是精度、推理时间、峰值内存、程序空间、功耗、系统耦合度这些指标能不能同时过线。只要其中一个明显超标，这个方案就不适合在当前设备上落地。
说得更直接一点：如果为了上本地 AI，你不得不大改硬件、升级芯片、增加存储、提高供电规格，最后连整机 BOM 和开发周期都被重新推翻，那这个场景就要重新评估。因为你做的已经不是"优化产品能力"，而是在重做一套产品。
四、先判断值不值得，再判断能不能做
本地 AI 不是不能做，而是要先找对场景。
真正适合做本地 AI 的，一般是那种数据持续产生、判断必须及时完成、网络条件又不稳定、上传原始数据成本高，同时传统规则已经越来越难维护的场景。反过来，如果一个任务不要求实时响应、数据又不连续、标签也不稳定，或者设备资源明显撑不住，那就不应该急着上。
很多项目之所以走偏，不是技术不行，而是一开始场景选错了。产品还没想清楚到底为什么要放在本地，就先开始研究模型、量化、部署、加速，最后投入了很多精力，结果业务收益并不明显。
所以，做本地 AI 之前，最重要的不是先问"模型怎么做"，而是先问"这件事为什么一定要在设备端做"。这个问题想清楚了，后面的路线才不会跑偏。
