智能驾驶稳行系统：从多传感器融合到航空级冗余的工程实践

关注智能汽车的朋友可能已经注意到，近一年来大家对“智能驾驶好不好用”的评价方式正在发生变化。早期我们更关注辅助驾驶能不能识别行人、能不能自动跟车、能不能在高速上完成超车；而现在，越来越多的用户会把“这车开起来稳不稳”放在第一位。这个“稳”字听起来很感性，但在工程上是一个非常硬核的指标。它背后涉及多传感器感知、多源定位、决策规划、底盘控制、系统冗余、故障降级、极端场景测试等环节。小鹏G9L在近期公开信息中强调，搭载了与GX同源的全场景稳行系统，并采用航空级安全冗余设计。这篇文章先从工程架构视角，拆解一套“稳行系统”是怎么被设计出来的。

为了让讨论不流于产品宣传，我会把重点放在系统设计方法论上：什么样的架构能让车辆在雨雾天气、复杂城市道路、高架桥下等场景中保持稳定；“双旗舰同源”在工程上意味着什么；“航空级冗余”如何从概念落地为真实的传感器、计算、执行链路。文中还会给出一些通用工程示例，包括感知融合流程、冗余仲裁逻辑、场景测试配置和健康监控代码。这些示例不针对具体车型，主要是帮助你建立对这类系统的工程直觉。

1. 背景：为什么“稳”比“功能多”更难

1.1 用户感受到的“稳”是什么

用户口中的“稳”，往往来自连续几个正向体验的叠加：车辆在雨天高速行驶时没有频繁退出辅助驾驶，车道保持没有左右画龙，前车切出时车辆只是轻微减速而不是急刹，系统偶发故障时能平滑降级而不是直接失控。这些体验叠加起来，会形成一个整体印象：这套系统靠谱、可信任。

反过来，如果一辆车功能清单非常丰富，但用户每一次在关键场景下都担心它会不会突然退出或误判，那么再多的“功能配置”也很难建立信任。所以，智能驾驶产品从“有功能”进入“好用”阶段后，稳定性就成了比功能数量更重要的一项竞争力。

1.2 系统稳定性为什么难做

稳定性难做，因为它在本质上不是某个单点模块可以解决的问题。一个稳定的智能驾驶系统，至少要同时处理好三件事：

• 在任何时刻都知道“自己在哪里、周边有什么”，也就是感知与定位足够可靠。
• 在所有正常场景下都能给出合理的驾驶决策，包括跟随、变道、避障、通过路口等。
• 在出现异常时能安全接管或退出，不把驾驶员置于危险境地。

这三件事中，第一件依赖传感器与算法，第二件依赖规则与模型，第三件依赖系统架构与安全设计。任何一环出现短板，用户都会在真实驾驶中感知到“不稳”。

1.3 系统化设计成为竞争核心

从行业发展趋势来看，主流厂商已经不再单纯比拼芯片算力或传感器数量，而是看谁能在整条链路上做到更高的可靠性与一致性。芯片算力再大，如果电源不稳定、温度过高后的降频策略不合理，系统依然可能在关键时候掉链子。传感器数量再多，如果感知融合算法做了错误的置信度分配，路况感知同样会失真。

因此，“稳行”本质上是系统性工程的结果。小鹏G9L这套与GX同源的全场景稳行系统，之所以能被官方作为核心卖点，正是因为“同一套系统在不同旗舰车型上复用时，工程经验、测试数据和安全框架可以持续积累”，这比单独开发一套系统更有利于稳定性的收敛。

2. 全场景稳行系统核心概念

2.1 全场景稳行系统是什么

全场景稳行系统，可以理解为覆盖“感知—决策—控制—监控—冗余”全链路的智能驾驶综合系统。它不是一个单独的传感器，也不是一个单纯的算法模型，而是把各种软硬件模块组合成一个闭环，让车辆在尽可能多的真实场景中都保持稳定可控。

从功能划分上，它通常包括以下模块：

2.2 “全场景”具体指什么

