驾驭自动驾驶系统的未来：人工智能时代的安全性、伦理与问责制
如果你问一群正在开发自动驾驶感知堆栈的工程师，他们对电车难题（Trolley Problem）有何看法，你通常只会得到他们疲惫的表情。这个问题本身确实很重要，但它并不是摆在他们面前实际工程问题的正确模型，而且解释其中的原因所花费的时间，远超大多数晚宴谈话所能容忍的限度。
自动驾驶系统安全挑战的真实版本远没有哲学上的戏剧性，却在数学上更加艰巨：在传感器噪声、遮挡和延迟下的概率感知，被输入到一个必须在连续动作空间中优化奖励函数的决策流水线中，且循环中没有任何清晰的二元选择。正确处理这种工程现实，并围绕它构建标准和问责框架，是一个比任何思想实验都更困难、影响更深远的问题，它理应得到相应的对待。
第 1 部分：为什么电车难题无法作为工程规范
电车难题假设了一个现实中任何自动驾驶系统都不具备的前提：确定性的世界、完美的状态知识、清晰的二元选择以及对结果的确定性。实际自动驾驶车辆的感知堆栈从不具备这些条件。它面对的是嘈杂的激光雷达（LiDAR）回波、因雨水或低太阳角而退化的摄像头画面、停放卡车后的遮挡，以及对周围环境的概率信念状态，而非绝对真值。
引擎盖下实际运行的内容
真正的自动驾驶车辆之所以依赖部分可观测马尔可夫决策过程（POMDP）和强化学习等形式化框架，正是因为世界本质上是部分可观测的。系统并非在两个预定的命运之间做出选择。它是在连续动作空间中进行采样，组合出数十种合理的转向角和加速度，并在对行人、迎面而来的车辆或骑行者未来两秒行为的真正不确定性下，针对围绕碰撞规避和注意义务阈值构建的奖励函数来优化预期结果。将自动驾驶汽车编程为“解决”电车式困境，并不是真实工程任务的简化版。它完全是在解决另一个问题，一个在思想实验所假设的形式下根本不会发生的问题。
道德机器实验与众包伦理为何是个陷阱
麻省理工学院的“道德机器”（Moral Machine）实验收集了数百万条关于假设性自动驾驶汽车碰撞场景的众包响应，其揭示的文化差异（例如在保护年轻人与老年人之间的人口统计学偏好）在社会学上确实很有趣。但对于任何试图直接根据这些数据训练伦理模块的人来说，这也是一个严重的警告信号。
人类在时间压力下的道德推理倾向于义务论；而当有时间深思熟虑时，同样的人又会倾向于功利主义。这不是你希望植入安全关键控制系统中的稳定偏好函数。更糟糕的是，存在一种有据可查的视角偏差：想象自己是自动驾驶汽车乘客的人希望汽车优先保护乘客，而同样的人在想象自己是行人时，希望却恰恰相反。用这种众包直觉来训练模型，你编码的不是伦理，而是大规模的自利不一致性，这正是为什么该领域的伦理不能被视为一种民主的数据拟合练习。它需要一种并非简单地从大众情绪中平均出来的宪法结构。
自上而下、自下而上以及实际部署的混合模式
自上而下的算法编码将特定的伦理承诺直接硬编码到确定性逻辑中，例如，除了避免迫在眉睫的碰撞外，严禁违反交通法规的义务论规则。它是可审计且可预测的，但对于规则设计者未预料到的场景，它却显得脆弱。
自下而上的机器学习让系统从训练数据中推断行为规范，这能更好地处理混乱的现实世界变化，但直接代价是可解释性差。黑盒策略网络无法轻易解释事后为何在特定边缘案例中选择了特定的轨迹，这对事故调查和监管问责来说是一个真正的问题。
在严肃部署中实际出现的模式是混合式的：自下而上的学习策略处理连续、混乱的感知和轨迹优化问题，并在硬性的自上而下约束内运行，无论奖励函数可能暗示什么，学习策略在架构上都被禁止违反这些约束。这种边界层（有时作为位于学习规划器下游的显式基于规则的安全过滤器实现）在功能上类似于工业环境中硬编码的关节限制或防碰撞联锁装置如何约束学习到的机器人操作策略。学习处理细微差别；确定性层处理不可妥协的边界。
安全的重要性本身就编织在产品设计的结构中，在决定其开发的监管框架中显而易见。
功能安全与 SOTIF：两类不同的失效
ISO 26262 规范了功能安全，这是一门管理硬件故障或系统性软件缺陷风险的成熟学科。其汽车安全完整性等级（ASIL）框架根据给定故障可能导致的危害的严重性和可能性，来衡量设计和验证活动的严谨性，大多数汽车电子工程师正是因为这个原因，花费了大量时间争论 ASIL 分解策略。
行业不得不面对的一个真正令人不安的现实是，自动驾驶汽车可能在所有组件都按设计运行的情况下发生碰撞。摄像头捕捉到了完美的图像。感知网络只是因为大雨中穿着奇装异服的行人处于训练分布的覆盖范围之外，而未能正确分类。没有任何组件发生故障。系统只是不足以应对那一刻的复杂性，而围绕故障风险构建的整个 ISO 26262 框架，对于这种失效模式根本没有原生的词汇。
ISO 21448（SOTIF，预期功能安全）专门用于填补这一空白，重点关注由性能限制和未预料到的操作条件而非组件故障引起的危害。SOTIF 的四象限模型值得详细了解，因为它为工程团队提供了实际的路线图，而不仅仅是一个问题标签。区域 1 是已知的安全目标状态。区域 2 是已知危险，即团队已经识别并正在通过设计变更积极缓解的风险。区域 3 是未知危险，这是真正危险的类别，因为团队甚至还没有识别出这些边缘案例。区域 4 是未知安全。
SOTIF 工程、广泛的仿真、统计现场验证和结构化边缘案例发现的全部实际目标，是将场景从区域 3 迁移到区域 2，使其成为可处理的设计问题，而不是隐形风险。并行运行 ISO 26262 和 SOTIF，而不是将两者中的任何一个视为充分条件，才是真正同时覆盖内部故障风险和外部复杂性风险的方法，跳过其中任何一个都会在安全论证中留下真正的缺口。
协作机器人：ISO 10218 与 2025 年 TS 15066 的合并
同样的根本性转变，即消除“人类始终是最终故障安全保障”的假设，也发生在工业机器人领域。传统的工业机器人运行在带有硬联锁的隔离安全笼内：打开笼子，电源立即切断。协作机器人的引入从根本上改变了传统的工作空间配置，使得人机共存成为必要。
2025 年对 ISO 10218-2 的更新正式将 ISO/TS 15066 吸收到一个统一的协作机器人标准中，如果你正在指定任何协作机器人单元，必须熟记它定义的四种协作操作模式。安全额定监控停止（Safety-Rated Monitored Stop）在人类进入时完全停止机器人，并在区域清除后恢复。为了确保安全高效的工作流程，操作员主动管理机器人手臂的移动，精确控制预定位置的速度。系统根据人类相对速度和接近程度的动态计算，实时优化其步调，确保更安全的工作环境。限制功率和力边界不仅限制机械接触，还以电子方式强制执行安全接触力，以防止碰撞超过预定义的安全限制。
最常让新集成商绊倒的细节是：标准明确指出，没有任何机器人本身在孤立状态下是“安全”或“协作”的。必须对整个应用、特定的末端执行器、工件几何形状、周围的夹具、实际任务进行风险评估，并验证为一个完整的系统。一个完全符合 PFL（功率和力限制）标准的机器人手臂如果配备了锋利的定制夹具，仅仅因为它基础机器人带有协作认证，并不意味着它就是一个协作应用。
IEEE P7000：社会技术伦理的正式化
安全是推动 ISO 标准的首要关注点，这些标准优先考虑物理和功能方面。IEEE P7000 系列是在 IEEE 全球自主与智能系统伦理倡议下发起的，它解决了 ISO 框架从未设计涵盖的社会技术和伦理维度，并且它通过具体的、可解决的标准而非模糊的愿景原则来做到这一点。
IEEE P7001 针对透明度，要求自动驾驶系统进行自我评估，并以事后人类真正可解释的形式公开决策路径，这正是纯黑盒自下而上学习在没有额外架构工作的情况下难以提供的能力。IEEE P7003 直接解决算法偏见，为在部署前识别和防止训练模型中的歧视性结果提供了结构化框架。IEEE P7009 专门涵盖故障安全设计，强制要求在系统确实无法继续正常运行时，采取优雅、安全的降级行为，而不是突发或不可预测的失效模式。IEEE P7010 比大多数工程标准走得更远，引入了福祉指标，评估人工智能系统对人类发展的实际影响，而不是止步于狭隘的经济或任务完成指标。
第 3 部分：构建真正站得住脚的安全论证
针对 ISO 26262 或 SOTIF 的合规性检查表是必要的基础工作，但它们本身并不构成特定系统在现实世界中可安全部署的有力论证。这种论证正是安全保证案例（Safety Assurance Case）正式构建的内容：结构化的主张，由逻辑论证链支持，并由具体的、可验证的证据、仿真日志、轨道测试结果、现场遥测数据作为后盾。
UL 4600：基于目标而非规定性
ANSI/UL 4600 采取了与规定具体实施要求的传统规定性标准截然不同的方法。它是基于目标的，提供了一套广泛的强制性、必需和推荐的提示，迫使工程团队积极解决特定的风险类别，而不是简单地勾选固定的实施框。
UL 4600 迫使人们直接面对机器学习固有的脆弱性、罕见边缘案例的漫长尾部，以及真实操作条件下人机交互的混乱现实。它要求严格定义操作设计域（ODD），即系统被授权在其中运行的明确环境、地理和时间范围（例如“白天、晴天、时速 45 英里以下的铺装道路”是一个代表性例子），这是该标准在操作上最重要的要求。如果车辆遇到该范围之外的条件（如突发的暴风雪、未映射的施工区域），安全论证必须证明系统能够可靠地检测到该 ODD 违规，并执行真正安全的后备机动，而不仅仅是寄希望于感知堆栈能优雅地处理它。
SACE 和 AMLAS：一种整体的、环境感知的方法论
约克大学的 SACE 方法论（复杂环境下的自动驾驶系统安全保证）与 AMLAS（自动驾驶系统中机器学习的保证）协同工作，采取了一种真正整体的视角，涵盖了系统本身及其所处的操作环境。
SACE 的“上下文外操作保证”组件解决了 UL 4600 的 ODD 概念暗示但未完全形式化的内容：现实世界比任何定义的操作域模型所能完全捕捉到的要复杂得多，因此系统最终不可避免地会游离于其定义的边界之外。SACE 要求明确展示两种不同的能力。首先，系统能够准确且及时地识别出它正在接近或已经跨越了 ODM 边界，并对该边界检测本身进行经过严格验证的误报率和漏报率评估，因为一个不断“狼来了”的边界检测器几乎和错过真实边界跨越的检测器一样不安全。其次，系统在离开 ODM 后已准备好执行真正的最小风险策略，无论是将控制权交还给人类操作员、执行受控的安全停止，还是过渡到专注于自我保护而非任务完成的刻意保守的降级安全模式。
为什么仿真承担了如此多的证据权重
没有任何车队（无论规模多大）能够通过道路测试物理行驶足够的里程来遇到每一个有意义的危险边缘案例；天气、光照、交通行为和稀有物体类别的组合使得这种方法在任何合理的项目时间表内从统计学上来说都是无望的。标准化的仿真框架（如用于道路网络描述的 ASAM OpenDRIVE 和用于动态机动规范的 OpenSCENARIO）让工程团队能够构建高度参数化的虚拟环境，在其中可以刻意注入故障，系统地改变天气和光照条件，并以远快于物理测试且更详尽的方式执行数百万种场景排列，从而生成 SOTIF 和 UL 4600 安全论证所依赖的大部分证据基础，甚至在软件接触物理硬件之前就已完成。
第 4 部分：问责制——工程与法律的交汇处
当自动驾驶系统导致死亡事故时，公众的第一直觉往往是询问机器“决定”做什么，就好像它做出了道德选择一样。这种框架是一种范畴错误，工程师和围绕这项技术构建的法律框架必须刻意抵制这种说法，这一点至关重要。
为什么机器不能拥有道德或法律主体资格
自动驾驶系统无论架构多么复杂，都是在优化数学奖励函数。它不具备法律或经典伦理所认可的任何意义上的意图、自由意志或真正的道德理解，将其归因于主体资格只会掩盖而非澄清责任的真正归属。由于机器缺乏法律人格和犯罪意图（mens rea）的能力，刑事责任无法附加在系统本身上。
相反，人们观察到的是“道德挤压区”（moral crumple zone）的形成，即最接近故障的人类（例如监控自动化系统的安全驾驶员）承担了与其实际因果贡献不成比例的法律和道德指责，而真正导致故障条件的系统工程和组织决策却逃脱了同等的审查。这种不对称是一种真正的问责失效模式，而不是操作先进技术的可接受后果。
Uber ATG 事故作为工程和组织案例研究
2018 年 Uber ATG 在亚利桑那州坦佩市发生的致命事故，在公众讨论中经常被错误地描述为现实世界的电车难题。实际的技术调查讲述了一个在哲学上不那么有趣，但在实践中却极具指导意义的故事：感知堆栈故障加上组织安全文化失败。
自动驾驶系统对一名推着自行车过马路的女性的分类，随着物体在场景中的移动，在“车辆”、“自行车”和“其他”之间反复震荡。每次重新分类都会重置系统对该物体的轨迹预测，而正是这种重置循环（而非电车式的刻意选择）延迟了适当的制动响应，直到为时已晚。这是多目标跟踪和分类流水线中一个真正被充分理解的失效模式，不稳定的类别预测会破坏下游的运动预测，这正是更成熟的传感器融合架构（在连续帧之间具有更强的时序一致性约束）在验证测试中应该在公共道路部署前就发现的问题。
直接叠加在技术故障之上的是一个独立的、可以说更严重的组织失败：Uber 专门抑制了发给人类安全驾驶员的紧急警报通知，以减少频繁误报带来的“警报疲劳”，而且该安全驾驶员角色的操作安全职责最初并未得到清晰或严格的定义。这些组织决策中的任何一个都不会出现在仅针对感知堆栈的技术根本原因分析中，而这正是重点所在：完整的问责框架必须审查整个系统生命周期，而不仅仅是撞击瞬间运行的软件。
定义全生命周期的角色责任
有意义的问责制必须明确追踪系统开发和操作的每一个阶段：负责收集和整理训练数据的组织和流程、设计和验证神经网络架构的工程师、编译并签署 UL 4600 安全案例的安全工程师、在商业压力下设定部署时间表和风险容忍度的高管，以及在现实条件下日常管理系统的现场操作员。
这种全生命周期的可追溯性正是为什么强制要求透明、可重构决策路径的标准（IEEE P7001 是最清晰的直接例子）超越纯技术兴趣而变得重要的原因。如果没有这种可重构记录，事后调查就无法准确地将因果责任追溯到实际故障条件产生的生命周期阶段，问责制就会坍塌到事故发生时物理上最接近故障的任何个人身上，而这几乎从来不是真正的工程责任所在。
未来之路
负责任地部署安全关键的自动驾驶系统，不是通过更巧妙地解决哲学思想实验就能解决的问题。它是通过 ISO 26262 下组件级功能安全分析、SOTIF 下环境和性能限制覆盖、统一的 ISO 10218 协作机器人框架下的应用级风险评估、IEEE P7000 下的社会技术问责结构，以及 UL 4600 和 SACE 等框架下结构化、证据支持的安全论证等枯燥、严谨且真正困难的工作来解决的。
这些框架中没有哪一个能单独解决整个问题，这正是严肃的工程组织将它们结合起来运行，而不是将任何单一标准视为足够保障的原因。从 Uber ATG 案例以及随后以这种严谨程度调查的每一项事故中得出的诚实结论都是一样的：这些系统行为的责任并不会仅仅因为机器在做即时决策就转移给机器。责任完全在于设计感知流水线、定义操作边界、签署安全案例以及设定组织优先级的那些人类。从一开始就将这种责任工程化到流程中，而不是在事故发生后才发现其缺失，才是该领域目前仍需完成的真正工作。