在 ASIL D 项目的实测中，使用 AI-HARA（DPAI 功能安全组件）完成一轮 HARA + FMEA + TARA 安全分析，工时从传统方式的 34 人天压缩到 8.7 人天，降幅 74.4%。

这篇文章讲清楚三件事：34 人天为什么这么久、8.7 人天怎么做到、以及——最重要的——AI 在安全分析里到底能替人做什么、不能做什么。

34 人天，传统安全分析的时间黑洞

安全分析是 ISO 26262 / ISO 21434 项目里最耗时的环节，没有之一。一个典型 ASIL D 项目的安全分析工时分布：

相关项定义与场景梳理：传统工时8人天，痛点为运行场景枚举靠经验，漏场景是常态

HARA（危害分析与风险评估）：传统工时10人天，痛点为每个危害事件要填 S/E/C 并写理由，重复劳动巨大

FMEA / TARA 分析：传统工时9人天，痛点为失效模式、威胁场景逐条编写，术语一致性难维护

安全目标与安全需求导出：传统工时4人天，痛点为从分析到需求的追溯手工建立

评审与整改：传统工时3人天，痛点为理由不充分被打回，逐条返工

合计：传统工时34人天

真正的瓶颈不是"分析"，而是写作的重复劳动和术语一致性维护。一个 HARA 表动辄上百个危害事件，每个都要写清场景描述、严重度理由、暴露率理由、可控性理由——安全工程师 70% 的时间花在"把判断写成合规文字"上。

8.7 人天，AI-HARA 的拆解

AI-HARA 的做法是把安全分析拆成"判断"和"表达"两层：

- 判断层（人做）：S/E/C 评级裁量、安全目标确认、风险接受决策——安全经理的职责，AI 不碰；

- 表达层（AI 做）：场景枚举建议、评级理由起草、术语一致性校验、追溯关系建立、文档生成。

实测拆解：

相关项定义与场景梳理：传统8人天，AI-HARA2人天，变化为AI基于场景库枚举建议，工程师增删确认

HARA：传统10人天，AI-HARA2.8人天，变化为AI起草评级理由与描述，工程师聚焦裁量

FMEA / TARA：传统9人天，AI-HARA2.2人天，变化为失效模式库+威胁场景库调用，术语自动一致

安全目标与需求导出：传统4人天，AI-HARA0.9人天，变化为追溯自动建立，需求初稿自动生成

评审与整改：传统3人天，AI-HARA0.8人天，变化为首过率高，返工大幅减少

合计：传统34人天，AI-HARA8.7人天，整体降幅74.4%

方法论：让数据可信的三个机制

1. 场景与模式库，而不是让大模型自由发挥。AI-HARA 内置了按车辆功能域组织的运行场景库、失效模式库、威胁场景库。AI 的产出受库约束，不是天马行空生成——这是分析结果可评审、可复用的前提。

2. 评级理由模板化 + 裁量留给人。每个 S/E/C 评级，AI 按 ISO 26262 口径起草理由草稿，但最终评级必须由安全经理确认签字。系统强制保留"AI 建议值"与"人工确认值"的差异记录——评估现场这恰恰是最受评估师欢迎的特性。

3. 安全分析是活文档。需求变更时，系统自动标记受影响的安全分析条目，提示重审。安全资产库（HARA/TARA/FMEA）随项目演进持续更新，而不是评估前突击补的死文档。

边界说清楚

AI 不替代安全工程师的判断。ASIL 定级、风险接受、安全目标的最终确认，都是人的责任——这既是标准要求，也是我们的产品设计红线。AI 把安全工程师从文书工作里解放出来，让他们把时间花在真正的风险判断上。

拿你的真实项目验证：付费范围 PoC，用贵司一个真实功能域跑一轮 HARA，评估师评审交付物，出具工时对比，不达标退款。

AI-HARA 为 亚远景DPAI 系统功能安全组件，覆盖 ISO 26262 HARA/FMEA 与 ISO 21434 TARA，纯私有化部署，数据不出企业内网。实测数据来自公司内部项目工时记录。