“全场景”这个词在工程上并不是说车辆能够在所有环境中都实现完全无人驾驶，而是指系统在设计时覆盖了用户高频使用和潜在风险较大的场景集合。常见场景维度如下：

• 天气维度：晴天、夜晚、雨天、雾天、雪天。
• 道路维度：高速、城市快速路、城市普通道路、乡村道路、停车场。
• 交通维度：拥堵跟车、自由流、前车切入、行人横穿、施工改道。
• 定位维度：空旷路段、高架桥下、隧道内、植被遮挡区域。
• 系统状态维度：主系统正常、单传感器故障、定位源丢失、计算单元异常。

每个维度延伸到真实世界中，都会产生大量的 corner case。例如雨天场景又可以拆成小雨、中雨、大雨、暴雨、路面积水、挡风玻璃雨滴干扰、摄像头起雾等子场景。真正的全场景稳行系统，需要针对这些子场景建立完整的开发与验证流程。

2.3 与普通辅助驾驶系统的区别

传统的辅助驾驶系统通常按照功能模块独立开发，例如自适应巡航负责纵向控制，车道保持负责横向控制，车道偏离预警负责提示。系统之间的信息交互较少，安全兜底机制也比较有限。

全场景稳行系统则更接近一个“整体系统”的概念。它的特点在于：

• 各模块之间有关联的置信度传递。感知模块输出目标的同时，会附带检测置信度和遮挡状态，供决策模块参考。
• 系统具备主动降级策略。当感知质量下降时，系统不会直接退出，而是先限制车速、缩小变道范围，再逐步提示接管。
• 全链路有健康监控。不只是监控某个CPU使用率，而是监控感知结果质量、定位精度、执行器响应、电源状态等多项指标。

换句话说，传统辅助驾驶追求的是“在某些场景下能干活”，而全场景稳行系统追求的是“在绝大多数场景下稳定、可预期地干活”。

3. 双旗舰同源方案：一套系统，多款车型

3.1 双旗舰同源的工程含义

“双旗舰同源”是这次小鹏G9L消息中的一个核心点。从工程角度看，它指的是两款旗舰车型共用同一套核心技术底座，包括全场景稳行系统软件框架、安全冗余设计、底盘与动力控制接口标准，以及相应的测试验证体系。

这种做法的行业基础，是汽车电子电气架构从分布式向集中式演进。过去不同车型可能各自拥有独立的控制器、不同的总线协议和完全不同的软件版本，导致研发成本高、维护难、迭代慢。而现在，伴随着中央计算平台的发展，不同车型可以共享同一套计算平台和基础软件，只是在传感器配置、外观尺寸、悬挂调校等维度做差异化适配。

3.2 同源方案的三层价值

第一层价值是软件迭代效率提升。两套车型共用一套系统软件后，开发团队不用维护多套独立代码分支，新版本算法只需要做一次底层开发，然后分别在两款车型上做适配验证。这样可以把有限的人力资源集中在算法优化和安全验证上。

第二层价值是测试用例复用。同一套稳行系统在GX上完成大量路测后，积累的场景库、故障案例、回归测试用例可以直接复用于G9L。新车型不需要从零开始验证，而是重点验证“硬件差异导致的感知差异”以及“车型尺寸带来的控制参数差异”。

第三层价值是OTA版本策略统一。当两款旗舰车型运行同一套系统基座时，OTA发布可以保持统一的版本管理。用户得到的更新节奏一致，安全补丁也能同步下发，这对汽车的安全运营尤其重要。

3.3 同源不意味着一刀切

需要注意的是，同源方案并不代表两款车型在所有维度上都完全一致。从工程经验来看，至少有三类差异需要车型级适配：

• 传感器安装位置不同会带来标定参数差异，必须重新做外参标定和感知盲区分析。
• 车型轴距、车重、重心高度不同，会影响横向控制和纵向制动的参数标定。
• 空气动力学特性不同，在高速场景下对横风、能耗的响应不同，需要调整控制策略。

