「PPT里的L3」自动驾驶的最后一公里

PPT不交税

你先别急着鼓掌，听听台上几位老总是怎么说的。

A总眉飞色舞：我们的ADAS全国都能开、有位就能停，端到端类人智驾，L3随时准备好。B总也不含糊：第二代VLA直接代际碾压，安全接管里程翻50倍，2026年L3大年，2027年L4爆发年。C总不服：L3、L4算什么，2028年我家1000万辆搭载，起步就是L4。D总最后压轴：我们开箱即满分，一套模型跑遍乘用车、商用车、机器人。

台下掌声雷动，弹幕刷屏“yyds”。

---

平心而论，这几年的技术确实突飞猛进。端到端终结了规则堆砌的苦日子，VLA模型看场景越来越像人，世界模型让仿真也有了想象力。路测视频一个比一个丝滑，谁要说不进步，那是睁眼说瞎话。

但你有没有发现一个问题——所有人都在说“我能开到哪”，没人敢说“我敢为它担什么责”？

这不是泼冷水，那一页页华丽地跳过去的幻灯片背后，藏着的冰冷事实：现有的所有安全标准——功能安全、预期功能安全、网络安全、场景验证——都是给“能拆开、能分析、能一条条列出来”的系统准备的。而神经网络呢？拆不开、分析不了、枚举不出来。

没有代码逻辑可以追溯，没有失效模式可以列清单，没有因果回路可以画框框。UL 4600和ISO 5083倒是想兼容，但它们只会说“你自己证明自己安全吧”，至于什么样的证据算“证明完了”——对不起，标准没写，监管也不敢批。

你宣布自己实现了L3，没人想当场戳穿你，因为“安全”这个内核谁也掏不出来给你看；你说你的车用了顶级安全配置，没人有工夫能拆一辆来给你做广告。于是大家心照不宣地集体开挂：你赢麻了，我也赢麻了，发布会上一片麻。反正没人能证实，也没人真的想证实——毕竟，谁先认真，谁就输了。

那些“明年L3、后年L4”的时间表，要么理解为对标准体系一无所知，要么理解为选择性失明。而真正能落地的路，从来不是更大的模型、更聪明的世界模拟器，而是更小的ODD、更傻但更硬的安全护栏、更保守到无聊的运营策略。

2017年就排好“2021年L3、2024年L4”时间表的厂家，到了2026年的今天，L3还在个别车型的极少数路段“限量内测”，L4更是连个像样的影子都没有。L4是2024年的，PPT是2017年的，现在你来猜，哪样现在是活的？我建议大家做图的时候多配一行小字：“该目标具有前瞻性，不代表实际交付。”

那些底层的脏活累活注定上不了发布会。当你看到宣传片里“全程零接管”的丝滑画面时，没人会告诉你，背后有一群安全工程师正在为“这个算法到底算不算失效”吵得面红耳赤，正在写一份可能永远不会被认证机构盖章的报告，正在用头发换标准委员会的会议纪要。

卖车的时候，也请体谅一下他们吧。毕竟，您在台上说“L3来了”只需要一个提词器，而他们在台下证明“这玩意真的安全”，可能需要等到您儿子来接班。

两种安全‍‍

汽车行业的安全方法论，是从一百多年的工程实践中打磨出来的。它的核心信条是：你必须能够回答“为什么会出事”。一辆车刹车失灵，你可以追溯到是制动管路破裂，还是控制单元的信号丢失。（「解锁EDR」特斯拉Model 3意外加速事故调查）

这种基于因果链的追溯能力，是所有安全认证体系的基石。（「无人驾驶」vs 「太空狂热」－ 由从容不迫到最后一搏！ ｜ Part 2江湖有道 － 自动驾驶巨头「无人车安全报告」独家解析！）ISO 26262、ISO 21448 （「天网危机昨日重现」一键黑掉100万辆汽车）这些行业标准，本质上就是在为这个因果链条提供工程化的落地框架。

然而，自动驾驶试图把司机从方向盘后面拿掉，这让“回答为什么”这件事变得前所未有的困难。当一辆自动驾驶汽车在路口做出错误决策时，工程师希望像查刹车管路一样，打开日志，发现“哦，是感知模块漏掉了那辆白色卡车”，然后去改进感知算法。模块化架构被设计出来，正是为了满足这个朴素的工程需求。

但它很快撞上了天花板：模块之间的接口永远在丢失信息，规则之间不断互相冲突，你修好了一个路口的左转，另一个路口的直行就莫名其妙地出问题。更根本的困境是：真实世界的场景是开放集，而模块化系统依赖人工枚举场景和规则——当场景数量爆炸时，规则系统也必然爆炸。这个组合爆炸不是工程上能不能修的问题，而是逻辑上不可收敛的。

正是在面对这个爆炸时，技术路线的深层分歧才开始浮现。为了解决组合爆炸，人们先尝试让单个模块（如规划）从数据中学习。但一旦某个模块变得不可解释，一个更激进的问题就自然冒出来了：如果模块边界本身就在丢失信息，为什么不把感知到决策的整个链条一起学习？

这就是端到端的起点。

站在模块化路线的立场，看到的是一套经过充分验证的、可追溯的、符合现有安全认证体系的工程传统。这个立场的核心关切是可解释性和可问责性（「浪漫科技」与「古典伦理」的碰撞 － 求解无人车技术的道德困局）。从这个角度看，端到端的崛起是对工程纪律的背弃，它用一个无法解释的黑箱取代了可以被逐层审计的透明系统。

模块化立场的人会指出，汽车工业用了上百年才建立起一套基于因果链的安全论证方法，而端到端试图用统计相关性替代因果逻辑，这在本质上是危险的。（黎明前的抉择：向AutoPilot开炮，与特斯拉分道扬镳）他们会说，不是模块化走不下去了，而是行业失去了耐心——模块化需要的是系统性的场景覆盖和海量的边界案例积累，这很慢，但这是唯一被证明可行的路。

站在端到端路线的立场，看到的则完全相反。

模块化系统里那些修不完的bug、调不完的接口、互相冲突的规则，本质上不是因为工程师不够努力，而是因为人工定义的模块边界和信息格式永远无法完美捕获真实世界的连续性和高维交互。端到端不是对工程纪律的背弃，而是对模块化困境的唯一诚实回应。

这个立场的人会说，你们所谓的可解释性是虚假的——感知模块输出一个目标列表，规划模块基于这个列表做决策，听起来很清晰，但那个列表丢掉了大量信息，比如目标的姿态、纹理、上下文关系，而这些被丢弃的信息可能恰恰是决策所需要的。模块化的透明是一种幻觉，因为你只看到了你定义的那些变量，而真实世界的因果关系，从来就不在这些变量的掌控之中。

