小区居民楼里的消防隐患有个很别扭的特点：真出事的时候都是大事，但平时看上去又都是些不起眼的小事。楼道拐角堆两袋旧纸箱、电井门口靠一辆电动车、天井里飘一缕不知道哪来的白烟，人走过去都不会多看一眼。可一旦烧起来，楼道就是唯一的逃生通道，浓烟顺着竖井往上蹿的速度远比人跑得快。这几年不少小区开始上烟火检测和楼道杂物堆积检测这两类消防隐患AI智能识别能力，思路是把摄像头从“事后查录像”变成“事前会喊人”。我前后参与过几个小区的落地，从选型、标注、调参到验收全套走下来，最大的感受是：这两件事看着都是“AI识别”，底层逻辑却完全不是一回事，用一套思路去做必然翻车。下面把我自己的做法和踩过的坑摊开讲，适合准备做社区消防智能化的工程人员、物业技术负责人，也适合刚接触视觉算法想找一个真实落地场景练手的同学。

1. 两类消防隐患，两套完全不同的识别逻辑

1.1 传统手段在居民楼里的三个明显缺口

先想清楚为什么要上视觉。居民楼现有的消防手段主要是室内烟感、灭火器巡检、人工巡查和群众报警，这四样各有各的盲区。室内烟感装在住户家里和公共走道顶部，但天井、电井、水井、地下车库坡道、屋顶平台、垃圾房这些位置基本是空白，而这些恰恰是堆物和阴燃的高发区。人工巡查的问题更直接：一个中等规模小区几十部电梯、上百个楼层，保安一晚上能爬几栋？实际执行下来往往是“重点楼层一周看两次”，剩下的靠运气。

群众报警则天然滞后，等有人闻到焦味打电话，很多时候已经在冒明火了。

摄像头的价值就在这里。它不需要新增布线，绝大多数小区本来就有覆盖楼道、车库、天井的监控点位，把视频流接出来做分析，边际成本很低。但这里有个特别容易被忽略的前提：摄像头当初是按“看得见人”装的，不是按“看得清烟”装的。安防点位追求大视野、广角，一个枪机要覆盖整条楼道，结果就是远处一个烟头大小的火点只有十几个像素。这个矛盾后面会单独讲，先记住它是很多项目“演示很准、上线很瞎”的根源。

1.2 火焰烟雾是“事件”，杂物堆积是“状态”

这是我认为整个项目里最重要的一个认知分水岭。

火焰和烟雾是事件型目标：它此刻不存在，下一秒可能就出现，出现之后每一秒都在变化。对这类目标，系统的核心指标是响应延迟和漏报率，业务上的容忍度是“宁可多报几次，也不能真烧起来没报”。一栋楼里一天冒出二十条误报，值班人员会骂娘，但能接受；漏报一次真火，性质就完全不同了。

楼道堆物是状态型目标：那堆纸箱可能已经在那儿放了三个月，明天还在。对这类目标，核心指标是判定准确和重复报警抑制，业务上最怕的是“同一堆东西一天报八十遍”，报到最后没人看。它的时效性要求低得多，小时级甚至天级都够用，但要求“报了就得有人去清，清完系统得知道”。

这个差异会一路传导到后面所有的设计上：模型怎么选、阈值怎么定、需不需要时序确认、报警怎么分发、验收怎么算。我见过有团队拿同一套逻辑硬套两个任务，烟火那边不敢调高阈值导致误报爆炸，堆物那边又因为学了事件的瞬时性导致一天报警几百次，最后两边都被物业关掉了。

2. 烟火识别：真正的对手不是火，是误报

2.1 单帧检测器为什么注定误报

刚开始做的时候，几乎所有人的第一反应都是“标一批火焰和烟雾的图，训一个检测模型就完事”。这么做Demo阶段效果会好得出奇，因为测试集和训练集同源，模型学到的其实就是“橙红色的、边缘不规则的、有亮度的东西”。一放到真实小区，误报源能列一长串：厨房排出的水蒸气、冬天供暖管道的白雾、垃圾房焚烧纸钱的烟、婚庆放的冷烟花、焊接施工的火花、夕阳斜照进楼道打在玻璃上的反光、红色雨伞、红色塑料凳、汽车尾灯的倒影、甚至住户晾晒的红色被单被风吹起来的形状。

本质上，单帧图像里“烟”和“水蒸气”的像素分布几乎一模一样，都是低对比度的灰白半透明区域。你让模型靠一帧画面区分它们，是在要求它做一件信息量不足的事。这不是模型不够强的问题，是输入信息本身不够。