所以，同源方案的正确理解是“一套系统，统一底座，分别标定，共享迭代”。这既能保留架构复用的效率，又能保证每款车型在自身物理特性下都做到稳定可控。

4. 航空级安全冗余设计原理

4.1 为什么借鉴航空级理念

“航空级冗余”这个说法并不是一个正式的国际标准术语，但它的核心思想确实来自于航空航天领域的系统工程实践。在飞行控制系统中，工程师很早就意识到单个部件的可靠性无论多高，都不足以支撑整个飞机在极端情况下的安全，于是提出了冗余设计的概念。

冗余设计的基本思路可以用一句话概括：当主系统失效时，备份系统能在极短的时间内接管，并且整个系统的功能不会完全丧失。为了实现这一点，需要提前设计故障检测机制、切换机制和降级策略，而不能等故障发生后临时决定怎么办。

汽车智能驾驶系统借鉴这一理念，是因为L2+级以上的辅助驾驶系统一旦在高速行驶中发生软件故障或传感器失效，驾驶员不一定能在第一时间接管。系统必须具备自我监测和最小风险状态控制能力。

4.2 感知层冗余：多传感器交叉验证

感知冗余是航空级冗余理念中最容易理解的一层。摄像头对车道线和交通标志识别能力强，但在强光和夜间表现一般；毫米波雷达在雨雾中穿透能力好，但对静止目标的探测不够精细；激光雷达测距精度高，但在大雨中会受到水雾散射影响。三种传感器单独使用都有缺陷，但组合起来就可以互相弥补。

工程上，感知层冗余通常包含两个环节：

• 多传感器信息融合，将摄像头、雷达、激光雷达的目标在同一时间戳下进行关联和匹配。
• 置信度交叉验证，当不同传感器对同一目标的判断不一致时，系统需要根据场景模型决定信任谁。

例如，在雨天场景中，摄像头可能因为雨滴遮挡无法清晰识别前方静止车辆，但毫米波雷达依然能探测到目标。此时系统不应因为摄像头置信度低就忽略目标，而要基于雷达结果继续跟踪，并降低对摄像头输出的依赖。

4.3 计算层冗余：双系统与健康切换

计算单元是智能驾驶系统的大脑，如果主计算单元出现死机、算力过载或软件卡死，整个系统都可能瘫痪。航空级冗余设计的一个基本要求，就是存在一个备份计算单元，能够在主计算单元失效时及时接管。

在实际工程中，常见方案有两种：

• 双芯片方案：主、备两个芯片同时运行相同或降级的业务，主芯片正常时输出控制指令，异常时由备芯片接管。
• 主芯片冷备方案：备芯片只运行基础监控功能，不参与完整感知决策，在主芯片异常后需要一定时间启动。

前者的安全性更高，但成本也更高；后者在成本和功耗上更有优势，但需要把切换时间控制到驾驶员无感知的程度。无论采用哪种方案，健康监控模块都要持续输出“主计算单元是否健康”的信号，并且这个信号本身必须独立于主计算单元运行，否则就存在“自己检测自己”的逻辑悖论。

4.4 执行层冗余：转向与制动

即使感知和计算都正常，如果转向或制动系统失效，车辆依然无法安全行驶。因此，执行层冗余也是航空级冗余理念中不可或缺的一部分。

转向系统通常采用双电源回路或双电机结构，当主转向电机出现故障时，备份电机能够提供基本的转向能力。制动系统则倾向于同时保留线控制动与传统液压制动的能力，当线控系统失效时，驾驶员踩下制动踏板仍然可以通过液压回路产生制动力。

这里还要特别关注的是“转向手感一致性”。冗余切换不仅要在功能上有效，还要在体验上尽量平滑。如果主转向系统和备份转向系统的助力特性差异过大，驾驶员会在接管瞬间感受到明显的转向力变化，这本身就是一种安全隐患。

4.5 电源与通信冗余

智能驾驶系统对电源稳定性的要求远高于普通车载娱乐系统。主计算单元、传感器、执行器都需要稳定供电，一旦电压跌落，低概率的时序错乱就可能引发严重故障。

