智能网联新规将来，全链条收紧多个环节？安全如何落到每个细节？车企如何提前布局？

[首发于智驾最前沿微信公众号]随着智能网联汽车加速落地，政府相关部门对其监管也更为明确，并多次发布相关标准及通知，其中涵盖了智能网联汽车的产品设计、测试要求及对外宣传等多个环节。就在2025年8月13日，市场监管总局会同工业和信息化部研究起草了《市场监管总局工业和信息化部关于加强智能网联新能源汽车产品召回、生产一致性监督管理与规范宣传的通知（征求意见稿）》（以下简称：《通知》），以落实《缺陷汽车产品召回管理条例》《关于进一步加强智能网联汽车产品准入、召回及软件在线升级管理的通知》等要求。

这份面向社会公开征求意见的《通知》，说白了就是给“软件定义汽车”的监管再上一个闸门，把召回、生产一致性、OTA、网络安全、驾驶员监测（DMS）以及营销宣传这几条链路拧成一股绳，这不仅可以约束企业的产品与行为，也可以保护消费者的知情权与安全权。它不是凭空冒出来的，而是承接《缺陷汽车产品召回管理条例》以及此前关于准入、召回和在线升级的管理通知，并且把《中华人民共和国广告法》《中华人民共和国反不正当竞争法》的底线要求一起拉进来，形成一张覆盖“造—卖—用—改—管—告”的监管网。换句话说，《通知》要解决的核心问题是当汽车越来越像“会上路的大型智能终端”，我们该如何把“安全第一”的工程原则落到每一次功能上线、每一条宣传语、每一次事故上报与每一轮召回改进中。

四根主骨，在“安全优先”下确保技术进步

从《通知》架构上看，这份征求意见稿有四根主骨，即加大缺陷调查与召回力度；强化生产一致性监督；规范广告宣传以及压实事件事故报告与深度调查。这四根骨头对应了智能网联汽车自市场化以来的四类典型风险，即技术功能被误用或失效、量产一致性和OTA失控、营销误导导致滥用，以及事故处置链条不闭环等。

第一根主骨：明确技术定义，加大品质管理力度

《通知》首先对准了组合驾驶辅助（通常覆盖L2/L2+功能）在真实使用中被当作“自动驾驶”误用的情况。明确要求企业必须在车机、手机App的显著位置，以及用户手册里，把该系统的安全提示和使用说明说清楚、放到位，避免用户“把辅助当自动”，同时要求企业开发并启用以安全优先为原则的驾驶员监测、警示与处置功能。这里的“处置”不是一句空话，而是列举了从语音警告、方向盘震动、限速、自动靠边，到必要时禁用组合驾驶辅助功能的一系列分级手段；并强调不得通过用户操作或系统逻辑主动关闭这些监测与处置功能。还强调市场监管总局将对这块开展专项调查，必要时纳入缺陷分析与召回。

这段要求意味着什么？第一，你的DMS不能是“摆设”。DMS的基本能力至少要覆盖“手离方向盘”“视线不聚焦”“闭眼/打瞌睡”等可观测征兆，触发分级告警并与纵向/横向控制联动。很多厂商以前把“手离方向盘检测”做成了一个“扭矩复位”的小游戏，驾驶员轻轻带一下力矩就算“在控”。现在，监管强调“安全优先”的监测与处置，这会倒逼DMS由单一的力矩传感走向多模态融合，通过方向盘力矩、目光与头部姿态、眨眼率、注意力回正时间，甚至座舱红外传感等，综合判断“可用驾驶员状态”。同时，“分级处置”不再只是“响一声就完了”，而是要有清晰的升级节奏，持续语音提示—方向盘震动—限速/扭矩衰减—请求靠边—功能退出与禁用。这要解决两个难题，一是“误报—漏报”权衡（例如太阳直射、墨镜、护目镜等工况），二是“处置”与交通环境安全之间的博弈，比如限速与靠边如何在高速车流中保持可控风险。这也意味着，HMI必须对“为什么我被限速/靠边”解释到位，避免二次风险。上述所有动作背后，都需要车端有稳定的状态机与超时策略设计，并用场景库在台架、实车与封闭场地进行系统级测试。《通知》中用一句“不得通过用户操作或系统逻辑主动关闭驾驶员监测、警示和处置功能”把“偷懒”这条路堵死了，也就是要求不能在设置里给“关闭DMS”留后门，也不能用OTA暗地里把阈值放宽。