我的做法是把任务拆成三层：第一层单帧召回，宁滥勿缺；第二层时序验证，把瞬时干扰筛掉；第三层区域与业务规则，把已知干扰源挡在门外。单帧模型的阈值可以压得很低，比如置信度0.15就放行，只要后面两层能收得住。

2.2 常见误报源清单与对应的工程化消解手段

把误报当成一个需要持续维护的清单，而不是一次调参能解决的问题。上线前我会和物业一起把小区里所有“会冒烟、会发光、会飘东西”的点位过一遍，形成一张对照表。

这张表不是一次写完的，是每次误报复盘后往里加。我建议在系统里内置一个“误报样本回流”的通道：值班人员点一下“误报”，那张图、那个片段自动进样本库，每周挑一次做增量训练或者规则补充。这个闭环比任何单次调参都值钱。

2.3 时序确认：把“像”变成“在烧”

时序验证我一般用三个信号叠加，任何一个不满足就往下压等级：

第一个是持续性。真实的火焰在视频里是连续存在的，即使有轻微抖动，也不会在第3帧突然消失又第5帧回来。做法是维护一个滑动窗口，最近N帧里命中帧数占比超过阈值才算确认。N的取值和帧率相关，15fps的情况下我通常取30帧窗口（约2秒），要求命中率≥60%。

第二个是形态演化。烟和火都有一个“生长”的过程。火焰面积会从小变大，烟雾区域会向外扩散。可以用帧差或者简单的区域生长算一个面积变化率，如果一块“烟”在两秒内面积几乎不变、位置也不动，那大概率是背景里的固定物体被误识别了。

第三个是动态特征。火焰有独特的闪烁频率（大致在5到15赫兹区间有明显的能量峰），这个用相邻帧的亮度差分做频域分析就能抓到，计算量很小，很适合放在边缘侧。烟雾则更依赖纹理运动，可以看局部区域的运动矢量是否呈现由下往上的整体漂移。

提示：时序确认会增加延迟，一般多出2到4秒。这个代价必须提前和业务方讲清楚，否则验收时会被拿“反应慢”说事。我的经验是把延迟写进需求文档，明确“从出现明火到推送不超过8秒”，而不是含糊地说“实时”。

2.4 小目标和夜间：采样策略决定上限

前面提过，安防摄像头的视野是为看人设计的。一个标准楼道枪机挂在顶端，距地面2.8米左右，画面里一个30厘米高的火苗可能只占纵向20个像素。这种尺度下，不管你用什么模型，召回率都会掉得厉害。

有三个办法，按性价比排序。第一是改点位，把烟火检测专用的摄像头装在更容易出现隐患的位置——电井口、垃圾房、天井底部、车库坡道，用中焦距镜头把视野收窄，别贪大而全。这一条最有效，但涉及施工，要提前协调。第二是切ROI，把整幅画面切成若干感兴趣区域，对小区域单独做一次上采样推理。代价是算力翻倍，一个点位跑4个ROI，边缘盒子的负载要重新算。第三是双光融合，加一路热成像，用温度异常做前置触发，可见光只负责确认。热成像对明火极其敏感，几乎不会漏，但成本高，一般只用在重点部位。

夜间还有个隐性坑：很多楼道用的是红外补光摄像头，画面是黑白的，火焰的红色特征完全丢失，只剩亮度信息。这时候如果模型主要靠颜色特征学出来的，夜里直接就瞎了。解决办法是在训练集里必须包含相当比例的红外/黑白样本，并且把颜色通道的依赖降下来。我一般要求红外样本占比不低于30%，否则模型在夜间就是个摆设。

3. 楼道堆物：把它当“状态比对”，而不是“目标检测”

3.1 先划通道基线，再谈占用

堆物检测最容易走的弯路，是直接训一个模型去识别“纸箱”“旧家具”“自行车”“花盆”。这条路走不通，因为要堆的东西千奇百怪，你今天标了纸箱，明天住户搬来一摞泡沫板，后天是几袋水泥。目标类别是开放集合，模型永远追不上。

换一个思路：不识别“什么东西”，只判断“通道还通不通”。楼道在规范意义上是有明确可通行宽度要求的，那就先在画面上把“应当保持畅通的区域”用多边形画出来，这个区域我叫它基线通道。然后判断这个多边形内是否被非背景物体侵占、侵占了多少。这样无论堆的是什么东西，只要它占了地方，就能被发现。

基线怎么划是有讲究的。不能简单画个矩形，因为楼道里本来就有消防栓箱、管道井门、配电箱、消火栓、地脚线，这些是合法存在且不能动的。我的做法是分两步：先让物业工程人员按楼层平面图标出“净宽必须保留”的那条带，通常是沿墙面内侧留出1.1到1.2米的通行带；再把消防设施、电表箱这些固定物作为“豁免区”从基线里挖掉。这一步做完，误报能直接降一大半。