电源冗余的常见措施是采用多路供电和电池备份。当主电源异常时，备份电源能够维持关键系统一定时间的正常运行，让车辆完成安全停车。通信冗余则体现在控制器局域网和车载以太网的多通道设计上。关键控制指令路径不能只有一条通路，总线出现故障时要能自动切换到备用通道。

4.6 最小风险状态与降级策略

冗余设计的最终目标不是“永远不出问题”，而是“出了问题之后依然安全”。这就必须提前定义最小风险状态。

例如，在高速行驶中发现主计算单元异常，备份计算单元接管后，系统可以主动将最高车速限制到60km/h，同时引导车辆驶入应急车道；如果多个核心传感器同时失效，系统可以开启双闪，逐步减速并靠边停车；如果通信总线中断导致无法控制车辆，则必须依赖执行层冗余完成紧急制动。

这些降级策略在开发时必须逐条定义，并通过仿真和实车测试验证。每条策略都要回答三个问题：什么条件触发、以什么方式降级、驾驶员如何感知和接管。

5. 水陆空多重场景考验的工程应对

5.1 水路场景：雨天、积水与湿滑

汽车与飞机不同，它面对的环境不是稳定的高空大气，而是复杂多变的近地环境。所谓“水路场景”，在智能驾驶语境下并不指车辆要下水行驶，而是指雨天、积水、湿滑路面等与水相关的低附着、低能见度场景。

雨天对智能驾驶系统的影响是多方面的。摄像头镜头上的水珠会造成局部模糊，挡风玻璃雨刮扫过时也会短暂遮挡视野；毫米波雷达虽然受雨滴影响较小，但积水路面会造成多径反射，导致目标回波出现虚警；车辆在积水路面行驶时，轮胎附着力下降，同样的制动命令产生的减速度会比干燥路面小，控制模块需要实时调整。

工程上应对这些问题的常用思路包括：

• 为传感器增加加热和清洗装置，及时清除水珠和泥污。
• 在感知算法中建立“雨天退化模型”，根据雨量传感器和遮挡检测结果调整置信度。
• 在控制模块中引入路面附着系数估计，实时修正最大制动减速度和转向响应。

这些能力无法通过单次测试解决，必须在开发阶段积累大量真实雨天数据。

5.2 陆路场景：城市复杂道路与施工区域

陆地场景是智能驾驶面临的最大难点来源。城市道路中有密集的行人、自行车、电动车、公交车，还有临时施工、锥桶改道、地面标线磨损、红绿灯遮蔽等情况。任何一个看似简单的场景，都可能成为系统的决策空白区。

以施工区域为例，车辆原本按车道保持系统行驶，但前方突然出现锥桶引导变道。系统需要回答一系列问题：锥桶是静态障碍物还是施工引导线？旁边车道是否有来车？当前车速是否适合变道？如果变道空间不足，是否需要减速等待？这些问题如果不能在几百毫秒内得到合理回答，系统就只能退出辅助驾驶，把控制权交还给驾驶员。

从工程经验来看，城市复杂道路的稳定性提升，更多依赖“场景库驱动开发”。团队会从大量真实事故和路测中提炼高频风险场景，把它们转化为自动化测试用例，再针对失败用例进行算法迭代。这套流程越完善，系统的“稳”就越可量化。

5.3 空路场景：高架与立交桥下的定位挑战

这里的“空路”指的是车辆在立体交通环境中的场景，典型代表是高架桥、立交桥和城市隧道。这类场景最大的挑战是定位信号的不稳定。

高架桥下、隧道内或密集城市峡谷中，卫星定位信号会被遮挡或产生多径效应，车辆的位置可能突然漂移数米。如果定位系统只依赖卫星信号，车辆可能出现在错误的车道或错误的位置上，进而影响感知目标的关联和决策规划。

