1. 智能驾驶规划控制算法十年演进2015—20252015年那会儿我在一家创业公司做智能驾驶决策模块。当时整个行业都在谈“量产”但真正敢把规划控制算法放到车上的团队屈指可数。十年过去从激光雷达点云里手写规则到端到端模型直接输出方向盘转角这中间的变化不是简单的版本迭代而是一套完整技术范式的迁移。今天这篇总结我想按时间线把规划控制算法走过的关键节点、踩过的坑、以及背后真正推动变革的工程逻辑原原本本摊开来聊一聊。文章适合刚入行的算法工程师、准备转型做规控的传统控制从业者以及想评估技术路线的产品经理。我会尽量少用晦涩公式多讲实际工程里“为什么这么做”和“当初怎么掉进坑里又爬出来”的经验。1.1 十年周期性回顾从规则到学习的范式迁移规划控制算法本质上是解决“车接下来往哪走、怎么走、以及怎么保证走得稳”这三个问题。2015年之前主流方案是分层架构感知层给出障碍物信息规划层负责生成轨迹控制层负责跟踪。当时业内默认的思路是“分而治之”每个模块拆开优化最后用接口串起来。这个思路本身没有错但十年里人们逐渐发现模块之间割裂导致的级联误差远比单个模块的精度问题更致命。2015年到2017年可以看作是“规则主导”的年代。那时候的规划算法大量依赖人为设计的代价函数比如用三次多项式拟合车道线、用篱笆图Frenet Frame生成横纵向解耦轨迹。控制层面则基本是PID和纯跟踪的天下好在当时测试场景相对固定封闭园区里能用就已经是很大的进步。但一套规则很难适应中国复杂路况——加塞、电动车逆行、施工路段随意改道这些场景靠手写权重根本调不过来。转折点出现在2018年前后。随着深度学习在感知领域成熟大家开始尝试把神经网络引入规划控制。一开始只是用学习来做“感知预测”的辅助比如预测行人意图、预测周围车辆的切入概率。这阶段业界最大的共识是预测和规划不能分开做预测的误差会直接摧毁规划的质量。于是出现了第一波“预测-规划联合优化”的尝试典型代表如清华大学MARS Lab等人提出的思路把多模态预测结果直接作为规划的输入约束。这套方案今天看仍然有参考价值它让规控系统第一次学会了“不确定”。2021年之后行业开始大面积拥抱“端到端”。特斯拉FSD V12把感知、预测、规划、控制全部塞进一个神经网络直接输出转向、加速、制动信号。国内不少公司也跟上但纯端到端在量产中仍然面临可解释性差、测试验证困难的问题所以又出现了“分模块端到端”“带规则兜底的神经网络规划器”等折中路线。十年的演进与其说是算法的线性进步不如说是工程范式从“手写一切”到“让模型负责大部分、规则负责底线”的一个渐变过程。1.2 为什么说规控算法演进本质是“不确定性处理”能力的演进我们常说规划控制难难在哪不是公式复杂而是真实世界的不可预测性。2015年我们写的规则里通常假设前方车辆匀速行驶、行人在斑马线前驻足等待。但现实是行人不一定走斑马线前车可能无征兆急刹甚至旁边车道的大货车可能突然压实线并线。所有的规划控制算法本质上都是在跟“不确定性”做对抗。早期做法是把不确定性当作噪声用滤波手段例如卡尔曼滤波来平滑掉但滤掉不代表解决。2017年我们做的一个项目里自车以60公里时速在城市快速路巡航旁边一辆公交车突然打灯变道。感知模块给出的车速预测误差在正负15%之间波动规划模块用恒定车速假设生成了轨迹控制模块实际执行时轨迹与预期横向偏差接近30厘米。那次测试虽然没有发生事故但暴露了瓶颈如果不显式建模不确定性任何下游优化都只是纸上谈兵。后来大家开始用概率图模型、高斯过程、蒙特卡洛树搜索等方法描述未来行为的分布。2020年之后基于学习的预测模型逐渐成了主流——比如基于Transformer的交互预测网络可以同时输出多个候选轨迹并附带置信度。规划器不再追求单条“最优”轨迹而是维护一个轨迹集合根据下游成本函数实时选择。这个思路改变了整套系统设计逻辑真正把“可能发生什么”纳入了决策依据。控制层面同样经历了一场“不确定性”革命。传统的MPC虽然可以处理约束但对模型失配非常敏感。2018年我们测试一种自适应MPC方案通过在线辨识轮胎刚度来提升极限工况的稳定性实测在低附着路面上横摆角速度误差降低了约40%但代价是调试周期长达三个月。相比之下后来引入的鲁棒MPC和扰动观测器思路在工程效率和系统鲁棒性之间取得了更好的平衡。所以回看这十年很多人以为变化最大的是模型结构和算力消耗。我觉得真正的内核是车辆对周围世界“不确定性”的建模精度和处理方式从确定性的规则假设走向了概率化的交互推理。这一点理解透了再去看技术路线之争就不会被表象迷惑。2. 规划算法演变路径Frenet框架、采样与优化派的十年拉锯规划控制算法里规划层的变化幅度最直观。2015年主流方案可以概括为“业务逻辑堆叠式”高精地图给出车道拓扑决策模块输出行为级指令——直行、变道、停车局部规划器再生成轨迹。到了2025年规划器的输入已经变成高维特征向量输出则是直接可执行的控制指令。中间经历的过程可以拆成三段路线来理解。2.1 Frenet坐标系下的轨迹生成为什么它统治了五年先补一个基础概念Frenet坐标系。简单说它以道路中心线为参考轴把车辆运动解耦为纵向沿道路方向的位移和横向垂直于道路方向的偏移。这个坐标系的好处非常直观——道路的曲率变化不会直接干扰横纵向解的求解让规划问题简化为两个独立的低维优化问题。2015到2019年几乎每一家L4级公司都在Frenet框架下做文章。我们当时生成一条变道轨迹的流程是这样的先决定变道耗时通常取3到5秒然后用五次多项式拟合横向偏移曲线要求起点和终点的横向位移、速度和加速度都给定最后再用纵向规划器解决速度分配问题。为了确保舒适性我们会约束最大横向加速度不超过2.0 m/s^2最大纵向减速度不超过3.5 m/s^2。这些数字不是拍脑袋而是来自大量实车乘坐体验测试的统计结果。但Frenet框架处理动态障碍物的能力比较弱。如果障碍车本身也在变道横向解耦后的约束就很难精确表达“两车是否会发生碰撞”。所以2018年后大家发展出了“横向轨迹包络面”和“纵向可通行区域”联合求解的方法。简单说不单独生成一条候选横向轨迹而是生成一个横向轨迹簇然后对每条轨迹做纵向可行性检查保留同时满足安全性和舒适性的解。这个思路在工程上工作量不小通常需要预计算几百条横向轨迹但有效缓解了解耦带来的保守性问题。不过Frenet框架最深的坑不是算法本身而是地图质量。高精地图的边界误差超过20厘米生成的参考线就会抖动进而导致轨迹跳变。2019年有一次测试由于地图中某个车道曲率刷新延迟车辆在弯道里出现了明显的“锯齿形”转向。后来我们专门写了一套曲率平滑后处理强制约束参考线的三阶导数才算压下了这个毛病。2.2 采样规划器与优化规划器的取舍从A*到MPC的工程实战与Frenet这种结构化思路并行的还有采样派和优化派。采样派的典型代表是A*、RRT及其变种它们更适合非结构化场景比如泊车、园区、矿卡等。优化派的典型代表是MPC适合结构化道路上的精确跟踪和轨迹优化。两者并不是非此即彼的关系实际量产里往往是嵌套使用的。先聊采样。2016年我写过一套基于RRT的园区泊车规划器状态空间是车辆的位姿控制空间是前轮转角和时间步。原始RRT的问题很典型轨迹不够平滑、采样效率低、甚至在窄通道里容易卡死。我们后来加了三个改进双向RRT、B样条轨迹平滑、以及基于车辆运动学的扩展步长控制。改进后典型泊车场景的求解时间从2秒左右降到0.4秒但依然不够稳定偶尔还会在复杂障碍物组合下求解失败。慢慢我们发现采样方法真正的优势在于可解释性和失败模式清晰这非常适合低速场景。一旦上了高速场景的搜索空间急剧膨胀纯采样的实时性就跟不上了。所以2018年之后业界几乎形成共识结构化道路场景用优化方法为主非结构化、低速场景用采样方法为主中间地带用“候选轨迹生成成本排序”的方式来兜底。再说优化派里的MPC。MPC的核心思想是在每个控制周期内基于当前状态求解一个有限时域优化问题只执行第一步控制量下个周期重新求解。优点是可以显式处理约束比如转向极限、加速度极限、安全距离非常适合“性能与安全兼顾”的需求。我实际用过线性时变MPC在时速100公里的高速场景下以20毫秒的周期稳定求解代价是线性化模型在强侧风或急弯中误差偏大。为了弥补我们在成本函数里加入了前馈项用静态前馈补偿曲率带来的稳态误差效果比单纯提高反馈增益来得好。这里给一个参数选择的参考MPC的预测时域通常取1.5到2.5秒过短容易造成控制振荡过长则计算负担上升而且远端模型失真严重。控制周期在高速场景取100到50毫秒之间比较稳妥在泊车这类低速场景可以放宽到200毫秒。权重矩阵Q和R的调整没有万能公式但我们常用“先调纵向、再调横向、最后做耦合测试”的顺序能在调参时省下不少时间。2.3 规则决策与学习决策的边界迁移行为决策层的进化规控系统里还有一个容易忽视但极其关键的模块——行为决策。它负责回答“我是该跟车、变道、还是靠边停车”这类问题。2015年的主流是有限状态机根据车道、信号灯、前车距离等人工设定条件切换状态。优点是逻辑透明调试方便缺点是长尾场景爆炸规则之间会出现冲突和漏洞。我统计过我们2017年版本的状态机代码里面定义了将近700条转移条件仍然没能覆盖高速上“前车突然减速且左后方有车高速逼近”的组合场景。那一版最终是靠增加一条“优先保证纵向安全距离、暂缓变道”的规则险险处理过去但逻辑链已经非常脆弱。行业同样面临这个问题因此很多团队开始实验用决策树、蒙特卡洛树搜索来替代状态机。2020年前后学习式决策开始走向前台。比较有代表性的思路是用深度强化学习训练一个“驾驶策略网络”输入是周围车辆的状态编码输出是离散动作或连续动作的概率分布。这个方向做了很多研究但量产落地很少原因有三点一是安全保证困难强化学习只管最大化reward不保证状态不越界二是仿真与真实差异大策略迁移后性能迅速下降三是调试成本高出了问题很难归因。我个人见过不少团队尝试用“强化学习规则安全层”的混合方案但在实际道路测试中依然困难重重真正跑通大规模路测的更不多。从最终落地结果来看业界更认可的是“轻决策、重规划”的路线。也就是说行为决策只负责给出一个高层的约束集合比如目标车道、允许的最大速度、可接受的最小跟车距离具体怎么走交给规划器去解。这样既保留了规则的可靠性又给了规划优化足够的自由度。这条路从2019年流行起来到2025年仍是量产规控系统的主流底座。3. 控制算法演进主线从PID到MPC再到学习控制的工程实践规划层负责生成参考轨迹控制层负责跟踪并抵抗扰动。控制算法在过去十年间的变化同样剧烈但不同于规划层那种“范式切换”控制层的演进更像是“在经典框架上逐步加buff”每一步都针对性解决一类实际问题。3.1 为什么PID和纯跟踪仍然没有退出历史舞台2015年时很多量产车型的横向控制还在用纯跟踪纵向控制用PID。纯跟踪的本质是选取前视距离处参考轨迹上的一个点计算车辆当前位置到该点的圆弧切线用这个切线转角控制前轮。它结构无比简单参数只有一个前视距离所以调试友好、响应快速非常适合低速、小曲率工况。但纯跟踪的缺点也非常明显弯道中前视距离过大会导致切弯、过小则引起方向抖动高速场景时稳定性不足容易造成横向误差发散。2016年我们在高速场景做过对比纯跟踪在100公里时速下遇到持续弯道时横向误差峰值能达到0.9米几乎不可用。所以后来量产方案普遍换成了LQR或MPC做横向控制纯跟踪则被保留在泊车、低速园区等场景作为兜底使用。PID在纵向控制里生命力更顽强。自适应巡航的四段式控制定速巡航、跟车行驶、减速停车、起步跟车里下层速度环至今仍大量使用PID。我们的经验是把PID参数按照“目标加速度-实际加速度-油门/制动转换”分层标定能比单一PID在大范围工况下都保持良好表现。当然纯PID的滞后问题也没法完全消除遇到前车急刹时必须配合前馈项和预测模块才能把减速度的响应时间压进400毫秒以内。这里想强调一个容易被忽视的点控制算法的好坏其实很大程度取决于控制器的执行精度。你算出来的方向盘转角如果执行机构响应有延迟再好的控制律也会变成震荡源。我们当时在标定转向执行器时专门测了阶跃响应和死区把滞后补偿加进了前馈环节效果相当明显。3.2 MPC控制器的工程落地约束建模、求解器选择与周期调优MPC在控制层的应用是过去十年最值得聊的工程话题之一。比起“MPC效果更好”这个简单结论我更想谈谈它落地时那些容易被忽略的细节。首先是约束建模。很多新手以为约束越多越好其实约束过强会让求解器频繁无解。正确做法是把约束分为硬约束和软约束两类硬约束是安全底线比如前轮转角极限、制动减速度上限一般不能突破软约束是舒适性指标比如横向加速度、加加速度允许在特殊工况下以一定代价突破。这样设计即使求解器找不到严格满足全部约束的解系统也能在“最接近安全”的状态下运行而不是直接宕机。工程里我们会在MPC成本函数末位增加松弛变量项并用很高的权重惩罚它效果比“一刀切”好很多。其次是求解器选择。在CPU资源紧张的域控制器上OSQP、qpOASES这类基于活跃集方法的求解器能较好地处理小规模凸优化问题。我们当时用qpOASES求解一个36维状态、12维输入、200个约束的横向MPC典型求解时间在3到5毫秒内完全满足50毫秒控制周期的要求。需要注意的坑是不同求解器的数值稳定性差异很大特别是在约束退化和病态条件下容易产生抖动解。所以上线前一定要做“约束饱和压力测试”把各类约束同时激活观察求解器是否稳定输出。最后是周期调优。MPC的周期不能简单“越快越好”因为周期太短会导致模型预测距离过短视野变浅周期太长又可能错过执行误差修正的最佳时机。我们在高速场景用20毫秒周期、预测时域2秒低速泊车场景则用100毫秒周期、预测时域4秒左右。周期还受限于执行器的通信延时如果底层转向系统是CAN总线报文周期通常是10毫秒MPC周期低于20毫秒就可能引入控制环路抖动这需要在实际集成时仔细标定。3.3 学习控制在量产的试探从黑盒到灰盒的妥协提到学习控制很多人的第一反应是“神经网络直接输出方向盘转角”。这个方向确实在学术界很热但量产落地时行业更倾向于“灰盒”方案利用学习模型修正已知物理模型的残差或者在线辨识模型参数而非彻底取代模型。我参与过的一个项目里用了一个轻量级神经网络来预测“轮胎侧偏刚度与路面附着系数的在线变化”并把修正后的参数传给MPC。实测在雨水路面、砂石路面上横向误差比固定参数MPC降低了25%左右。但代价是需要大量真实路面数据做训练而且极端工况比如冰雪路面的数据仍然不够导致模型外推时信心不足。所以业界最后的共识很务实学习控制不追求全栈接管而是做“模型增强器”。核心物理模型仍然保留学习模块负责补偿不确定性部分。这样做的好处是即使学习模块失效系统还能退回纯物理模型运行。我们内部称之为“安全降级设计”这也是规控系统量产必须要做的一道保险。当然学习控制还有一个隐藏问题——在线推理的可解释性。一旦车在测试中行为异常工程师需要快速判断是网络预测错了还是底层控制器执行错了。如果网络结构复杂这一定位过程会非常痛苦。因此我建议任何打算上学习控制的团队都提前规划好日志系统至少要把网络输入的中间特征、输出的置信度全部记录下来不然出了事故只能抓瞎。4. 仿真系统与规模化路测规控算法迭代的两条腿没有高质量的仿真环境这套算法迭代基本上只能靠天吃饭。2015年前后很多团队用开源的CARLA和Autoware搭建仿真但仿真和真实道路之间的“鸿沟”实在太大了。十年里仿真系统从简单场景编辑器发展到大规模并行仿真、数据回灌、以及“仿真-真实闭环”体系变化是根本性的。4.1 场景库建设与虚拟仿真如何逼出算法短板场景库是规控算法迭代的第一资产。2017年我们开始搭建针对中国路况的场景库时最先做的是收集真实路测的“危险片段”——急刹、强切、逆行、鬼探头然后按场景类型标签化。这些片段不仅用于算法回归测试还用于生成仿真环境中的动态障碍物行为模型。我印象最深的一个场景是“高速出口强切”目标车辆在距离出口匝道不到30米的位置从最内侧车道连续变道到最外侧并且没有开启转向灯。当年的规控算法在这种场景下几乎必让速但让速之后又面临被后车追尾的风险。为了在仿真中逼出算法短板我们把这类场景做成参数化模板随机扰动切入速度、切入角度、起始距离等参数批量跑上千次。迭代几轮后算法终于学会了一个更合理的策略先轻微制动创造空间同时判断与后车的距离如果安全则维持速度不盲目让速。这类经验让我对仿真有了一个核心认知仿真不是为了“证明算法好用”而是为了“逼出算法的边界”。所以场景库的建设比仿真器本身的渲染质量更重要。很多时候一个真实场景切片的价值超过一千个随机生成的虚拟场景。这也是为什么头部公司都在做“数据回灌系统”——把路测采集的真实传感器数据灌进仿真环境用真实轨迹作为障碍物行为测试规控算法的泛化能力。4.2 数据闭环与回灌测试规控算法迭代的真实燃料数据闭环这个词2018年之后在规控领域几乎无人不谈。但真正做扎实并不容易。回灌测试的第一步是数据筛选不是所有路测数据都值得回灌要优先挑选“边缘案例”比如有激烈交互、感知降级、定位跳变等情况的片段。第二步是场景重构把原始传感器数据还原成规控算法需要的坐标信息这一步最耗时也最容易出错。典型的坑是时间戳不同步摄像头帧率和激光雷达帧率不一致导致回灌出来的障碍物位置有跳变这会直接影响规控算法的评估结论。我们在回灌测试中吃过一次大亏一个减速带场景里感知模块连续三帧漏检了路肩回灌测试中规控算法顺利通过了但实车测试时却发生了骑跨路肩。后来排查发现问题不在于规控算法而在于回灌的传感器数据质量太差根本没法反映真实感知结果。从此之后我们定了一条规矩回灌测试前必须先跑一遍感知数据质量校验任何一帧缺检、漏检、跳变的直接剔除。严格是严格了点但换来的评估可信度完全不同。4.3 大规模路测的组织经验如何让算法在真实道路上“安全长跑”仿真做得再好路测还是必不可少的。但路测不是“随便找条路跑一跑就行”它需要严谨的里程管理、场景覆盖管理和安全员培训。2019年我们做高速路测时设计了一套分阶段测试方法先白天、后夜间先晴天、后雨天先空旷路段、后复杂路段。每个阶段都有明确的退出标准——如果连续三次出现安全员接管就停下来修算法而不是继续硬跑。路测的数据记录同样重要尤其是“接管片段”的分析。每一次安全员接管都要同步记录接管前的10秒-20秒传感器数据、规划轨迹、控制指令并给接管原因打标签。我们统计下来接管原因里占比最高的是感知漏检其次是规划行为“太过保守”导致的无法合流。真正的“纯控制失败”占比反而很低这说明规控问题的瓶颈往往来自于上下游模块的耦合问题。我建议团队在做路测规划时把“测试里程”和“有效场景数”拆开统计。单纯堆里程没有意义一万公里高速巡航不如一百次“迫近切入”场景有价值。有效场景数越多算法边界的摸底越准确。当然安全底线必须拉满这不仅是合规要求也是算法迭代可持续的前提。5. 典型量产项目复盘从自动泊车到高速领航的关键挑战规划控制算法在不同量产项目中面临的“主要矛盾”完全不同。我挑两个最有代表性的场景展开低速自动泊车和高速领航辅助它们几乎覆盖了“极端精度”和“极端动态”这两类难题。5.1 低速泊车场景精度与平滑性的双重折磨自动泊车是规控算法最亲密的量产战场。它的特点是速度低、空间窄、对控制精度要求极高。泊车场景的标准动作是“揉库”多次前进后退调整姿态。规划器每一步都要生成一条既能避障、又能让车辆最终进入目标车位的轨迹说白了就是一连串低速运动规划问题的串联求解。2018年我们做APA自动泊车辅助项目时最大的挑战来自两个指标泊车成功率和泊车时间。如果成功率超过95%但平均泊车时间要3分钟用户在车里会急疯。为了缩减时间我们把规划器从“单步生成轨迹”改成了“预先生成多点位引导线局部微调”先用低速采样规划器算出一条粗轨迹再用优化器在轨迹附近做局部平滑。这个方法让平均泊车时间从2分40秒压到了1分20秒成功率还小幅上升。这里有一个容易翻车的细节车辆在极限揉库时后轮轨迹与前轮轨迹完全不重合如果规划器只考虑车前点很容易发生“车头过了但车尾蹭墙”的情况。所以必须对整车轮廓做包络碰撞检测而不仅是质心点。我们在量产中用的是“四个外角点两侧后视镜”膨胀成五边形包络再与障碍物做多边形相交检测。这个细节虽然看起来简单但在狭窄车位中能明显降低碰撞风险。另外泊车过程中的控制周期比高速场景更短200毫秒的控制周期已经足够但规划器必须支持“在线重规划”因为每一次揉库后车辆实际位姿都会和规划预期有偏差如果不重新规划误差会不断累积最终导致泊车失败。早期我们在泊车项目里吃过这个亏假设车辆执行完美结果实测每次都越偏越多。后来加了低频重规划触发每当位姿误差超过阈值就重新规划剩余路径稳定性好了很多。5.2 高速领航场景动态交互与舒适性的平衡术高速领航辅助NOA是过去五年增长最快的量产功能之一。它的工况特点是速度高、动态交互频繁、对实时性和舒适性要求都很高。规划控制算法在这里面对的最大难题是如何在保证安全的前提下尽量不干扰交通流让驾乘者觉得“像老司机在开车”。先聊动态交互。高速上最典型的交互场景是“汇入匝道”自车需要从加速车道汇入主路车流。传统做法是“先加速到目标车速再寻找间隙变道”但这个策略在车流密集时往往会等不到间隙。更聪明的做法是“协同式汇入”不仅考虑自车速度还预测目标车道后车的速度寻找一个“可接受间隙”同时通过轻微的横向调整向间隙靠近。这里规划器的核心逻辑变成了“在时间和空间两个维度上同时寻找可行窗口”。从工程实现上看高速场景的规划器可选的时域和空间约束更复杂。自车既要保持与前后车的时距通常设定1.5秒到2.2秒还要考虑目标车道前车的急刹概率。我们在量产代码里保留了一个“风险系数”动态加权预测模块输出的碰撞概率。当碰撞概率超过阈值规划器会触发保守策略主动降低速度让行。这个风险系数的标定很大程度上决定了车辆风格是“激进派”还是“保守派”需要产品团队和算法团队一起反复调。舒适性方面高速场景最忌讳的是频繁的加减速和转向抖动。我们的经验是横向控制的目标不是最小化“横向误差”而是最小化“驾乘者感知的侧向加速度变化率”。为此MPC的成本函数里除了横向误差项还额外加了横向加速度变化率的惩罚项并且将转向指令做了低通滤波。实测下来高速变道时乘员的侧倾感明显收敛主观体验分数从6.8提升到8.2满分10分。控制算法不是越精准越好而是要“精准且舒适”这个观念在高速场景尤其重要。还有一个容易被低估的细节高速场景中规划轨迹的“时间一致性问题”。如果每个控制周期生成的轨迹之间出现跳变轻则车辆“画龙”重则引发驾驶员接管。我们专门设计了一套轨迹平滑机制把上个周期的最优轨迹作为本周期优化的初始解并且限制轨迹参数的变化率。这套机制看似简单却是消除“规划抖动”最有效的手段之一强烈建议遇到类似问题的团队参考。6. 规控算法与其他模块的耦合感知、预测与地图的边界模糊十年之后的今天再讨论规控算法时已经很难把它从感知、预测和地图的耦合中剥离开来。我们越来越发现真正决定系统上限的往往不是某个单独算法的优劣而是模块间接口的合理性和容错性。6.1 预测模块如何重塑规划策略2015年的预测模块基本就是一个“匀速外推器”假设障碍物保持当前速度不变最多加一个加速度限制。这种预测在低速场景能用但在高速交互场景非常危险。因为车辆驾驶行为高度依赖于驾驶员的意图匀速假设完全无法捕捉“准备变道前的微微减速”“切入前的转向灯闪烁”这类暗示。后来预测模块逐渐向“交互预测”演化。2020年前后基于图神经网络的交互预测器开始流行它可以同时建模多辆车之间的关系输出一组未来轨迹及其概率。规划器接收到这组轨迹后不再只回应单一“最可能轨迹”而是对所有可能轨迹做风险加权评估。这样即使一辆车突然切入只要它切入前的行为特征已经激活了预测器中的“变道模式”规划器就会提前调整速度留出安全余量而不是等它真正压到车道线才开始反应。这里有一个工程细节必须注意预测模块不能输出过多轨迹。每个障碍物输出10条轨迹如果有10个障碍物规划器就要处理100条候选轨迹的碰撞检测耗时骤增。所以量产中我们通常只保留每个障碍物的前3到5条轨迹并根据概率阈值做剪枝。更重要的是预测结果必须附带置信度下限如果某障碍物的预测置信度很低那么规划器应该采用“保守假设”而不是“期望假设”。我觉得预测与规划的关系就像下棋时“预判对手的走法”和“决定自己的下一步”。只关注当前局面而不预判永远只能被动应对但预判过度、假设太多又会导致决策保守、寸步难行。好的系统需要在“应激反应”和“主动规划”之间找到平衡点这也是我这么多年做规控最深的体会之一。6.2 高精地图在规控里的角色演变从强依赖到轻依赖2015年行业内对高精地图的依赖度极高。车道的中心线、边界线、曲率、坡度、限速信息几乎是规划算法的全部输入。但高精地图有一个致命问题更新慢。中国城市道路的施工、标线改划频率非常高地图数据一旦过期规控算法立刻“瞎”。2018年我们遇到过一起事故预兆某条城市道路的车道线因为施工被临时改划但高精地图里还是旧线型。规控算法按旧线型规划实车直接骑到施工路障前安全员紧急接管才避免碰撞。从那以后我开始坚定地推动“在线感知与地图融合”的路线用实时感知的车道线、路沿、交通标志与高精地图做在线匹配出现冲突时优先信任感知结果并在规划器里动态调整参考线。这个方案前期投入很大但长期看几乎是必须的。到了2023年之后随着“重感知、轻地图”的路线在业界流行规控算法对高精地图的依赖进一步削弱。很多城市导航辅助驾驶功能甚至只依赖导航地图和实时感知完全不需要高精地图。这种模式下规控算法必须更鲁棒因为它失去了“提前知道车道级拓扑信息”的便利只能靠实时感知推断前方路况。这也直接推动了一大批“在线局部地图生成”算法的兴起比如基于Transformer的在线拓扑推理。我认为未来的趋势不是抛弃地图而是让地图从“强依赖”变成“轻依赖”地图提供宏观引导感知提供实时细节两者融合后作为规划器的输入。核心是提高系统在“地图错误”情况下的容错能力而不是把地图当作绝对坐标基准。6.3 端到端模型对传统规控架构的影响融合还是替代端到端模型的出现让不少规划控制从业者感到紧张。特斯拉FSD V12的示范效应让很多人开始讨论“传统规控是不是要被扫进历史垃圾堆”。我的看法是端到端是一个值得全力以赴探索的方向但它不是对传统规控的简单替代而是一种更高维度的“融合”。端到端模型的优势很明确它能直接从传感器原始数据中学习驾驶行为避免了模块间大量人工接口设计并且可以借助大规模数据训练覆盖更广的长尾场景再加上模型内部的特征共享能让“感知-决策-控制”在语义空间上得到统一优化减少信息在不同表示之间转换时的损失。但它的问题也很突出第一安全性不可证明。传统规控可以通过硬约束和形式化方法保证安全边界但神经网络的决策过程很难给出同样的安全保证。第二测试验证困难。规控算法量产需要大量场景测试而神经网络在高维输入空间里的遍历几乎是不可行的。第三可解释性不足。一旦出现事故工程师很难定位是网络哪一层、哪个特征出了问题。第四还面临“灾难性遗忘”的问题模型在训练新场景时可能会遗忘掉之前学好的能力。我看到更多企业采取的是“混合架构”感知预测模型化决策规划仍用规则优化或者端到端模型负责生成参考轨迹传统控制层负责跟踪。这种“用学习提升上限、用规则保障下限”的思路短期看最稳妥长期看也有可能演变成“传统规控框架学习增强模块”的终极形态。所以我觉得搞规控的工程师不必焦虑“被替代”。真正需要焦虑的是你有没有理解清楚不确定性的本质你有没有掌握好控制系统的鲁棒设计你有没有能力把“模型的学习能力”转化为“系统的安全保证”这些底层能力在任何架构变迁中都是稀缺的。7. 规控算法的测试评价体系脱离道路安全谈指标没有意义最后一部分想聊聊测试评价体系这部分在公开资料里内容最少但在工程实践中极其重要。很多团队算法做得不错但到量产阶段卡在评价指标不清晰上。规控系统要回答的核心问题只有一个在各种真实交通场景下它到底能不能安全、舒适、有效率地完成驾驶任务7.1 核心指标体系从安全到舒适的量化拆解规控算法的测试指标不是单一的而是一套分层体系。最底层是安全指标包括碰撞时间TTC、最小安全距离、横向/纵向加速度极限、接管率等。中间层是合规指标是否超速、是否压实线、是否闯黄灯等。最高层是体验指标平均车速、加速度变化率、变道频率、乘坐舒适感评分等。安全指标不达上限直接否决合规指标必须严格保证体验指标则是不同团队差异化竞争的重点。具体到每个指标还得考虑统计口径。比如接管率不能只看“每千公里接管次数”因为接管触发条件可能与场景难度分布强相关。更合理的口径是“按场景难度分层的接管率”简单路况每千公里0次接管复杂城市道路每百公里少于1次接管极端场景允许接管但必须提前预警。只有分层统计才能真正暴露算法的薄弱环节。在实车测试中我们还会记录“潜在接管事件”——虽然没有触发安全员接管但系统自身已经进入极限状态比如最小距离已逼近阈值。这类事件的比例比实际接管次数更能反映算法的安全余量我一直建议团队把这一指标纳入常规周报。7.2 仿真-实车-道路测试的三角验证体系成熟团队普遍采用的验证体系是“仿真-实车-道路”三层递进。仿真层跑大量场景和参数化扰动覆盖概率大实车层在封闭场地验证传感器和执行器衔接覆盖真实性道路测试层在开放道路验证综合能力覆盖长尾场景。这三层不是串行关系而是并行交叉、互为反馈的。仿真层的价值在于快速迭代。每晚批量跑几万个场景第二天早上看回归结果这是传统路测给不了的效率。但仿真也有明显的天花板传感器仿真不够真实、渲染和物理引擎误差、动态障碍物行为简单粗暴。所以有必要把“仿真通过”和“可以在实车测试”之间设置明确门槛避免仿真得分高但实车翻车的情况。实车层最大的价值是验证“接口问题”。传感器时间戳同步、规划控制指令延迟、转向执行器响应特性这些杂七杂八的细节往往只有在真实硬件上才能暴露。我们有一次在实车上发现规划器明明输出了平滑轨迹但车辆实际运行时方向盘却出现了高频抖动排查了两周才发现是底层转向控制器的电流环参数和新执行器不匹配。这类问题仿真完全发现不了。道路测试是最终验收也是最耗时、成本最高的环节。要避免“为了凑里程而跑路”每次路测都要有明确的测试假设和希望通过路测回答的问题。比如“这是要验证泊车算法在窄车位上的成功率”就专门找一排窄车位反复测试而不是开着车在城市里漫无目的地逛。7.3 安全员培训与接管协议被忽视的关键环节路测安全员是规控系统可靠性的最后一道防线。安全员的培训不能只是“会踩刹车”而是要深入理解系统的失效模式和接管策略。我们培训安全员时会把算法在常见危险场景下的预期行为讲清楚比如前方车辆切入时系统预期会先轻微制动还是保持速度。当实际行为与预期明显不符时安全员必须立刻接管而不是犹豫观察。接管协议本身也要设计。不是所有情况都适合“一脚刹车接管”有些场景更适合“先握方向盘再踩刹车”的分步接管。安全员需要知道在什么情况下使用哪种接管方式。更重要的是每次接管后的记录要非常详细接管时间点、原因标签、系统当时的状态感知、规控、执行各模块的输出这些信息都是算法迭代的宝贵素材。我见过很多团队把安全员培训当成走过场结果不仅是测试效率低下还可能出现安全员误判接管时机导致严重事故。所以在这里郑重建议路测团队至少安排20-30小时的专项培训并且每季度做一次接管复训用真实接管片段做教学复盘。这件事的投入产出比比在算法上多调几天参要高得多。8. 行业趋势观察与规控工程师的能力边界重塑写到这里十年演进的脉络基本清晰了。最后一部分我想从行业视角聊聊趋势以及给当前还在做规控的工程师一些职业建议。8.1 从代码量到数据量规控系统生产方式的改变2015年时规控团队的核心竞争力是“代码能力”谁的状态机写得更完备谁的MPC调参经验更丰富谁就能做出更稳定的系统。但到2025年核心竞争力变成了“数据能力和工程体系”谁拥有更多高质量的场景数据谁能更快地完成数据采集、清洗、标注、回灌的全流程谁就拥有更大的算法迭代空间。这种转变带来的直接影响是规控工程师的工作内容发生了很大变化。早年间我们花大量时间手调阈值、调代价权重现在很多团队开始用自动超参搜索、离线仿真批量评估来替代手动调参。我对这种变化的态度是积极的但也要提醒一句自动调参替代不了对系统机理的理解。遇到一个极端场景如果不懂底层逻辑连调试方向都找不到再多的算力和数据也只能是“黑盒碰运气”。8.2 大模型和车路协同对规控算法的潜在影响2023年之后大语言模型引爆了AI领域也有一些团队尝试把大模型引入自动驾驶规控比如用大模型做场景理解和常识推理辅助决策。我认为这个方向有潜力但短期内更可行的落地点在“离线场景挖掘”和“数据处理”上而不是在线实时决策。大模型幻觉问题一旦出现在车辆控制上后果难以承受。在线决策的每一毫秒都性命攸关现阶段还是要以可证明、可验证的算法为基础。车路协同对规控的影响则更实际一些。如果道路基础设施能提供红绿灯相位、前方拥堵、事故信息等全局视角规控算法就能从“单车智能”扩展到“群体智能”。比如在绿灯即将结束的十字路口车路协同信息可以让规划器提前判断是否能通过而不是到了停止线前才急刹。这类信息对规控算法的提升比想象中更大值得关注。8.3 给规控工程师的职业建议底层能力比模型框架更值钱从业十年我越发觉得规控工程师最值钱的不是会几个模型而是底层能力系统思维、数学功底、工程直觉。模型和框架每年都在变但“如何把一个问题表述成可优化的数学形式”“如何在约束中寻找可行解”“如何在不确定性下做决策”这些能力是长期有效的。具体来说我建议新手先吃透经典方法Frenet坐标变换、MPC原理、卡尔曼滤波、碰撞检测算法。这些看似“古老”的东西是所有新方法的地基。然后再去学学习类方法同时把“系统失效分析”作为必修课——理解系统什么时候会挂比理解系统什么时候工作好更重要。最后多参与实车测试不要泡在仿真里自嗨。真实世界的噪声和延迟是学再多论文也体会不到的。我非常鼓励团队里年轻工程师去思考“大系统视角”的问题感知误差如何传递到规划执行延迟如何影响控制地图不实时如何调整参考线这些“接口问题”才是规控系统真正的核心难点。能把这些耦合问题解决明白的工程师在任何技术浪潮里都不会被淘汰。