一条加塞视频，怎么变成上千个测试场景？聊聊场景构建方法

去年秋天在南京，我跟一台测试车在路口蹲了一下午。电动车从右侧缝里钻出来，AEB一脚急刹，后排水杯飞了。回办公室有人拍桌子：把这段行车记录仪丢进仿真器，不就完了？我当场头大。视频是证据，不是场景。真要拿它做测试，得把它拆开、抽干、再重新长出来。这就是场景构建方法要干的脏活。

一条视频不是场景，顶多算线索

很多人对场景的想象还停在“录一段路，回放一遍”。哎，真不是。场景更像一份可复现的剧本：路怎么铺、谁从哪冒出来、当时是逆光还是雨雾、初始速度多少、评价标准看碰撞还是看舒适度。少一个约束，测试结果就可能飘。你看，同样叫“加塞”，早高峰的出租车和园区里的外卖电动车，完全两码事。

我习惯把场景拆成四块：静态环境、动态实体、初始状态、评价标准。静态环境是道路几何、车道线、路沿、信号灯；动态实体是车、人、骑行者；初始状态决定“从哪儿开始演”；评价标准决定“演成什么样算失败”。这四块缺一块，仿真器里跑出来的曲线就只是曲线，不是证据。

所以场景构建方法的起点不是建模，是判断：这段路采数据里，哪些东西值得被抽成参数？哪些只是当天的噪音？说实话，这一步很磨人。你盯着视频一帧一帧看，嘴里念叨“这个切入时距得记下来”“这个横向偏移不能丢”，像在拆一台满是油泥的旧发动机。

脏活都在参数化和筛选里

拿那条电动车加塞视频举例。我们不会直接把它塞进仿真器，而是先切片：找到加塞开始前几秒、切入瞬间、急刹之后。然后抽参数：电动车相对速度、切入时的时距、横向偏移、目标车减速度、路面附着、光照方向。抽完还不够，得看这些参数在真实路采里怎么分布。对吧，你不能只拿一个“典型值”糊弄自己。

接下来是组合生成。切入时距从偏早到偏晚拉一串，横向偏移从贴边到压线拉一串，光照从顺光到逆光拉一串。参数一交叉，一条视频能长出几百个变体。这里头有个坑：别为了数量把参数乱撒。撒过头，场景库会变成一堆“看起来不一样、其实测不出新东西”的重复样本。我们后来加了筛选，按风险等级和覆盖缺口挑，把低价值变体砍掉。心疼，但必须砍。

筛选完还要回灌。仿真里跑出的高风险场景，得回到实车或路采数据里核对：这个逆光加白车加湿滑路面的组合，现实里到底有没有？没有的话，是仿真器太乐观，还是参数分布偏了？这一步经常打脸。有一次我们以为发现了感知盲区，结果一查，是传感器模型把雨滴散射简化过头了。仿真通过不等于实车通过，反过来也一样。

常见误解得吐槽一下：场景越多越好？真不是。重复场景堆上去，回归测试跑得冒烟，长尾该漏还是漏。还有人说“仿真跑通了就稳了”，这话听着就悬。仿真器不是算命先生，它只是把已知约束摆出来让你看。约束错了，结论就歪。

别把仿真当算命，场景库要会“长牙”

那场景构建方法到底用在哪？软件在环、硬件在环、整车在环，回归测试，法规测试，还有影子模式。影子模式挺有意思：车在路上跑，系统在后台悄悄比对仿真或模型输出，发现不一致就回传。场景库不是建完就锁进柜子，它得会“长牙”，能咬住新问题。今天加塞，明天施工占道，后天暴雨积水，场景库得跟着路采数据一起长。

边界也得说清楚。仿真器的物理模型有简化，传感器模型有简化，交通参与者行为模型更是个大坑。你参数化得再细，也挡不住现实里有人一边看手机一边斜穿。场景构建方法的局限不是“不够多”，是“不知道的还没被采到”。所以我现在更愿意把场景库看成一张地图，不是一堵墙。地图会缺路，得靠实车回灌和线上数据补。

最后留个冷思考：别把场景构建方法做成参数表演。测试报告里写“覆盖了多少场景”，不如写清楚“这些场景为什么值得测、失败长什么样、回灌后改了啥”。场景是剧本，但观众是物理世界。剧本写得再花，物理世界不买账，那就得回去改。