站在世界模型（「向量的极限」LeCun世界模型新秩序）和 VLA 路线（「祛魅LLM」唤醒沉睡的“目的因”）的立场，则是在端到端的困境中寻找出口。

这个立场既接受了端到端的前提——模块接口是问题的根源——又拒绝接受端到端带来的完全黑箱。世界模型的支持者认为，可以通过在表征空间中强制几何结构，让系统内部的高维状态变得可监控、可干预；VLA 的支持者认为，可以通过语言对齐让系统的决策过程变得可解释。

这两个立场都承认因果链条在端到端系统中是缺失的，但都试图用不同的方式去重建它——不是在模块层面上重建，而是在表征空间里重建，或者在语言层面上重建。

如果同时站在这三个立场上，一个迫不得已的问题就会浮现：这不是哪条路更正确的问题，因为它们对“安全”的定义底层不一致。

模块化时代的“安全”是因果链意义上的安全。你知道某个决策是怎么做出的，你知道每个环节的失效模式，你可以通过分析来论证系统在特定条件下不会出问题。这是一个从因到果的链条，它要求系统内部的状态空间是低维的、可枚举的、可解释的。

端到端时代的“安全”则是统计意义上的安全。你不再能逐个枚举失效模式，你只能通过大量的测试和数据积累来估计系统在真实世界中的失败概率，并论证这个概率低到了可接受的范围内。这是一种从果到果的论证——不追问为什么会失败，只追问失败有多频繁、有多严重。

这两种安全观在原则上无法相互归约——因果安全要求系统在逻辑上可分析，统计安全只要求系统在数据上可接受。监管机构、工程师和消费者想要的往往是前者，而开放世界的复杂性强迫我们接受后者。正是这个不可通约的张力，逼着我们去重新定义“安全”本身——不是作为一条因果链，也不是作为一个统计阈值，而是作为两者在系统不同层面上的某种杂交。

世界模型和 VLA 的介入，本质上就是在做这种杂交：在统计系统中引入物理先验和几何约束（世界模型），或引入符号接口（VLA），让统计系统部分地回归因果逻辑。两者都在努力让统计意义上的安全论证能够被监管机构接受、被工程师调试、被消费者信任。

模块化提供了因果安全的范式和可追溯的工程方法，但它无法处理真实世界的高维复杂性和连续交互；端到端提供了处理复杂性的能力，但它的统计安全范式与传统安全认证体系之间存在根本性的不兼容；世界模型和 VLA 则是两端之间的妥协物，它们试图在不放弃端到端核心优势的前提下，重新引入可解释性和可干预性。

这个妥协是否可行，目前还没有定论。

但有一点是清晰的：未来的安全框架不会是模块化或端到端的单一胜利，而是这两种认知模式在工程实践中的某种杂交。它不是谁取代谁，而是谁在什么层、什么约束条件下、以什么失效后果为代价接管控制的问题。

肯定有人会说，这个结论不太漂亮，因为它不说哪条路是对的——实际上，我对这个立场也不是很满意。但是，我的目的不是探求哪条路应该是绝对正确的，而是想探索一个更接近工程现实中复杂性的图景，它虽然不完美，但可能是目前最诚实的一种描述。

要理解为什么两种安全范式之间的冲突如此棘手，最好回到汽车工业最原始的工程直觉。

假设你是一位刹车系统的工程师。你的团队设计了一套全新的电子液压刹车系统。你不会说：“我们让这套刹车系统在试车场跑了100万公里，没有发生过一次失效，所以它很安全。”

用户不会接受这个论证。因为100万公里的无事故记录，在统计上无法证明它在下一次紧急制动时不会失灵。你需要的是一份厚厚的分析报告。这份报告要求详细列出刹车系统的每一个部件：制动踏板、助力器、主缸、轮缸、液压管路、ECU控制器、轮速传感器。

然后，你逐项分析这些部件可能以什么方式失效——比如液压管路可能因为腐蚀而破裂，ECU的电源芯片可能因为过热而短路，轮速传感器可能因为泥污而输出错误信号——这就是FMEA；对于每一个失效模式，你都要给出对策：管路用双层不锈钢加防腐涂层，电源芯片有独立的监控电路，传感器信号与另外三个轮子的信号做合理性校验——这就是ISO 26262要求的东西。最后，你的论证在逻辑上是闭环的：所有的失效模式都被列出来了，所有的失效模式都有应对方案，所有应对方案都经过了验证。

这个论证不依赖于“概率足够低”，而是依赖于“分析足够完备”。

2010年前后的丰田“非预期加速”事件，就是这种分析逻辑的一个极端注脚。（解锁封尘笔录 － 「刹不住的丰田」审判纪实！ Part 2）

调查的核心不是去争论“车主有没有踩错踏板”，而是拆开ECU，读取flash里的软件，审查代码的中断优先级和全局变量访问冲突；把传感器接到信号发生器上，注入异常的模拟信号，看系统的故障诊断会不会在要求的100毫秒内报出故障并进入安全状态。

通过仔细的分析，调查人员最终梳理出了一条完整的因果链：变量保护缺失导致关键数据不可信，堆栈溢出与递归使用导致内存越界，关键数据结构损坏导致任务调度失效，TASK X被杀导致节气门失控，看门狗形同虚设无法复位，刹车回声检查的反人类逻辑让驾驶员在特定条件下无法制动——八层因果链环环相扣，每一层都可以在ISO 26262的框架内命名、分析、追责。

这就是因果链安全的力量——你不需要猜测系统“当时在想什么”，你可以直接读出它的状态，可以通过注入故障来重现当时的场景。

现在，想象你把同样的论证逻辑应用到端到端自动驾驶系统上。你不再有明确的部件边界。你只有一个神经网络，输入是摄像头图像，输出是方向盘转角和刹车压力。你无法做FMEA，因为你不知道这个神经网络的“失效模式”是什么。它不是因为某个电阻开路而失效，也不是因为某个全局变量被意外覆盖而失效。它是由于训练数据的分布偏移、由于某个像素点的微小扰动、由于它学到了一个你完全没有预料到的相关性而失效。你可以尝试打开它的权重文件——一个包含上亿个浮点数的巨大数组——但你找不到任何“模块边界”或“失效对策”。你无法像丰田的调查那样审查中断优先级，因为你面对的是统计权重，而不是手写的C代码。

这就是统计安全不得不登场的原因。

