★ FEATURED ARTICLE 1. 从L4降维到辅助驾驶这个思路为什么值得聊轻舟智航这家公司圈内人都不陌生。早年做L4级自动驾驶起家在限定区域里跑Robotaxi技术底子摆在那儿。但这两年他们做了一个挺关键的转身——把L4积累的能力往辅助驾驶系统上迁移喊出的口号是“好用、能用、爱用”。这三个词听着朴素但做过量产辅助驾驶的人都知道每一个字背后都是坑。我之所以想聊这个话题是因为“L4出身做辅助驾驶”这件事本身就充满张力。L4追求的是“去人化”系统要能独立应对所有场景辅助驾驶追求的是“人机共驾”系统要在人的监督下把高频场景做顺。两者的技术栈有重叠但产品逻辑、工程重心、验证方法几乎完全不同。很多L4团队转过来做辅助驾驶第一版demo往往很惊艳但一到量产就露馅——要么误触发多要么体验割裂要么成本压不住。轻舟智航这套“好用、能用、爱用”的提法其实是在回应这个行业通病。好用说的是功能层面该有的都有覆盖日常通勤的核心场景能用说的是可靠性不能动不动就退出、误刹、画龙爱用说的是体验层面用户愿意主动打开而不是买来就关。这三个层次递进恰好对应了辅助驾驶从“有”到“好用”再到“离不开”的完整路径。这篇文章适合谁看如果你是做辅助驾驶产品定义、系统架构、功能开发或者测试验证的这里面的思路拆解和实操细节会对你有直接参考价值。如果你只是对智能驾驶感兴趣想搞明白L4和辅助驾驶到底差在哪我也会用生活化的类比把技术逻辑讲清楚。接下来我会从整体设计思路、核心技术点、实操落地过程、常见问题排查几个维度把轻舟智航这套打法拆开揉碎讲一遍。2. 整体设计思路L4的能力怎么“降维”到辅助驾驶2.1 为什么L4团队做辅助驾驶有天然优势也有天然陷阱L4出身做辅助驾驶最大的优势在于感知和预测模块的积累。L4系统要在复杂城区里跑必须对行人、非机动车、异形车辆有极强的识别和意图预测能力。这套感知栈直接复用到辅助驾驶上对Cut-in、加塞、鬼探头这些场景的处理起点就比从零开始的团队高一大截。轻舟智航早期在多个城市跑Robotaxi积累的长尾数据也是做辅助驾驶时很宝贵的资产。但陷阱也在这儿。L4的感知追求的是“全场景覆盖”宁可误检不可漏检因为漏检意味着安全事故。但辅助驾驶的量产车对误检极其敏感——前方一个塑料袋被识别成障碍物来一脚急刹用户下次就不敢用了。所以L4的感知模型直接搬到辅助驾驶上往往表现为“过于保守”体验很差。轻舟智航的做法是对感知结果做分层处理高风险目标用高灵敏度低风险目标用高置信度阈值在安全和体验之间找平衡。另一个陷阱是控制策略。L4的规划控制可以为了安全牺牲舒适性急刹、猛打方向都无所谓反正车里可能没人。但辅助驾驶的用户就坐在驾驶位上任何不舒适的加减速都会被放大。轻舟智航在控制层做了大量的“拟人化”调校比如跟车时的加减速曲线要接近老司机的习惯变道时的横向加速度要控制在人体舒适范围内。这些细节在L4时代不是重点但在辅助驾驶上就是核心竞争力。2.2 “好用、能用、爱用”三层目标怎么拆解成工程指标“好用、能用、爱用”听起来像营销话术但轻舟智航内部是把它们拆成了可量化的工程指标的。好用对应的是功能覆盖率和场景通过率比如高速NOA的匝道通过率、城市LCC的路口通过率这些指标要拉到90%以上才算及格。能用对应的是系统可用时长占比和退出率比如连续行驶100公里需要人工接管的次数这个数字要压到个位数。爱用对应的是用户主动开启率和功能使用时长这是最终检验产品是否成功的标准。我特别想强调“能用”这一层。很多辅助驾驶系统功能列表很长但实际用起来频繁退出用户很快就失去耐心。轻舟智航把“能用”定义为系统在典型通勤路线上能够连续工作不中断这要求感知、规划、控制全链路都不能有短板。他们内部有个说法叫“木桶效应”任何一个模块的短板都会导致整个系统不可用所以资源投入要均衡不能只堆感知不管控制。2.3 成本约束下的技术选型为什么不是堆料辅助驾驶是量产生意成本是硬约束。轻舟智航没有走“堆激光雷达、堆高算力芯片”的路线而是选择了一套相对务实的传感器配置。他们的判断是辅助驾驶的场景复杂度远低于L4不需要L4级别的冗余。通过把L4的算法能力压缩到更低的算力平台上用算法效率换硬件成本这是他们能拿到量产订单的关键。具体来说他们在感知上采用了纯视觉加少量毫米波雷达的方案没有依赖高线束激光雷达。这在L4时代是不可想象的但在辅助驾驶场景下通过数据驱动的方式把视觉感知的边界推上去配合毫米波雷达的测距测速已经能满足高速和城区主干道的需求。这种选型逻辑背后是对场景的精准定义辅助驾驶不需要处理L4级别的极端场景把高频场景做到极致就够了。3. 核心技术点解析感知、规划、控制怎么协同3.1 感知模块从“全量输出”到“按需输出”L4的感知模块习惯输出全量目标列表把所有检测到的物体都传给下游。但辅助驾驶的算力有限下游规划控制也不需要那么多信息。轻舟智航的做法是让感知模块做“按需输出”——根据当前场景和自车意图只输出与决策相关的目标。比如高速巡航时重点输出本车道和相邻车道的车辆城区跟车时重点输出前车和可能加塞的车辆。这种按需输出的策略大幅降低了上下游的通信开销和计算负担。另一个关键点是时序融合。辅助驾驶的感知不能只看单帧必须利用时序信息来提升稳定性。轻舟智航在BEV感知的基础上加了时序对齐模块把过去几帧的特征对齐到当前帧这样对遮挡目标、远处小目标的检测更稳定。实测下来时序融合能让远处车辆的检测距离提升20%以上对高速场景特别有用。3.2 规划模块从“最优解”到“最像人”的解L4的规划模块追求的是全局最优但辅助驾驶的规划要追求“最像人”。轻舟智航在规划层引入了模仿学习用大量人类驾驶数据来训练规划模型让系统的驾驶风格接近老司机。比如变道时机的选择、跟车距离的保持、加减速的平滑度这些都没有绝对的最优解但有人类驾驶的统计规律。通过学习这些规律系统的行为更容易被用户理解和接受。具体实现上他们把规划分成两层一层是行为决策决定是跟车、变道还是超车另一层是轨迹生成在决策确定后生成平滑的轨迹。行为决策用规则加学习的方式规则保证安全底线学习优化体验。轨迹生成用优化方法把舒适性、安全性、效率作为目标函数用数值优化求解。这种分层架构的好处是每一层都可以独立迭代行为决策的改进不会影响轨迹生成的稳定性。3.3 控制模块把“不舒适”扼杀在摇篮里控制模块是辅助驾驶体验的最后一公里。很多系统感知规划都不错但控制做不好用户感受就是“一顿一顿的”。轻舟智航在控制层做了几件事一是纵向控制的加速度闭环把加速度变化率限制在人体舒适范围内二是横向控制的预瞄控制提前判断弯道曲率平滑地打方向三是执行器的延迟补偿因为从发出指令到车辆实际响应有延迟控制算法要提前预判。我特别想提一下他们的“影子模式”验证。在量产车上系统会在后台运行但不介入控制把系统的决策和人类驾驶员的实际操作做对比。如果系统决策和人类操作差异很大就说明系统行为可能不符合用户预期。这种影子模式让他们在功能上线前就能发现大量体验问题比传统的路测效率高得多。4. 实操落地从功能定义到量产验证的完整流程4.1 功能定义阶段先想清楚“不做什么”辅助驾驶的功能定义最容易犯的错误是贪多。轻舟智航的做法是先明确“不做什么”。比如第一版量产功能只做高速NOA和城区LCC泊车、城区NOA这些先放一放。为什么因为高速NOA的场景相对封闭变量少容易做到“能用”城区LCC虽然复杂但用户预期低只要跟车不画龙、不频繁退出就能达到“好用”。把有限的资源集中在两个功能上比铺开做五个功能但每个都半吊子要强。功能定义还要明确边界条件。比如高速NOA在暴雨天、大雪天要不要退出轻舟智航的选择是主动降级在天气传感器检测到恶劣天气时提前提示用户接管而不是等到系统撑不住了再退出。这种主动降级的策略虽然看起来“不够强”但用户感受反而更好因为系统没有把用户置于危险境地。4.2 数据闭环量产车就是最好的数据采集车L4时代的数据采集靠测试车队成本高、规模小。辅助驾驶的量产车天然就是数据采集车轻舟智航把数据闭环做成了核心能力。每辆量产车在用户授权后会把脱敏后的感知数据、系统决策数据、驾驶员操作数据回传到云端。云端用这些数据做两件事一是挖掘Corner Case找到系统表现不好的场景二是训练模型用真实数据迭代感知和规划算法。这个数据闭环的关键是“自动化”。如果靠人工筛选数据成本会失控。轻舟智航建了一套自动化的数据挖掘流水线用规则加模型的方式自动识别高价值场景比如急刹、急打方向、系统退出等。这些场景被自动标注后进入训练集模型迭代周期从月级缩短到周级。这套流水线是他们能快速提升“能用”指标的核心武器。4.3 仿真验证把90%的问题在云端解决量产辅助驾驶的验证不能全靠路测成本太高、周期太长。轻舟智航把仿真验证作为主要手段在云端构建了大规模的仿真场景库。这个场景库包含两类场景一类是真实数据回放把路测中遇到的场景在仿真里复现另一类是泛化场景对真实场景做扰动比如改变车辆位置、速度、天气生成大量变体。仿真验证的核心是“置信度”。仿真里的感知是完美的但实车的感知有误差。为了让仿真结果可信他们在仿真里注入了感知噪声模型模拟实车感知的误差分布。这样仿真里通过的场景实车通过的概率也高。实测下来仿真验证能覆盖90%以上的问题剩下的10%靠实车路测兜底。这种“仿真为主、路测为辅”的策略让他们的验证效率比传统方式高了一个数量级。4.4 实车标定与调校最后10%的体验靠这个仿真再强也替代不了实车调校。轻舟智航在实车标定上有一套标准流程先是传感器标定确保摄像头、雷达、IMU之间的外参准确然后是控制参数标定根据车辆的实际响应特性调整控制参数最后是体验调校由经验丰富的测试驾驶员主观评价对加减速、变道、跟车距离等做精细调整。体验调校是最耗时的环节也是最体现功力的地方。比如跟车距离设得太近用户紧张设得太远容易被加塞。轻舟智航的做法是提供多档跟车距离可选同时根据车速动态调整——低速时跟近一点高速时跟远一点。这种细节在功能列表里看不出来但用户一用就能感受到差别。5. 常见问题与排查技巧实录5.1 系统频繁退出怎么办辅助驾驶系统频繁退出是最常见的问题原因通常有三类感知不稳定、规划无解、控制超限。排查时先看退出时的场景如果是特定路段退出大概率是感知问题比如车道线识别不稳定、目标检测漏检。如果是随机退出可能是规划或控制的问题比如优化求解失败、执行器响应超时。轻舟智航的排查方法是先看数据回传把退出前后的感知、规划、控制数据都拉出来对比。他们内部有个“退出归因”工具能自动分析退出原因并归类。实测下来80%的退出是感知问题其中大部分是车道线识别在特殊路面如磨损车道线、光影交替上不稳定。解决方法是针对这些场景补充训练数据或者用地图先验做兜底。5.2 误刹车怎么定位和解决误刹车是辅助驾驶最影响体验的问题之一。误刹车通常来自感知的误检比如把路面的井盖、阴影、纸箱识别成障碍物。定位方法是回放误刹车时的感知数据看是哪个目标触发了刹车。如果是单帧误检可以用时序滤波解决如果是持续误检说明感知模型在这个场景上有缺陷需要补充训练数据。轻舟智航的做法是在感知后加一层“误检抑制”模块用规则加学习的方式过滤掉明显的误检。比如一个目标如果只出现一帧就消失大概率是误检如果一个目标在BEV空间里的运动学不符合物理规律也大概率是误检。这层抑制模块大幅降低了误刹车率同时没有明显增加漏检风险。5.3 变道犹豫、画龙怎么调变道犹豫和画龙是横向控制的问题。变道犹豫通常是决策层的问题系统在变道和不变道之间反复横跳。解决方法是给决策加迟滞一旦决定变道就执行到底除非出现紧急情况。画龙通常是控制层的问题横向控制参数太激进或者太保守都会导致画龙。调校方法是先用仿真扫参数空间找到稳定域再在实车上微调。轻舟智航在横向控制上用了模型预测控制把未来一段时间的轨迹作为优化目标而不是只跟踪当前点。这种方法天然更平滑不容易画龙。但模型预测控制对算力要求高他们在工程上做了不少优化把求解时间压到了实时性要求以内。5.4 常见问题速查表问题现象可能原因排查方法解决思路系统频繁退出感知不稳定/规划无解/控制超限回放退出前后数据用归因工具分类针对高频原因补充数据或加兜底策略误刹车感知误检回放感知数据定位触发目标加误检抑制模块补充训练数据变道犹豫决策迟滞不足检查决策日志看是否有反复横跳加决策迟滞一旦决定就执行画龙横向控制参数不当仿真扫参数实车微调用模型预测控制优化求解时间跟车距离不适跟车策略单一主观评价加数据对比提供多档可选随车速动态调整5.5 独家避坑技巧第一个坑是“过度依赖仿真”。仿真里的感知是完美的但实车感知有误差。如果仿真验证不注入感知噪声仿真通过率会虚高实车一跑就露馅。轻舟智航的做法是在仿真里加感知噪声模型让仿真结果更接近实车。第二个坑是“忽视执行器延迟”。从发出控制指令到车辆实际响应有延迟不同车型的延迟还不一样。如果控制算法不考虑这个延迟就会导致超调或者响应不足。解决方法是在控制里加延迟补偿用预测的方式提前发出指令。第三个坑是“数据闭环不闭环”。很多团队建了数据回传通道但数据回传后没人处理或者处理周期太长。轻舟智航的做法是把数据闭环做成自动化流水线从数据回传到模型迭代全自动迭代周期压缩到周级。这个能力是他们能快速提升“能用”指标的关键。6. 个人体会与后续扩展思路我在实际参与辅助驾驶项目时最大的体会是“做减法比做加法难”。L4出身的技术团队往往想把所有能力都塞进辅助驾驶里但量产车的算力、成本、用户预期都不允许。轻舟智航的“好用、能用、爱用”本质上是一个做减法的框架先保证核心场景好用再保证系统稳定能用最后才追求用户爱用。这个顺序不能乱乱了就会做出功能列表很长但没人愿意用的产品。另一个体会是“数据闭环是长期竞争力”。辅助驾驶的体验提升没有捷径就是靠数据迭代。谁的闭环效率高谁就能更快地把长尾场景处理好。轻舟智航把数据闭环做成自动化流水线这个投入在早期看起来重但长期看是护城河。后续这个系统还可以往几个方向扩展一是城区NOA把高速NOA的能力往城区延伸但城区的场景复杂度高一个量级需要更多的数据和更谨慎的验证二是泊车功能泊车场景相对封闭容易做到“好用”可以作为辅助驾驶的补充三是行泊一体把行车和泊车的感知、规划、控制打通用一个域控制器搞定进一步降成本。这些方向轻舟智航应该都在推进具体进展可以关注他们的量产车型落地情况。
阅读完成 · 觉得有帮助？
