CPD 通知路由与升级调度器：为什么停车态安全不能只有检测器

发布时间： 2026-03-26
主题： CPD / 通知路由 / 升级调度 / 停车态安全
关键词： notification routing、escalation scheduler、child presence detection、parked vehicle、remote alert

---

一句话结论

CPD 做到“检测到孩子”还远远不够。

真正难的是：

在正确的时间，把正确级别的警报，通过正确的通道，送到真正能采取行动的人。

所以停车态安全系统里，除了 detector，至少还需要两个一等模块：

• 升级调度器（escalation scheduler）
• 通知路由器（notification router）

---

1. 升级调度器解决什么问题

它负责把协议时序和风险逻辑落地成可执行调度，例如：

• 首报何时触发
• 用户允许一次延迟后如何恢复
• 何时从普通提醒升级到高优先级提醒
• 每分钟重复的循环如何保持稳定
• 温度快速升高时是否跳级

如果没有这一层，系统就会退化成“检测到就响一下”，无法满足真实法规和量产要求。

---

2. 通知路由器解决什么问题

停车态时，车内未必有人。

因此必须管理多通道：

• 车外本地通道：灯光、喇叭、可见文本
• owner 通道：手机 App、车钥匙反馈
• service 通道：connected service / 云记录
• third-party 通道：照护者、紧急联系人（若策略允许）

通知路由器的核心任务不是“多发几条消息”，而是：

• 根据风险等级选通道
• 根据网络/钥匙可达性做兜底
• 避免消息风暴和重复骚扰
• 确保 escalation 与 intervention 同步

---

3. 一个实用的四级通知策略

L1：Local External Alert

• 车外可见/可闻
• 面向附近可立即干预的人

L2：Owner Alert

• App push / key feedback
• 面向车主/照护者

L3：Persistent Escalation

• 重复推送
• 加强本地提醒
• 进入持续升级循环

L4：Intervention-linked Notification

• 开空调/解锁同时通知
• 强提示已进入高危状态

这样做的关键是：通道和动作必须联动，而不是各自为政。

---

4. 工程上最容易忽略的点

4.1 Snooze 不是取消

允许一次延迟，不代表风险消失。系统要保存：

• 延迟开始时间
• 延迟时长
• 延迟后恢复点
• 延迟期间高温是否可打断

4.2 通知去重

App、钥匙、车外提示如果毫无策略地一起轰炸，用户只会更快麻木。

4.3 无网络兜底

connected service 失败时，本地提醒和钥匙反馈要能兜底。

4.4 温度是并行加速器

高温不应只改变提示文案，而应直接影响调度优先级。

---

5. 推荐的模块边界

• detector：输出 presence suspicion / confidence
• confirmation：输出 confirmed risk / child likelihood
• escalation scheduler：输出 alert level / next trigger time
• notification router：输出 active channels / retry policy
• intervention layer：输出 climate / unlock / emergency path

这样团队边界才清晰，验证也更可控。

---

6. 研发优先级建议

P0：先把 scheduler 做成显式模块

P0：把 router 做成通道策略，不写死在业务里

P1：把 snooze / repeat / timeout / temperature override 纳入状态机

P1：做本地提醒、App、钥匙三通道联调

---

结语

停车态安全下一阶段真正的门槛，不是谁先多装一个传感器，
而是谁先把：

检测 → 升级调度 → 通知路由 → 干预动作

做成真正稳定的一条链。