既然你无法通过分析来证明它不会失效，你只能通过大量测试来估计它失效的概率。你会说：“我们在2000万公里的测试中只遇到了3次危险行为，所以它的失效概率大约是1.5e-7每公里，这比人类驾驶员的致死事故率还要低。”这个论证的逻辑是归纳式的——从过去的观察归纳出未来的表现。它的合法性来自大数定律，而不是逻辑必然性。（科学，是没有恒常逻辑的实践——漫谈归纳·演绎·溯因三大方法论）

问题是，大数定律要求测试样本的分布与部署环境的分布一致。而在自动驾驶中，这个假设几乎从来都不成立。你在加州测试的数据，在冰雹天的哈尔滨有用吗？你在封闭场地里测试的数据，在面对一个做出非常规手势的交警时有用吗？你不知道。你的统计论证无法回答一个根本问题：测试数据没有覆盖到的那个未知区域，系统会不会在那里出问题？

监管机构面对的就是这个困境。

UN R157是全球第一个针对L3自动驾驶的法规，它要求系统在激活时能够“安全地处理所有可合理预见的场景”。在ISO 26262的框架下，回答“什么叫所有可合理预见的场景”靠的是分析——基于物理原理的场景推导。但在端到端系统面前，分析推导失效了，因为失效模式无法被预先枚举。

UN R157的核心困境在于：尽管它提供了一套审批流程，但其核心的人类基准模型（CCDM和FSM）尚未得到充分验证，这加剧了监管机构在面对新型技术路线（如端到端系统）时的信任危机。这暴露出更深层次的问题——即便是用于界定“可合理预见场景”的参考模型本身都不可靠，那么基于这些模型来评判自动驾驶系统是否“安全地处理了所有场景”，其逻辑根基便不牢固。

根据UN R157的规定，在L3系统发出接管请求时，法规并未明确规定一个最低的、安全的接管过渡时间。这意味着，理论上系统可能在碰撞前0.1秒才发出警报，并立即将责任转移给驾驶员。这种“零秒接管”在现实中是不可能的，也让“系统担责”的承诺大打折扣。

更关键的是，车企在实践中可能会通过层层协议来规避风险。L3产品更可能会通过某些“免责协议”，本质上依然把事故责任推给驾驶员，使得L3沦为名义上的“高级辅助驾驶”。

于是你只能拿出UL 4600的安全论证框架，说：“我不走ISO 26262的分析路线了，我用另一套论证框架——我通过大量的仿真、封闭场地测试、道路测试来证明我的系统在统计上是安全的。”但问题在于，目前全球没有任何一个监管机构明确接受这种论证。

不是因为监管机构保守，而是因为UL 4600是一个“元标准”——它告诉你要写一个安全案例，但没告诉你什么样的证据才够分量。你的2000万公里够不够？还是需要2亿公里？如果测试数据覆盖了99%的场景，剩下的1%怎么办？这些都不是数学上能够给出标准答案的问题。

这就是因果链安全与统计安全之间最不可通约的那个裂缝：因果链安全 ≈ 频率学派（Frequentist）的“分析完备性”理想；统计安全 ≈ 贝叶斯学派（Bayesian）与肥尾统计（Fat-tailed Statistics）的“统计置信”现实。（《统计信仰》新书首发！）

监管机构习惯的是前者，但开放世界逼迫我们接受后者。而目前，还没有人知道这个裂缝应该怎么填补。

因果链安全中的“可解释”，在ISO 26262中被编码为“可追溯性”。这个要求不是一句空话，它对应着一整套工程实践。

标准要求你建立从需求到设计到实现到测试的双向追溯链。每一个安全相关的决策，都必须能追溯到一条明确的需求——你不能说“我觉得这样更安全”，你必须说“根据HARA分析得出的安全目标SG-03，我们推导出了功能安全要求FSR-07，然后在软件层面实现了SSR-12”。每一个代码模块，都必须能追溯到它实现了哪个安全目标。每一次测试，都必须能追溯到它验证了哪个安全需求。

这种追溯性不是为了让人“更好理解”系统在做什么，而是为了让第三方审计能够独立验证：我不需要信任你的工程师有多聪明，我只需要检查你的追溯矩阵是否完整。如果某个安全目标没有对应的测试用例，或者某个代码模块没有对应的安全需求，那就是不合规。这不是一个技术判断，这是一个管理判断——而管理判断是可以被审计、被复核、被追责的。

AUTOSAR在工程层面支撑了这种可追溯性。它标准化了模块之间的接口，定义了明确的输入输出格式：感知模块输出的目标列表有固定的数据结构，里面包含位置、速度、加速度、类型标签；规划模块输出的轨迹有固定的数据结构，里面包含一系列路径点和时间戳。因为接口是固定的，所以每一个模块都可以被独立开发、独立测试、独立替换。

你可以单独测试感知模块，给它输入合成的摄像头图像，检查它输出的目标列表是否正确，而不需要依赖规划模块是否存在。你可以单独测试规划模块，给它输入人工构造的目标列表，检查它输出的轨迹是否满足安全约束，而不需要真实的传感器数据。这种模块独立性不是工程上的奢侈品，而是可审计性的前提。

如果模块之间没有明确的契约，你就无法证明“这个模块是对的”，因为你永远不知道它出错是因为自己的算法问题，还是因为上游给了它错误的数据。

丰田非预期加速事件的调查之所以能够进行，正是因为有这种可追溯性。调查人员不需要猜测电子节气门控制系统“当时在想什么”。他们拆开ECU，读取flash里的软件，然后逐行审查代码。他们发现变量“目标节气门角度”没有镜像保护，他们发现系统使用了递归函数而堆栈溢出的风险评估是错的，他们发现关键数据结构紧挨着通用堆栈存放而且没有任何保护措施，他们发现看门狗不是用来监视任务存活性而是用来防止CPU过载的。

每一个发现都可以追溯到具体的代码行，每一个缺陷都可以被单独注入、单独验证、单独归因。这就是因果链安全的可审计性——你不需要依赖统计推断，你可以直接打开黑箱，看到里面每一个齿轮的运转。

现在，把同样的可审计性要求应用到端到端自动驾驶系统上。

你面对的是一个神经网络。它的输入是摄像头图像，输出是方向盘转角。你想知道：在某个具体的场景中，它为什么会做出转向决策？是因为它看到了那辆白色卡车，还是因为它误判了道路曲率，还是因为某个像素点的微小扰动被放大了？你不知道。你可以尝试打开它的权重文件——一个包含上亿个浮点数的巨大数组——但你找不到任何“模块边界”或“决策分支”。没有if-else语句，没有函数调用栈，没有可以单独测试的子模块。整个决策过程被压缩在矩阵乘法、激活函数和统计权重之中，没有一行代码是可以被单独审查的“逻辑”。

