一、我们为什么不想再做”烟感”

3.8 亿辆。这是 2025 年 7 月工信部公布的我国电动自行车社会保有量。2.1 万起——这是 2023 年国家消防救援局接报的电动自行车火灾事故数，其中 80% 发生在充电过程中。

我们（西藏大学火眼哨兵团队）一开始想做这件事，是因为一条 2024 年的新闻：广州某充电棚凌晨 3 点起火，4 辆电动车连锁爆燃，停放在棚内的 12 辆全部烧毁。烟感报警器响了，但当烟感响的时候，电池内部温度已经超过 800°C——热失控早已不可逆。

传统点型烟感探测器的原理是”烟雾颗粒物理接触触发”。它等待的是明火产生后的浓烟。从传感器原理上看，它根本看不到”温度在异常爬升”这个阶段。这就是我们看到的产品机会——不是做一个更好的烟感，而是把检测时间往前推 30-60 秒。

二、我们怎么把”检测”变成”预测”

火眼哨兵（FireGuard AI）核心想法只有一句话：用边缘多模态传感器 + TinyML 时序模型，在电池热失控爆发的”温升拐点”就报警。

具体到架构上，分三层：

感知层（单价 ≤ 200 元的边缘节点）：MLX90640 红外热阵列（32×24 像素）+ MQ-2 烟雾 + MQ-135 VOC 气体 + DHT22 温湿度 + ESP32-CAM 视觉。节点用 433MHz LoRa 自组网，地下车库也能穿墙。

边缘计算层（ESP32-S3，45 元的 MCU）：在上面跑一个 1D-CNN 时序模型，只用 226K 参数，INT8 量化后 268KB。模型吃 30 秒滑动窗口的温度 + 一阶差分 + 二阶差分 + 归一化四通道特征，输出一个异常概率。不依赖 WiFi、不依赖云端——断网也能独立工作。

云端（PyTorch 训练 + Web 管理平台）：Mamba-YOLOv8s 火焰检测（150 epoch、mAP@50 = 0.758）+ LightGBM 多模态融合（22 维特征，误报率 2.6%）做最终预警分级。

三、为什么是 42 秒

这是团队在答辩时被问得最多的问题。

锂电池热失控是经典的化学-热耦合过程。从温升速率 > 0.15°C/s 的”异常积累”阶段开始，到温度突破 600°C、电池起火，平均还有 30-60 秒。这段时间里，温度会经历一个明显的”加速爬升”——温升速率本身在变大。

我们用一个工业上常用的物理量来描述这个信号：温升的二阶导数 Δ²T/Δt²。它捕捉的就是”温升在加速”这件事。

这个数学特征就是热失控从线性爬升转向指数爆发的指纹。

我们基于 Arrhenius 方程（三阶段：正常充电 < 0.1°C/s → 异常积累 0.15-10°C/s → 热失控爆发 > 10°C/s）做了 18,000 条仿真曲线，训练 TCN 膨胀因果卷积。测试集 Acc 99.94%，Recall 99.81%，AUC 1.0——这个 99.94% 不该被理解成”模型接近完美”，而要看到仿真曲线里 15% 是硬负样本（阳光暴晒、冬季暖风、发动机余热），模型能在这上面零误报，才有意义。

最后算下来，从温度异常拐点到明火出现的平均预警提前量 42 秒。这 42 秒够干几件事：

完整应急链在火灾发生前闭合。这是 42 秒真正的物理含义。

四、产品视角：三个”非显然”的工程选择

作为一支工程团队，回看过去一年做的决定，有几个”产品决策”复盘下来比技术本身更值得讲：

1. 不做云端推理，做边缘推理——纯粹是产品定位

最初我们也考虑过”传感器只采数据，推理放云端”的标准 IoT 架构。算了一下时延放弃了——地下车库 4G 信号差，从节点到云到节点一个 RTT 至少 200-500ms。火灾已经在烧了。

改成边缘推理后，单帧推理延迟 < 50ms，网络只是用来”事后回传数据”和”远程运维”。代价是模型要小到 268KB（INT8），算法要重写。但这个代价是值得的——因为断网也得工作，这是产品定义里写死的。

2. 不卖硬件订阅，做”软硬一体”——商业模式护城河

如果只卖 ¥200 一个的传感器节点，200 节点一个棚 ¥4 万就到顶了，下一单要再去拉新，毛利再高也是单点生意。

我们做的是软硬一体 + 后续 SaaS：

硬件保本或微利，订阅和数据增值是利润。这是从一开始产品定位就决定了的——不是后来加上去的。

3. 多模态融合不是”加更多传感器”——是降低误报率

传统方案爱堆传感器：再加一个 CO、加一个温湿度、加一个热成像。但加传感器不解决误报——你不知道哪根稻草是最后那根。

我们的做法是三层交叉验证的”AND”逻辑：

只有三层全部命中，才触发红色预警。任何一层不满足就降级为黄色关注或橙色告警。

这套逻辑我们用 LightGBM 训练过——22 维特征，5 折交叉验证 AUC 1.0，最优阈值下 FPR 2.6%、Recall 100%。AUC=1.0 是因为我们用仿真数据训的，真实环境肯定有差距——但 2.6% FPR 这个数字，是模型在 18,000 条仿真曲线里没有放过任何一条真异常，也没有把 3000 条硬负样本标错的硬指标。

五、从”做完比赛”到”进入市场”——团队这一年踩过的坑

项目做到今天，给非技术读者分享几个”做产品才知道”的现实：

1. 校准预期比写代码更难最初我们以为 3 个月能完成所有模型训练 + 部署到 ESP32 实物。结果：YOLOv8 火焰检测 150 epoch 训练就用了 12.5 小时（4090D 显卡），TCN 调二阶差分这个特征用了 2 周才发现比单温度高 5 个点，量化到 268KB 用了 1 周。任何一步低估时间代价，都会让项目延期一个月。

2. “能跑通”和”能交付”是两个产品我们 1.0 版本 Mamba-YOLOv8 推理一帧 180ms（CPU 跑），完全不能上嵌入式。换 TFLite Micro 跑又遇到算子不支持，最后用 ONNX Runtime + 静态 INT8 量化才把延迟压到 50ms 以内。这中间 5 个月就是”能跑通”到”能交付”的距离。

3. 团队的角色错位最致命我（计科，负责算法 + 后端）一开始什么都想自己写。结果发现 ESP32 固件、LoRa 组网协议、PCB 设计这三块没有专门的硬件同学根本搞不定。后来我们引入了邓子丰（边缘部署 / 硬件协同）和李修（UI / 模型压缩）才把工程节奏跑起来。单干的天才在产品里是行不通的。

六、现在回到开头那个问题：值不值得做？

回看这条赛道，我们认为有三个判断值得产品经理同行关注：

我们今年的目标是和广东爱普拉新能源完成 30-50 节点的现场试点，把仿真数据换成真实运行数据。到那一天，所有 AUC=1.0 才能被真正验证。

写在最后

如果你是产品经理，正在评估 IoT / 边缘 AI 项目的可行性，希望这篇文章能帮到你。火眼哨兵不是终点，是传统消防行业开始接受”预测”思维的一个起点。

欢迎在评论区交流你们遇到的边缘 AI 实战问题。