企业官网建设流程全解析

你有没有想过这样一个画面：夏天中午，带娃出门办事，孩子在后排安全座椅上睡着了，你下车关上门，想着“就一分钟”，结果被各种事情拖住，二十分钟后阳光已经把车内晒成了蒸笼。这类新闻每年都有，而且发生在看起来最普通的日常里。这个项目的出发点很简单：做一个低成本、能真正装进普通家用车里的辅助报警装置，在车辆熄火后检测到车内还有生命体，并且“人不在旁边”的时候，主动通过4G网络远程提醒车主。

项目代号【dz-1042】，本质是一个物联网嵌入式系统，核心链路是：传感器感知人员存在，单片机做状态判断，4G模块远程报警。全文我会从需求拆解、硬件选型、软件状态机、实车测试、调试排坑五个方面展开。如果你正准备做类似的课程设计、毕业设计，或者想给自家车加一个低成本预警装置，这个方案可以直接复现，全程物料成本控制在150元以内，不需要开模，不需要私有云。

1. 先理解场景：车内滞留报警到底要解决什么问题

1.1 需求倒推：从悲剧场景到技术指标

先别急着选传感器，很多项目死在“一开始就把需求想简单了”。乍一看，这个问题好像是“车内温度高了就报警”，但实际细拆，远不止温度一个维度。

真实场景是这样的：车辆熄火、车门落锁、家长离开，孩子因为睡着或者玩耍被留在后座。危险发生的链条是“无人知晓”加上“温度迅速上升”。所以系统真正要做的是三个独立的事情：

第一，判断车辆状态，也就是“车已经熄火，且处于无人看管的驻车状态”。第二，判断车内是否有生命体存在，尤其要能检测到睡觉、安静状态下的儿童，这是一个低运动特征信号，比想象中难很多。第三，在确认异常后，把报警信息送出去，让车主在几十米外或者几公里外都能收到。

这三个事情对应到技术方案上就是：ACC电源检测、人体存在传感器组合、远程通信模块。再叠加一条隐形的硬要求，低功耗。系统必须从车辆电瓶取电，但是车辆经常一停就是一天，系统不能把电瓶耗到发动不了车。这个指标直接决定了传感器选型和电路设计。

1.2 方案选型：为什么是“热释电红外+微波雷达+4G”的组合

如果这是一道开卷题，市面上其实有好几条路可以走。我对比过四条路线，下面把取舍逻辑说清楚。

第一种是纯温度检测方案，用一个温度传感器，车内温度超过40℃就报警。这个方案最简单，但根本不合格，因为温度高不等于车里有孩子，夏天停在太阳底下的空车一样能到50℃。误报率会高到让人直接把系统拆掉。

第二种是座椅压力传感器方案，在坐垫下铺薄膜压力开关。问题是这个方案只能检测“坐在座椅上”的人，孩子如果躺在后座地垫上，或者被抱在怀里，压力传感器完全不工作，漏报风险太大。

第三种是视觉AI方案，车内摄像头加神经网络识别。检测效果确实好，无论睡姿还是坐姿都能识别，但成本高、功耗大，而且车内放一个摄像头，很多家庭会有隐私顾虑。项目初版直接排除了这个方向。

第四种就是最终选定的“热释电红外+微波雷达”双传感器融合方案。热释电红外传感器很便宜，五块钱左右，能检测人体红外辐射的变化，但有一个致命短板，静止的人体辐射信号恒定，传感器反而“看不见”。孩子睡觉时的微弱呼吸起伏，热释电基本是失灵的。微波雷达模块刚好补上这个短板，利用多普勒效应检测微动，呼吸导致的胸腔起伏也能捕捉到。两者组合，一个负责“动”，一个负责“微动”，成本低且互补性强。

远程通信环节，为什么选4G Cat.1而不是Wi-Fi、蓝牙或者传统2G/3G？因为报警场景是车停在商场地库、路边停车位这种地方，周围不一定有手机热点，Wi-Fi和蓝牙默认失效。传统2G/3G在国内已经大面积退网，用老模块等于赌运气。4G Cat.1是当前物联网的主流选择，网络覆盖和手机4G基本一致，模块价格在60到90元之间，待机功耗可控，支持短信和HTTP/MQTT，无论做短信报警还是云平台推送都够用。还有一种备选是NB-IoT，覆盖也不错，但实时性和下行速率不如Cat.1，短信能力也弱，本项目不考虑。