3.2 占用程度怎么量化，才不会天天扯皮

只说“有堆物”是不够的，物业需要知道严重程度，才能决定是打电话提醒还是当天派人清。我一般输出三个量：

• 占用面积比：侵占像素面积除以基线通道面积。低于10%基本忽略，10%到30%算提示级，超过30%算告警级，超过50%算严重，直接进重点工单。
• 有效通行宽度估计：这个是业务方最爱看的。做法是把基线通道按透视关系做一次简单的逆投影近似，把像素宽度折算成厘米。虽然是近似值，但比“面积比”直观得多，物业一看“还剩40厘米能过人”立刻就懂严重性了。
• 滞留时长：这是区分“临时挪一下”和“长期堆放”的关键。刚放上去半小时的东西不该报警，放了三天的那是隐患。用状态机来管：首次检出建一个跟踪ID，之后每隔一段时间比对一次位置和面积，IoU超过阈值就认为是同一堆东西，累加存活时长；连续若干个检测周期都消失才判定为“已清除”。

注意：滞留时长这个字段一定要落库，别只放在内存里。边缘设备重启、断电、升级固件都会丢状态，一丢就重新计时，结果就是放了半年的旧沙发永远报不出来。

3.3 反复报警抑制与工单化

堆物检测最怕的不是漏，是骚扰。同一堆纸箱，如果每五分钟报一次，一天就是288条，值班人员的处理方式一定是把这个点位静音，然后这个点位就彻底废了。

我的处理方式是把报警变成工单，让它在状态机里走完整条链路：待确认 → 已确认 → 已派单 → 处理中 → 已清理 → 观察期。同一跟踪ID在同一状态下只推一次，后续只更新滞留时长，不重复推送。清理完成之后进入观察期，观察期内如果同一位置再次出现堆物，直接升级等级——因为这说明是习惯性堆放，光清一次没用。

配套的做法是给每条工单附带一张“清理前”的截图。物业清理完拍一张“清理后”的照片回传，两边一对比，闭环才成立。这套流程听起来土，但实测下来是唯一能让系统活过半年的办法。没有闭环的AI报警系统，平均寿命不超过两个月。

4. 边缘部署：算力账和现场那些躲不开的事

4.1 点位与角度：装错了后面全是补丁

我在现场看过太多“装了等于没装”的点位。典型错误有三种：一是摄像头对着楼梯正中间，画面里全是台阶的斜线和扶手，堆物区域反而在画面边缘被裁掉了；二是逆光严重，楼道窗户在画面里，白天一片死白，什么也看不见；三是广角畸变太大，墙角的堆物被拉成一条弧线，检测框画出来完全对不上。

比较稳妥的画法是：摄像头安装在楼道一端、略高于人头的位置，俯角在15到25度之间，让画面能同时覆盖两侧墙面和地面，形成完整的通行带视野。如果是长走廊，宁可用两台分别覆盖两端，也不要一台硬扛。另外每层楼的楼梯转角平台是堆物重灾区，这个位置要么单独加点位，要么在现有画面上确认能看到至少70%的转角地面。

4.2 算力预算怎么算才不翻车

边缘盒子的选型，我一般先算一个粗账。假设一个小区有40路需要分析，其中烟火检测要跑到10fps以上，堆物检测每小时跑几次就行。那就把两类任务分开：烟火检测用轻量模型，输入分辨率可以适当降低，但要做多帧推理；堆物检测用稍重一点的分割或检测模型，抽帧处理，比如每5分钟取一帧。

单路烟火检测在中等算力的边缘盒子上大概能跑到15到25fps，那40路就是明显超载的。解决方式是前端降帧 + 事件触发。平时只跑3到5fps做粗筛，一旦触发疑似目标，立刻把该路切到高帧率精检。这样平均负载能压下来一大半，而响应延迟几乎不受影响。堆物检测则完全可以放到夜间低峰时段批量跑，白天一小时一次足够。

另外提醒一个容易忽略的点：解码也是要算力的。40路1080p的RTSP流同时解码，对盒子来说可能比推理本身还吃力。要么用支持硬件解码的芯片，要么在接入层做转码，把分析用的辅流降到720p甚至D1。用辅流做分析、主流用来看回放，这是标准做法，别图省事只用一路流。

4.3 断网、抖动与存储

小区网络环境比办公室差得多，交换机老化、光纤被挖断、物业机房跳闸都是常事。系统必须具备断网自治能力：检测照跑，告警先落本地，网络恢复后补推。本地至少要能存三天的告警事件和关键帧，别只存一个标志位，那样事后复盘什么都看不到。

