1. 从一次“惊险”的测试视频说起
前几天，我在一个自动驾驶技术交流群里，看到了一段流传甚广的测试视频片段。画面里，一辆贴着Uber ATG（Advanced Technologies Group）标识的测试车，在路口黄灯亮起的瞬间，非但没有减速，反而维持着甚至略微加速的姿态，径直“闯”了过去。视频的拍摄者显然被吓了一跳，旁白里充满了不解和担忧：“这车怎么这么‘虎’？黄灯了还不减速，不要命了吗？”
这个片段迅速引发了群里的激烈讨论。有人调侃这是“硅谷速度”，有人质疑传感器是不是坏了，更多的人则和我一样，陷入了技术层面的思考：这真的是一个“错误”或“鲁莽”的行为吗？还是说，在这看似违背常理的操作背后，隐藏着自动驾驶决策系统一套复杂的、甚至与我们人类驾驶员截然不同的逻辑？今天，我们就以这个“闯黄灯”事件为引子，深入拆解一下自动驾驶汽车（尤其是以Uber为代表的早期方案）在感知、预测、规划与控制（PPC）全链条中，面对此类动态交通场景时，究竟是如何“思考”并做出决策的。你会发现，机器的“不要命”，很可能源于它对“安全”和“效率”有一套更冷酷、更数学化的定义。
2. 黄灯困境：人类司机与自动驾驶的认知鸿沟
要理解自动驾驶的行为，首先得明白黄灯在人类交通规则中的模糊性。对于人类司机而言，黄灯不是一个非黑即白的指令。它意味着“警告”，是绿灯到红灯的过渡。我们的决策是一个复杂的、基于经验的快速博弈过程：估算自己到停止线的距离、当前车速、刹车性能、路口是否有摄像头、后车跟得紧不紧，甚至包括当时的心情和紧迫感。最终，我们会在“冲过去”和“停下来”之间选择一个自认为风险更低、或更“划算”的选项。这个过程充满了主观性和不确定性，也是路口事故的高发原因之一。
然而，对于自动驾驶系统，尤其是基于规则（Rule-based）或早期混合决策模型的系统，这种模糊性是灾难性的。系统必须将连续、模糊的现实世界，转化为离散、确定的可执行指令。因此，在程序设计中，黄灯通常会被赋予一个更“硬”的边界条件。一个常见的简化策略是设定一个“决策点”：当车辆到达距离停止线某个特定距离（例如，依据当前速度计算，需要X秒的减速度才能舒适停下）时，如果信号灯为绿灯，则评估通过可能性；如果变为黄灯，则系统必须立即决策——是执行“通过”还是“停止”。
问题就出在这个“决策点”和后续的“舒适减速度”参数上。以Uber早期采用的方案为例（其技术框架源自卡耐基梅隆大学机器人研究所的许多成果，与后来的纯数据驱动端到端模型有区别），它的决策模块很可能依赖于一个高度优化的成本函数（Cost Function）。这个函数会综合评估多个因素的成本，例如：
- 违反交通信号的成本：闯红灯的成本极高，闯黄灯的成本次之，但具体数值需要设定。
- 急刹车的成本：包括乘客舒适度下降（加速度变化率Jerk值）、潜在的后车追尾风险、以及能量损耗。
- 通行效率的成本：不必要的停车会导致行程时间增加。
- 预测轨迹的碰撞风险成本：基于对周围行人、车辆未来轨迹的预测，计算每条潜在路径的碰撞概率。
系统会在极短时间内，计算“紧急制动至停止”和“维持当前速度通过”两条主要轨迹的总成本，然后选择成本更低的那条。如果“急刹车成本” + “轻微违反黄灯规则的成本” < “平稳通过的成本”，系统就可能选择“冲黄灯”。在Uber的案例中，其算法可能对“急刹车”赋予了异常高的成本（过于追求乘坐舒适性或避免后车碰撞），同时对“闯黄灯”的规则成本设定得相对较低，从而导致系统在黄灯初期更倾向于通过。
注意：这里存在一个关键的“冷启动”问题。人类司机看到黄灯亮起，是从“允许通行”的绿灯状态切换过来的，心理上有一个预期。而自动驾驶的感知系统是逐帧判断的。如果感知延迟、或信号灯识别模块在黄灯亮起瞬间未能100%确信（例如光照干扰），系统可能会在几毫秒内仍按“绿灯”逻辑进行规划，等确认是黄灯时，车辆可能已经越过了那个理论上的“安全停止点”，此时急刹的风险反而大于通过。这也能部分解释视频中“不减速”的现象。
3. 透视Uber自动驾驶的技术栈与决策逻辑
要深入分析，我们不能停留在猜测，需要回顾一下Uber ATG当时可能采用的技术架构。虽然其具体代码未公开，但结合其招聘需求、技术论文以及行业通用的模块划分，我们可以勾勒出一个大致的画面。这有助于我们理解“闯黄灯”决策发生在哪个环节，以及为何会产生这样的结果。
Uber的自动驾驶系统大概率属于模块化架构，而非现在热门的端到端大模型（如VLA， Vision-Language-Action）。模块化架构将任务分解为感知、定位、预测、规划、控制等独立模块，每个模块各司其职，通过预定义的接口传递数据。这种架构的优点是可解释性强、模块可以单独调试和升级，但缺点也明显：信息在传递过程中会有损失和延迟，且“木桶效应”显著，最弱的模块决定整体上限。
3.1 感知与定位层：看见了什么，身在何处？这是所有决策的基础。Uber测试车通常配备了激光雷达（LiDAR）、摄像头、毫米波雷达和GNSS/IMU组合导航系统。
- 激光雷达：提供高精度的3D点云，用于检测障碍物轮廓和距离。点云分割标注是训练感知模型的关键，目的是将成千上万个点分类为“车辆”、“行人”、“骑行者”、“道路”、“植被”等。Uber早期可能使用了基于传统几何特征或早期深度学习（如PointNet系列）的分割算法。
- 摄像头：提供丰富的纹理和颜色信息，主要用于交通信号灯、标志牌、车道线的识别，以及对物体类型的精细分类。这里就涉及深度学习与自动驾驶的经典应用：用卷积神经网络（CNN）识别红绿灯状态。
- 毫米波雷达：擅长测速和在大雨、雾天工作，弥补激光雷达和摄像头的不足。
- 定位：结合高精地图（HD Map）、激光雷达点云与地图的匹配（Localization）、以及GNSS，实现厘米级定位。自动驾驶激光SLAM技术在这里扮演重要角色，尤其是在GNSS信号不佳的区域（如城市峡谷），通过激光雷达数据实时构建并匹配局部地图，确保车辆知道自己的精确位姿。
在“闯黄灯”场景中，感知层必须毫秒不差地完成以下任务：1）检测到交通信号灯的存在；2）正确分类其当前状态（红、黄、绿）；3）估算出车辆到停止线的准确距离。任何一个环节的微小延迟或误判，都会直接导致后续决策的偏差。
3.2 预测与规划层：核心的决策大脑这是整个系统最核心、也最复杂的部分，也是“闯黄灯”决策的产生地。
- 预测模块：它不仅要感知静态环境，还要预测动态参与者（其他车、人）的未来几秒内的轨迹。早期系统多采用基于物理模型（如恒定速度、加速度模型）或简单交互模型的方法。更先进的会使用深度学习进行轨迹预测。预测的准确性直接决定了规划的安全性。
- 规划模块：这是真正的“指挥官”。它接收感知和预测的结果，结合高精地图提供的车道、交通规则信息，生成一条从当前位置到目标位置的安全、舒适、高效的轨迹。Uber很可能使用了类似Apollo EM Planner的规划器，这是一种经典的、分层的规划方法。
- 行为决策层（Behavioral Layer）：在粗粒度上决定车辆要做什么，例如“车道保持”、“换道”、“路口左转”、“停车等待”。在黄灯路口，这一层需要做出“通过”或“停止”的行为决策。
- 运动规划层（Motion Planning Layer）：将行为决策转化为一条具体的、平滑的、无碰撞的轨迹。这需要求解一个复杂的优化问题，其中就包含了我们前面提到的成本函数。优化变量包括轨迹的曲率、加速度、速度等，约束条件包括车辆动力学限制、交通规则、障碍物避让等。自动驾驶控制业务的核心算法（如MPC模型预测控制）在这里被紧密集成，用于生成可被底层控制器执行的轨迹。
关键点在于成本函数的权重设置。如果算法工程师在调试时，将“乘客舒适度”（即减速度变化平缓）的权重设得过高，将“严格遵守黄灯规则”（视为一种可轻微违反的规则）的权重设得过低，那么系统在黄灯初期的优化求解中，就很容易得出“轻微加速通过比急刹车更优（成本更低）”的结论。这并非系统“想找死”，而是它在给定的数学公式下，计算出的“最优解”。
4. 从模块化到端到端：决策范式的迁移与挑战
“闯黄灯”事件暴露了模块化架构在处理复杂、模糊场景时的僵化。规则和成本函数是人为预设的，很难覆盖所有“长尾场景”。这也是为什么近年来，端到端自动驾驶成为了研究热点。
端到端模型试图用一个庞大的深度学习模型（通常是Transformer架构），直接输入传感器数据（如图像、激光雷达点云），输出控制指令（方向盘转角、油门刹车）。它不显式地分为感知、预测、规划模块，而是让模型自己从海量数据中学习这些中间表示和决策逻辑。端到端大模型VLA更是引入了语言指令，让系统能理解“小心通过路口”或“保守驾驶”等高级命令。
这种范式的优势在于：
- 减少信息损失：避免了模块间接口导致的信息压缩和延迟。
- 更好的泛化能力：通过海量自动驾驶数据集（包括中国自动驾驶数据集如DAIR-V2X、nuScenes的中国子集等）的训练，模型可能学会更接近人类的、更灵活的驾驶策略，包括对黄灯那种“可冲可停”的模糊地带的处理。
- 处理复杂交互：深度学习模型更擅长捕捉交通参与者之间微妙的、非定式的交互意图。
然而，端到端也带来了巨大挑战：
- 可解释性差：它是一个“黑箱”。我们很难理解为什么模型在某个时刻做出了“冲黄灯”的决策，这给调试、验证和权责认定带来了困难。
- 数据依赖性强：需要极其庞大、高质量、覆盖所有极端场景的数据。如果训练数据中“安全冲黄灯”的样本多于“急刹停黄灯”的样本，模型就可能偏向于前者。
- 安全验证难：如何证明一个端到端模型在所有未知场景下都是安全的，是目前尚未解决的难题。
有趣的是，一些前沿研究正在尝试结合两者优点，比如用端到端模型作为“老师”，来指导或优化模块化系统中成本函数的参数，或者用大模型来生成更合理的驾驶行为参考。甚至有人在**《欧洲卡车模拟2》（欧卡2）** 这类高度拟真的游戏中，用端到端模型进行训练和测试，因为游戏能低成本生成海量、多样的驾驶场景，包括各种极端天气和交通状况。
5. 实测复盘：如何设计更“像人”也更安全的黄灯策略？
那么，作为一个自动驾驶算法工程师，在面对黄灯场景时，应该如何设计一个更合理、更安全的策略呢？结合我个人的项目经验和行业实践，以下是一些关键思路和实操要点：
5.1 精细化定义“决策区间”而非“决策点”不要用一个固定的距离或时间点来触发二选一决策。应该定义一个动态的“决策区间”（例如，距离停止线2-5秒车程的范围）。在这个区间内，系统应持续评估，并允许决策在一定条件下反转。
- 区间入口（如黄灯亮起时距停止线5秒车程）：系统倾向于准备停车。除非有极高置信度的预测表明通过更安全（如后方有高速逼近的大型车辆且预测其可能无法及时制动）。
- 区间中部：综合计算通过和停止的成本，但会为“停止”预留更多的安全余量（即更早开始平缓制动）。
- 区间出口（如距停止线1.5秒车程）：一旦进入此区域，应果断锁定“通过”决策，并确保车辆能平稳通过，避免在停止线前急刹或犹豫不决，这是最危险的状态。
5.2 引入不确定性感知和风险预测成本函数不能只计算单一轨迹的成本，而应计算在预测不确定性下的期望成本。
- 感知不确定性：交通灯识别置信度是多少？如果置信度低于阈值（比如90%），应默认按最坏情况（即红灯）处理，或触发降级策略（如温和减速并提示人工接管）。
- 预测不确定性：对横向闯入的电动车、行人的预测轨迹方差有多大？方差越大，意味着风险越高，决策应越保守。
- 自身控制不确定性：考虑制动系统响应延迟、路面附着系数变化等因素，在计算制动距离时加入安全系数。
5.3 设计多层级的、可解释的成本函数将成本函数拆解为多个层级，并使其参数可在线调节或学习。
- 安全层（最高优先级，一票否决）：任何有确定碰撞风险的轨迹，成本直接设为无穷大。这需要精确的碰撞检测算法。
- 规则层：违反交通规则的成本。这里可以对“闯黄灯”进行分级惩罚，例如，在黄灯亮起前半秒通过，惩罚较小；在黄灯即将结束前半秒通过，惩罚应急剧增大，因为那意味着很可能闯红灯。
- 舒适层：考虑加速度、加加速度（Jerk）、曲率变化率等。急刹车的成本应该高，但不应高到让系统宁愿冒险。一个技巧是使用非对称成本：急刹车的舒适成本可以设得高，但急加速的舒适成本可以设得更高，因为乘客对突然的推背感更敏感，这也能抑制系统在黄灯前盲目加速。
- 效率层：行程时间、能耗等。权重通常最低。
在调试时，可以通过大量的仿真测试（包括极端案例回放），观察不同参数下系统在成千上万个黄灯场景中的表现，用数据来校准这些权重，而不是凭感觉。
5.4 利用高精地图和V2X信息如果车辆拥有路口的高精地图，它能提前知道停止线的精确位置、路口几何形状，甚至信号灯的相位时序（如果接入了V2X车路协同信号）。这能极大提升决策的准确性和提前量。系统可以提前规划速度，实现“绿波通行”或平稳停车，从根本上减少陷入“冲还是停”两难境地的次数。
5.5 引入驾驶风格参数和场景上下文系统不应只有一种驾驶策略。可以通过一个“驾驶风格”参数（如“保守”、“标准”、“高效”）来动态调整成本函数中各部分的权重。在天气恶劣、学校区域、或感知置信度低时，自动切换到“保守”模式，此时对黄灯的反应会更倾向于提前减速。同时，系统应能理解场景上下文：在高速路下匝道的黄灯路口，与在城市支路小路口，决策的激进程度理应不同。
回过头看Uber那个“闯黄灯”的案例，它很可能是在一套追求平顺性、且对规则层成本权重设置不够敏感的算法参数下，产生的“局部最优解”。对于公众和监管者而言，这样的行为是难以接受的，因为它挑战了人类的驾驶常识和安全感。这也提醒所有自动驾驶开发者，算法的“最优”必须建立在符合人类普遍预期和社会规范的基础之上。安全，永远不是一个单纯的数学最小值问题，更是一个涉及心理学、伦理学和社会学的复杂命题。在教会机器如何驾驶的路上，我们不仅要给它装上眼睛和大脑，或许还需要为它注入一丝人类的“谨慎”与“敬畏”。