1.3 系统整体架构与信号流

抛开具体芯片型号，这个系统从逻辑上分成四层，任何类似项目都可以复用这个分层思路：

感知层：热释电红外模块、微波雷达模块、温度传感器、ACC电压检测、电池电压采样。决策层：低功耗MCU，负责所有传感器数据的采集、滤波、状态判断和报警触发。通信层：4G Cat.1模块，负责短信、HTTP/MQTT数据上报。应用层：车主的手机，接收短信或者App推送通知。

信号流是单向加反馈的：传感器数据进MCU，MCU通过状态机判断当前处于什么状态，状态发生变化后，给4G模块下发AT指令，4G模块再通过运营商网络把信息送到车主手机。整个过程不依赖云端，即使没有任何平台，短信通道也能独立完成报警。

2. 硬件设计与器件选型：把每一分钱花在刀刃上

2.1 人体存在检测：热释电与微波雷达的组合逻辑

热释电红外传感器，核心是一个能感知红外线变化的探头，探头前面通常罩一个半球形的菲涅尔透镜，用来放大人体移动带来的红外变化。人从传感器前方走过时，传感器输出一个高电平脉冲。它的典型工作电流在几十到一百微安级别，这是它最大的优势，可以长期通电不心疼。但前面说过，静止人体不产生红外变化，输出电平会慢慢归零。所以热释电在这个系统里的定位是“辅助唤醒”，它第一时间发现车内有较大动作，然后通知MCU转入详细检测状态。

微波雷达模块，工作在10.525GHz频段，利用多普勒效应检测物体微动。人体呼吸时胸腔起伏速度很慢，但多普勒雷达依然能捕捉到这种周期性微动，这是它比热释电强的地方。代价是功耗稍高，工作电流大概在3到5毫安，而且会穿透部分非金属材料，车门外有人走动时，如果安装角度不对，也有可能误触发。这个模块一定要选带灵敏度调节引脚或者电位器的款式，实际调试会轻松很多。

组合逻辑要特别注意，不能粗暴地把两个传感器做“或”运算然后直接报警，否则误报会让人崩溃。正确的做法是：热释电触发后，连续在一段时间内检测微波雷达信号；如果微波雷达也持续有微动信号，才进入“疑似有人”状态。至于具体的时间窗口，后面软件部分细讲。

2.2 主控、温度传感器与车辆状态检测

主控选型的核心是低功耗，不需要跑复杂算法，不需要高主频，需要的是丰富的中断唤醒源和极低睡眠电流。以常见的L系列低功耗MCU为例，STOP模式下的电流可以做到几个微安，RTC闹钟还能定时唤醒芯片做周期性检测。这比普通MCU的待机电流低两个数量级，是长时驻车监测的基础。

温度传感器用的是数字单总线方案，精度正负0.5℃，供电电压范围宽，接线只需要一根数据线一根地线一根电源线，非常省IO。安装位置注意避开中控台和挡风玻璃下这种阳光直射点，否则测出来的温度会被太阳辐射加热，导致误报。建议把探头固定在后排座椅靠背的顶角位置，实测这个位置的温度更接近儿童实际停留区域的体感温度。

车辆状态检测是很多人容易忽略的环节。系统要判断“车是否熄火”，最简单可靠的办法是检测ACC电源。汽车电瓶的常电一直有电，而ACC在熄火后会断电。用一个电阻分压网络把12V的ACC电平降到3.3V可检测的范围内，接到MCU的GPIO上，即可实现熄火识别。另外可以加一个震动传感器或者单轴加速度计，用来判断车门开闭、车身晃动这类物理事件。比如系统刚检测到“车内有人”信号，紧接着又检测到一次剧烈震动，大概率是家长打开车门回来接人了，这种情况就可以延迟或取消报警，减少虚惊。

2.3 远程通信模块：Cat.1的选型与AT指令链路

4G Cat.1模块通过串口与MCU通信，数据交互完全靠标准AT指令，这是所有评估板和应用板的通用做法。模块上电后，MCU定期发送“AT”指令确认模块响应，再通过“AT+CSQ”查询信号强度，20以上属于良好水平。短信报警非常简单，配置成文本模式后，一条“AT+CMGS="手机号码"”指令加消息内容和结束符，就能把短信发出去，整个过程很多同学在学校阶段就写过。

