一句话定义：SOTIF（Safety Of The Intended Functionality，预期功能安全）关注的是——系统本身没有发生故障、所有零件都正常工作，但因为设计时没考虑到的场景或性能本身的局限，仍然导致了危害。它的目标是把这类"无故障却危险"的残余风险降到可接受的范围内。
为什么"没坏"也会出事
打个比方：一位开了十年车的司机，从没出过机械故障。但第一次开进暴雨积水路段、或者遇到一辆逆行的电动车，他可能就懵了。车没问题，人也没"坏"，是见识过的场景不够。
AI 系统同理。摄像头的动态范围有限，逆光下就可能看不清；目标检测模型没见过"侧翻的货车""散落的纸箱"，就可能识别不出来；感知算法对小目标远距离的精度天然有限——这些都是性能局限，不是 bug。还有一类是可预见误用：用户以为辅助驾驶能自己拐弯，手离方向盘去拿水杯。
SOTIF 的典型工作方式，就是把风险按"已知/未知"和"安全/不安全"划分成四象限，然后分头处理：已知不安全场景靠设计改进和场景库验证来消除；未知不安全场景靠探索性测试、真实路测、影子模式去"发现"，把它变成已知，再逐步压缩。术语上常说的 ODD（Operational Design Domain，运行设计域）就是先把"我到底能在哪些场景下工作"写清楚。
和功能安全（FuSa）的区别
| 维度 | 功能安全（Functional Safety） | 预期功能安全（SOTIF） |
|---|---|---|
| 起因 | 系统/硬件故障、随机失效 | 无故障，功能不足或场景未覆盖 |
| 典型例子 | 刹车 ECU 死机 | 逆光下没认出前方行人 |
| 应对手段 | 冗余、监控、失效降级 | 场景库、限制 ODD、算法改进、人机交互设计 |
| 核心问题 | "坏了怎么办" | "没坏但不会怎么办" |
两者互为补充：一辆车既要"坏得安全"，也要"在没坏的情况下尽量不出事"。相关标准是 ISO 26262（功能安全）与 ISO 21448（SOTIF），具体适用范围和条款以官方发布为准。
对从业者和普通人的意义
从业者：SOTIF 意味着"测试通过"不等于"安全"，因为测试集本身就是有限的。要重视触发条件的梳理（什么光照、天气、道路结构会让性能掉下去）、ODD 的明确声明，以及上线后的持续监控与数据回流。
普通人：看到"L2 辅助驾驶"这类字眼，要明白它的能力边界是被声明过的，声明之外的部分就是风险区。手别离开方向盘，不是因为法规要求，而是因为你正处在别人还没覆盖到的场景里。