解决这个问题的常见技术路线是多源融合定位。车辆将惯性导航单元、轮速传感器、转向角传感器、卫星信号、高精地图以及车道线视觉观测结果进行融合。像高精地图匹配和车道线约束这样的非卫星定位信号，可以在卫星信号不佳时稳定输出位置和姿态的估计。

在设计这类系统时，工程师需要格外注意“定位置信度”的传递。定位模块不能只输出一个位置坐标，还需要输出该位置的不确定度。决策规划模块看到较大的定位误差时，应当主动降低车速、减少变道操作，而不是继续按正常状态行驶。

5.4 场景库建设与数据闭环

无论是水、陆、空哪类场景，支撑系统稳定性的底层基础设施都是数据闭环。没有足够的数据，再精巧的算法也无法覆盖真实世界的长尾场景。

数据闭环的核心流程包括：

1. 量产车辆和测试车辆持续采集数据。
2. 数据经过脱敏后回传云端。
3. 云端通过挖掘工具自动筛选异常片段和困难场景。
4. 筛选后的数据进入自动化标注和场景提取流程。
5. 高质量场景进入仿真平台，用于回归测试和算法迭代。
6. 迭代后的模型通过OTA发布到量产车，再采集新一轮数据。

这条链路跑得越快，“全场景稳行系统”面对未知场景的能力就越强。在数据闭环的支撑下，双旗舰同源的价值也会进一步放大：两款车型的数据可以汇总到统一的场景库中，共享给整个系统团队使用。

6. 核心工程模块示例

接下来看几个与稳行系统相关的工程模块示例。需要提前说明的是，这些示例属于通用教学代码，旨在展示设计思路，并非小鹏官方代码，实际工程实现会更加复杂。

6.1 多传感器感知融合流程

感知融合模块的输入来自摄像头、毫米波雷达和激光雷达，输出是具备空间坐标和置信度信息的目标列表。下面用一个简化流程展示融合的基本思路：

# 文件路径：perception/fusion_pipeline.py # 说明：多传感器目标融合简化示例，仅用于展示设计思路 import numpy as np def align_timestamp(objects, frame_id): """将不同传感器目标对齐到同一时间基准""" aligned = [] for obj in objects: if obj.frame_id == frame_id: aligned.append(obj) return aligned def associate_targets(camera_objs, radar_objs, lidar_objs, max_gate=1.5): """ 多传感器目标关联： 1. 将各传感器目标转换到车体坐标系 2. 按空间距离和速度方向进行最邻近匹配 3. 返回融合后的目标列表 """ fused = [] radar_xyz = [(o.x, o.y) for o in radar_objs] for cam_obj in camera_objs: # 寻找距离最近的雷达目标 nearest_radar = None min_dist = float('inf') for radar_obj in radar_objs: dist = np.hypot(cam_obj.x - radar_obj.x, cam_obj.y - radar_obj.y) if dist < min_dist: min_dist = dist nearest_radar = radar_obj # 如果摄像头目标与雷达目标距离较近，则合并 if nearest_radar and min_dist < max_gate: fused_target = { 'x': (cam_obj.x + nearest_radar.x) / 2.0, 'y': (cam_obj.y + nearest_radar.y) / 2.0, 'vx': nearest_radar.vx, 'confidence': 0.8, 'source': 'camera_radar' } else: # 距离较远的目标只保留摄像头结果，置信度降低 fused_target = { 'x': cam_obj.x, 'y': cam_obj.y, 'vx': 0.0, 'confidence': 0.5, 'source': 'camera_only' } fused.append(fused_target) return fused

这个示例虽然简化，但体现了感知融合的两个关键原则：传感器目标需要统一到同一坐标系，融合结果必须附带置信度信息。下游决策模块会根据置信度决定是否信任该目标。

6.2 冗余仲裁逻辑示例

主计算单元与备份计算单元之间的切换，通常由独立的健康监控模块负责。下面是一个简化的冗余仲裁逻辑：