但我要特别提醒一点：模块峰值发射电流可能到2A，这个瞬间电流如果供电不足，模块会直接掉电重启，表现就是短信发到一半就没动静了。电路设计上，12V电瓶经过DCDC降压到5V之后，必须在模块电源输入端并联一个470uF以上的电解电容和几个100nF陶瓷电容，用这个电容网络扛住瞬间电流尖峰。这一步不做，通信必不稳定。

天线选择和摆放是第二坑。模块标配的天线是棒状天线或者小软天线，一定要让天线尽量贴在车窗玻璃内侧，不能完全被车内金属骨架遮挡。我之前测试，天线放在中控台下方的金属横梁附近时，信号强度只有10左右，放到后挡风玻璃角落，立刻跳到24。车内金属遮蔽对4G信号的影响比很多人想象中大得多。

2.4 电源分布与驻车功耗推算

整个系统的供电链路是这样的：汽车电瓶常电12V进DCDC降压模块转成5V，5V再经LDO降到3.3V供给MCU和传感器。4G模块由5V直供，但通过一个MOS管做开关，需要报警时才给模块上电，平时彻底断电。

这样的设计能省多少电？做一个简单推算。假设车辆平均单次驻车时间为12小时，MCU睡眠电流按10微安计，热释电模块每10秒才工作1秒，折算平均电流8微安，微波雷达模块每次检测持续2秒，扫描周期10秒，工作电流5毫安，折算平均1毫安，4G模块完全断电是0毫安。整个系统平均电流约1.1毫安，按2毫安算安全余量，12小时耗电约24毫安时。

一台家用车电瓶容量按45安时算，我们不能把电瓶放光，按最多消耗10%计算，也就是4.5安时可用容量。那么系统可以连续驻车工作187小时，约合7.8天。这远远覆盖了绝大多数停车场景。反过来，如果当初把4G模块设计成常供电，模块待机电流20毫安起，同样12小时要耗240毫安时，连续停两周就可能让电瓶亏电，这就很危险了。所以“把4G模块的电源控制起来”是整个项目功耗设计最关键的一笔。

3. 软件设计：状态机、防误报逻辑与报警链路

3.1 五状态主状态机设计

嵌入式报警系统最忌讳“堆逻辑”，把所有判断写在一个超级循环里，改一个参数可能牵扯出三个bug。我习惯用状态机来组织整个软件流程，本项目定义了五个状态：

S_INIT初始化状态、S_STANDBY正常驻车待机状态、S_MONITOR熄火后监测状态、S_CONFIRM人员确认状态、S_ALERT远程报警状态。

系统上电后进入S_INIT，完成传感器自检、模块初始化，然后进入S_STANDBY。在S_STANDBY状态下，车辆ACC为高，说明车正在使用或者刚熄火不久，系统每隔30秒做一次温度采集和生命信号快速检测，但不会报警。当ACC由高变低，说明车主锁车离开，系统进入S_MONITOR，开始正常周期性检测。

S_MONITOR状态下，如果连续多个周期检测到生命信号，系统转入S_CONFIRM，此时启动一个倒计时，默认3分钟。这个3分钟是防误报的关键参数，很多行人路过、车门震动导致的偶发误触发，都会在3分钟内自然消失。如果3分钟倒计时结束，生命信号仍然存在，系统就进入S_ALERT，触发远程报警，并在报警后继续周期重试，直到有人通过短信指令或者云平台上报“解除报警”，才回到S_STANDBY。

写代码的时候建议把状态转换表先画清楚，列清楚每个状态下哪个事件发生跳转，然后翻译成switch-case结构。

3.2 防误报设计的“三道防线”

第一道防线是时间消抖。任何单次传感器触发都不能直接报警，必须持续超过一定时长。这里的时间不是随便拍的，需要同时考虑误报和漏报。太短，比如30秒，行人从车边经过就会被误判；太长，比如10分钟，夏天车内温度上升速度很快，等报警可能已经太晚。我最终选择了3分钟，这个值既能滤掉大部分外部干扰，又不会错过黄金救援窗口。温度越高，消抖时间应该越短，后面可以做成动态调节。

