那场面试我准备得很充分。BEV 融合、时序注意力、端到端的最新论文，我都能讲。讲到第十分钟，面试官打断我，问了一个很土的问题：前方一辆白色卡车侧翻，背景是白色天空，视觉模型漏检了，你的车怎么办。
我卡住了。
我当时的答案大概是“加数据重新训练”。这个回答不算错，但它暴露了一件事：我一直在想模型，没想过系统。
他问的不是长尾，是兜底
自动驾驶的面试里，Corner Case 出现的频率高得反常。不是面试官不关心前沿，是因为这一行最终交付的不是 mAP，是“出错的时候车会怎么样”。
学术训练给人的惯性是看平均值。测试集上提升一个点，就是进步。工业界的算法是另一套：剩下那百分之几的错误里，有多少会导致急刹、碰撞或者卡在路中间。平均值好看，最差情况难看的系统，不能上路。
SOTIF 把这件事说得比较清楚。它把场景分成四个象限：已知安全、已知不安全、未知安全、未知不安全。前两个是已经认识的，未知安全是运气好，未知不安全才是长尾真正待的地方。工程目标不是消灭未知，是把未知不安全一点点搬进已知，再变成已知安全。
所以我在面试里现在会先给定义，而不是举例。Corner Case 至少同时满足三条：出现频率低、特征模式和训练分布不同、并且可能诱发危险行为。
第三条最容易被忽略。路边飘一个气球，模型没见过，但它不影响决策，那只是分布外样本。同一个气球如果让车误判成障碍物、在高速上急刹，它就是 Corner Case。危险性是把它和噪音分开的那条线。
面试官通常会顺着这个定义往下问：那你见过哪些。这时候泛泛地说“光照、天气、异形车”是不够的，得能落到具体机制上。
感知层的问题大多来自物理限制和训练分布。白色卡车在强光下漏检，是像素分布过于集中，特征提取失效；进出隧道时曝光调整滞后，摄像头会短暂致盲；玻璃幕墙的倒影、雨后积水里的路灯，会被当成真实障碍物；高速上飞起的塑料袋，可能触发一次没有必要的急刹。这些例子的共同点是：模型看到的输入，和它训练时见过的模式不一样。
预测和规划层的问题来自人。鬼探头是遮挡导致的轨迹不可见，不是检测框没画出来；零距离切入是意图识别跟不上，规则预测往往反应慢半拍；无保护路口的博弈死锁，则是两辆车都太保守，谁都不动。这一层没有标准答案，只有策略偏好：多等一秒，还是冒一点风险往前挪。
环境与系统层更接近 ODD 的边界。暴雨里激光雷达的雨滴回波会让周围全是“障碍物”，镜头被泥水糊住，施工改道而高精地图没更新。这些问题不是模型能独立解决的，得靠降级、冗余和地图策略一起兜。
把这三层分开讲，好处是面试官能看出这不是在背清单。同样是“异形车”，在感知层是检测泛化问题，在预测层是意图识别问题，在系统层可能是 ODD 该不该覆盖的问题。层次不同，解法完全不同。
发现：数据闭环比模型结构难
如果面试官继续问“怎么发现这些场景”，只回答“看日志”是不够的。
能用的信号大概有几类。车端的影子模式，让算法在后台跑，和人类司机的操作比对，偏离大的片段自动回传。接管数据也是同理，只是更稀疏，而且带有很强的司机主观性：有人接管是因为真的危险，有人只是因为不放心。
另一类是先验的不一致。视觉说前方有东西，激光雷达在那个位置没有回波，这种模态冲突往往对应着特殊场景。还有时序上的跳变，前一帧是卡车，后一帧变成路牌，这种抖动本身就值得挖。
再往上一层是不确定性采样。模型对某一帧的置信度在阈值附近，说明它自己也在犹豫，这类样本的信息量通常比随机采样高。现在也有团队用向量检索，把图像编码之后按语义找相似场景，比写 SQL 查“雨天隧道口”靠谱得多。
这些方法都不新，难的是另外两件事：触发条件怎么定，以及谁来复核。
触发条件定得太松，回传的数据淹没人；定得太紧，真正的问题漏掉。比较稳的做法是分层设阈值：高置信的异常直接回传，边缘样本进候选池，定期抽样看候选池的质量。阈值不是定一次就完事，模型能力变了，阈值也得跟着重调。
复核更现实。挖出来一万条，标注团队一周只能处理几百条，剩下的排队。我见过团队把挖掘能力做得很好，最后卡在标注产能上，数据在硬盘里躺着，模型一点没变。
数据闭环的瓶颈通常不在挖掘，在消化。
自动标注能缓解一部分。云端大模型先出伪标签，置信度过滤之后再训练车端的小模型，这套教师学生的做法已经很常见。但它有代价：教师模型的错误会被学生学走，而且学得很像。所以我现在更愿意保留一部分纯人工的抽检，比例不用高，但必须独立于自动标注流程。
抽检还有一个作用：发现“没被挖出来”的问题。挖掘系统只能找到它被设计去找的东西，剩下那部分要靠人去看随机样本。全自动的闭环跑久了，会越来越擅长解决已知类型的问题，对新型问题反而迟钝。
还有合规。影子模式上传的是真实道路数据，车牌、人脸、地理位置都在里面，脱敏和留存策略得先于挖掘能力建好。这个环节在面试里很少有人提，但它经常决定一个数据闭环能不能真的跑起来。
仿真不是测试工具，是数据生产工具
实车路测覆盖不了长尾，这一点没什么争议。更麻烦的是有些场景根本不能在路上复现，比如鬼探头、连环碰撞。没有人会为了收集数据去制造事故。
仿真在这里的角色变了。它不只是验证，它是生产数据的地方。
我比较看重 log-to-world 这条路径：一次真实的接管，把当时的传感器数据、道路拓扑、障碍物轨迹重建成可复现的场景，改完算法之后在里面跑成千上万次。这样一次失效就变成了永久资产，而不是一条躺在日志里的记录。
再往前一步是参数泛化。同一个雨天路口，把光照从清晨调到黄昏，把雨量加大，把路面摩擦系数改小，一个场景能裂变成几千个。这一步的价值在于把“等它发生”变成“假设它发生”。
但仿真有个老问题：虚实差距。渲染出来的图像和真实摄像头有纹理、噪声、动态范围上的差异，模型在仿真里学得越好，可能越适应渲染器，而不是适应世界。NeRF 和生成式模型缓解了一部分，能用少量真实图像重建高保真场景，也能凭空生成没见过的极端情况。它们同时也引入了新的偏差：生成模型自己的先验会混进数据里，而很难分辨模型学到的是物理规律，还是生成器的习惯。
所以我不太相信“仿真覆盖率”这种指标。覆盖了多少场景，和这些场景能不能代表真实世界，是两件事。更实在的做法是看失败分布：仿真里挂掉的案例，有多少能在实车上复现；实车上出现的接管，有多少已经在仿真里被覆盖。两个方向对不上，说明仿真和现实已经分家了。
仿真还缺一个东西：判定标准。真实世界里，一次避让算不算“处理成功”，有时候连司机都说不清。仿真必须把它写成可执行的规则，比如距离、减速度、是否压线。规则写得越死，越容易优化出一个专门对付规则的策略；写得太松，又测不出问题。这个取舍没有通用答案。
端到端之前，先想清楚怎么验证
端到端是这两年被问得最多的话题。它的吸引力很直接：模块之间不再有手工设计的接口，误差不会一层层累积，长尾场景下的全局优化理论上更好。
问题在验证。一个端到端模型在极端场景下做对了，很难说清它为什么对；做错了，也很难定位是哪一层出的问题。规则系统至少还能打印出触发条件，端到端只有一个权重文件。
我现在的看法是混合架构更现实：用大模型处理非结构化、需要常识的场景，同时保留一层轻量的规则或者传统算法做兜底，负责最后的安全边界。这层兜底不优雅，参数也不好看，但它在模型失效的时候还在。
这不是技术保守，是取舍。放弃的是端到端“全局最优”的想象，换来的是一个可解释、可审计、出了事能查的降级路径。在车规场景里，我认为这笔交换划算。
世界模型是另一个方向。它试图学习环境怎么演化，从而在传感器被遮挡、信息不全的时候补出一个合理的预测。这个思路对长尾很有吸引力，但补出来的东西对不对，仍然要靠真实数据验证。一个会“脑补”的系统，在面试里必须能说清楚脑补的边界，否则它只是把不确定性藏得更深。
顺便说一个容易混淆的地方：ISO 26262 管的是电子电气系统的功能失效，SOTIF 管的是没有故障、但性能不足导致的危害。两者不是替代关系。面试里能把这条边界说清楚的人不多，说清楚了，通常会让对方认真起来。
回到面试。我现在会用 STAR，但重点不在 R。
S 讲清楚边界：什么光照、什么遮挡、传感器当时是什么状态。T 讲约束：不只说降误检，还要说清召回不能掉，延迟和算力还有多少余量。A 讲全链路：数据怎么挖的、模型改了什么、系统层加了什么兜底。R 只报我真正测过的数，并且主动说回归测试的结果。
最关键的一句，通常是“我放弃了什么”。为了压住误刹，我接受了一部分漏检风险，然后用多传感器一致性和时序校验把它兜回来。面试官追问的往往就是这句“兜回来”，因为那才是工程判断发生的地方。
我后来没有再遇到那道白色卡车的题。但类似的问法一直有：如果模型没看见，然后呢。这个问题没有终局答案。做这行久了会慢慢接受，交付的不是一个不会犯错的系统，而是一个犯错时知道该往哪边倒的系统。
评论