网络安全是这条主骨的另一个重点。《通知》明确将因“网络攻击、网络威胁和漏洞”引发的安全事件纳入缺陷调查范围，必要时督促企业通过召回改进。这对于车企而言，意味着网络安全要从“内控评价项”上升为“召回触发项”。这就要建立持续的威胁情报与漏洞响应机制（PSIRT），车端必须具备必要的入侵检测与日志留存能力（例如关键控制报文异常、域间访问异常、刷写企图等），并能够通过合规的安全OTA快速修补。同时，安全补丁与功能性更新要分渠道、分优先级发布，避免“为了加一个小功能，顺手改了底层通信栈”这种高耦合风险。监管把网络事件与召回挂钩，目的就是倒逼“安全左移”，架构设计阶段就把安全域隔离、最小权限、密钥生命周期、Boot可信链等放到位，而不是上线后靠“补丁雨”救火。

第二根主骨：生产一致性与OTA的“闸门”

《通知》对生产一致性提出了几条“硬核”动作。首先，要求企业在机动车合格证系统中完整、准确填报组合驾驶辅助系统、储能装置单体及总成等关键信息；其次，严格执行OTA活动分类管理，未经备案不得开展OTA，不得把未经充分测试验证的软件版本推送给用户，也不得用OTA方式隐瞒缺陷；再者，监管部门会针对未按要求补充报送技术参数、车辆性能与报送参数不一致、未经备案开展OTA或与备案不一致等情况“依规处理”，对“频繁OTA”的企业还要重点抽查与专项核查。

这背后反映的其实是两个现实矛盾。第一，智能电车的“软件更新节奏”往往比“合规节奏”快，研发与产品想把迭代频率拉高，但量产一致性与安全合规必须跟得上。第二，OTA既是修错和提升体验的利器，也是把风险带到车端的“运送带”。所以监管的思路是“不是不让更，不是不能更，而是要带着‘刹车’更”。企业需要建立一条“需求变更—风险评估—测试验证—合规备案—灰度发布—场景监控—回滚预案—总结复盘”的闭环。尤其在“分类管理”这件事上，应该把功能性变更、标定变更、安全相关变更、对底层通信/诊断/OTA框架的变更区分开来，不同等级走不同闸口与审批链、不同的覆盖度测试与抽样规模。对“频繁OTA”的关注点，并不是要惩罚“爱更新”，而是要核查其背后是否存在“研发质量不过关”“上线前验证不足”或“用OTA遮掩已知缺陷”的问题；如果每次OTA都在“补昨天的坑”，那就不是“敏捷”，而是“冒进”。

把组合驾驶辅助与储能装置的信息纳入合格证系统的要求，等于把“型式参数”与“量产状态”关联起来，避免“报审样车”和“交付车辆”不一致。对供应链而言，这会倒逼Tier1/Tier2提供更稳定的版本管理、软件/标定的唯一性标识（SBOM/CBOM），以及和车辆VIN的绑定策略。如动力电池包的硬件版本、BMS软件版本、热管理策略、SOC/SOH算法版本等要能追溯到车，并且能在问题溯源时快速定位“这批次、这版本”的风险扩散范围。这不是“给文员加班”的管理动作，而是“给工程降低不确定性”的技术动作。

第三根主骨：宣传必须“说人话”，更要“说真话”

智能网联车的营销长期存在一个痛点，技术词汇绕、宣传边界虚、级别概念混。《通知》要求企业向消费者提供有关驾驶自动化等级、系统能力、系统边界的信息时必须真实、全面，不得做虚假、夸大或引人误解的宣传；命名和营销中不得暗示其为自动驾驶系统或具备事实上不具备的功能；也要避免夸大驾驶性能、误导用户以不合理的高速驾驶车辆。监管部门将加大对夸大组合驾驶辅助功能、欺骗或误导消费者等情形的监督检查，并组织技术机构对“过度宣传”做技术认定，必要时会同工信部开展专项联合调查。

这一要求是把“系统能力与边界”的沟通做成一份“可验证的产品声明”，而不是一条“凭感受的广告语”。所谓“可验证”，就是把需求规格、功能设计、验证报告、使用说明、宣传物料这五件事串起来，确保对外输出的与系统真实能力一致。如若系统对低附着路面、无车道线、强逆光、夜雨雾、施工区等工况天然能力衰减，那就必须在说明里和HMI里讲清楚“何时会退出、退出怎么提示、退出后驾驶员如何接手、会不会有残余扭矩/制动”。如果宣传用了“城市NOA”“高速点对点辅助”之类带有强场景暗示的名称，就要在同一物料里明确“需要驾驶员随时接管”“系统仅在符合使用条件时可用且可能随时退出”。技术认定的引入，实际上是用第三方视角来判断“宣传是否夸大”，这会促使企业内部把“市场语境”与“安全语境”对齐，减少“话术领先于技术”的冲动。

