ADAS十年：从单目感知到多传感器融合的实测与避坑指南

2014年我第一次在供应商的试验场里摸到ADAS实测车感觉这东西离普通消费者还很远。那会儿主流还是单目摄像头方案ACC和AEB能做出来就是大卖点车道保持能用但没人敢真松手。十年后再看整个赛道已经完全变了个样传感器从单目变成了激光雷达加毫米波加视觉的全套阵容芯片算力从几个TOPS飙到几百上千TOPS功能从基础预警一路干到城市领航辅助甚至不少车企已经喊出了L3级量产。这十年我先后经历过算法研发、实车测试、数据工具链和功能安全几个方向算是完整踩过这条演进路上的大部分坑。这篇文章不打算写成科普目录而是想把十年里几个关键节点的变化、背后为什么这么变、以及实操中真正管用的经验一次性讲透。不管你是刚入行的新人还是正在选型的工程师应该都能从中找到对你有用的东西。1. ADAS这十年到底变了什么——先画个整体脉络在拆细节之前很有必要先把这十年的整体脉络理清楚。ADAS的发展不是简单的“功能越来越多”背后其实有四条主线同时推进互相影响。第一条线是传感器格局的剧烈更替。2014年的主流方案是单目前视摄像头加前向毫米波雷达功能集中在FCW、ACC、AEB这类水平。到2016年开始出现基于Mobileye EyeQ3的一体化方案很多国内新势力第一批量产车的感知底座就是它。2018年之后国内供应链起来国产摄像头、国产毫米波开始大量装车。真正改变格局的是2020年前后激光雷达从Velodyne的万元级机械式演变到半固态、固态量产成本不断下探加上800万像素摄像头的普及感知系统的信息维度完全不一样了。到今天旗舰车型基本是“视觉毫米波激光雷达超声波”的全家桶而且开始出现“去激光雷达”和“重激光雷达”两条路线的路线之争。第二条线是电子电气架构的集中化。早期ADAS是典型的分布式ECU每个功能一个盒子比如单独的APA控制器、单独的BSD模块整车线束庞杂软件刷新一次苦不堪言。2018年后开始流行域控制器架构把自动驾驶相关的功能收敛到一到两个智驾域控制器里再往后就是中央计算平台加区域控制器。架构的变化直接决定了软件可迭代的上限这是很多老工程师深有体会的一点功能再多架构不升级就全卡在算力和通信带宽上。第三条线是算法范式的迁移。早期感知算法是传统CV为主靠人工设计特征加分类器后来快速切换到深度学习从两阶段目标检测切到单阶段实时检测再往后加入Transformer、BEV感知、占用网络决策规划从基于规则的有限状态机逐步演变为数据驱动的模仿学习、端到端模型整个开发方法论都在变。第四条线是验证体系的重构。十年前ADAS测试主要靠场地封闭测试加少量公开道路测试测试场景靠人工设计效率极低。现在则是仿真大规模生成的场景库、硬件在环、实车闭环的完整链条还加入了SOTIF预期功能安全的考量体系。测试验证的量级从几百个场景涨到几十万乃至数百万个场景。四条线交织在一起才形成了今天ADAS“既先进又复杂”的局面。后面几章我逐条深入拆解并把实操中的关键细节一并讲清楚。2. 感知系统的演进——从单目摄像头到多传感器融合的“军备竞赛”2.1 单目时代低成本与算法极限的拉锯2014到2016年是单目方案统治的时期。前视摄像头加Mobileye方案几乎是标配能实现车道线检测、车辆检测、交通标志识别等基础功能。前置毫米波雷达主要负责ACC和AEB的中远距离目标测距测速。这套方案最大的优势是成本低、功耗低、量产成熟但不能否认它的物理天花板单目摄像头本质上是从2D图像里反推3D信息物体测距精度天然受标定、路面起伏、光照条件影响明显毫米波雷达稀疏点云密度完全没法跟激光雷达比而且对静止目标、横穿目标存在天然的漏检误检风险。早期很多AEB误报或漏报根本原因就出在传感器本身的物理信息不足算法只是“巧妇难为无米之炊”。实操中这套系统有几个特别让人头疼的点单目摄像头的焦距是固定的为了兼顾远距和近距很多方案采用“远处看窄、近处看宽”的策略但近处的盲区依然在。记得有次实测一个锥桶在车头正前方很近的位置系统完全没感知到差点出事。后来我们对典型近距场景做了专门优化包括加装超声波融合才解决。毫米波雷达对金属角反射器类目标特别敏感路边护栏、金属井盖很容易被当成静止目标融合时要用多帧历史、目标运动模型去滤掉鬼影。光照剧烈变化进出隧道、逆光会导致单目感知性能大幅下降夜间远光灯下的对向车更是经典难题。这些痛点让行业逐渐认识到单靠单一传感器很难支撑更高阶的功能于是多传感器融合开始成为共识。2.2 激光雷达量产感知信息维度的质变2019到2021年是激光雷达上车的分水岭。一方面机械式雷达成本高、可靠性差只能用于测试车队另一方面半导体工艺进步催生了半固态转镜、MEMS微振镜以及后续的固态闪光式方案成本从几万元一只逐步下探到千元级别车规可靠性也有了质的提升。我自己主导过一个激光雷达点云与视觉融合的项目最大的体会是激光雷达真正补齐的其实是“可度量性”点云直接给出精确的3D坐标不用从2D反推对目标大小、距离、速度的估计精度提升巨大。尤其在隧道、夜间、逆光这些视觉困难场景下激光雷达几乎是“保底感知”。但它也引入了全新的工程问题点云量暴涨对计算和存储压力巨大。早期我们用的64线机械式雷达一帧就有几十万个点实时处理得做体素滤波、ROI裁剪不然CPU直接顶不住。回波模式和视觉完全不同。雨雪天、扬尘、水雾会造成点云噪声需要专门的过滤算法。传感器标定变得极度复杂。激光雷达和摄像头之间的外参标定、时间同步、空间同步任何一个环节漂移都会导致融合结果错乱必须有常态化的标定监控机制。综合来看激光雷达不是“增加了多少个点云”这么简单而是让整个感知系统从“猜测物体位置”变成了“测量物体位置”系统设计的Margin完全不一样了。2.3 毫米波雷达的进阶从“点目标”到“成像级”容易被忽视的是毫米波雷达本身的演进。第一代毫米波雷达只能输出少数几个目标点目标之间没有轮廓信息。后来4D毫米波雷达出现增加了俯仰维度的测量能力以及高密度点云输出目标不再是“点”而是一团“可分割的点簇”。这让毫米波雷达在恶劣天气下的感知能力显著增强同时也让雷达和视觉/激光雷达的融合从“目标级融合”升级到了“数据级融合”。我参与过4D毫米波和视觉前融合的试验说实话效果是“惊喜与失望并存”惊喜的是雨雾天气下雷达依然能输出基本点云失望的是雷达点云噪声仍然很大目标边缘非常糊如果把雷达原始数据直接灌给深度学习模型需要额外做很多数据清洗和增强。这个方向到今天仍在演进中很多团队在往“雷达聚合成目标特征”、“雷达与视觉BEV对齐”这些方向上做文章期望进一步逼近甚至超越激光雷达的感知能力。但目前来看在静态环境建模上毫米波依然不如激光雷达精细短期不会出现替代关系而是互补为主。2.4 传感器融合的实操心法数据同步比算法更磨人很多人以为多传感器融合的难点在“融合算法”但真实量产项目中最磨人的其实是传感器的时间同步和空间同步。时间同步层面摄像头帧率一般是30fps帧周期约33毫秒而毫米波雷达更新周期可能只有40毫秒甚至50毫秒激光雷达如果是转镜式扫描一帧的耗时可能是50到100毫秒不同传感器对同一物理场景的观测时刻天然不同。如果直接把不同时刻的数据做融合高速场景下车辆已经移动了数米结果就是目标轨迹抖动、刹车误触发。标准做法是引入统一的时钟基准PTP或GPS授时并在融合层做基于时间戳的插值或“预测到统一时刻”我习惯叫“时间对齐后的感知才是有效感知”。这个环节每天都有工程师踩坑你辛苦调好的融合算法可能就因为时间戳对不齐而效果稀烂。空间同步层面外参标定是重头戏。动态标定的思路是借助路上的车道线、交通标志、大型立柱作为地标在线估计传感器之间的相对位姿并持续监控标定是否漂移。量产工程里必须做“标定监控和失效管理”一旦检测到标定参数超出容忍范围系统要自动降级否则融合结果会错得离谱。2.5 感知数据闭环从“人工标注”到“自动挖掘”感知系统演进到一定阶段后大家发现一个残酷的现实算法的差异化很快会被数据规模抹平。2018年前后主流自动驾驶团队都开始疯狂堆数据——路采车队、标注基地、超算中心完全是军备竞赛的节奏。但单纯堆量没用真正有用的是“难例挖掘”Hard Case Mining。实操中我摸索出来一套比较务实的数据闭环流程实车采集原始数据遵循典型道路和非典型场景覆盖需求而非随机路采。自动触发清洗基于规则或轻量级模型筛选“异常帧”例如模型输出置信度极低、多传感器输出严重不一致、预测轨迹与真值偏差大的片段。人工复核标注难例进入人工标注构建专有的难例集。增量训练每次迭代用基础集加难例集控制过拟合倾向。回灌回归用历史回归集跑一遍确保新模型没有引入回退问题。这套流程中我踩过最深的坑是“难例集过拟合”模型在难例集上看起来效果很好但真实道路上新增了一堆问题后来才发现是难例集比例过高、分布失衡。解决方案是把难例集控制在总训练集的一定比例以内并且每周用新鲜路采数据做盲测。3. 决策与规划的十年——从规则决策到端到端学习3.1 状态机时代的逻辑困境2014到2018年ADAS的决策规划基本都是清晰规则制车道保持启用一个PID控制器或者更高级的MPCACC是跟随前车模型加逻辑跳转变道辅助则是一个简单的状态机判断“旁边车道是否有车-有车就等待-无车就打灯变道”。这套方案的优势是逻辑可解释、便于调试、易于过功能安全审查但缺陷也很明显真实交通场景的交互是高度连续的人类驾驶不是机械地按状态跳转而是根据周围车辆意图不断做概率评估。状态机对同一个场景可能因为一两个离散条件不同行为出现剧烈跳变乘客感受就是“顿挫”“犹豫”“突然”。我记得有次测试一个自动变道功能明明后面有辆快速接近的车辆系统因为状态机里的检测条件没更新到最新目标依然执行了变道差点酿成事故。排查后发现是不同模块的目标列表时间戳没有同步状态机的条件判定基于陈旧数据。从那以后我对规则系统加了一条铁律所有条件判定必须基于同一份带时间戳的融合目标列表。3.2 数据驱动决策从模仿学习到端到端2019年后随着Transformer和BEV感知的成熟数据驱动的决策规划开始崭露头角。最早期的落地形态是“感知用学习、决策用规则”的混血路线也就是感知用深度学习模型输出障碍物和车道线决策规划依然走优化和规则。这种混血路线的好处是工程上相对稳健问题在于规则层仍然承担了大量长尾逻辑遇到corner case还是抓瞎。再往后各家开始探索端到端。所谓端到端简单说就是输入传感器原始数据直接输出规划轨迹中间所有感知、预测、决策都由一个或几个大模型隐式完成。它的核心优势不是“看起来很科幻”而是能把整个系统的信息瓶颈打通规则系统需要人为设计接口来传递信息接口一旦定义就限制了信息上限端到端模型没有这种人为设计瓶颈相关信息都可以直接在模型中流转。劣势则是可解释性差、调试困难、数据需求巨大。我自己实际测试过一些端到端模型感受很直接正常道路上的表现确实更平滑尤其是变道、汇入场景行为更像人类。遇到训练集之外的罕见场景行为很难预测需要很强的安全兜底。调试方式变了不再是通过改参数修逻辑而是找数据标注数据重新训练迭代周期比传统规则更长。所以现实中的主流方案已经走向“端到端模型传统安全层”的分层架构学习模型负责输出拟人轨迹和安全置信度传统规则层负责硬约束与失效兜底两层交织构成量产可用的系统。我认为这个方向在接下来几年仍是主导。3.3 预测模块从“单目标轨迹”到“交互式博弈”决策规划里最容易被忽视但极其关键的是预测模块。早期预测基本是“恒速/恒加速度”模型顶多加个车道级约束。后来演化为基于LSTM、Transformer的多模态轨迹预测可以输出一个目标的多条候选轨迹及概率再后来发展到考虑多智能体交互的联合预测模拟“你让我、我让你”的博弈关系。实操中预测模块有几个常见的大坑预测目标数量受限。真实路况中一个十字路口可能同时有几十个动态目标预测模块的计算量必须严格控制很多量产方案只对“ROI内的前N个目标”做深度预测其余目标走轻量运动学模型。预测概率与决策规划之间的对接非常重要。如果规划模块不把预测的不确定性纳入优化成本只是选概率最高的轨迹遇到两个概率接近的模态就会发生抖动。预测的“长尾交互”是最难的部分。比如行人突然横穿或者车辆逆行这些场景很难用学习模型稳定预测最终还是要靠AEB之类的底层安全功能兜底。4. 计算平台与软件架构的演进——算力、中间件与OTA4.1 从ECU到域控再到中央计算算力军备竞赛的根源我没有见过哪一代硬件像ADAS这样换代如此频繁。早期用TDA2、TDA3这类车载SoC算力只有几十到几百GFLOPS跑个深度学习目标检测已经气喘吁吁。2018年之后大家开始用英伟达的Xavier算力到几十TOPS2020年Orin发布单颗254TOPS一辆车动辄上500TOPS再往后国产的高算力芯片也开始量产装车算力达到数百TOPS甚至上千TOPS。算力的增长之所以这么凶猛一方面是因为BEV感知、Transformer网络、端到端模型确实需要大算力另一方面也是商业上“算力数字”成为营销卖点导致军备竞赛被进一步放大。但从我的角度看堆算力是“办法”而不是“目标”。高算力芯片如果没有配套的内存带宽、数据吞吐和软件栈最终就是空转。我见过一个团队用顶级芯片却因为内存带宽不够推理延迟反而比低算力芯片还高。所以选平台时建议首要关注的是“有效算力”即某典型模型在这块芯片上的实测帧率和延迟而不是纸面TOPS。4.2 中间件与AI推理框架被忽视的“隐形杀手”ADAS的软件栈中中间件和推理框架是最容易翻车的地方。早期大家直接基于Linux/QNX 自研模块通信后来ROS在原型验证阶段很流行但ROS的通信机制、内存管理并不适合车规量产所以各家都转向了自研或半自研的中间件核心要求包括确定性调度、零拷贝通信、故障监控、状态恢复以及对多SoC/SFU架构的支持。AI推理框架同样关键。早期很多团队直接用公版框架跑模型结果发现车载嵌入式平台上算子兼容性差、性能不达标最后不得不手写算子或做算子融合。这里我强烈建议在选型阶段就做模型在目标硬件上的算子级性能摸查判断哪些算子会卡脖子以免算法团队交付出一个“在服务器上飞起、在车机上卡死”的模型。4.3 OTA与软件定义汽车量产之后算法还能持续进化和十年前最大的不同是ADAS功能不再定型于SOP节点。借助OTA算法团队可以持续迭代模型和逻辑车辆下线后还能获得全新功能。这套体系给工程带来的挑战是多方面的版本管理复杂度指数上升一个车型可能有十几个相关ECU的软件版本相互依赖关系的管理困难。影子模式成为核心数据来源需要在量产车上部署“影子”算法在不干预驾驶的前提下对比“现行算法”和“候选算法”的差异为后续迭代提供依据。安全回滚非常重要一旦新版本出现严重问题必须有可靠机制在几分钟内回退到旧版本。OTA本身不难实现难的是“持续迭代的体系建设”数据回传、标注、训练、验证、发布、监控必须全部跑通才能形成真正的飞轮效应。很多团队烧了很多钱做数据采集但数据回流之后没有高效的迭代闭环飞轮没转起来只是增加了存储成本。4.4 功能安全与预期功能安全从“加分项”到“准入门槛”功能安全ISO 26262在过去十年从“加分项”变成了“准入门槛”。尤其是L3及以上系统没有功能安全认证几乎不可能量产。ASIL等级不是越高越好因为ASIL D的开发成本极高大多数ADAS功能会通过安全冗余设计、安全机制分解来降低单个组件所需ASIL等级同时保持系统级安全目标。SOTIFISO 21448则是这几年才被大家重视的核心思想是功能安全主要处理系统故障问题而SOTIF处理的是“系统没有故障但依然不安全”的场景。经典例子是——传感器性能受限导致漏检算法数学上没问题但物理上就是识别不出某些目标。SOTIF要求我们通过已知场景分析、未知场景探索、以及系统性能边界明示把风险降到合理可接受水平。我见过很多团队早期完全忽视SOTIF等到监管和保险端提出要求才慌忙补课结果整个验证体系都要推倒重来。建议做新平台、新功能时从第一天就把SOTIF活动放进开发计划和预算中。5. 测试与验证体系的重构——从“试出来”到“算出来”5.1 仿真测试场景库驱动的“无限试验”传统场地测试效率极低一天能跑几十个场景已经是极限很多极端场景比如对向车越过中线、行人突然窜出实车复现危险且成本高昂。仿真测试的出现彻底改变了游戏规则。主流的做法是用场景库驱动基础场景库法规标准场景比如Euro NCAP的AEB场景、事故统计场景。长尾场景库从真实路采数据中挖掘典型案例包括三轮车横穿、施工区域改道、车辆压线行驶。随机场景生成基于参数化模型做蒙特卡洛采样在参数空间里大量生成组合比如“前车速度、相对距离、路面摩擦系数、天气”全随机。对抗性场景挖掘用遗传算法或强化学习生成“让被测系统表现最差”的场景专门挑软柿子捏。实操中要注意的是仿真和实车之间的“Sim2Real”差距。现在很多仿真器里渲染已经很真实但传感器模型、动力学模型、交通参与者行为模型仍然有偏差。一个在仿真里看似完美的模型上车后可能因为光照、材质、弹性形变等差异完全不工作。所以我的原则是“仿真找问题实车做确认闭环做回归”。5.2 硬件在环与车辆在环从部件到整车的验证链路硬件在环HIL是仿真与实车之间的桥梁。将真实的域控制器接入仿真环境传感器信号用仿真数据注入执行器和车辆动力学完全虚拟。HIL可以验证控制器硬件、底层软件、中间件和部分算法但无法验证传感器本身和整车电磁环境的影响。再往上就是车辆在环VEHIL把真实车辆放在试验台或封闭场地给它注入虚拟目标信息让车辆在物理世界里运动从而验证整个传感器控制器执行器的闭环。我的经验是HIL测试务必注意“时间同步”很多HIL环境里的仿真模型计算时间和真实时间不同步导致控制器看到的传感器数据时序与真实世界不一致测出来的结果毫无意义。做HIL时先做一套“时序基准测试”用已知输入验证HIL环境本身的确定性再开始功能测试。5.3 路测与影子模式无法替代的“最后一公里”仿真再强也无法完全替代真实道路测试因为真实交通的复杂度和偶发性是任何仿真都难以完整建模的。但路测也面临巨大挑战覆盖场景有限、成本高昂、安全风险不可控于是“影子模式”成了量产车队的主要数据来源。在影子模式下系统不干预驾驶只记录算法输出与人类驾驶员行为差异并触发数据回传。这套机制有几个关键点触发策略要合理不能把所有差异数据都回传否则数据量爆炸。我习惯用“多维差异化触发”模型置信度低、预测轨迹偏差大、环境复杂度高、人工接管等条件的或组合。数据回传要区分“即时回传”和“延时回传”紧急场景疑似碰撞、严重超出边界优先回传普通场景可以等到停车场或4G/WiFi下再回传。隐私合规要非常谨慎尤其是涉及行人面部、车牌等信息必须做匿名化处理。5.4 一个实操案例AEB系统的真值测试标定以AEB为例做一个完整的测试验证流程是很典型的场景在法规标准场景库如目标车静止、目标车减速、目标车切入里做仿真和场地测试。对系统的最大制动减速度、介入时机、目标检测距离做参数扫描形成系统性能边界。加入传感器感知性能边界测试比如光照变化、雨雾、隧道口对比度突变。加入高动态场景目标车辆快速切入、行人突然横穿、摩托车穿插。用多传感器融合的“参考真值系统”通常用高精度差分GPS加高精度激光雷达验证被测系统的感知精度。这套流程做完才能对“AEB到底在哪些条件下有效哪些条件下无效”有清晰认知也才能为SOTIF的已知场景清单提供量化依据。6. 实操十年的踩坑实录与避坑经验6.1 传感器标定所有问题的根源如果只能给一条经验我会说标定是ADAS的万恶之源先搞定稳定标定再谈算法。一台车的摄像头、毫米波、激光雷达、IMU任何一个外参漂移轻则目标定位不准重则功能完全失效。量产车上摄像头支架受热膨胀变形、碰撞后轻微位移都会导致外参偏移。实操心得下线前必须做“下线标定”最常见的是利用标定间里的特定图案快速计算摄像头与车辆的相对位姿。车辆使用一段时间后标定可能会漂移因此要设计“在线动态标定”功能利用车道线、静止地标等特征自动估计外参并做监控。标定异常后系统必须进入降级模式。比如检测到摄像头外参异常自动停用依赖该摄像头的功能并提示驾驶员而不是继续带病工作。6.2 时间同步感知融合的大坑前面提过时间同步这里再展开说几个真实踩过的坑。第一有时候你以为已经做了时间同步但不同传感器驱动对时间戳的定义不同有的是“曝光起始时间”有的是“曝光结束时间”有的是“输出完成时间”。混在一起计算目标位置可能错一个帧周期高速下误差非常可观。建议统一所有传感器时间戳定义为“数据采集的有效时刻”并在硬件层面打时间戳。第二系统重启后时钟跳变会导致时间戳乱序。实现上必须有“时钟单调性保护”禁止时间戳回跳。第三多路传感器融合在时间轴上要做“预测补偿”但同时要控制外推距离外推太多在换道场景里会导致目标位置偏移外推太少又引入延迟。这个平衡很难拿捏我的建议是做“变速外推”低速时外推少许高速时外推较多但设定最大边界。6.3 真值系统没有靠谱的真值所有测试都是猜做ADAS测试的人最常被低估的是真值系统的误差。很多人用GPS-RTK加惯性导航作为运动真值用激光雷达点云做目标真值但真值误差本身如果被忽视最终会导致系统评估失真。举个例子评估纵向距离精度的时候如果真值系统本身就有20cm误差被测传感器误差只有10cm那你测出来的“30cm误差”到底是感知还是真值系统贡献的这个问题很容易被忽略。实操建议在使用真值系统前先对真值系统本身做可靠性验证评估其静态漂移、动态延迟、更新频率。做过“真值对齐”测试时所有指标必须统一到同一个时间和坐标系基准上。多传感器融合真值参考时要清楚每种真值传感器的强项与弱项比如激光雷达对近距离目标准对远距离目标点云稀疏误差大GPS-RTK在隧道和城市峡谷会丢失信号需要用航位推算做融合。6.4 模型部署训练一套好用部署一套拉胯算法工程师经常抱怨“训练效果很好部署效果很拉”。最典型的原因是训练和部署之间在预处理、后处理、数值精度上存在差异。普通FP32训练模型转成INT8推理后精度下降或者因为实际推理框架的算子实现与训练框架不完全一致导致输出分布偏移。我习惯的流程是在训练阶段就引入“仿真部署环境”对模型做量化感知训练。部署前做“算子一致性验证”用同一输入分别跑训练框架和推理框架看输出最大误差是否在阈值内。用“真实路采数据”做评测而不是只用开源数据集因为车载图像的光照分布、运动模糊程度与公开数据差异很大。灰度发布先在影子模式下跑新模型和线上模型对比确认无误后再OTA推送。6.5 场景库建设算法水平高不如场景库全ADAS测试和开发的效率很大程度上由场景库的质量决定。我见过一些团队场景库看起来数量巨大但很多场景是低质量重复的真正有价值的难例比例很低。场景库建设不是简单的“收集数据”而是持续维护的系统工程场景标注要引入“语义标签”方便按类别检索例如天气、道路类型、目标类型、风险等级。场景库要有生命周期管理每轮迭代中新增的场景要持续补充过时的场景要归档。参数化场景与真实数据场景应该互为补充参数化场景覆盖大面积可能性真实数据场景覆盖真实世界的精确分布。最重要的是“场景覆盖度分析”用统计方法分析当前场景库与真实世界交通流分布的差异避免过度测试一大类场景而忽略另一大类。7. 写在最后的个人体会这十年的ADAS演进表面看是传感器和芯片的堆料狂欢实际上就是一场“从功能堆叠到系统工程能力”的比拼。早期做得好的团队是算法牛中期做得好的团队是数据多现在和未来做得好的团队拼的是把感知、决策、执行、验证、安全、数据、运维全部拉成一个闭环的“总工能力”。很多团队死在某一朵乌云上要么标定没做好要么数据闭环没跑通要么安全体系滞后要么测试验证跟不上——单点技术再强也救不了体系性的短板。我个人一直有个习惯每次评审项目第一句话不是问“精度多少”而是问“失效了会怎样”。这个习惯帮我避开了无数个潜在的坑。做ADAS追求性能上限当然重要但更重要的永远是失控时的兜底和降级策略是否可靠。只要这个根基坐实性能再差也差不到哪去根基坐虚表面性能越亮眼越危险。十年走过来我的核心工作方法其实浓缩成一句话永远用“闭环”的思维看问题传感器、算法、算力、车辆、路况、用户、法规、OTA全部是同一套系统里的相互约束变量。你想优化任何一个维度本质上都是在和其他维度做权衡。理解了这一点你就不会盲目追新也不会固步自封。这套思路希望也能帮你在ADAS这条路上少走一些弯路。