第二道防线是双传感器判决。热释电和微波雷达信号同时存在才算是有效人员信号，单独一个传感器高电平一律不做人员确认。微波雷达如果正对着车窗外，偶尔能检测到外面走动的人；热释电如果对着中控台，夏天阳光通过玻璃照射产生红外波动，也有误触。两个通道都过滤一遍，误报率会成倍降低。在S_CONFIRM的3分钟里，如果两个传感器不再同时满足条件，就视为之前的检测是干扰，状态回退。

第三道防线是温度分级。系统不能只依赖“是否有人”来报警，温度要做成辅助加权逻辑。我设定35℃为一级提醒阈值、38℃为二级强报警阈值。当检测到人员存在但温度低于35℃时，报警消息的级别标为“提示”，告知车主“车内疑似有生命体，请尽快查看”；当温度超过38℃，报警级别直接升为“紧急”，短信内容会额外强调高温中暑风险。这样设置的原因是：冬天孩子滞留车内同样有风险，但不能因为温度低就完全不报警。

3.3 远程报警双通道：短信与HTTP云上报

基础版报警通道做成短信，简单直接，不依赖任何第三方App。MCU给4G模块发送以下指令序列：

AT+CMGF=1 // 设置短信为文本模式 AT+CMGS="13800000000" // 设置接收号码 > [消息内容] // 以十六进制0x1A结束发送

发送完不是立刻完事，模块会返回一个结果码，一般是“+CMGS: xxx”，收到这个结果码才说明模块成功把短信交给网络。如果超时没有返回，需要重新发送。这一步是短信报警可靠性的关键，很多半成品项目短信“偶尔发出去、经常发不出”，就是因为没做结果确认和重试。

进阶版通道是HTTP上云。模块联网后，通过AT指令发起HTTP POST请求，把报警数据打包成JSON推送到云平台，云平台再通过App推送把消息发到车主手机。比短信多了实时数据记录，还能在手机端看到温度曲线。上报的JSON一般长这样：

{ "deviceId": "DZ1042-0001", "eventType": "child_presence_alert", "alertLevel": 2, "temperature": 38.5, "batteryVoltage": 12.3, "timestamp": 1712412345 }

我建议两个通道都做，短信保底，云平台增强。万一云平台服务临时不可用，短信照样能把消息送到。

3.4 低功耗调度与看门狗

系统在S_STANDBY和S_MONITOR状态里的行为完全不一样，功耗也不一样。S_STANDBY相对松散，每60秒唤醒一次，做一次快速温度采集和传感器扫描，30毫秒内完成，然后继续睡眠。S_MONITOR因为要检测非常微弱的生命信号，每10秒必须唤醒一次，每次持续约2秒，用于微波雷达完成一次稳定的多普勒检测。这个扫描节奏是实测跑出来的，雷达模块上电后有约100毫秒的稳定时间，之后信号才可信，所以每次唤醒后要先留出稳定时间再读数据。

看门狗一定要加。系统长期在车上无人维护，一旦程序跑飞或者传感器卡死，看门狗能在1秒内复位整个系统。复位后系统会重新执行S_INIT，不会停留在某个中间状态。实际跑车测试时，有一版程序在温度传感器偶尔读取出错时死循环，后来就是靠看门狗自动恢复的，否则车主第二天就得找汽修店拆电瓶。

4. 实操过程：从面包板到实车测试

4.1 实验室仿真测试：先别急着装车

所有模块单独验证通过之前，严禁直接上车，这是我踩过坑后的规矩。实验室阶段需要搭一个简易台架：一把汽车后排座椅或者普通沙发面前放一个可调亮度的碘钨灯模拟阳光直射，用带温度调节的热水袋模拟人体热源，再用一个缓慢起伏的气囊模拟呼吸微动。虽然粗糙，但足够验证传感器逻辑。

测试用例要提前写，不能漫无目的乱测。我整理了一份覆盖主要场景的用例表，每条都要有“预期结果”和“实测结果”两列。

第一个用例，模拟成人坐进座椅后静止不动30分钟，预期结果是“微波雷达检测到呼吸微动，热释电可能失灵，但系统通过复合判决确认有人”，实测结果与预期一致。这个用例是整套方案的核心验证点，直接关系到系统是否有存在价值。

第二个用例，车外人员贴着车身走过，车身轻微振动，持续10秒，预期结果是“系统不报警，3分钟内信号自然消失”。实测第一次跑的时候漏了，因为雷达灵敏度调得过高，车外人员被误判为车内人员。后来把雷达模块灵敏度旋钮调低了两档，再把安装朝向调整为斜对后排座椅，这个用例才通过。

