之前大家在刷短视频和车友群的时候应该都刷到过这样一个话题小鹏 MONA 系列车型去跑山和保时捷同场竞技最后的传播点落在“MONA 智驾跑山零接管登顶”上。另一个更有意思的说法是“保时捷居然弃轮保车了”。听起来很像一场网络口水战但如果你把它拆开看里面其实藏着两个完全不同层面的问题一个是赛道/山路上的驾驶策略差异另一个是量产车智能辅助驾驶系统在极端场景下的真实能力边界。本文不打算站在某个品牌立场上吹捧或拉踩而是从技术体系和工程测试的角度把“智驾跑山”这件事拆开聊聊跑山路段到底对智驾系统提出了哪些挑战所谓“零接管”是怎么测量和统计的以及“保时捷弃轮保车”和“智驾零接管”背后其实是两种完全不同的驾驶哲学。如果你是智能驾驶行业的研发、测试工程师或者对 ADAS 功能原理感兴趣的开发者这篇文章会给你一套比较完整的技术分析框架。我们也会给出一些用 Python 做轨迹数据和接管事件分析的示例代码方便你在实际项目中参考。1. 事件背景一场“网络热议”的智驾跑山1.1 这个热点到底在讨论什么先还原一下这个热点事件的基本画面一辆小鹏 MONA 系列车型跑山路车上开启辅助驾驶系统整个过程没有发生驾驶员接管车辆完成了上山或者下山全程。另一边保时捷在类似的激烈驾驶场景中选择“弃轮保车”也就是为了保住车辆完成比赛或行程宁愿牺牲轮胎不继续做极限驾驶。两个行为放在一起很容易被剪辑成“国产智驾挑战传统性能车”的叙事。但从工程师角度看这里其实存在明显的概念错位小鹏 MONA 的“零接管跑山”验证的是辅助驾驶系统在连续弯道、坡道、山区道路上的稳定控制能力保时捷的“弃轮保车”验证的是赛道驾驶中轮胎热衰减、抓地力极限和完赛策略之间的取舍。前者是自动驾驶算法的边界测试后者是赛车运动中的轮胎管理策略。两者不在同一个评价体系里。1.2 为什么“零接管”值得被讨论虽然对比本身不够严谨但“零接管”这个词确实是智能驾驶行业非常看重的指标。在辅助驾驶系统的路测中接管次数是最直观的安全性和可用性指标。一次接管可能意味着系统感知出现漏检没有识别出路边的锥桶或异形车辆规划模块在复杂弯道中无法生成合理轨迹驾驶员被迫介入控制模块在坡道或低附着路面上出现抖动、偏离车道中心线系统由于定位漂移或地图数据缺失主动退出驾驶员需要接管。所以如果一辆量产车真的能够在山区连续弯道路段实现全程不接管至少说明这套系统的感知、定位、规划、控制链路在特定工况下是比较成熟的。不过要注意“零接管”是有前提条件的。跑山测试往往选择特定路线、特定天气、特定时间段甚至会对道路做提前勘察。这不是否定测试价值而是提醒我们不要把一个场景下的成绩简单外推到所有场景。1.3 先泼一盆冷水别把营销事件当实验报告作为技术人员我们看这类热点事件要习惯性做“去噪”处理视频展示的是经过剪辑的最佳结果不代表系统在整段路程中没有任何瑕疵“零接管”没有统一的第三方评测标准不同品牌对“接管”的定义可能不一致山路测试的风险等级远高于城市道路任何一次失误都可能造成严重后果所以在解读测试成绩时要留有余地。这篇文章接下来的内容会抛开营销话术把跑山这种场景给智能驾驶系统带来的技术挑战逐条讲清楚。2. 跑山路段对智驾系统提出了哪些挑战智能驾驶系统在高速和城市快速路上的表现已经比较成熟但山路是另一种完全不同的工况。跑山路对系统的压力主要来自以下几个方面。2.1 连续弯道与车速控制山路最常见的特征就是连续弯道而且弯道曲率变化剧烈经常出现“S 型弯”“发卡弯”这样在城市和高速上少见的道路形态。这对规划控制模块提出了很高的要求入弯前需要在合适的位置开始减速减速度过大会让乘客不适过小则可能导致入弯速度过快弯中需要维持稳定的横向加速度如果转向控制不平顺车辆会明显摇摆出弯时需要根据前方视野恢复情况逐步加速但不能在弯道出口盲目急加速。算法上通常会把弯道处理拆成“路径规划”和“速度规划”两个子问题。路径规划生成一条平滑的参考线速度规划根据曲率、路面附着系数、限速信息计算每个位置点的允许速度。但是山路上的曲率往往不是固定不变的一个弯道内部可能包含从大曲率到小曲率的渐变段。如果速度规划没有充分预测这种变化系统很容易出现“进弯太慢、弯中犹豫、出弯太晚加速”的表现。2.2 车道线模糊与路面起伏山路上的车道线磨损严重甚至很多乡道、景区道路根本没有清晰的车道线。有些路段是双向两车道对向车辆压线行驶非常常见。这对感知系统的影响是直接的车道线检测模型在缺乏清晰标记的情况下需要依赖道路边缘、护栏、路沿石等语义信息来拟合可行驶区域路面起伏会导致摄像头视角变化影响目标检测的稳定性强烈阳光、树荫斑驳、雨后反光会进一步加大感知难度。跑山能“零接管”说明感知系统在车道线不完整的情况下仍然能够维持一个比较可靠的“可行驶区域”估计。这背后通常依赖多传感器融合而不是仅仅依靠车道线。2.3 GPS 信号遮挡与定位漂移山区还有一个隐蔽但非常重要的问题定位信号不稳定。两侧高山、茂密植被、隧道和弯道会造成卫星信号遮挡和多路径效应GPS/北斗定位精度会明显下降。而精确的定位是智能驾驶系统的地基。如果车辆不知道自己在道路坐标系中的精确位置即使感知模块识别出了车道线也很难把感知结果和地图数据对齐。目前主流解决方案是融合定位GNSS 卫星定位提供绝对位置参考惯性测量单元IMU提供短时间内的高频位移和姿态变化轮速传感器提供里程信息视觉、激光雷达等感知结果与高精地图要素做匹配对定位结果进行修正。跑山过程中如果某一个定位源失效系统还能不能继续工作就取决于剩余传感器的冗余程度和融合算法的鲁棒性。2.4 对向来车、非机动车与落石等异形障碍物山路不是封闭赛道。即使是相对偏远的山路也可能出现对向借道超车的车辆摩托车、自行车、行人掉落在路上的石块、树枝路旁临时施工的锥桶和警示牌。这些障碍物形态差异很大对感知模型来说属于典型的“长尾场景”。跑山测试能够零接管意味着系统面对这些非典型障碍物时没有出现“漏检”或者“误刹车”的极端错误。3. 智驾系统跑山的关键技术拆解前面说的是跑山场景给系统提了什么问题这一节我们站在系统架构的角度看看一套能够跑山的智能驾驶系统各模块到底是怎么协作的。3.1 感知层摄像头、毫米波雷达与超声波的分工主流量产车的感知方案通常包括摄像头、毫米波雷达和超声波雷达更高阶的车型可能还会加入激光雷达。传感器主要优势在跑山场景中的作用摄像头语义信息丰富能识别车道线、交通标志、物体类别车道线检测、障碍物分类、可行驶区域分割毫米波雷达不受光照影响直接测量距离和速度对金属障碍物的稳定检测弥补摄像头在逆光、雨雾时的不足超声波雷达近距离探测精度高低速泊车和近距离避障辅助激光雷达如果配备高精度 3D 点云不依赖光照提供精确障碍物轮廓和道路边缘信息在跑山场景中摄像头依然是信息量最大的传感器但单纯依靠摄像头会出现两个风险逆光或明暗剧烈变化时图像动态范围不足导致检测置信度下降单目视觉对距离的估计误差会随着距离增大而放大无法为规划模块提供足够精确的障碍物位置。因此感知层通常会做“前融合”或“后融合”把摄像头、雷达输出的结果在统一坐标下合并输出一个综合障碍物列表和可行驶区域。跑山时感知系统需要做到的是在任何一个单一传感器失效或被干扰时仍然能维持安全的最小感知能力。3.2 定位层高精地图 实时定位跑山场景对定位的依赖程度非常高因为山路的弯道几何信息如果只靠实时感知来重建计算压力会非常大而且对于弯道后面的盲区实时感知是解决不了的。这时候高精地图发挥作用高精地图提供车道的中心线、曲率、坡度、超高、限速等先验信息车辆通过实时感知与地图要素匹配判断自己在道路上的横向和纵向位置即使感知模块暂时无法看清车道线只要定位可靠系统仍能沿地图参考线行驶。但高精地图有一个现实问题更新不及时。如果道路标线重画、存在临时施工地图数据与实际路况不一致系统就需要依靠实时感知来“纠正”地图这是一个充满挑战的环节。跑山中常见的定位漂移现象往往发生在地图匹配错误之后。车辆明明在左弯地图却认为车辆在直道上规划出来的参考轨迹就会偏离实际道路。3.3 规划层全局路径与局部轨迹规划层负责回答“车应该往哪走”的问题。它可以拆成两层全局路径规划从起点到终点基于道路网络和高精地图生成一条宏观路径局部轨迹规划在全局路径基础上根据实时感知到的障碍物、车道线、交通规则生成未来 3 到 8 秒内的可执行轨迹包含位置、速度和朝向。在跑山过程中局部轨迹规划的压力最大。因为山路的弯道边界往往非常紧凑留给规划算法的调整空间很小。如果规划的轨迹偏向弯道内侧即使没有压线也会给乘客带来很强的心理压迫感如果偏向弯道外侧又容易离对向车道太近。好的轨迹规划器通常会把以下因素放进优化目标与车道边界和障碍物的安全距离轨迹的平滑程度包括横向加速度、纵向加加速度与驾驶员预期的一致性简单说就是“像个正常人在开车”。3.4 控制层转向、油门、制动的协同规划层生成轨迹后控制层负责执行。控制层主要解决两个问题横向控制通过转向系统让车辆沿目标轨迹行驶纵向控制通过油门和制动控制车速使其符合规划速度曲线。跑山路时控制层最怕的是“执行延迟”。从规划生成指令到转向机构真正响应中间存在通信延迟、执行器响应延迟。在高速直道上几十毫秒的延迟几乎感觉不到但在曲率很大的弯道中延迟会直接导致车辆偏离参考线。另一个常见问题是纵向控制与横向控制的耦合。弯道中驾驶员通常会先减速再转向好的智驾系统也会模拟这种操作逻辑在入弯前完成主要减速弯中保持稳定油门或轻微加速出弯后再线性提速。如果纵向控制过于激进车辆在弯中会因为重心转移而降低极限也让乘客很不舒服。3.5 算力平台与系统冗余最后一个底层支撑是算力。跑山场景需要同时运行多个神经网络模型目标检测模型车辆、行人、障碍物车道线检测模型可行驶区域分割模型地图匹配与定位融合算法轨迹规划与运动控制算法。这些算法对算力的消耗非常大。如果芯片算力不足系统只能降低模型推理频率或者牺牲模型精度来换取实时性。此外系统的安全性还取决于冗余设计。跑山过程中如果主计算平台出现故障有没有一套降级策略转向系统失效时是否可以安全靠边停车这些都是衡量系统成熟度的重要指标。4. “零接管”是如何被测量的从工程视角看测试4.1 接管的定义与统计口径在讨论“零接管”之前需要先定义一个关键问题什么算一次接管不同团队有不同的口径常见包括接管类型定义示例是否计入接管次数主动安全接管系统检测到风险主动退出辅助驾驶并报警通常计入驾驶员主动接管驾驶员认为系统表现不佳主动转动方向盘或踩刹车退出通常计入系统降级接管系统检测到传感器失效提示驾驶员接管通常计入自然退出到达目的地或驶出辅助驾驶可运行区域系统正常退出通常不计入测试前主动关闭在测试外路段由驾驶员关闭系统不计入测试统计可以看到如果不明确统计口径“零接管”这个数字很难横向比较。有些测试把“驾驶员因为系统表现不好而接管”列为接管有些则只统计“系统因为故障强制退出”两者差距很大。因此在看任何“零接管”成绩时要先问三个问题测试路段的长度和复杂度是什么接管的统计口径是什么是否有第三方机构或完整视频记录作为证据4.2 一个简单的接管事件分析示例Python在实际研发中我们通常会把试驾或路测的车端日志拉下来从中提取接管事件。下面给出一段简化示例代码演示如何从记录车辆状态和时间戳的 CSV 中统计接管次数。假设日志中包含如下字段timestamp时间戳speed_mps车速单位 m/ssteer_angle方向盘转角单位度accel_mps2纵向加速度单位 m/s²system_status系统状态1 表示辅助驾驶激活0 表示未激活takeover_flag接管标记1 表示出现驾驶员接管0 表示无接管先用 Python 写一个读取和统计接管事件的函数import pandas as pd def load_drive_log(csv_path): 加载车端日志 CSV 文件 df pd.read_csv(csv_path) df[timestamp] pd.to_datetime(df[timestamp]) return df def count_takeovers(df): 统计接管事件数量。 定义takeover_flag 从 0 变为 1 时认为发生一次接管。 df df.sort_values(timestamp).reset_index(dropTrue) flag df[takeover_flag].astype(int) # 检测上升沿 transitions (flag.diff() 1).astype(int) takeover_count transitions.sum() takeover_indices df.index[transitions 1].tolist() return takeover_count, takeover_indices # 用法示例 if __name__ __main__: df load_drive_log(mountain_drive.csv) count, indices count_takeovers(df) print(接管次数:, count) print(接管发生行索引:, indices) # 进一步输出每次接管发生前的车速 for idx in indices[:10]: row df.iloc[idx] print(f接管时间 {row[timestamp]}, 接管前车速 {row[speed_mps]:.2f} m/s)这段代码的核心逻辑是检测takeover_flag的上升沿。这样能避免在一段持续接管过程中重复计数符合大多数测试数据的处理习惯。在实际生产项目中接管标记往往不是提前打好的而是通过方向盘力矩传感器、刹车踏板位移、ACC 取消信号等若干条件组合判断而来。你需要根据自己所在团队的定义来调整判断条件。4.3 弯道通过质量的客观指标除了接管次数弯道通过质量也需要量化。否则就会出现一种情况虽然零接管但车辆在弯道里速度极低、压线严重实际上没有可用性。常用指标包括横向加速度反映车辆在弯道中的侧向受力通常控制在 0.2g 到 0.4g 之间比较舒适车道中心线偏移量车辆中心点与车道中心线之间的距离反映横向控制精度加加速度加速度的变化率反映纵向控制平顺性通过时间完成同一段弯道所需时间反映整体效率。下面给出一个用轨迹数据估算弯道曲率和横向加速度的简化示例import numpy as np import pandas as pd def estimate_curvature(x, y): 根据轨迹点估算曲率。 输入 x, y 为二维平面坐标序列。 dx np.gradient(x) dy np.gradient(y) ddx np.gradient(dx) ddy np.gradient(dy) denominator (dx**2 dy**2) ** 1.5 numerator np.abs(dx * ddy - dy * ddx) with np.errstate(divideignore, invalidignore): curvature np.where(denominator 1e-6, numerator / denominator, 0.0) return curvature def estimate_lateral_accel(speed_mps, curvature): 根据车速和曲率计算横向加速度 a v^2 * kappa return speed_mps**2 * curvature # 读取轨迹数据 df pd.read_csv(track_gps.csv) # 假设字段为 x, y, speed_mps df[curvature] estimate_curvature(df[x].values, df[y].values) df[lateral_accel] estimate_lateral_accel(df[speed_mps].values, df[curvature].values) print(横向加速度统计:) print(df[lateral_accel].describe()) print(最大横向加速度:, round(df[lateral_accel].max(), 3), g 对应 9.8 m/s²)这里有一个技术点需要提醒从 GPS 轨迹估算曲率对轨迹的平滑度非常敏感。如果原始坐标噪声太大直接求导会产生很多虚假的曲率峰值。实际项目中一般会先对轨迹做平滑滤波比如使用 Savitzky-Golay 滤波器或 B 样条拟合再计算曲率。from scipy.signal import savgol_filter x_smooth savgol_filter(df[x].values, window_length15, polyorder2) y_smooth savgol_filter(df[y].values, window_length15, polyorder2) df[curvature] estimate_curvature(x_smooth, y_smooth)这类分析在智驾测试中非常常用可以帮助测试工程师从数据上看出系统在哪个弯道表现最差从而反推是哪一层模块出现短板。5. “弃轮保车”与“零接管”两种驾驶哲学的碰撞5.1 赛道里的“弃轮保车”是什么先解释一下“弃轮保车”这个说法。在赛车运动中轮胎是最重要的消耗品之一。轮胎的抓地力会随着温度和磨损状态变化太凉时抓地力不足过度高温后抓地力又会断崖式下降。所谓“弃轮保车”指的是车手或车队判断当前轮胎状态已经无法支撑继续做极限圈速于是主动降低车速、减少横向和纵向负荷保护轮胎不要提前衰竭从而保证赛车能够顺利冲线或跑完剩余赛程。这在赛车策略中是正常甚至是明智的选择。轮胎一旦完全失去抓地力轻则损失圈速重则冲出赛道、撞墙退赛反而因小失大。5.2 为什么智驾系统选择“稳”而不是“猛”智驾跑山追求的则是另一套目标。智能驾驶系统的第一优先级永远是安全第二优先级是舒适第三优先级才是效率。在这样的排序下系统天然会选择更保守的驾驶策略入弯前提前减速即使这意味着入弯速度比人类老司机更慢弯中保持一个相对安全的横向加速度而不是逼近物理极限出弯后缓慢加速避免因为路面变化导致车辆失稳。这套策略决定了智驾系统可以在“稳”的维度做到很高水平但在“猛”的维度上暂时无法和顶尖车手相比。这次热点中小鹏 MONA 的“零接管跑山”体现的正是前者系统能在山路上稳定完成驾驶任务不给驾驶员带来惊吓。5.3 什么时候应该追求极限这里要补充一个观点智能驾驶系统其实没有必要像赛车手那样追求物理极限。驾驶的极限界限是极其模糊的它取决于轮胎状态、路面附着系数、风速、车辆载荷分布等几十个变量。量产智驾系统无法在毫秒级精确感知所有这些变量所以更现实的做法是保持在物理极限的 70% 到 80% 附近运行把余量留给突发情况。只有在自动驾驶算法发展和传感器精度大幅提升之后系统才可能逐步逼近人类驾驶员的极限操控能力。在那之前我们更应该用“稳定性”和“可用性”来评价智驾系统而不是看它是否能跑出赛车圈速。6. 消费者应该如何理解“智驾跑山”宣传6.1 先看测试边界再看宣传话术作为消费者看到“智驾跑山零接管”这类宣传时建议先做一次信息拆解不要直接默认“这辆车在任何山路都能零接管”。可以参考下面这个清单测试路线有多长包含哪些类型的弯道测试当天的天气、光线、车流量如何是否是媒体团队提前勘察过的道路是否有完整脱敏视频而不是只有高光片段测试车辆是量产版软件还是内测版软件测试过程中是否出现过系统退出但未被剪辑的情况这些问题没有标准答案但多问一句就能少一分误解。6.2 “零接管”不等于“自动驾驶”这里需要强调一个最关键的安全边界当前所有量产车的辅助驾驶系统都属于 L2 级辅助驾驶。即使车辆在整段山路上没有要求接管驾驶员依然要对行车安全负全部责任。也就是说“零接管”描述的是系统在特定路段上的表现不代表系统已经具备完全自动驾驶能力。实际驾驶中前方可能突然出现施工、落石、逆行车辆等系统从未见过的场景驾驶员必须时刻保持注意力随时准备接管。这也是为什么几乎所有量产车的用户手册中都会用大段文字强调辅助驾驶功能不能替代驾驶员对车辆的控制义务。6.3 跑山体验的注意点如果你自己也想在山路上体验车辆的辅助驾驶功能需要注意以下几点首次在山路使用辅助驾驶前先仔细阅读车主手册了解功能激活条件和降级策略不要在雨雪、大雾、夜间看不清路面的情况下强行开启进入急弯密集路段时提前预判系统是否会主动退出不要把“零接管测试”当作日常驾驶标准如果发现系统在弯道中明显偏离车道中心线要果断接管不要为了测试系统极限而冒险任何时候上车就系好安全带不要把辅助驾驶当作可以分心玩手机的理由。7. 智驾跑山背后的工程最佳实践热点事件会过去但跑山测试背后反映的工程问题值得智驾研发团队长期关注。7.1 数据闭环比单次秀肌肉更重要一次成功的跑山测试只能证明系统在特定场景、特定时间点表现良好。真正决定系统能力的是能不能把跑山过程中发现的 corner case 回传到数据平台形成“采集 → 标注 → 训练 → 仿真 → 验证 → 上线”的闭环。山路的 corner case 比城市道路更丰富例如树干阴影造成的“虚拟车道线”干扰窄桥上无车道线且两侧护栏距离极近路面从沥青切换到水泥导致视觉算法置信度跳变。如果没有数据闭环这些问题在路测中只会零星出现无法被有效积累和迭代。7.2 仿真测试与真实路测结合跑山路测试成本高、风险大不能每次都靠实车验证。成熟的团队会把在山路采集的轨迹和障碍物数据导入仿真环境做大量的参数扫描和异常注入。例如在仿真中把定位误差调大两倍观察规划模块是否仍然能生成安全轨迹或者给感知模块注入一个突然出现的落石障碍物验证紧急制动策略是否及时。仿真无法完全替代实车但能把实车的风险降到最低。合理的组合是仿真做广覆盖的算法验证实车做针对性的最终验收。7.3 安全兜底与最小风险状态跑山场景下系统必须有明确的最小风险状态。一旦出现传感器故障、定位丢失、模型置信度不足等问题系统不能继续“硬撑”而应该发出明确的接管提示执行安全的减速策略在条件允许的情况下靠边停车。这个逻辑需要贯穿到系统架构中。比如当定位模块方差超过阈值时规划模块是否会被强制切换到保守模式当感知模块的 fps 下降时是否会自动降低最高车速这些问题都应该有清晰的策略定义。7.4 对研发团队的三条建议如果你所在的团队正在做智驾相关开发这里有三条建议值得放进日常工作流建立接管事件的自动化归因工具。每次接管都要能自动关联到感知、定位、规划、控制中的某一层并输出原因分类否则问题无法闭环。把“接管率”和“不舒适事件”分开统计。只统计接管次数会漏掉很多“虽然没接管但乘客已经头晕”的情况弯道通过质量指标同样重要。对高曲率路段做专项评估。在测试矩阵中加入专门的山路科目并且设置“弯道横向加速度不超过阈值”“车道中心线偏差不超过阈值”等硬性通过标准。8. 总结与下一步关注什么回到最开始的话题。这次“小鹏大战保时捷”的热点本质上是两个维度的错位一边是智能驾驶系统在追求稳定、安全、舒适一边是传统性能车在追求轮胎极限、圈速和完赛策略。前者用“零接管”证明了自己在特定山路场景的控制能力后者用“弃轮保车”展现了赛车策略中的取舍智慧。作为技术人我更建议大家把关注点放在这件事带出来的工程问题上跑山场景暴露了智驾系统在连续弯道、GPS 不稳定、车道线缺失等长尾场景中的能力边界。一次零接管成绩是数据闭环、仿真测试、安全兜底等体系化能力长期积累的结果而不是某一个功能模块的单点突破。下一步你可以持续关注三个方向各品牌在“接管定义”上的标准化进展山路、乡村道路等长尾场景在智驾测试体系中的占比变化感知、定位、规划、控制四层架构在极端场景下的融合方案演进。如果你手上有实际的路测日志或者轨迹数据不妨用本文里的 Python 示例跑一遍看看自己的数据里能不能发现有趣的问题。代码比较简单重点在于分析思路先定义什么是接管再量化弯道通过质量最后定位问题到具体模块。这套方法论在任何一款智驾产品的研发测试中都是通用的。