干这行多年，今天翻项目台账，顺手聊聊点实在的——都是这些年踩坑踩出来的心得，没什么高大上的概念，全是落地现场的糟心事。

这两年去安博会，展台演示还是那套熟悉的路子：烟火识别一秒定位、摔倒检测秒级弹窗、设备故障提前半个月预判，数据漂亮得很。旁边几个年轻工程师看得两眼放光，我跟老同行在边上笑，心说等真拉到项目现场，就知道有多难伺候了。见过太多项目，演示会上客户当场拍板签合同，真交付的时候误报满天飞，验收卡半年，最后不上不下成了半拉子工程，尾款拖着结不了。

很多人一上来就怪算法不行，其实真不全是。AI项目落地难，难的往往不是算法本身，是算法之外一堆细碎的工程烂事，一点点把项目周期、利润全耗光了。

一、先说说算法那点事：实验里的准，不算真的准

最直观的差距，就是训练数据和现场环境，根本是两码事。算法公司训模型用的数据集，全是标准光照、正对目标、特征干净的理想样本；真到了项目现场，逆光、背光、镜头落灰、杂物挡画面都是家常便饭，赶上阴雨天画面发灰，准确率直接往下掉一大截。

前几年温州那个汽配厂区的项目，我到现在印象还深。烟火识别算法实验室标称准确率97%，刚上线实测也就八成出头。夏天更离谱，厂区边上梧桐树长得旺，风一吹枝叶晃影子，正午阳光斜射的光斑，都能被算法当成烟雾，一天蹦十几次告警。最后保安队嫌烦，直接把弹窗通知关了，等于白装。

比环境适配更隐蔽的是模型漂移，也就是行里常说的模型衰减。不少人觉得算法上线就完事了，可现场场景是一直在变的：仓库堆货挪了位置、工位加了新设备、换季光照角度不一样，这些全是训练集里没有的新数据。正常来说，上线三个月后准确率掉10%到15%是行业常态，没人持续迭代的话，半年下来基本就没法看了。

还有个误区，很多人总觉得通用算法能打天下。实际上越细分的行业，场景差得越远。就拿跌倒检测说，放养老院里，老人走路慢、弯腰幅度大、坐轮椅的多，通用算法很容易误判；放工厂车间，工人穿工装戴安全帽，频繁蹲起搬东西，又是另一套特征。别指望拿个开源模型改改就能用，细分场景的适配工作量，不比重新训模型小多少。

二、最容易被忽略的坑：一半人力耗在接设备上

我见过不少开发团队，一上来就扎进算法优化里死磕，最后回头一算账，一半以上的人力，全耗在了设备接入和数据对齐这种基础活上，纯纯的无效劳动。

现在线下场景的设备太杂了。摄像头海康、大华、宇视各有各的私有协议，GB28181算是通用标准，可各家扩展字段、信令细节都有出入；传感器更乱，Modbus、MQTT、LoRa、DLMS，一个厂商一套规矩。早些年做连锁酒店项目，光给七八款设备写驱动、调协议适配，就耗了三四十人天，项目周期直接拖了三分之一，利润全被对接成本吃掉了。

最头疼的还不是接设备，是数据时间对不上。烟感报警的时间戳、摄像头的帧时间、门禁的刷卡记录、业务系统的状态数据，各走各的本地时钟，差几秒甚至几十秒都是常事。想做“传感告警+视频复核”的联动逻辑，时间戳对不齐，联动根本就是空谈。

后来行业里慢慢有了成熟的方案，比如畅联云平台这类开放底座，主流的视频、IoT协议基本都提前适配过一遍，统一输出带标准时间戳的结构化数据，确实能省掉大量重复造轮子的功夫。但话说回来，底座只是把数据入口理顺了，算法怎么训、业务逻辑怎么搭，还是得自己磨，别指望买个底座就能解决所有问题。

三、工程和运维：上线才是麻烦的开始

算法调通了、设备接好了，也不代表项目就能成。工程实施和后期运维里的坑，一点不比技术本身少，很多项目死就死在这上面。

首先是现场资源的限制。很多人一开始想把算法放云端跑，可几十路高清视频回传，带宽成本高得吓人，普通客户根本承担不起；推到边缘侧跑吧，网关算力就那么多，大模型塞不进去，只能上轻量化版本，精度自然要打折扣。再加上厂区、园区的网络环境，懂的都懂，一到阴雨天4G信号飘得厉害，边缘网关时不时断连，客户可不管你什么客观原因，就看告警准不准、能不能用。

其次是模型运维的缺失。绝大多数项目都是“上线即终点”，交付完就没人管了。可现场环境一直在变，今天加个货架、明天换个灯光、后天路面改了标线，模型没见过这些新场景，准确率就慢慢往下滑。等客户发现不好用的时候，已经差得没法看了。说白了就是MLOps没跟上，多数集成商团队里连个专职做模型迭代的人都没有，上线全靠一锤子买卖，后期出问题只能临时救火。

最磨人的还是客户预期管理。不少甲方觉得AI就是万能的，必须100%准确，漏一个、误一个都不行。可行业现状是，成熟场景能做到95%准确率就算不错了；就这95%，放到一周几十次告警里，也能碰上两三次误报，客户就会觉得你这东西没用。我见过最夸张的甲方，要求摔倒检测零误报，说有一次误报就扣尾款，这根本不现实。预期没提前掰扯清楚，项目验收能给你拖到天荒地老。

 四、踩坑踩多了，也攒了几条实打实的经验，权当给大家提个醒。

第一，别上来就死磕算法，先把数据底座选明白。协议对接这种重复劳动，能交给成熟底座就交给底座，像美畅物联的智能物联中台这类，市面上主流的设备基本都适配过了，把人力省下来做业务逻辑、做场景适配，比自己闷头写驱动性价比高太多。

第二，算法选型别迷信榜单精度，拿现场数据实测。开源排行榜上准确率再高，放到你的项目场景里不一定好用。签合同前一定要拿客户现场的真实数据跑一轮，重点看错报率、漏报率能不能接受，别等项目做了一半才发现算法不落地，进退两难。

第三，项目前期就把AI的能力边界说透。别为了拿单吹得天花乱坠，哪些场景能做、哪些做不了，准确率大概在什么水平，误报率大概多少，提前跟客户讲清楚。预期管理做好了，后面验收、运维能少一半麻烦。

第四，先打通数据链路，再谈AI应用。别项目刚启动就堆一堆AI功能，先把设备接进来、数据跑通、时序对齐，基础链路跑稳了，再往上加算法功能，一步一步来，比贪多求全稳得多。

干了这么多年，早就不信什么一招鲜的方案了。AIoT项目从来不是算法单打独斗就能成的，算法决定了效果的上限，物联底座决定了落地的基础，工程实施和运维决定了能不能长期用下去，三者缺一个，项目都容易掉链子。

别迷信什么“万能AI算法”，也别觉得有了中台就一劳永逸。这行拼到最后，拼的还是工程能力——是把一个个细碎的坑填上，把演示厅里的完美效果，变成现场能稳定跑、客户真能用的东西。务实一点，把基础打牢，比追什么新概念都管用。