第四根主骨：事故必须“报得快、查得深、改得动”

《通知》要求企业按照此前关于准入、召回和在线升级管理的要求，及时报告组合驾驶辅助系统使用期间发生的安全事件和碰撞事故；监管部门将联合开展事故深度调查与分析，并对企业的事故报告进行监督检查，发现未按要求报告的，将向社会公开通报并督促整改；若存在隐瞒或遗漏重大事实的，还要开展专项核查。

这一要求，对智能网联事故上报从“报、查、改”三个方面进行了闭环，想要及时、准确地上报，就需要车辆具备事件数据记录能力（EDR/SDR），能把触发前后的关键信号保留下来，这其中就包含驾驶员可用状态、HMI告警、纵横向控制量、传感器健康状态、功能启停/接管时间线、环境要素（速度/相对距离/车道模型置信度/目标分类与置信度），以及异常码等关键数据。此外，隐私与合规同样重要，企业必须在采集范围、加密与脱敏、传输与存储合规、使用目的和最小化原则之间做好取舍，既做到“事故可还原”，也做到“数据可交代”。深度调查的价值，不只是在“追责”，更在“改进”，它能帮企业识别“模型泛化不足”“传感器冗余不够”“状态机切换策略不稳”“交互提示不清”这类系统性问题，从而引出架构级的改造，而不是头痛医头脚痛医脚。

把四根主骨连起来看可以看出，《通知》的核心目的有三，一是把“安全优先”落到产品功能与使用过程的每一个细节上，特别是组合驾驶辅助的正确使用与驾驶员状态可用性；二是把“一致性与可追溯”贯穿到从准入参数到量产再到OTA的软件全生命周期；三是把“真实边界的沟通”变成刚性约束，让消费者知道什么能做、什么不能做，不被“技术话术”带偏。

《通知》要求下，企业应该如何落地？

先说DMS与HMI的协同落地。DMS不是单点算法，而是系统工程。它的输入来自座舱摄像头、方向盘力矩、座椅占用、可能还有红外/TOF；它的输出不是“一个灯”，而是多通道联动，其中就包含语音播报、组合仪表/中控UI高亮、方向盘震动、控制器限扭限速请求、紧急靠边模块唤醒，以及对功能安全状态机的“降级/退出”指令。把这条链串起来，要求跨ECU的通信可靠、时序明确、优先级配置合理；在ASIL评估中要明确告警失效/误触发的危害等级，并给出冗余机制。需要注意的是，《通知》特别强调“不得通过用户操作或系统逻辑主动关闭”这类安全功能，这就要求在软件架构上把DMS的核心能力放在安全域内，不允许由非安全域的用户设置模块改变其生效与阈值；仅能在售后模式下经授权工具进行合法的诊断校准，并记录审计轨迹。

在网络安全方面，车企应在网关与域控制器配置IDS/IPS的基础能力，对关键CAN/LIN/Ethernet通道做白名单与速率限制，防止泛洪或异常注入；Boot过程使用安全启动与镜像签名，运行时结合可信执行环境保障关键任务；对OTA渠道进行端到端签名校验与断点续传保护，避免半包刷写造成“车端砖化”。同时，PSIRT的工作流要打通云端威胁情报、CVE/CNVD订阅、供应链通告，以及车队遥测报警，将“是否召回/是否OTA修复”纳入一个量化决策模型，其中的指标包括受影响车数、可被利用的现实性、潜在安全影响等级与补救时延。《通知》提出把“网络攻击/威胁/漏洞事件”纳入缺陷调查，就是希望企业把这套机制从“安全白皮书”搬到“真实SOP”。

再看OTA的分类与备案，这里就建议车企把OTA变更划分为“四象限”，安全相关/非安全相关×平台底座/应用层。凡是安全相关+平台底座（如通信栈、诊断服务、调度内核、底层驱动）的变更，必须走最高等级的验证闸口，其中包括静态代码分析、单元/集成/回归、硬件在环（HiL）、在环仿真（SiL/MiL）与极限工况场景模拟，且需要更高比例的预发布灰度与更长观测期。备案材料不应仅是“版本号与改动摘要”，而要包含“变更影响分析、回滚策略、已知风险与缓解、验证覆盖率证据、潜在跨域影响评估”。对“频繁OTA”进行专项核查，实质是行业希望把“追求迭代速度”的动力转成“追求迭代质量”的动力。