这不是一个“技术可以解决”的问题，而是一个“范式不兼容”的问题。ISO 26262的追溯链要求每一个安全决策都能追溯到一行代码或一个硬件组件。但在神经网络里，安全决策不是由某一行代码做出的，而是由整个权重分布共同决定的。你无法说“这个神经元的激活导致了危险决策”，因为那个神经元的激活本身又依赖于前面一万个神经元的激活。你可以用归因方法（如SHAP、LIME）估算每个输入像素对输出的贡献，但这些方法给出的是相关性，不是因果。而且，不同的归因方法可能给出完全不同的结论——你选哪个？凭什么选那个？

AUTOSAR的模块化接口在这里同样失效。端到端系统没有“感知模块输出目标列表”这个中间层。它直接从像素映射到控制信号，跳过了所有人类可读的中间表征。你不能单独测试它的“感知能力”，因为你没有一个独立于规划的标准来判断它的感知是否正确——它的感知和规划是纠缠在一起的。

一个误判可能是因为感知错了，也可能是因为感知对了但规划逻辑在那种情况下做出了错误选择。在模块化系统中，你可以通过固定规划部分的输入来单独测试感知；在端到端系统中，你做不到。

UL 4600意识到了这个问题，因此它不要求你提供模块化的追溯链。它要求你提供“充分的证据”来支持你的安全主张。但这个“充分”是什么意思？如果你说“我们在1000万公里的测试中没有发生事故”，审计者可以反驳：1000万公里在统计上不足以证明安全，因为致命事故的概率可能是每1亿公里一次。

如果你说“我们覆盖了ISO 34502定义的所有场景”，审计者可以反驳：那些场景是基于物理原理推导出来的，适用于模块化系统，但端到端系统的失效模式可能来自表征空间的畸变，根本不是那些场景能够捕捉到的。如果你说“我们的模型在多个公开数据集上达到了State Of the Art的精度”，审计者可以反驳：精度不等于安全，一个在分类任务上99.9%精度的模型可能在那个0.1%的corner case上完全失效。

这就是统计安全面临的可审计性困境。

在因果链安全的那套体系里，审计者的工作很简单：手里拿着一份硬性清单，逐条打钩。追溯矩阵完整了吗？FMEA覆盖全了吗？测试达标了吗？每一项都能用“是”或“否”来回答，谁来做结论都一样。

但到了统计安全这里，清单没了。审计者面对的是一个开放问题：“你觉得证据够不够？”这个答案全看个人立场。一个对端到端技术不信任的人，永远会觉得不够，因为理论上总有没测到的场景；而一个乐观的人，可能觉得1000万公里就够了。问题是，监管机构不能依赖个人感觉，它需要的是可重复、可量化、可辩护的标准——而这样的标准，目前还不存在。

如果非要硬在统计安全上搞“打钩审计”，那钩就不能打在“系统是否安全”上，因为没人能回答这个问题。只能打在流程上：你有没有按公认的统计规范做测试？样本量够不够行业标准？置信区间的下限有没有低于某个阈值？审计者不再判断“证据够不够”，只判断“过程对不对、报告规不规范”。钩还是能打，但打的是“流程合规”的钩，而不是“系统安全”的钩。这跟因果链那套“用流程保安全”的思路其实一脉相承，只不过这时已经没人敢公开说“流程合规就等于安全”罢了。

UL 4600也解决不了这个难题。这不是标准的缺陷，而是统计安全范式本身的特征——它注定无法像因果链那样，给出一个让所有人都闭嘴的黑白答案。

统计推断（「失落的记忆」统计推断三叉戟）的本质就是用不确定性换取代价。你放弃了“绝对安全”的承诺（因为你知道你永远无法证明它），换来了“在现有数据下表现足够好”的实用方案。但对于监管机构来说，“不确定性”是一个很难被接受的概念。它们被授权在“安全”和“不安全”之间做出二元判断，而不是输出一个概率分布。它们需要的是可以写进法规的硬性标准，而不是“我们觉得差不多够了”的主观判断。

这就是为什么迄今为止，全球没有任何一个监管机构明确接受纯端到端系统的安全认证（中国在2025年底已经批准了首批L3准入车型，虽然这些车型未必是纯端到端，但监管口径也可能发生变化）。不是因为技术不成熟，而是因为审计框架本身还没有准备好面对一个不接受可追溯性检验的对象。

因果链安全中的失效归因，被ISO 26262的“故障模型”所支撑。这个模型的核心假设是：系统的失效可以追溯到某个具体的、可命名的故障。

标准定义了硬件故障——短路、开路、漂移、比特翻转。它还定义了软件故障——数据错误、时序错误、资源冲突、死锁。每一种故障模式都有明确的工程定义。当一个ECU因为电源芯片过热而输出错误信号时，你可以说：“故障是电源芯片的热过载。”当一个全局变量被两个任务同时写入而导致数据不一致时，你可以说：“故障是资源冲突，缺少互斥锁保护。”——这些故障模式是可以被提前枚举的，每一种都有对应的安全机制：温度监控电路会在过热时触发降级，操作系统提供互斥锁来保护共享资源。

当系统失效时，你打开诊断日志。日志里记录着：哪一刻，哪个故障被检测到了，系统进入了什么安全状态。这就是可归因性。你不必猜测“系统当时在想什么”，因为系统自己会告诉你它哪里不舒服。你可以精确地定位到是哪个部件、哪个变量、哪一行代码出了问题，然后针对性地改进对应的安全机制。

这个过程是系统性的、可重复的、可验证的。每一次事故都转化为一个具体的工程问题，每一次修复都可以被单独测试和验证。你在下一次设计中复用这个经验——不是作为一个模糊的教训，而是作为一个明确的约束：“变量X必须有镜像保护，函数Y的复杂度不能超过30，堆栈使用率在任何情况下不能超过70%。”

STPA提供了另一种归因方法。（无人车安全之战 — AI觉醒的前夜，人类还在沉睡？）

它不关注部件失效，而是关注“控制回路中的约束被违反”。这个方法在处理复杂交互问题时比传统的FMEA/FTA更有效。

在丰田非预期加速事件中，STPA视角会发现：不是某一个部件坏了导致事故，而是整个控制回路的设计没有施加正确的约束——监控CPU没有独立于主CPU的任务存活性检测机制，看门狗没有被配置用来监视关键任务的执行周期，刹车回声检查程序的条件逻辑让驾驶员在特定时刻无法获得制动能力。

