无人快递车车顶趴着两个人“搭便车”的视频在网络上传播后讨论很快从“这样危不危险”转向了一个更专业的疑问当一辆无人车被人攀爬、遮挡甚至强行推动时车辆自己到底能不能发现、能不能处置。很多人的默认判断是无人车一定“眼观六路”但工程实现并不是这样。无人配送车的传感器布局、识别算法和应急响应主要围绕“安全完成配送任务”设计并不天然覆盖“防止有人爬到车顶”这类非典型场景。这篇文章不讨论事件中的责任划分也不复述相关厂商客服的具体回应而是把这件事当作一个安全工程案例无人配送车从感知到追溯的完整安全链路应该由哪些环节组成当前常见设计容易漏掉什么遇到人员攀爬这类物理干扰时应该如何感知、识别、处置和追溯。先说明攀爬行驶中的无人配送车是危险行为存在人身伤害风险也不符合道路运营安全管理要求。本文不从道德或法律角度评价行为只从工程开发角度分析车辆安全防护链路应该怎么设计。1. 从“车顶搭便车”事件看无人配送车的安全链路1.1 事件背后的真问题无人行驶不等于无人值守事件表面上是两个人的危险行为工程上暴露的问题却更基础无人配送车没有驾驶员但它并不是一个只能单向执行任务的设备。它在公开或半公开区域运行时需要具备对外部异常事件的自感知、自判断和自处置能力。所谓自感知不只是看见前方的行人车辆还包括感知车身上、车身周围发生的异常接触。这里有一个容易混淆的点自动驾驶感知和安全防护感知不是一回事。自动驾驶感知的目标是完成导航和避障它关心的是道路上的动态障碍物安全防护感知的目标是识别车辆本身是否正在被异常影响它关心的是车顶、车门、货箱、底盘等位置是否出现非预期的人员或物体。前者决定“车能不能开”后者决定“车周围有没有出问题”。很多无人配送车在公开路测时表现不错遇到的是第一类问题而“车顶搭便车”属于第二类问题。从研发角度看第二类问题往往比第一类更容易被忽略因为它的发生概率低、场景非典型很难进入产品初期的需求池。但这类事件一旦发生造成的人身伤害风险和品牌风险都不小。工程上正确的做法是把这类低频但高危的场景纳入安全需求而不是等到事件出现后再补。1.2 一条完整的车辆安全链路由四个阶段组成要应对这类事件不能只靠某一个传感器或某一个算法。工程上通常把安全链路拆成四个阶段感知、识别、处置、追溯。任何一个阶段缺位整个系统都可能在真实事件中失效。阶段要解决的问题典型组件失败后果感知层车辆周围、车顶、底盘等区域是否存在物体摄像头、激光雷达、毫米波雷达、超声波、振动传感器没有基础数据后续全部失效识别层检测到的物体是什么、在做什么、是否构成风险目标检测、行为识别、事件分级有数据但判不出风险不会产生告警处置层车辆以什么动作响应是否需要人工介入决策规划、底盘控制、远程监控平台识别到风险但响应错误或不及时追溯层事件如何被记录、取证、复盘录像、日志、时间同步、云存储事后无法定位根因问题反复出现拿这次事件来说检验安全闭环是否成立可以依次问四个问题车辆能否用传感器覆盖到车顶哪怕感知到了“有东西”算法能否判断这是人在攀爬判断出来之后车辆应当减速停车还是继续行驶事件发生后运营方能拿到哪些录像和日志来复盘这四个问题正好对应下文的四个章节。2. 感知层车辆周围的盲区是客观存在的2.1 常见传感器布局和覆盖范围先说一个基本判断无人配送车当前的传感器布局很难做到对车身外壳的无死角覆盖。常见配置包括激光雷达、前视摄像头、环视鱼眼摄像头、超声波雷达和毫米波雷达每一种传感器都有明确的职责和局限。传感器典型安装位置主要覆盖范围优点盲区或限制激光雷达车顶或车头水平 360 度周边环境距离测量直接不受光照影响垂直视场角有限车顶正上方和车身边缘容易漏检前视/环视摄像头车身四周车辆前后、侧面环境信息丰富可识别目标类型近距离畸变大强光或夜间退化车顶区域通常不在画面内毫米波雷达前后保险杠前后中远距离不惧雨雾可测速度对静止小目标和缓慢移动目标不敏感超声波雷达前后保险杠周边 0.2 到 3 米近距成本低近距可靠探测距离短只能感知距离无法区分目标类型从这张表可以看出激光雷达虽然能扫描周围环境但它主要做水平方向的感知摄像头虽然信息丰富但视场角有限车顶正上方往往不在画面内超声波和毫米波雷达负责近距和远距但都不能识别目标类型。真正要覆盖车顶需要在设计初期就把“车身安全区域”纳入感知需求而不是沿用纯自动驾驶的传感器方案。2.2 车顶区域为什么容易成为盲区车顶成为盲区原因有三个。第一设计目标里没有它。无人配送车的常规行驶场景中车顶只安装传感器或货箱不参与道路风险判断所以开发时一般不会为车顶单独配置感知资源。产品需求、标定规范、测试用例都没有这一条传感器自然覆盖不到。第二物理视场限制。车载激光雷达的垂直视场角通常在几十度以内前视相机的俯仰角按路面场景标定超声波雷达安装高度低这些传感器从物理结构上就无法覆盖车顶正上方。要让车辆“看见”车顶必须增加专门面向车顶区域的相机或其他传感器。第三成本和标定工作量。增加顶部鱼眼相机、压力传感器、振动传感器都会带来硬件成本和标定工作量如果没有明确的安全需求驱动产品经理不会主动加。事件发生后这些“非典型场景”才会进入需求池这也是行业常见的演进路径。从工程角度看这不是某一个厂商的问题而是行业在“安全冗余成本”和“常见运营风险”之间的取舍。事件的价值在于提醒车顶、底盘、货箱盖等盲区应该被正式纳入风险清单而不是默认不存在。2.3 补盲手段多传感器融合而不是只加一个摄像头补盲不是简单地在车顶加一个摄像头。摄像头在夜间、逆光、雨天效果有限所以更稳妥的方式是让多种低成本传感器配合形成互相印证的证据。常见补盲手段包括顶部鱼眼相机或广角相机检测车顶区域是否有人员、包裹、异物输出目标框和置信度。振动传感器或 IMU人员爬上静止或行驶中的车辆会造成车身振动模式异常。货舱门磁开关、车门状态传感器检测非授权开门或舱门异常。底盘激光或红外传感器检测车底是否有人或物体这也是防碾压安全项目的一部分。多源信息融合的思路可以用一小段伪代码说明# 多源融合简单示例判断车顶是否有人员驻留 def fuse_roof_signals(camera_det, vibration, imu_z): # camera_det: 顶部相机检测结果 dict # vibration: 振动传感器短时能量 # imu_z: 车身垂直方向加速度波动 score 0.0 if camera_det.get(person_on_roof, False): score 0.6 if vibration 15.0: score 0.3 if abs(imu_z - 9.8) 1.2: score 0.2 return score def judge(score): if score 0.8: return HIGH if score 0.4: return MEDIUM return LOW融合策略的要点不是数学上越复杂越好而是要让各信号源互为补充视觉负责“看到什么”振动负责“确实有接触”两者同时成立时才触发高等级事件从而降低误报。示例里的阈值 15.0 和 1.2 都需要根据具体车型实测标定不能直接照搬。3. 识别层从“检测到目标”到“判断为目标状态异常”3.1 从目标检测到行为识别感知层输出的是原始信号和目标框识别层要回答三个问题这是什么物体、它处于什么状态、这个状态持续了多久。例如摄像头在车顶区域框出一个目标这并不等于告警。如果目标是一只鸟、一片落叶或维护人员放在车顶的工具包就不需要停车。识别层需要结合目标类别、面积、运动轨迹和停留时间才能把“车顶有目标”升级为“车顶有人驻留”。行为识别的一个关键设计是时间窗口瞬时遮挡可以忽略持续驻留才需要处置。时间窗口能过滤掉大量偶发误报是工程上非常实用的手段。识别层的另一个任务是区分正常作业和异常入侵。无人配送车在运营中不可避免地会有维护人员靠近、装卸货物、充电等操作这些场景也会触发传感器。如果识别层不能区分“维护人员在操作”和“陌生人攀爬”车辆就会频繁误报运营人员也会逐渐对告警失去信任。3.2 事件分级模型与响应策略无人配送车不能把所有异常都当成同一等级处理。事件分级的意义在于低等级事件只需要提示和记录中等级事件需要上报并观察高等级事件才需要停车甚至远程报警。如果所有事件都触发急刹反而会制造新的交通风险。事件类型判断依据示例风险等级推荐响应周边人员靠近行人距离小于 1.5 米速度正常低减速、语音提示车顶短暂遮挡顶部相机检测到遮挡持续时间小于 10 秒中上报监控持续观察人员攀爬或驻留顶部目标检测到人伴随振动异常持续超过 5 秒高停车、锁货箱、远程告警车辆被强行推动或破坏底盘、舱门传感器触发异常高停车、锁货箱、远程告警以“人员攀爬”为例判断依据至少包括目标是人、目标出现在车顶区域、目标停留超过数秒、车身振动信号与人员攀爬一致。多个条件同时满足才进入 HIGH 等级。这种“多条件组合”的设计能有效降低单传感器误报带来的错误急停。3.3 一个可落地的告警规则配置示例事件规则适合以配置方式管理方便不同车型和运营场景做差异化调整。下面是 YAML 格式的规则示例用于说明思路。# 安全事件规则配置示例需按车型、算法和运营场景调整 rules: - rule_id: roof_person_presence description: 车顶人员驻留 sensors: [top_camera, vibration_sensor] conditions: - signal: top_camera.person_on_roof operator: value: 0.6 - signal: vibration_sensor.delta operator: value: 15.0 - signal: event_duration_s operator: value: 5 event_level: HIGH actions: [pull_over, lock_cargo, notify_operator] - rule_id: roof_temporary_occlusion description: 车顶短暂遮挡 sensors: [top_camera] conditions: - signal: top_camera.roof_occlusion operator: value: 0.5 - signal: event_duration_s operator: value: 10 event_level: MEDIUM actions: [notify_operator]配置里的阈值不能拍脑袋定。正确做法是先采集一段时间真实运营数据统计正常场景下的误报分布再把阈值设定在误报率和漏报率的平衡点上。规则引擎的好处是调整阈值不需要重新编译代码坏处是阈值太多后难以维护所以规则要定期清理、汇总并沉淀到统一的配置中心。4. 处置层车辆发现异常后按什么逻辑行动4.1 分级响应状态机识别到高等级事件后车辆要决定怎么行动。常规做法是定义一个安全状态机让车辆在不同状态下执行不同动作。# 无人配送车安全状态机最小示例仅用于说明思路 class SafetyStateMachine: def __init__(self): self.state NORMAL def handle_event(self, level): # level: 0无事件 1LOW 2MEDIUM 3HIGH if level 3: self.state EMERGENCY elif level 2: self.state WARNING elif level 1 and self.state NORMAL: self.state CAUTION elif level 0: self.state NORMAL return self.action() def action(self): if self.state EMERGENCY: return {action: brake, target_speed_mps: 0} if self.state WARNING: return {action: pull_over, target_speed_mps: 0, timeout_s: 5} if self.state CAUTION: return {action: slow_down, target_speed_mps: 0.5} return {action: normal, target_speed_mps: None}这个状态机的关键不是代码逻辑而是动作选择背后的取舍。EMERGENCY 对应直接制动WARNING 对应先减速、再靠边 无人配送车安全链路解析：感知、识别、处置与追溯
无人快递车车顶趴着两个人“搭便车”的视频在网络上传播后讨论很快从“这样危不危险”转向了一个更专业的疑问当一辆无人车被人攀爬、遮挡甚至强行推动时车辆自己到底能不能发现、能不能处置。很多人的默认判断是无人车一定“眼观六路”但工程实现并不是这样。无人配送车的传感器布局、识别算法和应急响应主要围绕“安全完成配送任务”设计并不天然覆盖“防止有人爬到车顶”这类非典型场景。这篇文章不讨论事件中的责任划分也不复述相关厂商客服的具体回应而是把这件事当作一个安全工程案例无人配送车从感知到追溯的完整安全链路应该由哪些环节组成当前常见设计容易漏掉什么遇到人员攀爬这类物理干扰时应该如何感知、识别、处置和追溯。先说明攀爬行驶中的无人配送车是危险行为存在人身伤害风险也不符合道路运营安全管理要求。本文不从道德或法律角度评价行为只从工程开发角度分析车辆安全防护链路应该怎么设计。1. 从“车顶搭便车”事件看无人配送车的安全链路1.1 事件背后的真问题无人行驶不等于无人值守事件表面上是两个人的危险行为工程上暴露的问题却更基础无人配送车没有驾驶员但它并不是一个只能单向执行任务的设备。它在公开或半公开区域运行时需要具备对外部异常事件的自感知、自判断和自处置能力。所谓自感知不只是看见前方的行人车辆还包括感知车身上、车身周围发生的异常接触。这里有一个容易混淆的点自动驾驶感知和安全防护感知不是一回事。自动驾驶感知的目标是完成导航和避障它关心的是道路上的动态障碍物安全防护感知的目标是识别车辆本身是否正在被异常影响它关心的是车顶、车门、货箱、底盘等位置是否出现非预期的人员或物体。前者决定“车能不能开”后者决定“车周围有没有出问题”。很多无人配送车在公开路测时表现不错遇到的是第一类问题而“车顶搭便车”属于第二类问题。从研发角度看第二类问题往往比第一类更容易被忽略因为它的发生概率低、场景非典型很难进入产品初期的需求池。但这类事件一旦发生造成的人身伤害风险和品牌风险都不小。工程上正确的做法是把这类低频但高危的场景纳入安全需求而不是等到事件出现后再补。1.2 一条完整的车辆安全链路由四个阶段组成要应对这类事件不能只靠某一个传感器或某一个算法。工程上通常把安全链路拆成四个阶段感知、识别、处置、追溯。任何一个阶段缺位整个系统都可能在真实事件中失效。阶段要解决的问题典型组件失败后果感知层车辆周围、车顶、底盘等区域是否存在物体摄像头、激光雷达、毫米波雷达、超声波、振动传感器没有基础数据后续全部失效识别层检测到的物体是什么、在做什么、是否构成风险目标检测、行为识别、事件分级有数据但判不出风险不会产生告警处置层车辆以什么动作响应是否需要人工介入决策规划、底盘控制、远程监控平台识别到风险但响应错误或不及时追溯层事件如何被记录、取证、复盘录像、日志、时间同步、云存储事后无法定位根因问题反复出现拿这次事件来说检验安全闭环是否成立可以依次问四个问题车辆能否用传感器覆盖到车顶哪怕感知到了“有东西”算法能否判断这是人在攀爬判断出来之后车辆应当减速停车还是继续行驶事件发生后运营方能拿到哪些录像和日志来复盘这四个问题正好对应下文的四个章节。2. 感知层车辆周围的盲区是客观存在的2.1 常见传感器布局和覆盖范围先说一个基本判断无人配送车当前的传感器布局很难做到对车身外壳的无死角覆盖。常见配置包括激光雷达、前视摄像头、环视鱼眼摄像头、超声波雷达和毫米波雷达每一种传感器都有明确的职责和局限。传感器典型安装位置主要覆盖范围优点盲区或限制激光雷达车顶或车头水平 360 度周边环境距离测量直接不受光照影响垂直视场角有限车顶正上方和车身边缘容易漏检前视/环视摄像头车身四周车辆前后、侧面环境信息丰富可识别目标类型近距离畸变大强光或夜间退化车顶区域通常不在画面内毫米波雷达前后保险杠前后中远距离不惧雨雾可测速度对静止小目标和缓慢移动目标不敏感超声波雷达前后保险杠周边 0.2 到 3 米近距成本低近距可靠探测距离短只能感知距离无法区分目标类型从这张表可以看出激光雷达虽然能扫描周围环境但它主要做水平方向的感知摄像头虽然信息丰富但视场角有限车顶正上方往往不在画面内超声波和毫米波雷达负责近距和远距但都不能识别目标类型。真正要覆盖车顶需要在设计初期就把“车身安全区域”纳入感知需求而不是沿用纯自动驾驶的传感器方案。2.2 车顶区域为什么容易成为盲区车顶成为盲区原因有三个。第一设计目标里没有它。无人配送车的常规行驶场景中车顶只安装传感器或货箱不参与道路风险判断所以开发时一般不会为车顶单独配置感知资源。产品需求、标定规范、测试用例都没有这一条传感器自然覆盖不到。第二物理视场限制。车载激光雷达的垂直视场角通常在几十度以内前视相机的俯仰角按路面场景标定超声波雷达安装高度低这些传感器从物理结构上就无法覆盖车顶正上方。要让车辆“看见”车顶必须增加专门面向车顶区域的相机或其他传感器。第三成本和标定工作量。增加顶部鱼眼相机、压力传感器、振动传感器都会带来硬件成本和标定工作量如果没有明确的安全需求驱动产品经理不会主动加。事件发生后这些“非典型场景”才会进入需求池这也是行业常见的演进路径。从工程角度看这不是某一个厂商的问题而是行业在“安全冗余成本”和“常见运营风险”之间的取舍。事件的价值在于提醒车顶、底盘、货箱盖等盲区应该被正式纳入风险清单而不是默认不存在。2.3 补盲手段多传感器融合而不是只加一个摄像头补盲不是简单地在车顶加一个摄像头。摄像头在夜间、逆光、雨天效果有限所以更稳妥的方式是让多种低成本传感器配合形成互相印证的证据。常见补盲手段包括顶部鱼眼相机或广角相机检测车顶区域是否有人员、包裹、异物输出目标框和置信度。振动传感器或 IMU人员爬上静止或行驶中的车辆会造成车身振动模式异常。货舱门磁开关、车门状态传感器检测非授权开门或舱门异常。底盘激光或红外传感器检测车底是否有人或物体这也是防碾压安全项目的一部分。多源信息融合的思路可以用一小段伪代码说明# 多源融合简单示例判断车顶是否有人员驻留 def fuse_roof_signals(camera_det, vibration, imu_z): # camera_det: 顶部相机检测结果 dict # vibration: 振动传感器短时能量 # imu_z: 车身垂直方向加速度波动 score 0.0 if camera_det.get(person_on_roof, False): score 0.6 if vibration 15.0: score 0.3 if abs(imu_z - 9.8) 1.2: score 0.2 return score def judge(score): if score 0.8: return HIGH if score 0.4: return MEDIUM return LOW融合策略的要点不是数学上越复杂越好而是要让各信号源互为补充视觉负责“看到什么”振动负责“确实有接触”两者同时成立时才触发高等级事件从而降低误报。示例里的阈值 15.0 和 1.2 都需要根据具体车型实测标定不能直接照搬。3. 识别层从“检测到目标”到“判断为目标状态异常”3.1 从目标检测到行为识别感知层输出的是原始信号和目标框识别层要回答三个问题这是什么物体、它处于什么状态、这个状态持续了多久。例如摄像头在车顶区域框出一个目标这并不等于告警。如果目标是一只鸟、一片落叶或维护人员放在车顶的工具包就不需要停车。识别层需要结合目标类别、面积、运动轨迹和停留时间才能把“车顶有目标”升级为“车顶有人驻留”。行为识别的一个关键设计是时间窗口瞬时遮挡可以忽略持续驻留才需要处置。时间窗口能过滤掉大量偶发误报是工程上非常实用的手段。识别层的另一个任务是区分正常作业和异常入侵。无人配送车在运营中不可避免地会有维护人员靠近、装卸货物、充电等操作这些场景也会触发传感器。如果识别层不能区分“维护人员在操作”和“陌生人攀爬”车辆就会频繁误报运营人员也会逐渐对告警失去信任。3.2 事件分级模型与响应策略无人配送车不能把所有异常都当成同一等级处理。事件分级的意义在于低等级事件只需要提示和记录中等级事件需要上报并观察高等级事件才需要停车甚至远程报警。如果所有事件都触发急刹反而会制造新的交通风险。事件类型判断依据示例风险等级推荐响应周边人员靠近行人距离小于 1.5 米速度正常低减速、语音提示车顶短暂遮挡顶部相机检测到遮挡持续时间小于 10 秒中上报监控持续观察人员攀爬或驻留顶部目标检测到人伴随振动异常持续超过 5 秒高停车、锁货箱、远程告警车辆被强行推动或破坏底盘、舱门传感器触发异常高停车、锁货箱、远程告警以“人员攀爬”为例判断依据至少包括目标是人、目标出现在车顶区域、目标停留超过数秒、车身振动信号与人员攀爬一致。多个条件同时满足才进入 HIGH 等级。这种“多条件组合”的设计能有效降低单传感器误报带来的错误急停。3.3 一个可落地的告警规则配置示例事件规则适合以配置方式管理方便不同车型和运营场景做差异化调整。下面是 YAML 格式的规则示例用于说明思路。# 安全事件规则配置示例需按车型、算法和运营场景调整 rules: - rule_id: roof_person_presence description: 车顶人员驻留 sensors: [top_camera, vibration_sensor] conditions: - signal: top_camera.person_on_roof operator: value: 0.6 - signal: vibration_sensor.delta operator: value: 15.0 - signal: event_duration_s operator: value: 5 event_level: HIGH actions: [pull_over, lock_cargo, notify_operator] - rule_id: roof_temporary_occlusion description: 车顶短暂遮挡 sensors: [top_camera] conditions: - signal: top_camera.roof_occlusion operator: value: 0.5 - signal: event_duration_s operator: value: 10 event_level: MEDIUM actions: [notify_operator]配置里的阈值不能拍脑袋定。正确做法是先采集一段时间真实运营数据统计正常场景下的误报分布再把阈值设定在误报率和漏报率的平衡点上。规则引擎的好处是调整阈值不需要重新编译代码坏处是阈值太多后难以维护所以规则要定期清理、汇总并沉淀到统一的配置中心。4. 处置层车辆发现异常后按什么逻辑行动4.1 分级响应状态机识别到高等级事件后车辆要决定怎么行动。常规做法是定义一个安全状态机让车辆在不同状态下执行不同动作。# 无人配送车安全状态机最小示例仅用于说明思路 class SafetyStateMachine: def __init__(self): self.state NORMAL def handle_event(self, level): # level: 0无事件 1LOW 2MEDIUM 3HIGH if level 3: self.state EMERGENCY elif level 2: self.state WARNING elif level 1 and self.state NORMAL: self.state CAUTION elif level 0: self.state NORMAL return self.action() def action(self): if self.state EMERGENCY: return {action: brake, target_speed_mps: 0} if self.state WARNING: return {action: pull_over, target_speed_mps: 0, timeout_s: 5} if self.state CAUTION: return {action: slow_down, target_speed_mps: 0.5} return {action: normal, target_speed_mps: None}这个状态机的关键不是代码逻辑而是动作选择背后的取舍。EMERGENCY 对应直接制动WARNING 对应先减速、再靠边