# 文件路径：safety/arbitrator.py # 说明：冗余仲裁逻辑简化示例，实际系统还会考虑更多状态 class ControlArbitrator: def __init__(self, max_speed_degraded=60): self.max_speed_degraded = max_speed_degraded self.main_healthy = True self.backup_healthy = True def update_health(self, main_status, backup_status): self.main_healthy = main_status self.backup_healthy = backup_status def decide(self, normal_plan, backup_plan): # 主系统健康：正常执行规划结果 if self.main_healthy: return normal_plan # 主系统异常、备份正常：切换备份，并限制车速 if self.backup_healthy: backup_plan.max_speed = min( backup_plan.max_speed, self.max_speed_degraded ) return backup_plan # 双系统异常：进入最小风险状态，执行安全停车 return MinimalRiskPlan( target_speed=0, pull_over=True, hazard_lights=True )

冗余仲裁的核心设计点有两个：一是健康状态必须独立监测，不能依赖主系统自身的判断；二是降级策略必须是“可预期的”，驾驶员和云端都能理解系统当前处于什么状态。

6.3 场景测试配置片段

全场景稳行系统的开发离不开仿真测试。下面是一个场景测试配置的示例，用YAML描述具体测试场景：

# 文件路径：test/scenarios/rain_highway.yaml # 场景：暴雨高速巡航 test_scenarios: - name: "rain_highway_night" weather: rain_intensity: "heavy" visibility: 60 # 能见度单位：米 road_friction: 0.45 sensor_condition: camera: "lens_dirty_with_rain" radar: "normal" lidar: "mist_attenuation" vehicle_state: initial_speed_kmh: 100 lane: "middle" expected_behavior: min_keep_lane_seconds: 120 max_lateral_error_m: 0.35 max_deceleration_mps2: 3.0

# 文件路径：test/scenarios/under_viaduct.yaml # 场景：高架桥下GPS信号丢失 test_scenarios: - name: "under_viaduct_gps_loss" localization: gps: "loss_duration_10s" imu: "normal" wheel_speed: "normal" lane_line_visibility: "partial" expected_behavior: max_velocity_kmh: 80 no_lane_change: true lateral_deviation_m: 0.20

这类测试配置文件的最大价值，是让同一场景可以在不同版本软件、不同车型上复现执行。测试工程师只需要调整配置项，就能快速生成回归用例，发现新版本是否引入了稳定性退化。

6.4 健康监控与告警示例

健康监控模块需要避免一个常见问题：过于敏感。如果系统因为一次瞬时抖动就告警，会导致不必要的降级和驾驶员困惑。更合理的做法是采用“连续多次异常”的判定策略。

# 文件路径：monitor/health_monitor.py # 说明：健康监控模块中连续异常判定简化示例 import time class HealthMonitor: def __init__(self, failure_threshold=3, check_interval_ms=100): self.failure_threshold = failure_threshold self.check_interval_ms = check_interval_ms self.continuous_failures = {} self.last_status = {} def check_component(self, component, data, validator): """ :param component: 组件名称，例如 'camera_front' :param data: 组件上报的数据 :param validator: 校验函数，返回 True 表示正常 """ is_ok = validator(data) if component not in self.continuous_failures: self.continuous_failures[component] = 0 if is_ok: self.continuous_failures[component] = 0 else: self.continuous_failures[component] += 1 # 连续失败次数达到阈值，判定为故障 if self.continuous_failures[component] >= self.failure_threshold: self.last_status[component] = "fault" else: self.last_status[component] = "ok" return self.last_status[component]

在设计健康监控系统时，除了连续异常判定，还要考虑恢复机制。如果组件在恢复正常后持续一段时间稳定输出，系统应该自动恢复该组件的可信状态，而不是永远停留在故障锁定状态。

7. 常见问题与排查思路

全场景稳行系统在开发与测试中经常会遇到一些典型问题。下面整理一张排查表格，适合研发、测试和标定工程师参考。

这张表总结了实际项目中最常见的六类问题。从共性来看，大多数稳定性问题都不是“算法单点出了问题”，而是多个模块之间的状态传递、置信度传递和降级策略配合不够好。排查时建议先看系统日志，再看感知输出，最后核对控制指令，按“感知—决策—执行”链路逐层定位。