还有一个细节是时间同步。多个点位的告警要能按时间排序、要能和录像对上，设备之间时钟偏差超过几秒就会很难受。建议现场部署一台内网的时间源，所有边缘设备和摄像头统一校时，这个小动作能省掉后面无数扯皮。

5. 从“报了”到“处理了”：分发链路与验收口径

5.1 分级推送，别把值班室炸了

告警分发我一般分三级。一级是即时推送，只给火焰和高置信度烟雾，直接打到值班室的大屏和值班手机，带声音；二级是汇总推送，中等置信度的可疑目标合并成一条，每半小时推一次；三级是日报，堆物、通道占用这类，每天早班一次性推给物业主管，附一张点位分布图。

这套分级的核心目的是保护注意力。一级通道必须保持“一响就是真事”的纯净度，为此我宁愿把大量可疑事件压到二级。可以用一个简单规则来保证：如果某个点位的一级告警在一周内误报超过3次，自动降级到二级，同时触发一次现场核查。这相当于给系统加了个信用分机制。

5.2 验收指标怎么定才不扯皮

验收阶段最容易吵架的是指标定义。我建议在合同阶段就把口径写死，别留模糊地带。

特别要强调的是“明火”的判定标准。验收时一定要用真实点火测试，而不是拿视频回放。回放可以挑最好的角度，真实点火的气流、光照、摄像头自动曝光调整都是变量。测试的时候选三个点位：一个近距、一个远距、一个逆光，各点一小堆报纸或者用烟雾发生器，记录从点火到告警的实际秒数。这一关过了，项目才算真成立。

5.3 隐私边界要提前想清楚

楼道属于公共区域，但不代表可以无限制地采集。我的原则是三条：只分析公共区域，不朝向住户入户门内侧；不做人脸识别和人脸存储；告警截图只保留与事件相关的区域，且保存期限明确告知。技术上可以做的是在推送给外部人员的截图上对无关人员进行模糊化处理，只保留堆物和通道的清晰度。

这些做法不只是为了合规，也是为了减少落地阻力。很多小区的项目卡在业主沟通环节，技术再好也推不动。提前把这些边界讲明白，反而推进更快。

6. 上线之后踩出来的几条经验

说几个只有真正跑起来才会遇到的坑。

第一是“白天准夜里瞎”这个问题的隐蔽性。我做过的一个项目，白天测试连续一周零误报、零漏报，团队都觉得稳了。结果上线第二周夜里连续报了十几次，全是楼道声控灯亮起来瞬间的强光被识别成火焰。原因是训练集里几乎没有“灯突然亮起”这种样本，模型把属于亮度突变的区域当成了火。后来加了负样本，并且要求火焰必须持续3秒以上，才压下去。这告诉我：测试必须按光照条件分时段做，白天验收等于没验收。

第二是堆物的“阴影陷阱”。楼道里的堆物在白天会拖出长长的影子，模型有时把影子也算进占用面积，导致面积比虚高，本来只是个小纸箱被报成严重堆物。后来在面积计算里扣除了低饱和度的阴影区域，问题明显缓解。这类细节在实验室里根本想不到。

第三是安装工人和算法的信息断层。施工队按“视野开阔”的原则调角度，算法那边按“能看到地面通道”的需求设计，两边没沟通，结果二十多个点位里有六个完全不可用。后来我强制要求施工完成后必须上传每个点位的“实际画面截图”并附上基线多边形草图，算法侧确认通过才算完工。这一个流程改动，把返工率从三成降到了几乎为零。

第四是清理动作的反馈缺失。系统报了堆物，物业确实清了，但没人回来点“已处理”，导致同一位置持续报警、工单越积越多，最后物业干脆不看。解决办法是把处理动作绑到人：工单推给具体的保洁班长，处理完必须拍照片回传，系统自动核验堆物是否消失（比对前后两帧的区域占用），核验不通过就打回。听起来麻烦，但这是让系统活下去的必要成本。

还有一个体会是模型更新节奏。烟火检测的模型我基本每季度做一次增量，把这段时间的回流误报样本加进去；堆物检测的模型反而很少动，因为它判的是区域占用，对物体类别不敏感，稳定性好得多。所以两个任务的运维投入完全不是一个量级，做预算的时候要分开算，别笼统地说“AI模型维护费”。

最后分享一个小技巧：给每个点位的检测结果做一份“点位健康度”统计，把近30天的告警次数、确认率、误报率做成一张表，挂在后台首页。哪个点位最近老是误报、哪个点位一直没报过（可能是摄像头坏了或者被挡住了），一眼就能看出来。这个功能看着不起眼，但它是整个系统长期可用的关键——毕竟没人会天天盯着四十路画面，但所有人都会看那张排行榜。