第三个用例，熄火后车内有人的同时，模拟车门打开散热、车身出现较大幅度的振动，预期结果“系统短暂进入人员确认状态，但振动事件后信号消失，不触发报警”。这模拟的是家长打开车门感受了一下温度，没发现孩子又关上门离开的情况。这个场景很考验状态机回退逻辑，实测时发现状态机在振动事件后依然在累计时间，后来增加了“车身剧烈振动视为门开启事件”的逻辑分支，才处理好。

第四个用例，温度快速爬升，热水袋旁边再开一盏强光碘钨灯，让温度传感器附近环境温度在两分钟内从28℃升到40℃，预期结果“系统在38℃时触发二级紧急报警”，实测系统确实在温度穿过38℃阈值后约8秒内发出短信，符合预期。

4.2 实车接线与安装：常电、ACC和传感器朝向

实验室测试通过后，进入实车安装环节。第一件事是确定取电位置。常电要接一个熄火后依然有电的保险丝位，通常车内保险丝盒里很多空位就是常电口，用万用表测量确认即可。ACC信号要从点烟器保险丝或者ACC控制线引出来，这条路熄火后断电，正好用来做状态判断。

接线的原则就一条：所有进入车内的改装线路必须做好可靠的绝缘和固定。线束走门槛饰板下方，避开座椅活动区域，所有接头用热缩管封住，电路板装进3D打印外壳后固定在后排座椅背后或者后备箱侧壁。传感器朝向是安装成败的关键，热释电和微波雷达的正面必须对准后排座椅方向，不能朝天、不能水平对着车窗。实车安装后，要重新按实验室用例表跑一遍，因为车内空间和实验室沙发的环境完全不同，电磁环境、反射环境都变了。

信号强度测试要重点做。车停在地表停车场，天线放后挡风玻璃下，实测“AT+CSQ”信号强度在20以上；同样位置，天线放到前排中央扶手箱内，信号强度掉到13。这个差距直接影响短信发送成功率。实车测试时，我把天线沿着后备箱内饰板走到后挡风玻璃底角，信号稳定在23左右，所以在停车的时候发短信几乎没有失败过。地库环境也单独测过，深地库信号明显弱，但“AT+CSQ”值仍然在12以上，短信能发出，只是偶有延迟。

4.3 测试统计与漏报误报指标

项目验收不能只看“能报警”，要量化指标。我在持续5天、每天反复模拟二十次场景的测试中做了完整统计：共计测试100次人员滞留场景，系统成功报警98次，漏报2次。漏报的2次都发生在微波雷达模块灵敏度被人为调低了以后，调回合理档位后连续测试30次全部成功。外部干扰误报场景测试100次，误报1次，发生在倾盆大雨、雷声很响、车身持续震动的极端天气，这种误报在可接受范围内。

测试数据是设计报告里最有说服力的部分。如果你打算把这个项目用作课程设计或者毕业设计，这部分一定要写详细，评审老师一般不会在意你用了多贵的芯片，但一定会追问“误报率和漏报率怎么测出来的”。

5. 调试排坑实录：那些文档里不会写的坑

5.1 热释电传感器“时灵时不灵”

初版测试时，遇到一个很难复现的故障，热释电模块时而触发、时而不触发。排查了很久，最终定位到供电问题。5V转3.3V用的LDO在小电流状态下输出正常，但当4G模块突然上电时，整个5V轨电压跌落，3.3V也跟着掉到2.9V以下，热释电传感器在这种低电压下输出逻辑混乱。解决办法就是前面讲过的，模块电源加储能电容，并且让4G模块的上电延时晚于传感器检测周期，从时序上错开。

5.2 微波雷达隔着车门也能触发

有一次测试，车停在路边，人明明站在车外打电话，系统却报了“车内有人”。检查雷达模块的安装角度发现，模块正面正好对着后侧窗玻璃，10.525GHz微波能穿透汽车玻璃，把车外两米范围内人员的微动检测了出来。这个坑让我养成了一个习惯：安装完成后，让一个人先在车外正常走动几圈，确认雷达不输出异常信号，再坐进车内测试。调整方法是把雷达灵敏度调到最低可用档，同时把模块正面朝向座椅靠背方向。