8. 最佳实践与工程建议

8.1 安全设计要前置，不能靠事后补丁

全场景稳行系统一旦在量产车上运行，安全设计就必须是前置的，不能等出现问题后再打补丁。开发初期应该同步开展系统故障模式分析，列出传感器失效、计算单元故障、通信中断、电源跌落等关键失效模式，并针对每种失效模式定义对应的降级策略。

同时，安全策略不能只停留在设计文档中，还必须在仿真环境和实车上逐条验证。每条降级策略都要有明确的触发条件、执行动作、驾驶员提示方式和退出条件。

8.2 用场景库驱动算法迭代

稳定性问题通常隐藏在长尾场景中，而算法团队很容易陷入“修好一个场景，破坏另一个场景”的循环。避免这个问题的有效方法，是建设统一的场景库，把所有已知的困难场景和回归用例沉淀下来。

每次算法更新，都必须跑完整个场景回归集。通过率低于基线版本时，新版本不予发布。这样虽然会拖慢短期迭代速度，但能保证系统稳定性长期处于上行通道。

8.3 建立细粒度的可观测性

智能驾驶系统运行在高速移动的车辆上，一旦出现问题，离线复现的成本非常高。因此，系统必须具备细粒度的日志和监控能力，才能在问题发生后还原现场。

工程上需要记录的至少包括：每个传感器原始数据和帧号、感知输出的目标列表、定位模块的置信度、规划模块的轨迹、控制模块的指令、健康监控模块的状态切换记录。这些数据需要标明时间戳和版本号，便于后续在仿真平台上回放。

8.4 OTA发布要遵循灰度策略

对于量产车来说，新版系统软件即使通过了全部回归测试，也仍然存在未知风险。更稳妥的做法是采用灰度发布策略，先向小范围用户推送，观察目标数据和用户反馈，再逐步扩大发布范围。

灰度发布并不是简单地把用户分成几批，而是要形成完整的监控闭环。例如，新版软件上线后，要对比同一路段、同一时段的系统退出率、接管次数、急刹次数等关键指标，与上一版本进行量化对比。任何异常上升都应及时触发暂停放量。

8.5 多车型适配要有版本基线

在双旗舰同源或多车型共用的开发模式下，版本管理是最容易被忽视的问题。建议以统一的稳行系统软件版本作为基线，各车型只维护差异化的标定配置和车型适配包。改基线前必须完成所有已发布车型的回归测试，避免为了适配新车型而引入老车型回归风险。

9. 总结与后续学习方向

这篇内容围绕小鹏G9L搭载的全场景稳行系统展开，但本质上讨论的是智能驾驶系统工程化的共性方法论。所谓“稳”，是一个系统工程结果，不是某一个算力最强的芯片或某一颗最贵的传感器带来的。它需要感知、定位、决策、控制、冗余、监控、测试、数据闭环多个环节协同工作。

如果你正在从事智能驾驶、机器人或嵌入式控制方向的工作，可以顺着以下路径继续深入学习：

• 功能安全标准ISO 26262，了解汽车电子系统的安全生命周期和ASIL等级。
• 预期功能安全标准ISO 21448，重点研究传感器局限性和算法误判导致的风险。
• 自动驾驶仿真与场景库构建，理解如何用自动化手段持续挖掘长尾场景。
• 多传感器融合与多源定位，掌握卡尔曼滤波、因子图优化等核心算法。
• 车载通信与电子电气架构，理解中央计算平台、域控制器和车载以太网的发展趋势。

从短期看，全场景稳行系统的持续迭代仍集中在“已知困难场景的稳定通过”和“未知场景的安全兜底”上。对于开发者来说，与其把目光放在某一个花哨的新功能上，不如先把数据闭环、监控告警、回归测试和冗余切换这些基础设施做扎实。系统能稳定跑完一万公里，比在演示视频里完成一次漂亮操作更有工程价值。