这些不是“部件故障”，而是“约束缺失”或“约束被违反”。

STPA能捕捉到“模块都没坏，但组合在一起就出问题了”这类涌现性失效——这正是模块化系统在面对复杂交互时最容易出问题的地方，也是传统FMEA很难覆盖的地方——STPA目前虽然还不是ISO标准，但已经学术界和部分领先企业中受到重视。

现在，把同样的归因框架应用到端到端系统上。这就立即触发了一系列的新问题：

你没有故障模型——因为你没有模块。

你不知道这个系统的“部件”是什么——神经网络里的每一个神经元、每一个权重、每一层，这些划分在工程上没有意义，因为系统的行为不是由单个神经元或单层决定的，而是由整个权重分布共同涌现出来的。

你没有“故障模式”的枚举列表——因为你根本不知道这个系统可能以什么方式失效。它不是像电源芯片那样“过热就会输出错误信号”，它是“在某些你无法事先描述的条件下，输出会偏离预期”——而这个“某些条件”可能是像素级的微小扰动，也可能是训练数据中没有充分表征的某种场景特征。

你没有控制回路分析——因为你没有一个可识别的“控制器”。在传统系统中，控制器是一个明确的模块：它接收传感器输入，根据预设的逻辑计算出控制输出。在端到端系统中，整个网络就是控制器，但这个控制器没有内部状态是你能够解读的。

你不知道它的“控制律”是什么——它不是写在代码里的PID参数，而是分布在亿万权重中的统计规律。你可以输入数据，观察输出，但你不能问它“你为什么做出这个决策”，因为它没有内置的解释机制。你能做的，只有分析输入和输出之间的相关性。

你可以用SHAP值计算每个输入像素对输出方向盘转角的贡献，画出一张热力图，看到“这个区域的像素对决策的影响最大”。你可以用LIME训练一个局部可解释模型来近似网络在某个邻域内的行为。但这些都是相关性，不是因果。SHAP值告诉你“这个像素的值与输出之间存在统计关联”，但它不能告诉你“如果这个像素的值不同，输出会如何变化”——因为网络的决策边界是非线性的，局部的相关性不能外推到反事实场景。（「自然之殇」缺失实在性的因果之惑）

模块化系统的问题是：虽然每个模块内部是透明的——感知模块输出了目标列表，规划模块基于这个列表做决策，逻辑链条清晰可追溯——但模块之间的接口是死的。感知模块丢掉的信息（比如目标的姿态、纹理、上下文）可能恰恰是规划模块需要的。你修好了一个路口的左转，另一个路口的直行莫名其妙就坏了。它的“说不清”不是看不见，而是看见了也没用——规则之间互相打架、接口丢失信息，整个系统像一台齿轮咬合永远有毛病的机器。

端到端系统的问题正好反过来：它的内部你根本看不见。你不知道它为什么在那个路口左转，你只知道它转了。归因工具（SHAP、LIME这些）倒是能拿来用，但它们给出的答案互相打架——SHAP说A重要，LIME说B重要，Integrated Gradients说C重要。你信哪一个？凭什么信？这些工具本身就不靠谱。

于是你陷入了一个两头堵的尴尬：用模块化，规则和接口的组合爆炸，Bug你永远修不完。用端到端，黑箱打不开，归因工具又自卖自夸，你根本没法回答“为什么会出事”。

这就是ISO 21448（SOTIF）在2022版中做出那个著名声明的原因：对于AI/ML驱动的功能，传统的SOTIF方法“不直接适用”——这几个字的真正含义不是说FMEA、FTA这些工具需要调整，而是它们压根就不是设计来对付神经网络的。因果链分析要求你能拆开系统、枚举失效模式，但端到端拆不开、枚举不了。2025修订版想塞进数据驱动的方法来补救，但数据驱动和原理驱动是两套逻辑，硬凑在一起，至今没人知道怎么收场。

整个功能安全社区花了十年时间建立起来的归因方法论，在端到端系统面前，突然失去了适用对象。不是方法不够好，而是方法的底层假设——系统可以被分解为可命名的部件，失效可以追溯到具体的故障——在涌现系统面前不成立了。

说端到端系统无法被归因并不确切，应该说，归因的方式需要被彻底改变——不是在模块层面归因，而是在表征空间层面归因；不是问“哪个模块坏了”，而是问“表征在哪个区域发生了漂移”；不是用故障树，而是用概率图模型和反事实推断。

学术界正在探索这些方向——表征空间监控、形式化验证与神经网络的结合、基于贝叶斯推断的因果归因——但没有一个写入了正式标准，也没有一个在量产项目中得到大规模验证。

这不是一个方法论的问题，这是一个范式迁移的问题。模块化时代的归因方法用了三十年才成熟。端到端时代的归因方法，可能需要下一个三十年。而在这三十年里，工程师们只能站在裂缝中间，一边用旧工具分析不适用它的系统，一边等待新工具的出现。这个等待期，可能比任何人愿意承认的都要长。

业界普遍对因果链安全处理未知的方式，是通过ISO 34502的结构化场景设计实现的。

这个标准的核心方法是“物理原理驱动”：你不是开着车在路上随机跑，指望运气碰到问题，而是坐在会议室里，基于物理原理系统性地推导出“可能出错的场景”。

感知模块的干扰来自传感器物理特性。摄像头依赖可见光，所以它怕强光直射、怕夜间低照度、怕水面反光。毫米波雷达依赖电磁波反射，所以它怕多径反射、怕其他雷达的相互干扰。LiDAR依赖红外激光，所以它怕雨雪吸收信号、怕灰尘散射——这些不是从事故数据里统计出来的，而是从物理课本里读出来的。

因为光的直线传播、电磁波的反射特性、大气对特定波长的衰减——这些物理规律是普适的、不变的、不依赖于你收集了多少数据的。所以你可以论证：所有感知层面的干扰，都来自这些物理原理，而你已经把它们全部列出来了。

这就是完备性的来源——不是因为你跑了一百万公里没出事，而是因为你知道物理学不允许出现其他类型的干扰。

规划模块的干扰来自交通交互模式，ISO 34502定义了24个高速场景，通过道路几何（非交叉路段、合流区、分流区）、自车行为（车道保持、变道）、对手车行为（切入、切出、加速逼近、减速阻碍）三个维度的系统组合生成。SAKURA V4.0把这个框架扩展到了58个车辆交通干扰模式和8个弱势道路使用者模式。

这些场景不是从数据里聚类出来的，而是从驾驶任务分解中推导出来的。

