做自动驾驶这几年我最大的感受是真正让人卡住的从来不是某个模型不够新而是整条链路上的信息断层——感知团队不知道规控要什么规控不清楚数据闭环在采什么部署那边又在为几十毫秒的延迟反复改图。这一期「自动驾驶合集26」我打算把感知、预测规划、数据闭环、仿真评测、车端部署这五块重新串一遍重点讲那些文档里不写、但实际干活时会绊你一脚的细节。核心关键词就三个BEV 与 Occupancy 的表达取舍、端到端对工程链路的真实影响、数据闭环的带宽与标注成本控制。刚入行的感知同学、想从后端转规控的同学、做数据平台和仿真评测的同学都能从里面找到能直接抄的部分。合集这种形态在自动驾驶团队里特别常见因为这套系统耦合太深单点优化极容易做成局部最优只有横向摊开看才知道自己那块到底在给谁兜底。1. 这一期合集想解决的真问题1.1 为什么合集这种形态在自动驾驶团队里特别常见做单一模块的人容易陷入一个错觉指标涨了系统就好了。我见过不止一次感知的检测 mAP 涨了两个点路测接管次数反而变多。原因很简单——新增的那部分召回很多是远处的小目标检测出来了但预测模块的时间窗只有两秒等它进入规划可用的距离范围车已经该做决策了。这种问题在任何单模块的周报里都看不出来只有把链路摊开才能看到。所以合集的价值不在于资料汇总而在于强制你把上下游的约束条件摆到同一张桌子上。这一期我按数据流的方向组织传感器进来感知出中间表达预测给意图规划出轨迹数据闭环把失败案例捞回来仿真做回归验证最后压到车端算力里。每个环节我都会讲清楚它的输入契约、输出契约、以及最容易和邻居打架的地方。1.2 三个最容易被低估的瓶颈排第一的是时间同步。摄像头、激光雷达、组合导航的采样率各不相同硬同步做不干净后面所有融合都是在拟合噪声。排第二是评测口径离线指标和真实驾驶表现之间的相关性比大多数人想象的要弱得多。排第三是内存带宽不是算力。很多人算车端预算只算 TOPS实际跑起来发现瓶颈在搬运数据上算力单元一半时间在等数据。这三件事有个共同点它们都不性感不出论文不写进融资材料但它们是决定一个团队能不能把 demo 变成产品的那条分界线。这一期我会用具体的数字把这三点讲透包括显存怎么算、带宽怎么算、延迟怎么分解。1.3 给不同角色的阅读路径建议时间紧的话我建议按角色跳读角色定位优先看原因感知 / 融合工程师第 2 章、第 6 章中间表达选型和部署约束是绑定的预测 / 规划工程师第 3 章、第 5 章接口契约和评测口径决定你的迭代方向数据平台 / 标注管理第 4 章触发策略和复核比例直接决定成本仿真 / 测试第 5 章、第 4.4 节场景库和问题速查表是配套的嵌入式 / 部署第 6 章、第 2.3 节精度对齐要和前端预处理一起看新手我建议从第 2 章开始顺着读因为感知的中间表达决定了后面所有模块的输入形状先把这个搞明白后面的接口设计会顺畅很多。2. 感知链路BEV 与 Occupancy 的表达取舍2.1 BEV 视图成为事实标准靠的不是精度而是对齐BEV鸟瞰图之所以成为多传感器融合的默认中间表达本质上解决的是一个坐标系问题而不是精度问题。摄像头的图像空间是透视投影近大远小同一个车道线在近处和远处像素长度差好几倍激光雷达是三维点云稀疏且不均匀。这两种数据要在网络里做融合你必须先找一个公共的、几何一致的空间。BEV 就是这个空间——它把视角统一到地面平面距离度量变成等比的车道宽度在两米外和五十米外在特征图上占的格子数是一样的。实现路线上分两派。一派是显式的几何投影把图像特征按相机内外参抬到三维空间再压平好处是可解释、便于插值坏处是深度估计不准的时候会撒出一大片模糊特征。另一派是 query 式的用一组可学习的查询向量去图像里取特征好处是不依赖显式深度坏处是训练收敛慢、对数据量要求高。我在实际项目里见过两种混用的方案近处用显式投影保证精度远处用 query 补稀疏区域。这种混合方案调试成本不低但如果你的场景里有大量远距离高速工况收益是实打实的。有个细节值得提醒BEV 特征图的分辨率不是越高越好。0.2 米一格和 0.5 米一格在 100 米处的实际差异远小于你的直觉。我做过一次对比把 BEV 网格从 0.2 米降到 0.4 米检测指标掉了不到 0.5 个点但特征图元素数量减少到四分之一显存和带宽压力直接松了一大截。这个取舍在下文 2.3 节会具体算。2.2 Occupancy 补的是 BEV 的通用障碍物短板BEV 的一个结构性缺陷是它假设世界是由车、人、车道线这些预定义类别构成的。现实里不是。掉落的纸箱、横在路上的树枝、施工围挡的斜撑、倒在路上的共享单车——这些东西不在类别表里BEV 检测头会直接忽略它们而规划模块默认没检测到就是没有于是径直撞上去。Occupancy 网络把输出从框换成体素占据状态本质上是把问题从这是什么降级成这里有没有东西难度大幅下降覆盖面大幅上升。这也是它能快速落地的原因。它不需要知道类别只需要判断每个三维小格子里有没有被占据、以及是不是可通行。代价是显存和标注。给你算一笔账假设体素网格是 200 × 200 × 16长宽各 200 格高度 16 层特征通道 128半精度存储200 × 200 × 16 × 128 × 2 Byte 40000 × 16 × 128 × 2 640000 × 256 163,840,000 Byte ≈ 156 MB这是单帧、单尺度的特征张量。如果做四帧时序融合就是 624 MB训练时反向传播还要存激活值再乘个系数加上优化器状态一张卡上光这一块的占用就很可观了。这还没算解码头的输出。所以体素分辨率的选择不是学术问题是显存预算问题。我的经验是高度方向不要盲目堆16 层已经能覆盖绝大多数路面障碍物的高度分辨需求把预算花在长宽方向的远处覆盖上更划算。2.3 时间同步与在线标定融合效果的隐形天花板前面说了时间同步是第一瓶颈这里展开讲。多传感器融合里时间误差会直接转化成空间误差。假设车速 20 m/s也就是 72 km/h时间戳差 50 毫秒对应 1 米的位移。1 米在城市道路里意味着什么意味着你的融合结果里前车的位置误差已经超过半个车身宽度了。实操上我推荐三步走。第一步是硬件触发尽量让所有传感器共享同一个时钟源这是最干净的方案但很多存量车型改不了。第二步是软件插值对高频传感器做时间戳对齐摄像头一般 30 Hz激光雷达 10 Hz组合导航 100 Hz把低速的那个作为基准高频的做插值。第三步是残差补偿用车辆运动模型把点云推到统一时刻。在线标定这块我要多说一句外参漂移是慢性病。出厂标定做得再好跑几万公里、过几次大坑、轻微剐蹭外参就会偏。偏一点点的时候融合结果看起来还行但 BEV 特征里叠影会变模糊检测置信度整体下降你会误以为是模型退化重新训练一轮白烧几周算力。所以我现在做项目一定会要求加一个基于车道线和静态目标的在线标定监控把外参残差做成可视化每周看一次趋势。下面是时间对齐的伪代码思路很朴素但踩过的坑都在注释里def align_by_timestamp(sensor_streams, ref_stream, max_gap_ms60): sensor_streams: {name: [(ts_ns, data), ...]} 各传感器按时间排序 ref_stream: 基准流通常选激光雷达或组合导航 aligned [] for ref_ts, ref_data in ref_stream: frame {ref: ref_data} for name, stream in sensor_streams.items(): # 坑1不能只找最近邻要检查gap超阈值必须标记为缺失 # 而不是硬插值否则会给融合层喂假数据 prev, nxt find_bracket(stream, ref_ts) gap_ms min(abs(ref_ts - prev.ts), abs(nxt.ts - ref_ts)) / 1e6 if gap_ms max_gap_ms: frame[name] None # 显式缺失下游走降级分支 continue # 坑2插值必须带运动补偿直接用相邻帧线性插值 # 在转弯工况下会引入横向偏差 frame[name] interpolate_with_motion(prev, nxt, ref_ts) aligned.append(frame) return aligned这里的两个坑是我实打实吃过亏的。第一个是硬插值喂假数据导致感知在某些时刻置信度虚高规划据此做了激进决策。第二个更隐蔽是转弯时的线性插值偏差直道上完全看不出来一到环岛或者匝道就暴露。2.4 实操心得先把数据管道跑通再谈模型结构我见过太多团队模型结构换了一轮又一轮最后发现瓶颈在数据加载上。具体表现是GPU 利用率曲线锯齿状峰值 90%谷值 20%平均下来不到 50%。这意味着你花钱买的算力有一半在等硬盘。排查顺序我一般是这么走的先用性能分析工具看一个 epoch 里数据加载和前后向传播的时间占比如果数据加载超过 30%就先别动模型。然后看是不是在做重复解码——很多团队把图像解码放在训练循环里每张图每轮都重新解 JPEG这是纯浪费。正确做法是离线转成未压缩或者轻量压缩的中间格式用顺序读代替随机读。另一个容易被忽略的点是数据增强的位置。把增强放在 CPU 侧的多进程里做GPU 只负责前向和反向这个分工比全塞进 GPU 要划算得多。我在一个项目里把增强从 GPU 挪到 CPU worker单卡吞吐提升了接近 40%改造成本只有两天。3. 预测与规划从规则堆叠到学习式规划3.1 预测模块的接口契约比模型精度更重要预测模块的输出到底该给规划什么这个问题的答案在不同团队之间差异巨大。有的给未来 3 秒、6 秒、9 秒三个时刻的位置点有的给 8 条候选轨迹加概率有的直接给占据栅格的概率分布。我个人的偏好是多条轨迹加概率同时保留一条最保守边界。为什么要有保守边界因为规划模块需要知道最坏情况下这个东西可能在哪。只有均值轨迹的话规划会倾向于贴着预测轨迹走一旦预测偏差就是碰撞。加一条把横向不确定性和纵向不确定性都放大的边界轨迹规划在做安全间距检查时会自动留出余量。数据结构上我建议用矢量化的输入表示把场景里的每个交通参与者表示成历史轨迹点的序列把地图表示成折线段的集合。相比栅格化表示矢量化省内存、省算力而且对长距离依赖更友好。格式大致长这样scene: timestamp_us: 1730000000000000 ego: history: [[x, y, heading, v, a], ...] # 过去20帧0.1s间隔 size: [4.8, 1.9, 1.5] agents: - id: 17 type: vehicle history: [[x, y, heading, v], ...] # 缺失帧用 null 占位不要补零 valid_mask: [1,1,1,0,1,...] map_polylines: - type: lane_center points: [[x, y, dir_x, dir_y], ...] speed_limit: 13.9这里有个小坑缺失帧不要补零。补零会让网络以为那辆车瞬移到了坐标原点然后又飞回来学出来的东西是错的。正确做法是用掩码显式告诉网络这一帧无效让注意力机制自己去忽略它。这个细节在很多开源实现里都处理得不对。3.2 规划的分层结构和代价函数的权重设计规划我一般拆成三层全局路由、行为决策、局部轨迹优化。全局路由负责从 A 到 B 的路径行为决策负责跟车、变道、让行、通过路口这类离散选择局部轨迹优化负责在选定行为下生成平滑、可执行的轨迹。代价函数是这套东西的心脏。一个典型的加权形式J w_col * J_collision w_com * J_comfort w_eff * J_efficiency w_ref * J_reference_deviation w_prg * J_progress各项的含义和量纲要对齐否则权重没法调。J_collision是碰撞风险用时间维度上的最小距离或者 TTC 倒数来衡量J_comfort一般用加速度和加加速度的平方积分横向加加速度超过 5 m/s³ 乘客就会明显不适J_efficiency惩罚速度偏离期望速度J_reference_deviation惩罚偏离参考线J_progress奖励沿路径的推进量。权重配置我是这么写的用配置文件而不是硬编码方便不同车型、不同驾驶风格切换planner_costs: collision: weight: 1000.0 # 硬约束级别必须远大于其他项 ttc_threshold_s: 2.5 comfort: weight: 12.0 jerk_limit: 5.0 # m/s^3 lat_acc_limit: 3.0 # m/s^2 efficiency: weight: 6.0 desired_speed_ratio: 1.05 reference_deviation: weight: 3.5 progress: weight: 8.0调权重的经验先让碰撞项独占把其他项全设为零确认轨迹绝对安全然后逐项加每次只加一项观察路测表现的变化。一次性把所有项都开起来调你会陷入改了 A 结果 B 坏了的死循环因为各项之间存在耦合。我吃过这个亏整整两周时间在权重上打转最后退回单项目标才把问题定位清楚。3.3 学习式规划落地时最容易翻车的地方端到端或者学习式规划这两年热度很高但我建议保持清醒。它最大的价值在于减少手工规则的维护成本把特殊路口怎么办这类长尾问题的处理方式从代码里挪到数据里。它没有改变的是系统依然需要安全兜底依然需要可解释性依然需要在异常输入下有确定性的降级行为。翻车点我总结出三个。第一是分布偏移训练数据里没有的工况模型输出可能荒谬到无法用规则拦住。第二是时序一致性逐帧独立的模型会在相邻帧之间输出抖动的轨迹执行层根本没法跟。第三是可调试性归零出问题的时候你没法像规则系统那样定位到第 217 行那个判断写错了。我的做法是分层学习式模块只负责生成候选轨迹和打分最终执行前一定要过一层基于运动学的可行性校验包括曲率连续性、加速度边界、轮胎转角限制。这层校验是纯粹的几何和物理计算没有学习成分它的存在让系统在最坏情况下也能保持可执行但不优而不是优但不可执行。4. 数据闭环真正拉开差距的地方4.1 触发式回传的条件设计和带宽预算车队每天产生的数据是海量的全量回传不现实。所以必须设计触发策略让车端自己判断这段值得传。触发条件我一般分几类接管类安全员接管、系统主动退出、驾驶员踩刹车或打方向动力学类急刹减速度超过阈值、急打方向、频繁修正感知类目标置信度剧烈波动、跟踪目标 ID 频繁切换、出现大量的未知类别占据规划类规划失败重规划、轨迹频繁重选、长时间低速徘徊优先级要分层接管类最高规划类次之感知类再次。因为接管类直接对应真实失败信息密度最高。带宽预算必须提前算清楚不然你会发现车队一跑起来云端存储账单失控。给你算一笔假设 100 辆车每车每天触发 20 次每次 30 秒 摄像头 8 路H.264 压缩后每路约 4 Mbps 0.5 MB/s 单次视频0.5 MB/s × 30 s × 8 路 120 MB 激光雷达点云压缩后约 2 MB/帧10 Hz30 s 300 帧 → 600 MB 单次合计约 720 MB点云占大头 单车每天720 MB × 20 14.4 GB 100 车每天1.44 TB看到问题了吧点云是绝对的带宽杀手占了八成以上。所以实际操作里我会做三件事点云只在关键帧传完整数据中间帧降采样或者只传跟踪结果视频按事件窗口裁剪只保留触发前 10 秒和后 20 秒加一个去重机制同一条路上重复触发的场景用相似度过滤掉。这三招下来实测能把传输量压到原来的四分之一左右。4.2 自动标注和人工复核的比例控制自动标注的核心不是能不能标而是标完之后你敢不敢信。我的做法是把自动标注拆成两段预标注模型出初稿人工只做修正。人工修正的方式不是从头画框而是接受/拒绝/微调这样单帧工时能降六成以上。但复核比例不能一刀切。我按场景难度和数据用途分档数据用途预标注质量要求人工复核比例说明训练集主体中10% 抽样量大靠规模稀释噪声训练集长尾高60% 以上长尾场景本身稀少噪声影响放大回归测试集极高100%测试集一旦有错标回归结论全废部署前验收集极高100%同上且需双人交叉这里有个反直觉的结论测试集的标注质量投资回报率远高于训练集。训练集有 1% 的噪声模型基本能扛住测试集有 1% 的噪声你可能会在一个版本里看到指标莫名波动然后花两周去找一个根本不存在的模型退化。4.3 数据集版本管理和标签溯源这一块听起来像工程琐事但它决定了一个团队能不能做可复现的迭代。我见过的最惨的情况是跑了三个月实验发现最好的那个版本用的数据集已经找不回来了中间有人重新生成过一次标签被覆盖。我的要求是三条硬规矩。第一每个数据集版本有一个不可变的哈希标识由采样清单、标签文件、预处理参数共同计算得出。第二标签必须带血缘即这条标注是谁标的、用什么工具标的、经过了哪几次修正、每次修正的原因是什么。第三训练配置里必须记录数据集哈希而不是路径。路径会变哈希不会。这三条执行起来有阻力因为标注团队会觉得增加工作量、算法同学会觉得填配置麻烦。我的做法是把哈希自动注入训练日志不让人手工填同时把数据集的差异对比做成命令行工具让这次和上次有什么不同变成一条命令就能回答的问题。4.4 数据侧常见问题速查表现象可能原因排查动作处理方式训练损失正常但路测表现差训练集与实车分布偏移对比两者场景类型分布补采缺失场景或做场景重加权某些类别召回突然大幅下降该类别标注规则变更未同步检查标签版本历史回滚规则或重新标注影响集同一模型两次训练结果差异大数据加载顺序随机性未固定检查种子和数据打乱策略固定种子记录采样清单云端指标好车端推理差前后处理不一致逐层比对中间输出对齐归一化参数、插值方式长尾场景检出率始终上不去该场景绝对样本数太少统计样本数分布定向采集 过采样 合成增强标注成本超预算复核比例设置过粗分档统计各档复核收益按收益重新分配复核预算5. 仿真与评测别让离线指标骗了你5.1 三类仿真各自的能力边界仿真这块我见过的最大的误区是把仿真通过率当成产品成熟度的替代指标。实际上仿真分三类能力边界差别很大混着用就会得出错误结论。回放仿真是把真实录制的数据重新喂给系统验证改动后的输出。它最真实但只能验证感知到规划这一段因为环境不会对你的动作做出反应——你规划的轨迹和现实不一致回放也不会变。所以回放仿真适合做感知回归、规划一致性检查。闭环仿真里虚拟世界会对你的动作做出响应。它能验证完整的决策链路适合测交互场景比如无保护左转、窄路会车、加塞应对。难点在于其他交通参与者的行为模型如果它们的行为太傻你会得到一个过度乐观的结论。场景生成是用参数化或者生成式方法造出真实数据里稀少的场景。它的价值在于可以定向补长尾风险在于生成出来的场景可能不真实——物理上不可行或者违背常识。我的使用顺序是场景生成补覆盖闭环仿真做筛选回放仿真做验收。先用生成场景把候选方案在一大批极端工况里筛一遍通过的再进闭环看交互表现最后用真实回放数据做最终确认。反过来用会很浪费因为回放数据宝贵且有限。5.2 评测指标的陷阱单指标最优往往是系统退化这里我要重点讲一个我踩过的坑。有一段时间我们的目标是提升路口通行效率于是把平均通过时间作为核心指标。优化了两周指标确实降了 15%但路测的接管次数上升了。查下来的原因很朴素规划变得更激进了抢行变多虽然大部分时候能抢过去但一旦遇到不守规矩的对手车就得靠安全员兜底。这件事让我确立了一个原则任何单一指标优化都必须搭配一组约束指标同时监控。常用的组合类别指标用途陷阱安全碰撞率、近碰事件率、最小 TTC 分布硬约束只看均值会被少数极端值掩盖舒适纵向/横向 jerk 分布、加速度峰值体验平均舒适但偶尔剧烈乘客感知很差效率平均车速、通行时间、停车次数目标单方面优化必然牺牲安全拟人与人类驾驶轨迹的偏离、决策一致性可接受度与效率目标常常冲突稳定相邻帧轨迹差异、重规划频率工程质量抖动在仿真里看不出来实车很明显看指标的正确姿势是看分布而不是均值。近碰事件率 0.1% 听起来很小但如果这些事件全部集中在某一个特定场景类型上那这个场景类型就是系统性缺陷不是随机噪声。5.3 一套可落地的评测矩阵设计我给团队设计的评测矩阵是二维的行是场景类型列是能力维度。场景类型按道路结构分直道、弯道、路口、匝道、环岛、施工区、窄路能力维度按工况分跟车、变道、切入、切出、静止障碍、遮挡、恶劣天气。每个格子里放一组参数化的用例覆盖不同的难度档位。这样做的好处是能定位到具体的格子。以前的做法是所有场景混在一起算总分总分掉了 2 个点完全不知道从哪查。现在能直接看到是环岛 × 切入这一格掉了排查范围立刻收敛。难度档位我一般设三档基础档正常参数、边界档参数推到物理极限附近、极端档参数超出正常范围。基础档决定能不能上线边界档决定上线后稳不稳极端档只做参考不作为阻塞项——因为极端档里很多情况现实中不会发生为了它牺牲常规表现不划算。6. 车端部署算力、延迟与功耗的三方拉扯6.1 量化的边界在哪里INT8 量化几乎是车端部署的标配但边界在哪很多人没搞清楚。我的判断标准是看量化误差是否落在下游能容忍的范围内而不是看整体精度掉了几个点。具体做法是分层量化敏感度分析把每一层单独量化看输出差异找出敏感层。经验上第一层卷积和最后一层检测头最敏感中间的主干网络耐受度很高。所以我的策略是主干全 INT8头部的最后几层保留 FP16混合精度。这样做的实测收益是相比全 FP16延迟降 45% 左右相比全 INT8精度几乎无损。还有一个更隐蔽的坑校准集的代表性。校准用的是训练集里的样本但训练集里的光照、天气分布和实车不一样。如果校准集里全是晴天量化参数就会偏向高亮度区间雨天进隧道的时候数值溢出输出直接崩。所以校准集必须按场景分层抽样宁可多花一天时间也别在这上面省。6.2 真正的瓶颈是内存带宽不是算力前面提过这个观点这里给数字。用算术强度每字节内存访问能支撑多少次浮点运算来衡量一个算子到底是计算密集还是带宽密集。一个标准的 3×3 卷积输入输出通道都是 256特征图 56×56FLOPs 2 × 56 × 56 × 256 × 256 × 9 ≈ 3.7 GFLOP 内存访问 ≈ 输入 3.2 MB 输出 3.2 MB 权重 2.36 MB ≈ 8.8 MB 算术强度 ≈ 3.7e9 / 8.8e6 ≈ 420 FLOP/Byte再看一个深度可分离卷积的深度卷积部分同样配置FLOPs 2 × 56 × 56 × 256 × 9 ≈ 14.5 MFLOP 内存访问 ≈ 3.2 MB 3.2 MB 9 KB ≈ 6.4 MB 算术强度 ≈ 14.5e6 / 6.4e6 ≈ 2.3 FLOP/Byte差了将近两百倍。前者的算术强度远高于大多数芯片的拐点性能由算力决定后者远低于拐点性能完全由带宽决定你算力再强也没用因为数据搬不过来。这就解释了为什么很多轻量化模型在车端跑起来并没有想象中快——参数量降了但访存次数没降多少甚至因为频繁的小算子切换变多了。所以模型选型的时候参数量不是好指标访存量才是。我一般会要求部署团队提供每个算子的访存统计而不是只看总 FLOPs。6.3 实测延迟分解表给一个我实际调过的分解表10 Hz 的周期意味着总预算 100 毫秒环节耗时占比优化空间图像预处理缩放、归一化6 ms6%用硬件加速单元可压到 3 ms主干特征提取28 ms28%量化 算子融合已接近极限BEV 变换与融合14 ms14%分辨率降档可省 5 ms检测/占据解码头9 ms9%混合精度可省 2 ms后处理NMS、轨迹关联5 ms5%改为算子内融合可省 2 ms预测8 ms8%缩短历史窗可省 2 ms规划18 ms18%减少采样数可省 4 ms控制4 ms4%空间很小通信与调度开销8 ms8%零拷贝、共享内存合计100 ms100%—注意最后一行的通信与调度开销占了 8%这个数字在纸面设计里往往被忽略实际跑起来经常是 15% 以上。它主要来自模块间的数据拷贝和进程切换。我的处理办法是把感知、预测、规划做成同一个进程里的不同线程共享内存池避免序列化。这一改动在一个项目里直接省出了 10 毫秒比抠模型结构来得快。还有一个现实约束不能把预算用满。100 毫秒的周期规划出来之后还要留出执行余量加上系统抖动和偶发的热点实际可用预算我一般按 75 到 80 毫秒设计。剩下的作为安全余量这样在高温降频或者负载突增的时候系统不会直接超时。7. 我在实际项目里踩过的几个坑第一个是过早追求模型统一。曾经想过用一个大模型同时做检测、占据、预测理由是共享特征、减少冗余。实际做下来发现训练极其不稳定一个任务的损失震荡会污染共享主干最后每个任务都收敛不好。后来还是回到分任务训练、共享一部分浅层特征的老路。教训是架构上的优雅要让位于工程上的可控。第二个是低估了数据加载的工程量。前面 2.4 节也提过但值得再强调一次。一个支持多传感器、多帧时序、动态采样的数据加载器代码量不比模型少而且它出的 bug 最难查——因为不会报错只会让指标悄悄地偏低。第三个是对仿真结果过于信任。有一次一个改动在仿真里提升了 8%兴冲冲上线路测发现新增了一类奇怪的减速行为。查下来是闭环仿真里的对手车模型太礼貌从不强行切入导致我们的规划学会了贴着别人走也没事。这个教训让我在仿真里永远保留一批恶意对手专门用来测边界。最后一个是指标体系的维护成本。指标体系一旦建起来就会不断有人往里加指标加到几十个之后没人看得懂全貌。我现在的做法是分三层三层核心指标安全、效率、舒适每周看中间一层按模块看最细的一层只在定位问题时看。层级清晰比指标多更重要。如果你手上也在做类似的事情我建议先挑一个最小的闭环跑通——哪怕只是在一条固定路线上跑通采集、标注、训练、回放验证这一圈也比在单点上雕花三个月有价值。真正的进步往往来自链路被打通的那一刻而不是某个模型结构的灵光一现。