视觉感知后处理和辅助驾驶功能之间的那段链路，是我在智能驾驶工程中见过最容易被低估的地方。很多人觉得，模型把障碍物框画出来，后处理把框修一修，剩下的交给决策规划就行。实际做下来你会发现，视觉障碍物后处理输出的目标形态、稳定性、时间对齐方式，几乎决定了FCW、AEB、ACC这些功能能不能可靠触发，也决定了用户在路上会不会被突然的报警吓一跳。这篇聊的不是模型结构，而是障碍物后处理里那些看起来不起眼、却直接影响功能上车的细节，以及它们如何一步步变成功能决策的输入。适合正在做感知后处理、传感器融合、功能安全或者辅助驾驶策略的朋友，也适合想真正弄懂智驾全链路的人。
1. 感知输出到功能触发，中间缺了一层"翻译"
1.1 从原始检测框到结构化目标，后处理补了哪几步
先说完整链路，方便对齐上下文：相机采集图像，检测模型输出原始框、类别和像素级置信度，然后进入视觉后处理模块，做过滤、去重、坐标转换、深度估计、目标追踪，最终输出一个结构化的目标列表，再往下游做融合和功能决策。
这中间没有任何一个环节能跳过去。模型直接输出的东西，说实话，不能叫"目标"，只能叫"检测响应"。它的问题是：
第一，单帧输出冗余。同一辆车可能被检测出三个重叠框，一个给乘用车类别、一个给SUV类别、还有一个是像素级背景响应，你不做非极大值抑制，下游根本不知道该听谁的。
第二，缺少物理量。模型输出的是像素坐标下的bounding box，功能要的是自车坐标系下的距离、相对速度、横向重叠率。这个换算不是几何投影就完事，还涉及相机外参标定、地面平面估计、目标高度假设。不做这一步，距离就是估不准的。
第三，没有时间概念。单帧检测不会告诉你这个目标上一帧在哪里、下一秒大概率在哪里。功能做决策需要知道目标是一直在还是刚冒出来的，需要估计它在时间上的发展趋势。这需要后处理做目标追踪，维护目标ID和轨迹。
第四，要输出质量信息。光说"这里有辆车"不够，还得说"我有多大把握确定它是车"、"它的位置估计方差多大"、"它是否被部分遮挡"。这些质量信息是后面功能降级和功能安全的基础。
所以视觉后处理本质上是个翻译层：把模型输出的、像素域的、瞬时性的检测结果，翻译成功能模块能直接消费的、物理域的、有时间一致性的结构化目标。下游功能模块不长眼睛，它只看你给的目标列表。
一个典型的输出数据结构大概长这样：
struct VisualTarget { uint32_t object_id; // 目标ID，追踪模块分配，要求稳定 uint8_t object_class; // 类别：乘用车/卡车/行人/骑行者等 float distance; // 目标相对自车的纵向距离，米 float relative_speed; // 目标相对自车的纵向速度，米/秒 float lateral_position; // 目标中心横向位置，米 float overlap_ratio; // 横向重叠率，0~1 float confidence; // 综合置信度，后处理汇总 float existence_prob; // 存在概率，基于多帧估计 uint8_t truncation_state; // 遮挡/截断状态 uint8_t quality_level; // 质量等级，供功能分级使用 uint64_t source_timestamp; // 图像曝光时刻的时间戳 uint64_t output_timestamp; // 后处理输出的时间戳 };后面所有辅助驾驶功能的触发，本质上都是基于这样一个结构体在做数学判断。
1.2 为什么不能让辅助驾驶功能直接消费模型输出
我经常拿一个类比说明这个问题：模型输出是作者的初稿，后处理是编辑校对，辅助驾驶功能是发行部门。初稿里可能有错别字、有重复段落、有些地方前后矛盾，直接给发行部门，肯定要出事。
具体到数据层面，原因有几个。
最致命的问题在目标ID跳变。模型本身没有跨帧记忆，这一帧给前车分配了ID 17，下一帧因为光照变化输出框偏了一个像素，跟踪匹配失败，后处理又给同一个车分配了ID 18。功能层拿到一个"新目标"，会认为前方突然切入了一辆车，本来在做的ACC跟随策略立刻切换，车猛地顿一下。这种体验对用户来说非常糟糕，而在时序处理不完善的后处理里，这几乎是必现的问题。
第二个问题在物理量不稳定。视觉距离估计天然有噪声，如果不做时间滤波，距离值可能在80米和82米之间跳变，相对速度可能在一帧是-1.5米/秒、下一帧变成-0.5米/秒。功能层用这种数据算TTC，结果一会儿是3秒、一会儿是8秒，触发时机忽早忽晚。特别是AEB这类功能，触发晚0.2秒就是完全不同的结果。
第三个问题在输出频率。模型可能因为算力限制只跑到15帧每秒，而功能层希望以25到30赫兹的周期做决策。如果后处理不做插值、不维护目标状态，功能层在模型没输出的间隙里就拿不到数据，只能把目标丢掉，等下个周期再捡回来，决策连续性完全没法保障。
所以后处理的存在不是可有可无的"修图环节"，而是为了把感知数据调整到功能模块能安全消费的程度。这也是为什么后处理模块的代码看起来经常比模型推理代码更琐碎、更"脏"——因为它要处理大量边缘情况，而这些边缘情况恰恰决定了功能能不能稳定干活。
2. 目标质量是功能触发的"货币"：置信度与时间一致性
2.1 置信度不能一刀切，功能是分级消费的
很多后处理模块刚起步的时候，习惯做一件事：设置一个置信度阈值，比如0.6，高于阈值的目标才输出，低于阈值直接丢掉。看起来没毛病，实际上会摔得很惨。
原因是，辅助驾驶功能对目标质量的要求不是单一的。FCW（前向碰撞预警）这种功能，误触发容忍度极低。你在高速上正常跟车，前车距离80米，如果系统突然报"碰撞风险"，驾驶员会吓一跳，紧接着就会投诉。所以FCW消费的目标，置信度门槛必须非常高，宁可漏报，不可误报。但AEB（自动紧急制动）就不一样，AEB漏报是要出大事的，它的目标是"绝不漏掉真实危险"，所以它消费的目标允许置信度低一些，同时用多帧确认来压制误报。
也就是说，后处理不应该只输出一个"0.6以上保留、0.6以下丢弃"的二元结果，而应该把目标质量的维度保留下来，让功能自己去决策。我倾向于把置信度拆成三个维度：
分类置信度，指的是"这个目标属于乘用车/卡车/行人这个类别的概率"，反映类别判断有多可靠。定位置信度，指的是bounding box和深度估计的稳定程度，可以用轨迹的协方差、深度值的波动幅度来近似。存在概率，则是基于多帧历史估计出来的"这里真的有一个实物目标"的概率。
这三个维度互相独立。一个目标可能分类置信度很高，但深度估计波动很大，这时候定位置信度低，AEB不会依赖它的距离做紧急制动，但FCW可能愿意看它一眼。反过来，一个目标分类置信度只有0.4，但连续20帧都稳定存在，存在概率很高，你也不能直接扔掉，因为阴雨天、黑夜里模型特征本来就弱，不代表目标不可信。
所以我在后处理里一般保留一个质量等级字段，分三档。L1是高质量目标，可以被AEB、ACC直接消费；L2是中等质量，可以参与FCW、BSD这类预警功能；L3是低质量疑似目标，只作为提示信息，不参与任何主动控制。这种分级方式，让功能侧有据可依，而不是靠猜。
2.2 单帧稳定不算稳定，用"存在概率"压住瞬时抖动
接下来是时间一致性，这是我见到的后处理模块最大的分水岭。
单帧检测稳定，不等于功能触发稳定。现实场景里，目标偶尔会在某一帧丢失，原因可能是遮挡、逆光、运动模糊，也可能是模型在某一帧打了个盹。如果功能层以"这一帧有没有目标"为准，那么目标就会闪烁——一帧在、一帧不在、一帧又在，ACC的跟车间距会不断重置，AEB会反复进入退出预触发状态，车内的人体验就是一顿一顿，非常吓人。
后处理模块要想办法让目标"记住"自己上一帧存在过。标准的做法是维护目标轨迹，每一帧用检测结果去匹配已有轨迹，用卡尔曼滤波来预测和更新目标状态。匹配上了，目标继续存活，状态被平滑更新；暂时没匹配上，轨迹并不会立刻删除，而是进入"待定"状态，继续用运动模型外推位置。只有连续多帧都匹配不上，才判定目标确实离开。
这里有一个核心概念：存在概率。它是基于多帧数据算出来的后验概率。简单说，如果帧率是20赫兹，单个检测的真实丢失率只有10%，那么连续两帧同时丢失的概率是1%，连续三帧同时丢失的概率是千分之一。用滑动窗口做m/n确认（比如3帧内确认2帧），存在概率可以稳定保持在90%以上。功能层拿到的目标从"时有时无"变成了"稳定存在但偶尔观测噪声增大"，决策连续性完全不同。
下面是一个简化的对比：
| 处理方式 | 目标在某帧漏检后 | 功能层表现 | 体验结果 |
|---|---|---|---|
| 纯单帧输出 | 目标立刻消失 | 报警中断，距离重置 | 误判频繁、控制抖动 |
| 带存在概率的时序输出 | 目标继续存在，位置按运动模型外推 | 报警连续，等待下一次观测 | 稳定平顺，偶有轻微噪声 |
这里需要提醒的是，时序平滑有个度。如果后处理对外推过度信任，目标明明已经离开视野了，轨迹还悬空存在好几秒，就会造成"跟空气较劲"。我一般会给外推存活时间设上限，比如视觉目标最多外推0.3到0.5秒，超过这个时间没有新观测就直接删除。具体数值要看功能需求：ACC要求目标不能凭空消失，但也不能凭空出现，所以外推时间长一点；AEB则更偏向保守，外推时间短一点，防止拿错位置做制动决策。
3. FCW/AEB数据流拆解：从后处理字段到制动请求
3.1 功能触发所需的关键物理量与后处理来源
既然说辅助驾驶功能消费的是结构化目标，那就拿FCW和AEB这两个最典型的例子，把数据流完整走一遍。这两个功能本质都是在回答一个问题：前方目标有没有碰撞风险，风险等级多高，该做多少干预。
要回答这个问题，功能需要后处理提供四个关键物理量。
第一是纵向距离。视觉后处理通常基于地面平面约束和障碍物底部位置来估计距离，也可以用深度估计网络直接回归。无论哪种方式，这个距离都必须是在自车坐标系下的物理距离，而且要补偿相机安装位置和自车运动带来的偏差。距离是所有后续计算的基础，它错一点，后面全错。
第二是相对速度。相对速度可以通过帧间距离差分得到：相对速度 = (距离_t - 距离_{t-1}) / dt。但差分会放大噪声，所以必须做滤波。更稳妥的做法是让后处理直接输出经过卡尔曼滤波后的相对速度估计。注意，功能层计算TTC时必须使用后处理输出的相对速度，而不是让功能层自己去差分，否则同一份数据在两个模块里算出两种结果，很难调试。
第三是TTC（碰撞时间），公式是TTC = 距离 / 相对速度。视觉后处理一般不直接输出TTC，因为它属于功能策略层的概念，但后处理输出的距离和相对速度，决定了功能算出来的TTC准不准。这里有个容易踩的坑：当相对速度趋近于零时（比如两车同速行驶），TTC会趋近于无穷大，功能一定要做上限保护，否则会出现TTC=9999秒这种毫无意义的数值，直接影响后级判断逻辑。我一般建议后处理在输出相对速度时同步输出一个速度有效标志，让功能知道这个值是否可信。
第四是横向重叠率。光有距离和速度还不够，你得判断目标是否在当前车道的前进路径上。横向重叠率就是后处理根据目标的横向位置、横向宽度和自车预测行驶轨迹算出来的一个0到1的值。它不为零，才说明有真正的碰撞路径。
我把这些映射关系整理成一张表：
| 功能所需物理量 | 后处理输出来源 | 典型质量要求 |
|---|---|---|
| 纵向距离 | 深度估计、地面几何解算 | 误差小于5%，延迟补偿到统一时刻 |
| 相对速度 | 帧间差分+滤波估计 | 平滑无跳变，噪声小于0.5 m/s |
| 横向重叠率 | 目标轮廓与自车路径交点计算 | 稳定，不随单帧抖动跳变 |
| 存在概率/置信度 | 多帧确认、追踪质量汇总 | 区分等级供功能分级使用 |
| 目标ID | 追踪模块分配 | 同一目标ID连续，不轻易切换 |
3.2 一个虚拟场景的全链路计算：从像素到减速度请求
下面用一个相对具体的例子把链路串起来。
假设自车以60 km/h（约16.7 m/s）行驶，前方车道内有一辆静止车辆，后处理模块在距离80米处检测到它。模型输出的原始bbox经过坐标换算，得到目标的纵向距离80米，帧间差分后得到相对速度约为-16.7 m/s（即自车在逼近目标）。存在概率经过3帧确认后达到0.96，质量等级为L1。
功能层拿到这些数据后，做TTC计算：TTC = 80 / 16.7 ≈ 4.8秒。
然后策略层按TTC分级处理。一般来说，TTC大于2.6秒时只出FCW一级预警，提示驾驶员制动；TTC进入1.2秒到2.6秒区间，系统可能施加部分制动力度；TTC小于1.2秒时进入紧急制动请求。每个阈值在不同厂家的策略里略有差异，但量级差不多。
重点在于，整个链路里后处理的角色非常明确：它不决定何时刹车，但它决定了距离和相对速度是否可信。后处理需要确保距离曲线平滑不跳变，相对速度经过滤波不出现正负跳变，目标存在概率在触发过程中始终保持在阈值之上，让功能层从头到尾看到一个连续、可信的目标。
这里有一个工程细节必须提：时间戳同步。图像曝光的时刻、后处理输出的时刻，中间隔着推理时间、后处理计算时间，可能还有排队等待时间，加起来少则30毫秒，多则上百毫秒。如果不做补偿，后处理输出"当前距离80米"时，自车实际已经前进了0.5到1米。TTC本身就对距离敏感，距离误差影响的是碰撞时间计算，可能在紧急场景下让系统晚触发几十毫秒，那就是真金白银的安全差距了。
所以后处理的输出里一定要同时带source_timestamp和output_timestamp，功能层或融合模块用这两个时间戳把距离、相对速度外推到统一的决策时刻。这个外推计算听起来简单，但漏做这个步骤的项目我见过好几个，无一例外都出现了"明明感知没问题，但AEB触发时机就是比预期晚"的诡异问题。
4. 功能安全视角：后处理的失效模式与降级策略
4.1 失效模式不能靠侥幸，后处理要输出"可靠度"信号
辅助驾驶功能只要牵扯到横纵向控制，就绕不开功能安全。功能安全对感知后处理最核心的诉求是：你得让下游知道你的输出什么时候不可信。
后处理的失效模式，我归纳下来大概是这几类。
漏检，目标真实存在但系统没报出来。可能是因为遮挡太严重、目标太远、模型对该类别的召回率不足。漏检对AEB这种功能是致命的，因为下游完全没有目标，根本谈不上触发。
误检，不存在目标但系统报出一个假目标。比如高架桥的路牌阴影被识别成行人，路侧护栏反光被识别成车辆。误检对FCW体验影响大，会频繁报警，用户很快就会选择把功能关掉。
跟踪丢失，目标本来在轨迹里，因为匹配失败被踢出去。表现为输出目标列表里ID 17突然消失，下一秒ID 23出现。功能层会误以为原来的目标消失了，接着又有一个"新目标"切入，决策逻辑被打乱。
输出跳变，同一个目标的状态参数在连续帧之间发生突变，可能从距离80米跳到75米，或者相对速度从-2 m/s变成+1 m/s。这类失效对TTC计算影响很大，功能层在极短时间内会看到风险等级从低跳到高，容易触发过敏反应。
状态退化，指后处理判断当前感知质量整体下降，比如暴雨天、强逆光、夜间无照明路段，或摄像头镜头被泥水遮挡。这时候单个目标看起来都正常，但整体可信度低，任何基于单个目标的判断都可能不可靠。
我的建议是，后处理输出里除了每个目标的confindence，一定要有一个反映整个感知链路的诊断状态字段，比如"正常、降级、不可用"。下游功能模块看到这个字段才敢决定：是继续依赖视觉目标，还是切到雷达/激光做融合兜底，或者干脆提示驾驶员接管。
下面是一个简化的响应矩阵：
| 失效模式 | 后处理表现 | 功能层应如何响应 |
|---|---|---|
| 漏检 | 目标缺失 | AEB类功能依赖其他传感器冗余，视觉仅做提示 |
| 误检 | 出现无对应实物的目标 | FCW对低置信度目标只提示不控制，多帧存活后再升级 |
| 跟踪丢失 | ID切换、目标突然消失 | 功能层保持上一状态短暂维持，等待重建轨迹 |
| 输出跳变 | 参数突变 | 功能层设置变化率上限，超过阈值拒绝更新 |
| 状态退化 | 整体诊断状态异常 | 功能降级，ACC退出，提示驾驶员接管 |
4.2 遮挡与自车运动估计：两个系统性偏差要提前想清楚
遮挡问题，在视觉后处理里特别典型。城市路口场景，前方一辆大车挡住了一部分视野，被遮挡的后方目标可能只露出一条边。模型在可见部分上仍然可以给出一个框，但这个框的定位是偏移的，距离估计也会偏。如果后处理不做遮挡补偿，功能层拿到的目标距离可能是"可见边缘的距离"而不是"真实目标的距离"。后果是，AEB以为离目标还有30米，实际已经只剩20米了。
后处理要做的，是输出截断状态（truncation_state）和部分可见标志。当目标被部分遮挡时，一方面降低该目标的质量等级，另一方面用历史轨迹信息对位置做补偿，而不是直接沿用当前帧的原始输出。在融合阶段，视觉后处理的遮挡标志也能帮助融合算法决定是否更信任雷达目标。
自车运动估计的问题，很多人会忽略。后处理计算目标相对速度，最常用的方式是帧间距差，也就是我们前面说的相对速度 = (距离_t - 距离_{t-1}) / dt。这里有个隐含前提：自车速度和自车位置是已知的。一旦自车运动估计不准，比如轮速传感器标定偏差、车辆横摆角估计漂移，帧间坐标对齐就会出错，算出来的相对速度也会跟着飘。
举个例子：如果自车速度误差是1 m/s，在TTC计算里，这个误差会直接叠加到相对速度上。对于TTC = 80 / 16.7 = 4.8秒的场景，相对速度若被估计成15.7 m/s，TTC变成5.1秒；若被估计成17.7 m/s，TTC变成4.5秒。这0.3到0.6秒的误差，在紧急制动场景里足以改变功能是否点火。所以后处理在融合自车速度时，一定要对输入的自车运动状态做有效性检查，并且在输出相对速度时附带估计方差，让功能层意识到这个值有多可信。
这部分的经验是：光把目标本身做准不够，还要把"目标状态估计的输入条件是否可靠"一并传下去。功能安全不是单个模块的孤岛任务，它贯穿到后处理每一个数值的语义里。
5. 工程落地检查清单：从后处理到辅助驾驶功能上车的八个细节
5.1 上车之前逐项排查的清单
在实验室跑通算法和真正装车应用之间，隔着大量琐碎但致命的工程细节。我梳理了一份自用检查清单，每次新项目联调时都会逐项过一遍。
第一，坐标系一致。后处理输出的目标坐标必须统一到自车后轴中心或惯导安装点，和功能层使用的坐标系完全一致。坐标系定义差一点，横向重叠率就会错，车道内目标判断会偏。
第二，时间戳对齐。保证source_timestamp是图像曝光时刻，不是输出时刻；保证功能层在决策时使用同一套时钟源。多传感器融合时还要把相机的曝光时间和雷达的扫描时间对齐，否则融合出来的目标距离会有周期性抖动。
第三，目标ID稳定性。一条轨迹从创建到删除，ID不能变。如果必须重建轨迹，要输出轨迹切换标识，让功能层知道这个目标经历了中断，而不是当成"同一辆车数据发生了跳变"。
第四，输出频率和插值。模型推理可能是15帧每秒，但功能层需要25赫兹的数据。后处理要负责以固定频率发布目标状态，在无新观测时用预测值填充，并标记当前的预测状态是"观测更新"还是"外推预测"。
第五，置信度分级。不要只保留一个置信度，把分类置信度、定位置信度、存在概率分开输出，并给出综合质量等级。功能层可以据此做差异化决策。
第六，遮挡和截断状态。目标是否被部分遮挡、遮挡比例大致多少，要显式输出。遮挡目标的距离和质量都要打折扣，不能和完好目标一视同仁。
第七，自诊断和退化状态。后处理要实时评估自身输出质量，镜头污染、强光饱和、连续帧匹配率下降，都要及时上报。这是功能降级的前置条件。
第八，日志可回放。后处理输出的每个目标状态要和原始图像、功能触发日志同帧对齐保存。出问题时，工程师能按时间轴逐帧查看：图像里到底有什么，后处理为何判断成目标，功能层又基于什么做出了触发。没有这样完整的日志链路，调参就是瞎猜。
5.2 一次虚拟调参复盘：雨夜高架误报是怎么水落石出的
这套检查清单不是纸上谈兵，我举个例子说明实际排查思路。某次在城市高架环境下，FCW功能出现偶发急促报警，频率不高但每次都很吓人，用户反馈集中在雨夜时段。
拿到问题后，处理链路是这样拆的。第一步，拉功能触发日志，找到报警发生的时间点。第二步，按时间戳回放该段时间的后处理输出，发现报警前约0.3秒，后处理目标列表里新增了一个质量等级为L1的目标，位于车道中心，距离大约45米，存在概率达到0.9以上。第三步，打开同帧原始图像，看到的东西却很简单——车道线上方有两根路灯杆，雨夜地面反光形成了一团亮斑，模型把它框成了一个疑似车辆。
问题定位到这里已经比较清晰：后处理对"新冒出来的目标"没有做充分验证。单帧的检测响应经过m/n确认后，很快被提升为L1目标，功能层拿到的数据看起来完全正常，自然就执行了报警。
后续的修正也很有代表性：一方面在后处理里增加了目标有效性判定，结合深度一致性、纹理强度和时序稳定性做综合评分，对新创建的目标设置更长的确认窗口。另一方面给FCW功能侧增加了"目标在近端新增时，第一轮只提示不触发"的规则。刷完这一版，同场景的误报警数量降了两个数量级。
这个案例里没有高深算法，但每一步排查都依赖一个前提：后处理输出的目标状态，必须能够追溯到产生它的源头。没有日志回放能力，这种事只能靠运气去复现。
6. 如果只让我说一点，我会强调什么
做了这么多年视觉后处理，如果只能留一条经验给同行，我会说：把后处理的输出当成"可消费的产品"来设计，而不只是当成"某个更准的检测结果"。
这句话有两层意思。第一层，产品要有规格说明书。目标列表里的每个字段，代表什么物理含义、噪声有多大、更新频率是多少、哪些情况会导致它不可信，这些都要写清楚。下游功能侧只有拿到这样的规格，才知道怎么安全地消费这批数据。第二层，产品要带质检报告。每次输出都应该包含质量相关的元信息，让下游能够识别"这次的数据到底值不值得信"。
我在实际联调中体会到，感知和后处理团队如果能花一个下午，把功能侧最底层的触发逻辑完整过一遍，效率比盲目堆精度高得多。很多时候问题不在"检测准不准"，而在"检测结果传到功能层时，语义已经被静默扭曲了"。是坐标没对齐，还是时间戳没同步，还是目标ID被重建，这些才是真正让功能突然犯傻的原因。
另外一个很实用的小技巧：调试时把功能触发日志、后处理输出日志、原始图像视频三条流按时间戳合并成一个文件回放。这一条帮我解决过的疑难问题，比任何花哨的调试工具都多。任何一个中间环节的数据变化，都能当场看到它对最终表现的影响，排查链路瞬间短了一半。如果你做的项目还没有这样一套回放工具，我建议你把它列为优先级最高的事情之一。