你把动态驾驶任务拆成感知、规划、控制三个过程，然后问：在每个过程中，什么东西会干扰它正常工作？感知的干扰来自物理世界，规划的干扰来自其他交通参与者的行为模式，控制的干扰来自车辆动力学。这套分解的逻辑是封闭的——如果你接受了这个分解，那么你接受的就是这个分类体系。

这就是“原理驱动”方法的核心优势：你可以论证场景集合的完备性。你能说清楚为什么这些场景就够了，不需要依赖数据告诉你还有什么场景。不是说数据没有用——数据可以用来确定场景参数的分布（比如切入角度在5°到30°之间，相对速度在10到40公里每小时之间）——但场景的类型结构不是数据告诉你的，而是物理学和驾驶任务分解告诉你的。

这意味着即使你没有任何事故数据，也能设计出一套合理的测试场景——这在航空、航天、核电等安全关键领域是标准做法——你不会等到坠机了才知道“哦，原来发动机在高空结冰会出问题”，你是在设计阶段就从物理原理推导出这个可能性，然后设计对策。

现在，把同样的方法应用到端到端系统上。

你会突然发现，你不知道失效出现在哪个“环节”——因为你根本没有环节。端到端系统没有感知模块和规划模块的边界，它的内部状态是一个高维的表征空间，你不知道这个表征空间里哪些区域对应“感知错误”、哪些区域对应“规划错误”、哪些区域对应“控制错误”。

传感器的物理特性当然还是会影响输入——强光仍然会让摄像头图像过曝，雨雪仍然会衰减LiDAR信号——但这些干扰不是只在“感知环节”产生影响，它们可能被网络的深层表征以你无法预料的方式放大、扭曲、重新解释。

一个在模块化系统中只会导致感知置信度降低的雨雪噪声，但在端到端系统中可能导致网络输出一个完全不可预测的控制信号——因为你没有中间的语义层来缓冲这种干扰。更重要的是，你无法像ISO 34502那样“系统性地推导”出端到端系统的失效场景——因为你不知道失效的物理原理是什么。

模块化系统的失效可以追溯到传感器物理特性或交通交互模式，这是物理定律层面的原因。但端到端系统的失效可能来自表征空间的几何畸变、训练数据的分布偏移、某个特征维度的过度激活、或者多个因素的非线性耦合——这些不是物理定律，而是高维统计现象。

它们没有简洁的物理描述，你不能在会议室里推导出“在这个场景下网络会失效”，因为你连网络内部在做什么都不知道。你只能通过大量测试去发现失效，然后试图归纳出规律。但归纳出来的规律不是普适的——网络更新后，规律可能就变了。

这就是统计安全处理未知的方式：依赖数据覆盖。

你不再试图从原理上推导出所有可能的失效场景，你转而依赖大规模自然驾驶数据来“覆盖”真实世界的分布。你采集上千万公里的数据，从中提取场景参数的真实分布，然后用这些分布来指导仿真测试和封闭场地测试。这里的理论基础是：如果测试数据的分布覆盖了部署数据的分布，那么统计推断就是有效的——即系统在测试集上的表现可以外推到部署环境。可问题的关键是：你无法证明覆盖。

你可以说“我们采集了2000万公里，覆盖了大部分常见场景”，但“大部分”不是监管机构能接受的安全论证。“大部分”意味着还有一部分你没有覆盖到，而你不知道那一部分里藏着什么。

正如前文所述，ISO 21448的2025修订版纳入数据驱动的补充方法，试图在SOTIF框架内为AI/ML功能提供指导。但目前的现实是：传统SOTIF的方法是“基于场景的”，而AI/ML的验证需要“基于数据的”——两者方法论基础不同。

前者要求你事前枚举场景，后者承认你无法枚举，只能用数据去“覆盖”。这不是一个技术问题，这是一个认识论问题：你能否通过有限的样本来论证一个无限状态空间中的系统是安全的？

统计学的答案是：只有在样本分布与部署分布一致的假设下才能。而自动驾驶的部署环境，偏偏是那个分布永远在变化、永远无法被完全采样的开放世界。（「余厄未绝」关于肥尾的预测悖论）

ISO 5083在2025年发布，试图在两者之间架桥。它要求自动驾驶系统的设计、验证和确认流程同时考虑“基于场景的方法”和“基于数据的方法”。但它没有给出如何结合的细节。这不是标准的缺陷，而是因为目前没有人真正知道如何结合。

你可以先做场景分析，然后用数据来填充参数分布；你也可以先做数据驱动的场景挖掘，然后用物理原理来验证挖掘出的场景是否合理。这两种顺序都有道理，也都有问题。

遗憾的是，行业标准在这里的角色不是给出答案，而是只是承认问题的存在，并提供一个框架让行业去探索。这就是2026年的真实状态：原理驱动的方法让你能够论证完备性，但它处理不了端到端的涌现行为；数据驱动的方法让你能够处理复杂性，但它无法证明覆盖。

两者都需要，两者都不够。而如何将它们结合起来，还没有现成的答案。

因果链安全对复杂度的容忍度，受到AUTOSAR架构的刚性约束。

AUTOSAR的分层设计（应用层、运行时环境、基础软件、微控制器抽象层）的本意，就是管理复杂度。AUTOSAR把一个庞大的软件系统拆成四层，每层之间用标准化的接口通信，这样不同的模块可以由不同的供应商开发，可以独立测试、独立升级、独立替换。

这在工程管理上是巨大的进步，但它也带来了一个固有限制：模块之间的接口必须是静态定义的。所谓的“静态定义”？就是在编译时就知道的，在设计时就写死的。感知模块输出什么数据结构，规划模块输入什么数据结构，这些都要在开发阶段就确定下来。你不能在运行时突然说“今天我想传递一个特征图”，因为规划模块根本不知道特征图是什么格式。你不能动态地改变信息流动的拓扑结构，比如“今天路况复杂，我们绕开规划模块直接让感知控制执行”。

在AUTOSAR的世界里，信息的路径是修好的高速公路，不是可以随意改道的乡村土路。

当场景变得足够复杂时，这种静态接口就成了瓶颈——感知模块在通往复杂路口时，希望传递给规划模块的不只是一个目标列表，而是整个场景的语义理解——“那辆车在减速，但它的刹车灯没亮，可能是因为它在溜车，也可能是因为它的刹车灯坏了，也可能是因为...”——但这些细粒度的信息没有定义在接口里，因为你在设计时根本不知道你需要传递这些信息。你只能传递你在设计时预见到需要传递的信息，但你无法预见到所有的需要。