生产一致性的底层逻辑，是“让每一台交付车都与合格证声明的是同一台车”。这要求软件也要“可度量”。工程上可以引入SBOM（软件物料清单）与参数包签名，把“功能版本—标定版本—硬件版本—VIN—合格证申报参数”五点一线地绑定起来。售后或OTA后，车端自动生成“版本指纹”，并与云端留存的备案指纹比对，异常则触发合规告警。这类“溯源框架”不是监管的“额外成本”，而是未来应对跨域问题的“保险丝”。

在宣传治理上，技术应与法务、市场需要建立“技术校审”。每一条对外宣称的能力，都要能在规格书与验证报告里找到证据链；每一个“系统边界”的表述，都要在HMI/用户手册与App帮助中心同步；每一个功能命名，都要经过“误导倾向审查”。监管引入“技术认定”的做法，会促使企业内部建立“宣传即文档”的意识，当你说“可在城市道路点对点辅助驾驶”，你就必须同步声明“需要驾驶员全程注意并随时接管，并在遇到以下工况（具体工况）将退出”，并把“退出”做成可见、可测、可复现实验的技术条件。

事故报告与深度调查的落地，可以从三个方面去深入，一是事件记录器，把“功能启停/接管/告警/控制量/目标识别/模型置信度/传感器健康”等关键信号以环形缓冲的方式滚动记录，并在触发条件（碰撞、急制动、紧急靠边、功能异常退出）下固化；二是云端与本地的取证能力，确保合法合规的前提下，可对事故前后时段的数据进行还原分析；三是“工程复盘会议”的组织机制，把每一次上报、每一宗深度调查的发现沉淀为设计规则的改进。《通知》强调未按要求报告将公开通报与整改，以及对隐瞒或遗漏重大事实的专项核查，这些都是在“促使问题更早暴露、让改进更快发生”。

把这些要求合在一起，车企可以做几步“先手棋”。第一，要建立“安全门禁”文化，任何能影响车辆控制或用户安全感知的改动，都必须通过跨部门的安全评审，安全评审时就要考虑风险分析（包括功能安全、预期功能安全SOTIF、网络安全）、场景覆盖率报告与回滚预案等内容。第二，要建设“场景化技术”体系，对于技术的评定，不应只看传统的覆盖率指标，更看对“失效模式×场景”的覆盖，确保DMS—HMI—控制—退出—驾驶员接管这一链条在“光照极端/佩戴遮蔽物/高频振动/车道线缺失/施工/低附着”等复杂工况中的稳定性。第三，要做“OTA工程化”的下沉，这就要求把灰度发布、分域分级、快速回滚、故障安全（fail-safe）等机制固化在整个平台框架里，而不是每个域控制器各自为政。第四，搭建“宣传合规联席机制”，产品、法务、技术三方对命名、海报、发布会措辞、App文案、车机动画等做一致性把关，杜绝“技术团队知道有边界、营销团队却不提边界”的错位。第五，完善“事故处置—知识回流”链路，每一次事故，不能只是当成一个个例，而是要当作一次研发与安全的“训练样本”，要形成训练集更新、规则库更新与UI文案更新的闭环。

最后的话

当然，任何监管都会带来短期的不适应。比如备案会延长上线节奏、合规审查会推迟发布会、DMS收紧会让个别用户吐槽“使用太烦”。但从长期看，《通知》的宏观目标是“让智能化红利与安全底线兼得”。当行业把“安全优先”写进流程，把“可追溯”写进架构，把“真实边界”写进HMI与宣传，消费者对组合驾驶辅助的理解会更接近技术事实，滥用与误用也会下降，事故处置会更透明，召回会更有的放矢，网络安全会从“补洞”变为“少挖洞”。

最后，从技术角度来聊一聊《通知》意义，它其实不是要“卡住创新”，而是要“卡住不负责任的创新”。智能网联汽车的竞争，早就不是谁先在发布会上放出更炫的Demo，而是谁能把“安全、合规、可信”变成一种稳定的交付能力。《通知》把该“上交的作业”列了个目录，接下来，就看每一家企业用多快的速度、多扎实的工程把作业按质量交上来。

审核编辑 黄宇