5.3 4G模块一上电就重启

这个故障很经典，短信发送成功率只有两成。现象是模块一发射就掉电，串口完全无响应。最初怀疑是SIM卡接触不良，换了新卡还是一样。后来用示波器测5V电源轨，发射瞬间电压从5V跌到3.8V，模块低于工作电压直接宕机。原因就是DCDC模块的输出电流标称够，但动态响应太差，瞬时大电流拉死了电压。解决方法是模块电源两端并联一个大容量电解电容，让电容在发射瞬间充当能量缓冲。这个改动之后，短信发送成功率从20%升到接近100%。

5.4 车辆熄火后系统反而断电

第一次实车安装，常电接入的保险丝位选错了，看起来是常电，实际上熄火后约五分钟也会断电。结果就是车停在路边，刚开始还能检测，十几分钟后系统先于危险到来之前“下班”了。所以接线后必须做断电验证：锁车等待十分钟，确认系统仍然在工作。选保险丝位时最好用万用表连续监测几分钟，确认电压不回落再接系统。

5.5 报警疲劳问题

这个问题不是技术问题，而是产品问题。如果系统三天两头误报，用户最后会习惯性忽略报警，真正出状况时反而误事。第一次跑完实测，我的误报源主要是热释电对车内中控区域阳光反射的误触发。后来把热释电的安装位置从仪表台改到后排座椅上方，同时关了热释电在高光照环境下的检测通道，误报立刻清零。这种“宁可少触发几次假警，也不能让用户对报警脱敏”的思路，是这类安全类产品设计中最需要提前想清楚的一点。

6. 成本核算与项目扩展思考

6.1 物料成本清单

整套系统做下来，物料成本比很多人想象中低，我列一下主要开销：

这个成本放在防危险产品线里，属于极低水平。一个普通车载手机支架的价格都比它高。如果你用国产替代器件，还能再压到100元以内。当然，前装产品还要考虑认证、可靠性测试、批量生产外壳模具，那价格另算，但作为后装DIY或者课程设计项目，这个成本是完全可以接受的。

6.2 课程设计/毕业设计如何把项目写完整

有些同学拿到dz-1042这样的编号，其实是一门课程设计或毕业设计的题目。我建议设计报告不要只写硬件原理，而是完整覆盖需求分析、系统设计、模块选型、软件流程、仿真与实测、总结展望六个部分。重点强调两点：一是在需求分析里写明“本项目要解决什么问题”，二是在测试部分把误报率、漏报率数据放进去，并提供测试过程照片或视频记录。光是这两点就能让项目从“做了一个电路”上升到“系统性地解决了一个问题”。

6.3 后续扩展方向

这个项目后续能扩展的空间很大。第一是接入车辆总线或者利用蓝牙关系来判定“离车距离”，比如车主手机通过蓝牙与车内系统连接，当手机蓝牙信号完全消失时，才正式进入监测模式，这可以从源头避免“人还在车旁边但系统已经报警”的情况。第二是加入毫米波雷达，毫米波雷达能直接检测呼吸、心跳等微动信号，准确率和抗干扰能力比微波雷达更高，缺点是模块成本暂时还比较高。第三是接入更完整的云平台，实现车辆定位、历史温度曲线、远程查看车内画面的功能，配合微信小程序或手机App使用，体验会贴近商业产品。

我个人认为，最有价值的下一步是和儿童安全座椅做联动。在座椅靠背里集成这套系统，把距离传感器和温湿度传感器放在座椅内部，由座椅自带的小电池供电，再通过蓝牙与手机通信，几个月充一次电即可。这样就能把“车载改装”变成“安全座椅自带功能”，产品化路径会清晰很多。

这个项目我前后调了两周，最大的体会不是哪颗芯片功耗低，而是“检测算法的可靠性”才是这种救命类产品的命门。误报一次，用户就会关掉系统；漏报一次，后果无法承受。我建议你在做任何同类项目时，都把抗误报测试用例和连续稳定运行测试，放在和功能开发同等重要的位置。一个小技巧是：每次调整传感器灵敏度后，先让一个人在车外正常走动几次，把“行人路过误触发”的情况先调掉，再测车内真实人员检测，这样能省掉大量后续排查的时间。车内儿童滞留报警，真正难的不是把系统做出来，而是让系统在该响的时候一定响，不该响的时候绝对安静。