这就是“未知的未知”在架构层面的体现：不是你不知道某一类场景的存在，而是你的架构根本就没有预留传递这类场景信息的通道。

除此之外，ISO 21434（网络安全）也增加了另一层复杂度约束——它要求你分析系统的攻击面，识别潜在的网络安全威胁，并设计相应的防护机制。在模块化系统中，这通常是可行的，因为攻击面是有限的——你只需要保护那些公开的接口。

你知道攻击者可能通过CAN总线注入恶意消息，所以你给CAN总线加认证；你知道攻击者可能通过OTA更新植入恶意代码，所以你给固件签名。攻击面是你可以枚举的，因为系统的边界是清晰的。（「天网危机昨日重现」一键黑掉100万辆汽车）

但在端到端系统中，攻击面是整个输入空间。你不是在保护几个公开的接口，你是在保护一个高维连续空间。攻击者不需要攻破你的通信协议或签名机制，他只需要在停车场的路面上贴几张对抗性贴纸——你的神经网络就把停车标志识别成限速标志了。这不是理论上的威胁，这是已经被大量论文证明的实战漏洞。（无人车的未来有什么看不到的？你仔细看看，可凄惨了）

在模块化系统中，这种攻击会被感知模块的输入校验挡住吗？如果你根本没定义“输入校验”这个模块呢？对抗性攻击的本质是利用了神经网络决策边界的局部不连续性——微小的人为扰动可以导致输出剧烈变化。

目前没有任何标准能告诉你如何为一个纯神经网络系统做网络安全论证，因为论证的前提是你能够枚举攻击面，而在这里你做不到。

统计安全在这个角度上反而有优势，因为它的核心就是不拆分系统。即端到端系统的复杂度可以无限增长而不增加“接口复杂度”，因为接口始终只有一个：传感器输入和控制输出。你不需要在设计时预见所有需要传递的信息，因为信息根本就没有被“传递”——它在整个网络中流动，没有任何人工边界阻断它。

你可以增加网络的深度，增加隐藏层的维度，增加注意力机制，增加记忆模块——复杂度可以一直涨，但接口还是那两个：输入和输出。这就是端到端架构在复杂度管理上最优雅的地方：你把复杂度吸收到了网络内部，而不是让它暴露在模块接口上。

但问题是，你把复杂度吸收到网络内部之后，你就失去了对系统行为的控制。你不知道网络内部发生了什么，你不知道它学到了什么，你不知道它会在什么条件下失效。你能做的，不是分析它，而是约束它。

你给它加一个安全护栏——一个独立于神经网络的监控模块，当网络的输出超出安全边界时，强行覆盖。你给它加运行时监控——在表征空间里监测异常激活，当网络进入它没见过的区域时请求接管。你给它加地理围栏——只在它被充分测试过的区域内激活。你给它加运行设计域限制——只在满足特定条件（天气、光照、道路类型）时启用。这些都是外部约束，不依赖于对网络内部的理解。

ISO/PAS 8800试图为AI系统的安全提供指导，但它还非常早期。

它承认了AI系统的特殊性——不可解释、不可分析、不可预测——但它还没有给出具体的工程方法。它说的是“你应该做这些事”，而不是“你应该这样做”。这不是标准的错，是因为整个行业都还不知道“这样做”应该怎么做。

目前最务实的方法是UL 4600的“论证框架”。它不要求你用特定方法，只要求你提出一个完整的安全案例——你要论证你的系统为什么是安全的，不管你是用分析、测试、仿真、形式化验证，还是用其他什么方法。

对于端到端系统，这意味着你需要证明：即使你无法分析系统内部，你也能通过外部约束来确保安全。

你的论证结构大致是这样的：我们定义了严格的ODD，只在地理围栏内的特定天气条件下激活；我们设计了独立于神经网络的安全护栏，监控方向盘转角和刹车压力的合理性；我们部署了运行时异常检测模块，在表征空间中发现不确定性过高时主动降级；我们做了海量的仿真测试和道路测试，覆盖了ODD内的场景分布。

这个论证框架在逻辑上是自洽的。问题在于，监管机构是否接受？目前全球还没有一个先例。不是因为监管机构不开放，而是因为他们需要为这个“接受”负责——如果他们接受了你的论证，就意味着承认“统计证据可以替代分析证据”，承认“外部约束可以替代内部可解释性”，承认“ODD限制可以替代完备性论证”。

每一个承认都是一个先例，每一个先例都可能被下一个申请者要求沿用。监管机构不敢轻易开这个口子，因为他们不知道这个口子开大了之后，安全标准会滑向哪里。

这不是UL 4600的问题，也不是监管机构的问题，这是统计安全范式本身的问题。你放弃了“绝对安全”的承诺，换来了“在受限条件下统计上安全”的实用方案。但对于监管机构来说，“受限”和“统计”是两个很难量化的词。

什么样的限制算足够严格？什么样的统计量算足够高？这些问题的答案，不是数学能给出的，是社会共识能给出的。而社会共识的形成，需要时间，需要案例，需要一次次的博弈和妥协。我们需要更多的耐心。

至此，我们似乎有了一个标准体系，首先是模块化世界里的三板斧：ISO 26262、AUTOSAR、ISO 21434。

功能安全要求你做HARA，你就做HARA；要求你做FMEA，你就做FMEA；要求你建立追溯矩阵，你就建立追溯矩阵。AUTOSAR给你定义了模块接口，你就按接口开发。网络安全要求你分析攻击面，你就列出CAN总线、OTA更新、诊断接口，然后一个一个加防护。

这套流程已经跑了十几年，咨询公司有现成的培训课程，认证机构有现成的审核清单，工程师有现成的模板可以套用。它不简单，但是路径非常清晰——你知道要做什么，你知道怎么做，你知道怎么证明你做完了。

在三板斧的基础上，ISO 34502和SAKURA提供了进一步的场景方法论，你从感知、规划、控制三个过程出发，基于物理原理推导干扰因素，然后系统性地生成场景。感知层你考虑强光、雨雪、多径反射；规划层你考虑24个高速场景、58个车辆模式、8个VRU模式；控制层你考虑湿滑路面、侧风、轮胎衰减。

这套方法的边界是清晰的——它覆盖的是“基于物理原理可推导的失效模式”。在模块化系统中，这恰恰是失效的主要来源，所以它的适用性很强。

但在端到端世界里，这套方法不灵了——你突然面临“不知道失效在哪个环节”的困境。端到端系统的失效不一定来自传感器物理极限或交通交互模式，它可能来自表征空间的几何畸变、训练数据的分布偏移、特征维度的意外耦合——这些都不是物理原理层面的失效，而是统计学习层面的失效。

