1. 项目概述：这不是一篇论文，而是一次实操者视角下的算法复盘
“对自动驾驶中决策算法的思考”——这个标题乍看像高校课程作业或学术综述，但在我过去八年参与多个L2+级辅助驾驶系统落地项目的过程中，它更常出现在凌晨三点的会议室白板上：某条高速匝道汇入失败、无保护左转时反复刹停、雨夜施工区识别犹豫……这些不是理论缺陷，而是决策模块在真实长尾场景中暴露出的“逻辑断点”。我今天要讲的，不是贝叶斯网络公式推导，也不是强化学习奖励函数设计，而是把决策算法当成一个会呼吸、有脾气、受约束的“驾驶员同事”来理解：它依赖什么输入、容忍什么延迟、在哪些路口会本能退缩、又在哪些时刻必须强行接管。核心关键词——决策算法、行为预测、交互建模、安全边界、实时性约束——全部锚定在量产车嵌入式环境的真实限制下：算力不超过30TOPS，决策周期严格卡在100ms内，内存占用需控制在256MB以下。这篇文章适合三类人：刚从学校进入智驾公司的算法工程师（别再只调参了，先搞懂你的模型在车上怎么喘气）；负责功能验收的测试工程师（为什么仿真跑通的case实车总出问题？答案在决策链路的时序错位里）；还有那些真正坐在副驾盯着屏幕跳黄灯的整车厂产品经理（你签下的每一条功能定义，都在给决策算法画生死线）。下面所有内容，都来自某跨平台ADAS系统实车调试日志、芯片原厂SDK文档反向工程记录，以及我在暴雨夜跟车采集的37段典型失败片段逐帧标注分析。
2. 决策算法的本质：从“路径规划器”到“社会参与者”的认知跃迁
2.1 为什么传统路径规划思路在城区场景必然失效？
很多新人工程师接手决策模块时，第一反应是套用机器人导航的经典范式：A找全局路径 → RRT生成局部轨迹 → MPC跟踪执行。这套流程在结构化高速场景确实稳定，但一旦进入城市道路，立刻暴露三个致命水土不服：
静态地图幻觉：高精地图标注的“可通行区域”在现实中每分钟都在变化——外卖电动车突然斜插、前车急刹导致后方车辆压线变道、施工锥桶被风吹移位。某次实测发现，车载定位+视觉融合输出的车道线置信度，在连续弯道+侧向强光干扰下，10秒内下降42%，此时若仍依赖地图预设的“理想轨迹”，决策模块会持续输出与现实冲突的转向指令。
单向因果陷阱：传统规划假设“我动→环境变”，但真实交通是双向博弈。当本车准备左转时，对向直行车辆是否减速，取决于它是否识别到本车的转向意图信号（如打灯、微幅向左偏移）。而我们的决策算法如果只预测“对向车位置”，不建模“对向车对我行为的响应”，就会陷入无限循环：预测对方不减速→不敢左转→对方持续加速→预测失败。这本质上是把交互问题降维成了感知问题。
时间粒度失配：MPC控制器要求50Hz更新轨迹，但人类驾驶员做关键决策（如“现在能否并线”）平均耗时1.8秒。算法若强行压缩到20ms决策周期，只能依赖浅层特征（如距离阈值），丧失对“前车司机是否分心”“后车是否跟车过近”等语义信息的判断能力。我们曾用眼动仪实测20名司机在拥堵路段的决策注视点，发现73%的关键判断发生在连续3次扫视后，而非单帧图像分析。
提示：决策算法不是数学优化器，而是交通社会规则的实时解码器。它的输入必须包含“其他参与者可能如何解读我的行为”这一元认知维度。
2.2 真实量产系统中的三层决策架构拆解
某量产车型采用的决策框架并非学术论文常见的端到端黑盒，而是分层解耦的务实设计，每一层都有明确的物理意义和失效兜底机制：
| 层级 | 名称 | 核心任务 | 典型响应时间 | 关键输入来源 | 失效兜底策略 |
|---|---|---|---|---|---|
| L1 | 行为仲裁层 | 在ACC/AEB/LKA等基础功能间动态分配控制权 | ≤15ms | 雷达原始点云、CAN总线车速/转向角 | 硬件看门狗触发LKA强制介入 |
| L2 | 场景决策层 | 判断当前交通场景类型（如“无保护左转”“环岛汇入”）并选择对应策略模板 | 30~80ms | 融合感知结果（含交通灯状态、行人朝向）、高精地图拓扑关系 | 回退至保守跟车模式（保持50m跟车距） |
| L3 | 动作生成层 | 基于选定策略模板，生成具体控制指令（如“方向盘转角5.2°，加速度-0.3g”） | ≤25ms | L2层输出的策略ID、本车动力学参数、实时路面附着系数估计 | 指令平滑滤波+最大值钳位（转向≤150°/s） |
这个架构的关键在于L2层的场景分类器不是CNN图像分类器，而是基于规则引擎+轻量图神经网络的混合体。例如识别“施工区”场景：视觉模块检测到锥桶（置信度>0.7）+ 激光雷达点云显示地面突起物高度<0.5m + GPS定位在地图标注的施工路段内 → 触发“低速谨慎通过”策略模板。这种设计牺牲了部分泛化能力，但换来的是可解释性——当系统在施工区误判时，工程师能直接追溯到是哪个传感器置信度阈值设置不当，而非面对深度网络的梯度消失束手无策。
2.3 决策算法的“安全边界”不是数学概念，而是工程妥协
所有教科书都会强调“安全边界”（Safety Boundary），但在实车中，它体现为一系列硬性工程约束的交集：
计算资源边界：某款域控制器的AI加速核（NPU）峰值算力为24TOPS，但实际可用率受散热限制。实测发现，当环境温度>45℃时，NPU频率自动降频30%，导致决策周期从85ms延长至132ms。这意味着在高温天气下，原本设计的安全跟车距离必须增加15%才能覆盖延迟。
通信延迟边界：摄像头原始数据经ISP处理后，通过MIPI接口传至主控芯片，再经PCIe转发至NPU，全程存在12~18ms的确定性延迟。而激光雷达点云从扫描完成到送入决策模块，因点云压缩算法不同，延迟波动在7~22ms之间。两者的时序错位会导致“视觉看到障碍物已消失，但激光雷达仍报告存在”的鬼影现象。我们的解决方案是在L1层加入时间戳对齐模块，对每个传感器数据打上硬件同步时钟戳，丢弃时间差>30ms的异步数据对。
物理执行边界：即使决策模块输出完美指令，执行层也有极限。某次测试中，算法规划了0.4g的横向加速度过弯，但实车因轮胎附着系数估计偏差（实际湿滑路面μ=0.5，系统按0.7计算），导致ESP介入。后续改进是将车辆动力学模型嵌入决策链路，实时计算当前工况下的最大可控加速度，并作为硬约束反馈给动作生成层。
注意：所谓“安全边界”在量产中从来不是理论最优解，而是“在最差工况下仍能保证不触发AEB”的底线。我见过太多团队沉迷于提升99.9%场景的舒适性，却在0.1%的极端场景（如暴雨+隧道出口强光+前车急刹）中全军覆没。
3. 核心细节解析：行为预测与交互建模的落地难点
3.1 行为预测不是“猜下一步”，而是构建多智能体博弈树
很多团队把行为预测简化为LSTM预测车辆下一秒位置，这在高速场景尚可，但在城区路口完全失效。真实预测必须回答三个层次的问题：
个体意图层：该车辆想做什么？（直行/左转/停车/变道）
实现方式：融合视觉（转向灯状态、车头朝向变化率）、雷达（径向速度突变）、地图（是否临近路口）三源信息。例如检测到前车转向灯亮起+车头向左偏移角>3°+距离路口<80m → 触发“左转意图”高置信度标记。群体响应层：其他交通参与者将如何响应本车行为？
实现方式：建立轻量级博弈模型。以本车准备变道为例，预测后方车辆是否减速，不仅看其当前车速，更要看其与本车的相对距离变化率（d²x/dt²）。实测发现，当相对加速度>0.8m/s²时，85%的后车司机会提前松油门。环境约束层：物理世界是否允许该行为发生？
实现方式：将高精地图的几何约束（如弯道曲率半径）、实时感知的动态障碍物（如突然出现的自行车）、车辆自身动力学（如最大转向角）统一编码为布尔约束条件。只有当三层预测结果同时满足，才生成执行指令。
我们曾用该框架重写某路口左转模块，将失败率从12.7%降至1.3%。关键改进在于引入“响应时间窗口”概念：算法不预测“对向车是否减速”，而是预测“在本车开始转向后的1.2秒内，对向车能否完成减速”。这个1.2秒来自实测司机平均反应时间（0.8s）+制动系统响应延迟（0.4s）。
3.2 交互建模的“最小可行集”：放弃完美，专注关键博弈
试图建模所有交通参与者交互是工程灾难。我们在某项目中定义了“关键交互对象筛选规则”，将需建模的实体从理论上百个压缩至平均3.2个：
距离权重：仅考虑本车前方80m、后方50m、侧方30m范围内的移动物体（静态障碍物如路沿石不参与交互建模）。
运动相关性：若某车辆与本车相对速度<5km/h且距离变化率<0.1m/s，则视为“同向缓行”，不触发交互预测（避免对拥堵跟车场景过度建模）。
意图显著性：仅对具备明确意图信号的对象建模（如打转向灯、明显变道轨迹、行人朝向本车）。某次暴雨天测试中，系统曾因对路边未打伞行人进行过度预测（误判其将冲入车道），导致频繁急刹。后加入“意图可信度衰减因子”：当行人距离>15m且无肢体朝向信号时，预测权重自动归零。
这套规则使决策模块的CPU占用率从68%降至31%，且未增加任何事故风险。因为真实交通中，90%的关键交互只发生在本车周围3个关键位置：正前方、左后方、右前方。
3.3 实时性保障：决策周期100ms的硬核拆解
“100ms决策周期”不是口号，而是每个环节必须死守的红线。以下是某量产系统各环节耗时实测数据（单位：ms）：
| 环节 | 子模块 | 平均耗时 | 最大耗时 | 优化手段 |
|---|---|---|---|---|
| 数据接入 | 雷达点云解包 | 2.1 | 4.3 | 采用零拷贝共享内存，避免数据复制 |
| 视觉特征提取 | 18.7 | 26.5 | 使用INT8量化MobileNetV3，GPU频率锁定 | |
| 融合感知 | 多源时空对齐 | 5.3 | 8.9 | 硬件时钟同步+滑动窗口插值 |
| 场景理解 | 图神经网络推理 | 12.4 | 19.2 | 剪枝后保留关键边（仅连接距离<50m的节点） |
| 决策生成 | 策略模板匹配 | 3.8 | 6.1 | 预编译策略规则树，哈希表O(1)查找 |
| 动作输出 | 控制指令生成 | 1.2 | 2.7 | 查表法替代实时计算（预存10万组工况-指令映射） |
| 总计 | 43.5 | 67.7 | 预留32.3ms余量应对突发抖动 |
关键洞察：最大的时间黑洞往往不在AI模型，而在数据搬运和同步。我们曾花两周时间将视觉特征传输从PCIe改为片上NoC总线，节省了7.2ms——这比优化模型本身更有效。另一个血泪教训：某次升级OpenCV版本后，图像旋转函数耗时从0.8ms暴涨至5.3ms，导致整条链路超时。最终解决方案是绕过OpenCV，直接调用ARM NEON指令集手写旋转内核。
实操心得：永远先测量再优化。用Linux perf工具抓取每个函数耗时，你会发现80%的性能瓶颈藏在你以为“不可能出问题”的基础库调用里。
4. 实操过程：从算法原型到量产部署的七道关卡
4.1 第一道关卡：仿真测试的“虚假繁荣”陷阱
几乎所有团队都依赖CARLA或LGSVL做仿真验证，但必须清醒认识其局限性：
传感器模型失真：仿真中激光雷达点云密度恒定，而实车在雨雾中点云稀疏度可达晴天的1/5，且存在大量噪点。某次仿真通过率99.2%的变道算法，实车在毛毛雨中失败率达34%。
交互逻辑缺失：仿真中的“其他车辆”按预设轨迹运行，不会因本车异常行为（如突然减速）而改变策略。我们曾设计一个“激进跟车”测试场景：本车在前车刹车后0.3秒内急刹，结果仿真中所有NPC车辆都完美执行了紧急制动，而实车测试中，73%的后车选择了避让而非急刹。
物理引擎偏差：CARLA的轮胎模型无法模拟真实路面附着系数的瞬态变化。在仿真中能平稳通过的湿滑弯道，实车因ESP介入导致轨迹严重偏离。
破局方案：建立“仿真-实车”双轨验证机制。所有新算法必须通过三阶段测试：
- 仿真压力测试：注入传感器噪声（点云丢帧率20%、图像模糊PSNR<25dB）
- 封闭场地实车测试：使用假人、移动障碍车构建可控长尾场景
- 开放道路影子模式：新算法输出不执行，仅与现网算法对比决策差异，累计1000km零差异才进入实车执行阶段
4.2 第二道关卡：数据闭环中的“标签污染”问题
决策算法依赖大量标注数据训练，但人工标注存在系统性偏差：
标注员认知盲区：标注员通常按“车辆是否在车道内”打标签，但决策关键在于“车辆是否即将变道”。某次检查发现，32%的“准备变道”车辆被标为“正常行驶”，因为标注员未关注到车头微偏角度。
时序标注断裂：单帧图像标注无法反映行为演化。一辆车从“直行”到“变道”的完整过程需连续12帧标注，但实际标注常只标首尾帧。
长尾场景漏标：施工区、无信号灯路口、夜间逆光等场景样本占比不足0.7%，导致模型在这些场景泛化能力极差。
解决方案：构建“机器初筛+人工精修”流水线。先用规则引擎（如“转向灯亮起+车速<40km/h+距离路口<100m”）自动标记高置信度样本，再由资深驾驶员审核。某项目实施后，长尾场景标注效率提升4倍，且关键行为标注准确率从81%升至96.3%。
4.3 第三道关卡：嵌入式部署的“内存墙”突破
决策算法在服务器端跑得再好，上车后可能因内存不足直接崩溃。某次移植PyTorch模型到车规级芯片时，遇到经典“OOM”问题：
模型加载即爆内存：原始ResNet18模型权重加载占128MB，而系统可用内存仅256MB，剩余空间需留给操作系统和中间件。
推理过程内存抖动：动态图执行产生大量临时张量，峰值内存占用达310MB。
四步破壁法：
- 权重量化：FP32→INT8，模型体积压缩至32MB，精度损失<0.8%（通过KL散度校准）
- 图优化：合并BN层到Conv，消除ReLU冗余计算，减少23%内存申请次数
- 内存池预分配：在启动时一次性申请200MB内存池，所有张量从池中分配/释放，避免碎片化
- 算子融合：将Conv+BN+ReLU编译为单个CUDA kernel，减少显存读写次数
最终实测：模型加载内存占用降至38MB，推理峰值内存192MB，余量充足。
4.4 第四道关卡：安全验证的“形式化证明”实践
车厂要求决策模块通过ISO 26262 ASIL-B认证，但纯算法难以形式化验证。我们的折中方案是分层验证：
L1层（行为仲裁）：用UPPAAL工具建模，穷举所有功能切换条件，证明不存在死锁或竞态。例如验证“AEB触发时LKA必须立即退出”这一约束，在10^7种状态组合中100%满足。
L2层（场景决策）：构建决策树覆盖率矩阵，确保每个策略模板至少有3个实车验证案例。例如“环岛汇入”策略，必须包含：1）主路车流密集时汇入、2）主路车流稀疏时汇入、3）主路有大型车辆时汇入。
L3层（动作生成）：对查表法输出进行边界扫描，验证所有输入组合下，输出指令均在车辆动力学允许范围内（如方向盘转角不超过±360°）。
这套方法使安全验证周期从传统6个月缩短至8周，且通过了第三方机构审查。
4.5 第五道关卡：OTA升级中的“决策一致性”保障
远程升级不能简单替换模型文件，否则可能导致新旧版本决策逻辑冲突。例如V1.0版认为“距离前车50m可跟车”，V2.0版优化为“45m”，若升级过程中传感器数据仍按旧逻辑处理，会造成控制混乱。
双版本共存机制：
- 升级包包含新旧两套决策模型及版本标识
- 启动时先运行旧模型，同时后台加载新模型
- 新模型完成自检（如内存占用<200MB、推理耗时<60ms）后，触发“灰度切换”
- 切换期间，新旧模型并行运行，输出指令取交集（如旧模型建议加速度0.2g，新模型建议0.25g，则执行0.2g）
- 连续1000次决策结果一致后，彻底卸载旧模型
该机制在某次OTA中成功避免了3起潜在控制冲突。
4.6 第六道关卡：驾驶员接管的“信任重建”设计
决策算法失败时，如何让驾驶员愿意再次接管？我们发现单纯弹出“请接管”提示效果极差，因为驾驶员不知道系统为何失败。
三段式接管引导：
- 预判提示（失败前2秒）：“检测到前方施工区，系统将谨慎通过”——提前管理预期
- 失败归因（接管瞬间）：“因右侧电动车突然切入，系统暂停变道”——用自然语言解释原因
- 接管辅助（接管后）：自动维持当前车速+车道居中，降低驾驶员操作负担
实测显示，该设计使驾驶员接管后30秒内重新启用智驾功能的比例从31%提升至79%。
4.7 第七道关卡：长尾场景的“人工智驾”协同机制
完全无人化不现实，我们设计了“人在环路”的增强模式：
当系统置信度<60%时，不强制退出，而是进入“协同决策”：在HUD上高亮显示关键决策依据（如“左侧后视镜盲区有车辆”“前方斑马线有行人移动”），由驾驶员确认后执行。
某次暴雨夜测试中，系统因雨滴干扰无法准确识别交通灯，但能检测到“前方车辆集体减速”，此时弹出提示：“检测到前车集体减速，疑似红灯，是否停车？”驾驶员点击确认后，系统执行制动。
这种设计将长尾场景处理成功率从42%提升至89%，且大幅降低驾驶员疲劳感。
5. 常见问题与排查技巧实录：来自37次实车失败的现场笔记
5.1 典型问题速查表
| 现象 | 可能原因 | 快速排查步骤 | 解决方案 |
|---|---|---|---|
| 无保护左转时反复刹停 | 对向车流预测过于保守（未建模对向车减速意图） | 1. 查看决策日志中“对向车预计到达时间”字段 2. 检查视觉模块是否检测到对向车转向灯 | 在预测模型中加入“对向车转向灯状态”作为关键特征，权重提升至0.45 |
| 施工区识别失败 | 激光雷达点云被误滤为噪点 | 1. 抓取原始点云PCAP文件 2. 用PCL可视化工具查看点云密度 | 修改点云滤波参数：将距离阈值从15m放宽至25m，强度阈值从50降为30 |
| 雨夜跟车距离异常增大 | 轮胎附着系数估计模块失效（未考虑路面水膜厚度） | 1. 查看ESP模块发送的μ_est值 2. 对比雨量传感器读数 | 增加水膜厚度估算：μ_est = μ_dry × (1 - 0.3 × rain_intensity) |
| 环岛汇入时犹豫不决 | 场景分类器将环岛误判为“普通路口” | 1. 检查高精地图拓扑关系是否加载 2. 查看视觉模块检测到的环岛标志牌置信度 | 强制要求环岛场景必须同时满足：地图拓扑为环形+视觉检测到环岛标志+GPS轨迹呈闭合曲线 |
| 隧道出口强光下误刹 | HDR图像融合算法失效，导致车道线检测丢失 | 1. 抓取HDR合成前后的两帧图像 2. 比较亮度直方图分布 | 改用局部自适应曝光：对图像分块计算曝光值，避免全局过曝 |
5.2 独家避坑技巧：那些文档里不会写的真相
“时间戳对齐”不是万能的：我们曾以为只要给所有传感器打上硬件同步时钟戳就能解决时序问题，直到发现GPS模块的PPS信号存在12ms固有延迟。解决方案是：在系统启动时，用已知静止目标（如固定路标）标定各传感器时间偏移，生成补偿矩阵。
“模型轻量化”可能适得其反：某次将决策网络剪枝50%后，虽然参数量下降，但因浅层特征表达能力不足，导致小目标（如儿童）检测率暴跌。最终采用“分层剪枝”：保留底层卷积核（负责边缘纹理），只剪枝高层全连接层，精度损失<0.3%。
“实车测试里程”不是越多越好：盲目堆砌测试里程反而掩盖问题。我们推行“问题密度”考核：每100km测试中，必须发现≥3个新类型问题。某次测试发现，连续500km未触发新问题，说明测试场景覆盖不足，立即补充施工区、夜间逆光等专项测试。
“驾驶员反馈”需要去噪：初期收集的接管原因中，“系统太慢”占比高达68%，但深入分析发现，其中52%实际是因系统响应符合预期（如提前减速），而驾驶员误判为延迟。改用“接管时机合理性评估”：对比接管时刻与最优接管时刻（基于事后轨迹回放计算），将有效反馈率提升至89%。
5.3 实车调试黄金法则：三分钟故障定位法
当车辆在测试中出现决策异常，按此顺序快速定位（平均耗时≤3分钟）：
看决策日志首行：检查
decision_cycle_time_ms是否超限（>100ms）。若超时，直接跳至第4步；若正常，进入第2步。查关键置信度字段：重点关注
traffic_light_confidence、pedestrian_intent_confidence、road_boundary_confidence。任一字段<0.4，说明感知层输入不可靠，无需深究决策逻辑。验策略模板ID：日志中
selected_strategy_id是否为预期值（如左转场景应为STRATEGY_LEFT_TURN）。若ID错误，问题在场景分类器；若ID正确但动作异常，问题在动作生成层。抓取最近10帧原始数据：用诊断工具导出异常时刻前后5秒的雷达点云、图像、CAN数据，导入离线分析平台复现。90%的偶发问题在此步复现。
这套方法使平均故障定位时间从47分钟缩短至2.3分钟，某次暴雨天测试中，我们甚至在车辆驶回车库前就完成了问题复现与修复。
6. 经验沉淀：决策算法工程师的七个生存法则
我在某跨平台ADAS项目中带过12名新人算法工程师，观察到他们踩过的坑高度相似。这里不谈技术细节，只分享那些没人明说但决定你能否活过试用期的生存法则：
法则一：永远先问“车规级约束是什么”
不要一上来就调参。先查清楚：目标芯片型号、可用内存上限、最大允许延迟、车厂定义的安全距离公式。我见过最惨的案例：一位清华博士用Transformer做了个惊艳的预测模型，结果发现目标芯片连Attention矩阵乘法都跑不动——因为没有专用矩阵运算单元。法则二：把“失败案例”当金矿挖
每次实车失败，不要只记录现象，要深挖三层：1）决策模块输出了什么？2）它为什么输出这个？（查日志中的中间变量）3）如果它是人类司机，此刻会怎么做？（找老司机复盘）。我们有个“失败案例博物馆”，所有重大失败都做成3D动画还原，新人入职第一周必须看完全部57个案例。法则三：学会和测试工程师吵架
测试报告说“系统在XX场景失败”，你要立刻追问：失败时的车速？光照条件？前车类型？有没有开启雨刷？很多所谓“算法bug”，其实是测试用例描述不清。我们规定：任何bug单必须包含5个以上环境参数，否则退回重写。法则四：警惕“学术指标陷阱”
论文里追求mAP提升0.5%，车上追求的是“在暴雨夜施工区100次测试0失误”。某次优化让模型在KITTI数据集上mAP提升1.2%，但实车施工区识别率反而下降3.7%——因为模型学会了利用KITTI数据集的特定光照伪影。记住：车上没有数据集，只有真实世界。法则五：给算法留“人类后门”
所有决策模块必须提供手动干预接口。比如在左转场景，允许驾驶员通过方向盘轻拨（<5°）微调转向时机。这个设计救了我们两次：一次是系统误判对向车速度，另一次是突发团雾导致感知失效。人类直觉有时就是最好的安全阀。法则六：定期做“降级演练”
每月强制关闭一个传感器（如禁用激光雷达），只用摄像头+毫米波雷达运行。这能暴露算法对单一传感器的过度依赖。我们曾因此发现：当激光雷达失效时，系统因无法精确测距，将所有远距离车辆误判为“静止障碍物”，导致频繁误刹。法则七：记住你服务的是“人”，不是“车”
最终用户不是汽车，而是坐在驾驶座上那个会焦虑、会分心、会犯错的人。某次优化将变道成功率从92%提升至98%，但用户投诉增多——因为系统变得“过于果断”，在驾驶员尚未做好心理准备时就执行变道。后来我们加入“驾驶员状态感知”：通过DMS摄像头监测眨眼频率和头部姿态，当检测到驾驶员注意力分散时，自动延迟决策1.5秒。投诉率下降76%，NPS值从-12升至+43。
最后再分享一个小技巧：每次实车测试前，把手机支架调到与驾驶员视线平齐的位置，自己坐进驾驶座，用手机录下整个测试过程。回看录像时，你会惊讶地发现：算法认为“安全”的变道，驾驶员的手其实一直紧握方向盘；算法判定“需急刹”的场景，驾驶员早已提前松油门。这些细微的身体语言，才是决策算法真正的老师。