而ISO 34502的语境下，没有对应的框架。UL 4600和ISO 5083试图提供一个超越具体方法的论证框架。但它们却不告诉你用什么方法——它们只会说大话，要求你提出一个完整的安全论证。

理论上，这种元标准可以兼容任何技术路线——模块化也好，端到端也好，混合架构也好，只要你能拿出证据，它都认。但问题是，监管机构还没有点头。

不是因为监管者不认可UL 4600的逻辑，而是因为他们需要为自己的认可负责。UL 4600说“你的论证要充分”，但什么叫“充分”？在ISO 26262的世界里，答案是清晰的：追溯矩阵完整，测试覆盖率达到要求，故障模式全部识别。在UL 4600的世界里，答案是不清晰的。监管机构不知道自己的审核员应该用什么标准来判断一个安全论证是否“充分”，不知道如何培训审核员，不知道如何应对被拒企业的申诉。

这不是UL 4600的缺陷，而是任何元标准在落地时都会遇到的问题——它把判断的责任从标准制定者转移给了标准使用者，而使用者还没有准备好承担这个责任。

ISO 21448（SOTIF）已经承认AI/ML不在它的适用范围内。这句话写在2022版的附录里，措辞很克制，但含义很沉重。

SOTIF诞生的初衷就是处理“非故障但不安全”的场景——那些不是部件坏了，而是系统在复杂环境中做出了错误判断的情况。这正是端到端系统最容易出问题的地方。SOTIF的方法论基于场景的分析、基于物理原理的干扰识别、基于参数的边界测试——这些假设你可以分解系统、可以枚举失效模式、可以建立因果链。

而在端到端系统面前，这些假设不成立。标准不是不想覆盖，而是覆盖不了。它只能承认自己的局限，然后等待新的方法成熟。这个等待期，可能是五年，可能是十年，没人知道。

至于ISO/PAS 8800，就更早期了——它是2024年发布的，但它的内容基本上是框架性的指南——“你应该考虑AI系统的特殊性”“你应该做数据质量管控”“你应该做分布偏移检测”——但这些“应该”都不是具体的工程方法。

你不能拿着一份PAS去跟认证机构说“我符合了”。它离ISO 21448那种“你可以照着做的标准”还有很远的距离。这不是因为编写标准的人不努力，而是因为整个行业对“怎么验证一个神经网络是安全的”这个问题还没有共识。没有共识，就写不出标准——标准是实践的沉淀，不是实践的先锋。

无人车这个战场不是技术路线之争，而是一套已经写了三十年的标准体系被迫面对一个它从未设想过的对象。

ISO 26262的第一版是2000年之后才成型的，但它的思想根源可以追溯到更早的航空和核电安全标准。这套体系花了三十年，才打磨成一个相对完备、可操作、可认证的框架。它假设系统是分解的、可分析的、可枚举的。它假设失效可以被归因。它假设因果关系是线性的、可追溯的。

这些假设在传统汽车电子领域基本成立，在模块化自动驾驶系统中勉强成立，但在端到端系统面前，它们不成立了。不是标准写错了，是技术走了一条标准没有预见到的路。标准的修订速度跟不上技术的迭代速度。一个标准的修订周期是三到五年，而端到端技术从论文到量产只用了不到两年。工程师们只能在标准还没有覆盖的灰色地带中摸索前行。

他们在ISO 26262的框架里写端到端系统的合规报告，把神经网络包装成“一个模块”，给它分配ASIL等级，做FMEA，建立追溯矩阵——做这些事的时候，所有人都知道这是在用一个不适用于对象的工具，但这是唯一能走通认证流程的方式。这是工程实践中常见的“合规性表演”，不是因为它虚伪，而是因为没有更好的选择。

我们正在见证一套安全范式如何（或是否能够）适应涌现系统的挑战。这个过程没有先例可循。汽车行业过去没有遇到过不可分析的组件，航空行业没有，核电行业也没有。

这是第一次，安全关键系统引入了一个内部状态无法被人类理解、失效模式无法被预先枚举、行为无法被因果链解释的组件。这个组件的名字叫神经网络，而它正在从感知扩散到规划，从规划扩散到控制，从辅助功能扩散到主控功能。

回顾历史上那些各家画的“安全大饼”——Waymo SSP给了一份厚达43页、五维齐全却找不到及格线的菜单，Mobileye RSS则用一套数学上完美但现实中假设过强的公式把自动驾驶算成了不敢动窝的路障，Voyage OAS以开源理想开场却在公司被收购后沦为无人维护的数字废墟，百度APC打包了接管冗余RSS的所有卖点却连自己的量产车都没等来。

它们共同证明了同一件事：在自动驾驶这个行当，PPT上的安全框架，远比跑在路上的安全产品更长寿。

尽管一切都还没有定论。可以确定的是，ISO 26262暂时不会消失，模块化系统还会存在很长时间，传统安全论证方法在它适用的领域内仍然有效。端到端也不会消失，因为它处理复杂场景的能力是模块化系统无法比拟的。UL 4600和ISO 5083提供了一个让两者共存的论证框架，但它的可操作性还需要时间来打磨。ISO 21448会慢慢扩展它的边界，把数据驱动的方法纳入进来。ISO/PAS 8800会逐步成熟，变成可工程化的标准。

所有的标准都是在动态演化的，因此你很难现在就讲清楚谁必将取代谁——这没有任何意义，目前的主要矛盾，是两套范式、两套方法论、两套安全哲学在同一个工程体系中寻找共存方式的过程：因果链安全负责那些“可以被分析的”部分——安全护栏、运行时监控、ODD限制、故障检测与响应；统计安全负责那些“只能被统计的”部分——端到端模型的训练、验证、分布监控。

两者不是取代关系，而是在系统的不同层次上各司其职。谁在什么层、什么约束条件下、以什么失效后果为代价接管控制——这个问题的答案，需要未来的标准能给出，需要工程师在每一个具体项目中，根据安全目标、失效后果、可用数据和计算资源，做出具体的权衡和判断。

自动驾驶虽然是新概念，但却是人类如何用旧世界的工具箱去应对新世界的周期性循环问题。工具箱不够用，我们就发明新的——但又不敢真的用，因为用错了要负责。于是大家集体表演“我们在努力”，然后各回各家，各找各妈。

这就是2026年自动驾驶安全的真实图景：没有标准答案，只有权衡。显然这不是一个让那些断言L3/L4马上就要实现的人舒服的结论，但目前来看，这就是现实。

https://github.com/lostinet/Finance-at-a-loss

在混沌之中，包含了惊人的新秩序。