AI Agent如何重塑功能安全咨询：从FMEA到ISO 26262的Prompt工程实践

1. 功能安全咨询行业正在被AI Agent悄悄改写功能安全咨询这个行当过去十几年一直是典型的人力密集经验密集生意。一个ISO 26262的完整项目从概念阶段的HARA危害分析与风险评估到系统阶段的FMEA、FTA再到软件阶段的单元测试覆盖率论证、诊断覆盖率计算最后到安全案例Safety Case的撰写动辄需要三五个资深工程师投入半年以上。咨询公司卖的本质上是人天一个资深功能安全工程师的日费率在行业里是公开的秘密而客户买到的其实是这个人脑子里那套经过多个量产项目打磨的判断力。但这两年情况在变。我接触过几家做功能安全咨询的团队他们开始把AI Agent塞进自己的交付流程里而且不是那种用ChatGPT写写文档的浅层用法而是把Agent做成了能独立承担某类安全分析任务、能调用工具、能维护上下文记忆、能输出可追溯结论的数字安全工程师。这个转变的意义在于咨询公司卖的东西从人天变成了能力单元一个Agent可以7x24小时跑FMEA的初稿可以自动核对ISO 26262各部分的条款符合性可以在需求变更时自动重跑影响分析。这篇文章我想拆解的就是这件事——功能安全咨询公司到底怎么把AI Agent做成可售卖的产品中间踩过哪些坑Prompt工程在功能安全这种强规范领域有什么特殊之处以及一个刚入门的团队如果想复现这套东西应该从哪个环节切入。关键词里的AI Agent、功能安全、ISO 26262、Prompt、FMEA这几个词基本覆盖了这件事的全部核心要素。不管你是功能安全工程师想了解AI怎么用还是AI开发者想切入垂直行业这篇内容应该都能给你一些可以直接抄作业的东西。2. 为什么功能安全咨询是AI Agent的天然试验场2.1 功能安全工作的可结构化程度远超一般人想象很多人觉得功能安全是高度依赖专家判断的领域AI很难插手。这个判断对了一半。功能安全里确实有大量需要经验判断的环节比如ASIL等级的最终定级、安全机制的选型权衡、与客户就安全目标达成一致的政治博弈。但另一半——也就是那些有明确输入输出规范、有标准条款可对照、有历史案例可参考的工作——比例其实非常高。我粗略统计过一个典型ISO 26262项目的工时分布HARA阶段大约30%的时间花在整理危害清单和场景枚举上FMEA阶段大约40%的时间花在填写表格和追溯失效模式上安全案例撰写阶段大约50%的时间花在把已有分析结果组织成符合标准结构的文档上。这些工作的共同特征是输入是结构化的需求、架构、参数输出是结构化的表格、条款对照、追溯矩阵中间的处理逻辑虽然复杂但有明确的规则可循。这正是AI Agent最擅长的场景。LLM本身擅长处理非结构化文本但当它被Agent框架约束在读取结构化输入→按规则处理→输出结构化结果的流程里时它的表现会稳定得多。功能安全咨询公司看中的就是这一点他们不需要Agent做最终决策只需要Agent把那些填表、追溯、初稿的活干掉让资深工程师把时间花在真正需要判断力的地方。2.2 ISO 26262的条款结构天然适合做Prompt的骨架ISO 26262有12个部分每个部分下面有若干条款Clause每个条款下面有具体要求Requirement。这个层级结构非常清晰而且条款之间的引用关系是显式的。比如Part 6的软件架构设计要求会引用Part 5的硬件-软件接口要求Part 4的系统级要求会引用Part 3的概念阶段输出。这个结构对Prompt工程来说是个巨大的便利。你可以把每个条款做成一个独立的Prompt模板模板里包含条款编号、条款要求原文、该条款的输入依赖来自哪些前置条款的输出、该条款的输出格式要求、该条款的常见不符合项清单。当Agent需要处理某个具体任务时它先根据任务类型检索到对应的条款模板然后把项目实际数据填充进去最后按模板规定的格式输出。我见过一个做得比较成熟的团队他们把ISO 26262 Part 4到Part 6的所有条款都做成了Prompt模板库每个模板都经过至少三个真实项目的验证和迭代。他们的Agent在处理一个新的系统级FMEA任务时会先调用Part 4的条款模板确认分析范围再调用Part 5的模板确认硬件失效模式库最后调用Part 6的模板确认软件诊断覆盖率的计算方式。整个过程不需要人工干预输出的FMEA初稿能直接进入工程师的评审环节。2.3 咨询公司的交付物本质上是可复用的知识产品功能安全咨询公司卖的东西表面上是报告和文档实际上是把标准条款映射到具体项目的那套方法论。这套方法论在项目之间是有大量复用的同样的ASIL D刹车系统不同主机厂的项目在HARA阶段要考虑的危害场景高度相似同样的电机控制器不同Tier 1的FMEA失效模式库有70%以上是重叠的。AI Agent的价值就在于把这个复用过程自动化。传统模式下一个资深工程师做完一个项目他的经验留在脑子里下一个项目还得重新想一遍。Agent模式下每个项目的分析结果、Prompt模板、工具调用记录都被结构化地保存下来下一个项目启动时Agent可以直接调用历史项目的相似分析作为起点工程师只需要做差异化的调整。这个转变对咨询公司的商业模式影响是深远的。过去他们卖的是人天客户买的是工程师的时间。现在他们可以卖分析能力包——比如ASIL D刹车系统HARA分析包里面包含预训练好的Agent、针对该场景优化的Prompt模板库、历史项目脱敏后的参考案例。客户买回去可以自己跑也可以让咨询公司的人来跑。交付周期从几个月缩短到几周客单价可能降低但毛利率反而上升因为边际成本几乎为零。3. 把FMEA做成Agent可执行任务的关键拆解3.1 FMEA为什么是第一个被Agent化的功能安全任务在所有功能安全任务里FMEA失效模式与影响分析是最早被Agent化的没有之一。原因很直接FMEA的输入输出格式最固定处理逻辑最线性而且工作量最大。一个中等复杂度的ECU系统级FMEA的失效模式条目通常在500到2000条之间每条需要填写失效模式、失效原因、局部影响、系统影响、整车影响、严重度、频度、探测度、RPN、建议措施等十几个字段。人工做一遍一个熟练工程师需要两到三周。FMEA的另一个特点是它的可枚举性。虽然失效模式本身需要经验来判断但一旦确定了某个组件的功能它的失效模式基本是可以穷举的功能丧失、功能退化、功能间歇、功能超出预期、非预期功能。这五种失效模式对应到具体组件上再结合组件的物理特性电气、机械、软件就能生成一个相当完整的候选失效模式清单。Agent要做的第一件事就是这个枚举然后才是影响分析和RPN计算。我见过一个团队的做法是先用一个专门的Prompt让LLM根据组件功能描述生成候选失效模式清单然后用另一个Prompt让LLM对每个失效模式做影响分析最后用一个计算脚本不是LLM做RPN计算和排序。这个分工很关键——LLM负责生成和判断脚本负责计算和排序各干各擅长的事。3.2 失效模式枚举的Prompt设计从功能描述到候选清单失效模式枚举的Prompt是整个FMEA Agent的核心。这个Prompt的设计质量直接决定了后续所有环节的输入质量。我拆解过一个效果比较好的Prompt模板它的结构是这样的你是一名资深功能安全工程师正在执行ISO 26262 Part 5要求的硬件FMEA分析。 组件信息 - 组件名称{component_name} - 组件功能{component_function} - 组件类型{component_type}电气/机械/软件/机电 - 安全目标{safety_goal} - ASIL等级{asil_level} 请根据以下五种失效模式分类枚举该组件的所有可能失效模式 1. 功能丧失Loss of Function 2. 功能退化Degradation of Function 3. 功能间歇Intermittent Function 4. 功能超出预期Unintended Function 5. 非预期功能Unintended Activation 对每个失效模式输出 - 失效模式编号 - 失效模式描述一句话包含组件名和失效类型 - 可能的失效原因至少两条区分随机硬件失效和系统性失效 - 该失效模式是否与安全目标相关是/否 输出格式为Markdown表格。这个Prompt有几个设计要点值得说。第一它明确要求区分随机硬件失效和系统性失效因为ISO 26262对这两类失效的处理方式完全不同随机硬件失效需要计算PMHF概率度量硬件失效系统性失效需要论证开发过程的符合性。第二它要求判断是否与安全目标相关这是为了后续只对安全相关的失效模式做详细分析避免在无关条目上浪费算力。第三它强制要求输出格式为表格这样后续的解析和入库可以直接用脚本处理。实测下来这个Prompt对电气组件的失效模式枚举准确率能到85%以上对机械组件稍低一些大约70%。主要漏项集中在共因失效和级联失效上这两类失效模式需要跨组件分析单个组件的Prompt很难覆盖。解决办法是在Prompt里加一段提示如果该组件的失效可能由其他组件的失效引发或可能引发其他组件的失效请单独列出并标注。加了这段之后漏项率能降到10%以下。3.3 影响分析的链式推理从局部影响到整车影响失效模式枚举完之后下一步是影响分析。ISO 26262要求FMEA分析三个层级的影响局部影响组件自身、系统影响所属系统、整车影响车辆层面。这三个层级是递进关系局部影响导致系统影响系统影响导致整车影响。这个递进关系天然适合用链式推理Chain-of-Thought来处理。我见过一个Prompt设计是这样的针对以下失效模式请按三个层级分析其影响 失效模式{failure_mode} 组件功能{component_function} 所属系统{system_name} 系统功能{system_function} 整车功能{vehicle_function} 请按以下步骤推理 步骤1该失效模式对组件自身功能的影响是什么局部影响 步骤2组件功能的丧失或退化如何传导到系统层面系统影响 步骤3系统层面的影响最终如何影响整车行为整车影响 步骤4根据整车影响评估严重度S1-10分并说明评分理由。 注意严重度评分必须参考ISO 26262 Part 3的严重度评分表S9-S10为危及生命S7-S8为严重伤害S4-S6为中度伤害S1-S3为轻度伤害。这个Prompt的关键在于步骤4的严重度评分。LLM直接给严重度评分往往不准因为它缺乏对危及生命和严重伤害之间界限的直观理解。解决办法是在Prompt里嵌入评分表的简化版本并要求LLM说明评分理由。实测下来加了评分表之后严重度评分的准确率从60%提升到80%左右。剩下的20%误差主要集中在S7-S9的边界上这部分需要人工复核。3.4 RPN计算和排序为什么这部分不该交给LLMRPN风险优先数的计算是S×O×D其中S是严重度O是频度D是探测度。这个计算本身很简单但LLM做乘法经常出错尤其是当数字比较大的时候。我试过让LLM直接算RPN准确率只有70%左右而且错误没有规律有时候是乘法算错有时候是抄错了S/O/D的值。正确的做法是把RPN计算从LLM的职责里剥离出来。Agent的工作流应该是LLM负责生成S/O/D的评分和理由然后把评分结果传给一个Python脚本脚本负责计算RPN、排序、生成最终的FMEA表格。这个分工的好处是LLM专注于它擅长的判断和生成脚本专注于它擅长的计算和格式化两者通过结构化数据JSON交接。我见过一个团队的做法更彻底他们让LLM输出S/O/D的评分和理由但RPN的计算和排序完全由脚本完成而且脚本还会做一致性检查——比如如果某个失效模式的S评分是9但O评分是10几乎必然发生脚本会标记这个组合为需要人工复核因为S9且O10的失效模式在现实中极其罕见很可能是LLM评分有误。4. Prompt工程在功能安全领域的特殊约束4.1 功能安全Prompt不能有创造性通用Prompt工程里经常鼓励LLM发挥创造力、给出多样化的回答。这在功能安全领域是致命的。功能安全分析要求的是可追溯、可复现、可审计。同一个输入今天跑和明天跑必须得到相同的结果同一个输入A工程师跑和B工程师跑必须得到相同的结果。如果LLM每次输出都不一样那这个分析结果就没法写进安全案例里。所以功能安全领域的Prompt必须把确定性放在第一位。具体做法包括把temperature参数设到最低通常是0或0.1在Prompt里明确要求不要发挥严格按照给定规则处理以及最重要的——把分析规则尽可能写死在Prompt里而不是让LLM自己去理解。我见过一个反例有个团队为了让Agent更智能在Prompt里只写了请根据ISO 26262的要求分析这个失效模式的影响没有给出具体的评分规则。结果Agent每次跑出来的严重度评分都不一样同一个失效模式有时候评S7有时候评S9。后来他们把Part 3的严重度评分表完整嵌入Prompt并要求LLM必须从评分表中选择不得自行判断评分才稳定下来。4.2 条款引用必须精确到Clause编号功能安全文档里每一个结论都必须有条款依据。比如该失效模式的诊断覆盖率要求为90%这句话必须注明依据是ISO 26262 Part 5 Clause 8.4.5。如果Agent输出的结论没有条款依据或者条款编号错了那这个结论在安全案例里就是无效的。这对Prompt设计提出了一个硬性要求Prompt里必须包含条款编号的映射关系。我见过一个做得比较细的团队他们建了一个条款映射表把每个分析任务和对应的条款编号关联起来。比如硬件失效模式枚举对应Part 5 Clause 7.4.2诊断覆盖率计算对应Part 5 Clause 8.4.5安全机制验证对应Part 5 Clause 9.4.3。Agent在执行任务时会先查这个映射表拿到条款编号然后把条款编号嵌入输出里。这个映射表本身也是需要维护的。ISO 26262在2018年出了第二版很多条款编号和第一版不一样。如果Agent用的是第一版的条款编号输出的文档在客户那里是通不过评审的。所以咨询公司需要定期更新这个映射表而且要在Prompt里注明本分析依据ISO 26262:2018。4.3 处理无效Prompt和Prompt过长的实战经验热词里出现了invalid prompt: your prompt was flagged as potentially violating our usage policy和prompt is too long这两个问题在功能安全Agent的实际运行中非常常见。先说invalid prompt。功能安全分析里经常需要描述一些极端场景比如车辆在高速行驶时刹车系统完全失效或者电池管理系统在碰撞后未能切断高压。这些描述在LLM的安全过滤器看来可能涉及危险行为从而触发拦截。解决办法不是删掉这些描述——它们是功能安全分析的核心内容——而是换一种表达方式。比如把刹车系统完全失效改成制动功能丧失Loss of Braking Function把未能切断高压改成高压断电功能未激活HV Disconnect Not Activated。用标准术语替代日常描述既能通过过滤器又更符合功能安全文档的规范。再说prompt is too long。功能安全分析的Prompt往往很长因为要嵌入条款原文、评分表、历史案例、输出格式要求。我见过一个FMEA的Prompt超过8000个token直接超过了某些模型的上下文窗口。解决办法有两个一是把Prompt拆成多个子Prompt分步执行每步的输出作为下一步的输入二是把那些不常变的部分比如条款原文、评分表做成外部知识库Agent在需要时通过检索调用而不是每次都塞进Prompt里。第二种做法更优雅但实现难度更高。它要求Agent有检索能力RAG而且检索的准确率要足够高否则Agent会引用错误的条款。我见过一个团队用向量数据库做条款检索检索准确率能到95%以上但剩下的5%错误在功能安全场景里是不可接受的。他们的解决办法是检索结果必须经过人工确认才能进入下一步Agent只负责把候选条款列出来工程师点选确认。5. 从零搭建一个功能安全FMEA Agent的实操路径5.1 环境准备不要一上来就搞多Agent框架很多团队一上来就想搞多Agent协作什么规划Agent、执行Agent、评审Agent听起来很高级实际跑起来一团糟。功能安全FMEA这个任务单Agent加工具调用就足够了。我的建议是先用最简单的架构跑通一个最小可用版本再根据实际瓶颈决定要不要加Agent。最小可用版本的技术栈可以是这样Python LangChain或者更轻量的LlamaIndex 一个支持长上下文的LLM API 一个本地的SQLite数据库。LangChain负责Prompt模板管理和工具调用SQLite负责存储FMEA条目和条款映射表。不需要向量数据库不需要多Agent框架不需要复杂的编排引擎。环境准备里最容易忽略的是LLM的选型。功能安全分析对LLM的要求和通用场景不一样它不需要很强的创造性但需要很强的指令遵循能力和长上下文处理能力。我实测下来Claude系列在指令遵循上表现最好GPT-4系列在长上下文上更稳国产模型里DeepSeek在中文功能安全术语的理解上意外地不错。建议至少准备两个模型的API一个主用一个备用因为API的稳定性在项目交付期是刚需。5.2 条款知识库的构建从PDF到结构化数据ISO 26262的标准原文是PDF而且是有版权的不能直接塞进Prompt里。但条款的编号、标题、核心要求是可以引用的。构建条款知识库的第一步是把PDF里的条款结构提取出来做成一个结构化的JSON文件。这个JSON的结构可以是这样{ standard: ISO 26262:2018, part: 5, clause: 7.4.2, title: Hardware failure mode identification, requirements: [ The failure modes of the hardware shall be identified..., The failure modes shall be classified as..., ... ], inputs: [Part 5 Clause 6.4.2 output, Part 4 Clause 7.4.3 output], outputs: [Failure mode list, Failure mode classification], common_nonconformities: [ Failure modes not traced to safety goals, Random hardware failures not distinguished from systematic failures ] }这个JSON的构建过程可以半自动化先用PDF解析工具提取文本然后用LLM做结构化抽取最后人工校对。一个Part 5大约有200个条款人工校对需要两到三天但这是一次性投入后续所有项目都能复用。条款知识库建好之后Agent在执行任务时就可以通过条款编号检索到对应的要求然后把要求嵌入Prompt里。这样既避免了版权问题又保证了条款引用的准确性。5.3 工具调用的设计LLM什么时候该动手Agent和纯LLM的区别在于Agent能调用工具。在功能安全FMEA场景里哪些环节应该让LLM调用工具哪些环节应该让LLM直接输出这个边界需要仔细设计。我的经验是凡是涉及计算、排序、格式转换、数据查询的环节都应该做成工具让LLM调用。凡是涉及判断、生成、推理的环节都应该让LLM直接输出。具体到FMEA失效模式枚举LLM直接输出判断生成影响分析LLM直接输出推理生成S/O/D评分LLM直接输出判断RPN计算工具调用计算FMEA表格排序工具调用排序条款检索工具调用查询历史案例检索工具调用查询输出格式转换工具调用格式转换这个边界不是绝对的。比如S/O/D评分如果LLM的评分准确率不够可以考虑做成LLM给候选评分工具做一致性检查的混合模式。但总体原则是LLM做它擅长的语义理解和判断工具做它擅长的确定性计算和查询。5.4 跑通第一个FMEA任务的完整流程假设你已经有了条款知识库、Prompt模板库、工具集现在要跑一个具体的FMEA任务。完整流程是这样的第一步输入准备。你需要准备组件清单、组件功能描述、系统架构图、安全目标清单。这些输入的质量直接决定输出质量。我见过很多团队在这一步偷懒组件功能描述只写一句话结果Agent枚举出来的失效模式非常粗糙。建议组件功能描述至少包含功能名称、输入信号、输出信号、功能逻辑、性能指标、安全相关性。第二步任务初始化。Agent根据组件类型和安全目标从条款知识库检索到适用的条款从Prompt模板库检索到对应的模板然后组装成完整的Prompt。第三步失效模式枚举。Agent执行枚举Prompt输出候选失效模式清单。这个清单会先存到数据库里等待人工确认。人工确认的环节不能省因为失效模式枚举的准确率再高也有漏项而漏项在功能安全里是不可接受的。第四步影响分析和评分。人工确认后的失效模式清单进入影响分析环节Agent对每个失效模式做三层影响分析和S/O/D评分。这一步的输出同样需要人工复核但复核的重点是评分的一致性而不是逐条检查。第五步RPN计算和排序。Agent调用计算工具对复核后的评分做RPN计算和排序生成最终的FMEA表格。第六步输出和归档。最终的FMEA表格导出为Excel同时把整个分析过程的Prompt、工具调用记录、人工复核记录归档作为安全案例的证据材料。这个流程跑下来一个中等复杂度的ECU系统级FMEA的初稿生成时间从两到三周缩短到两到三天其中人工投入从全程参与变成只做确认和复核。效率提升是数量级的。6. 实际交付中踩过的坑和应对策略6.1 LLM的幻觉在功能安全场景里是致命的通用场景里LLM的幻觉可能只是让人哭笑不得但在功能安全场景里幻觉可能导致安全案例被驳回甚至可能导致实际的安全风险。我见过最严重的一次是Agent在诊断覆盖率计算时引用了一个不存在的条款编号Part 5 Clause 8.4.7实际不存在而且给出了一个看起来合理的覆盖率数值。如果这个错误没有被发现写进安全案例里客户在评审时发现条款编号不存在整个安全案例的可信度都会受影响。应对策略有三层。第一层是Prompt层面在Prompt里明确要求如果无法确定条款编号请输出条款编号待确认不要编造。第二层是工具层面Agent输出的所有条款编号都通过工具去条款知识库里验证验证不通过的直接标记为错误。第三层是流程层面所有Agent输出都必须经过人工复核才能进入下一环节复核的重点之一就是条款引用的准确性。6.2 上下文窗口的限制比想象中更早到来功能安全分析的上下文消耗非常快。一个组件的功能描述可能就几百个token但加上条款原文、评分表、历史案例、输出格式要求很容易就超过4000个token。如果一次分析多个组件上下文窗口很快就满了。我见过一个团队的做法是一个组件一个会话。每个组件的FMEA分析都在独立的会话里完成会话之间不共享上下文需要共享的信息比如系统架构、安全目标通过外部数据库传递。这样做的好处是上下文不会累积每个会话都是干净的。坏处是Agent失去了跨组件的全局视野共因失效和级联失效的分析会受影响。折中方案是分层会话系统级分析用一个会话组件级分析各自用独立会话系统级会话的输出作为组件级会话的输入。这样既控制了上下文长度又保留了必要的全局信息。6.3 客户对AI生成的接受度是个现实问题功能安全咨询的客户通常是主机厂或Tier 1他们对交付物的要求非常严格而且对AI生成这件事有天然的警惕。我见过一个项目咨询公司用Agent生成了FMEA初稿工程师复核后提交给客户客户在评审时问了一句这个FMEA是用AI做的吗整个会议室的气氛就变了。应对策略不是隐瞒而是重新定义AI的角色。在交付文档里不要写本FMEA由AI生成而是写本FMEA基于XX方法论使用自动化工具辅助完成所有分析结果均经过资深功能安全工程师复核确认。这个表述是事实而且把重点从谁做的转移到怎么做的和谁确认的。客户真正关心的是分析质量而不是分析工具。另一个策略是让客户参与Agent的验证过程。在项目初期用Agent跑几个已知结果的案例让客户看到Agent的输出和人工输出的一致性。客户看到Agent在已知案例上的表现后对Agent在新案例上的表现会更有信心。6.4 Prompt模板的版本管理是个隐形工作量功能安全咨询公司的Prompt模板库是核心资产但它的维护工作量往往被低估。ISO 26262标准在更新客户的要求在变化历史项目的经验在积累这些都会导致Prompt模板需要迭代。如果没有版本管理很容易出现这个项目用的是哪个版本的模板都说不清的情况。我的建议是Prompt模板库必须用Git管理每个模板文件都有版本号每次修改都有commit记录。Agent在调用模板时会把模板版本号写进输出里。这样任何一个分析结果都能追溯到具体的模板版本满足功能安全的可追溯性要求。版本管理还有一个好处是A/B测试。当你想改进某个Prompt模板时可以同时保留旧版本和新版本用同一批输入跑两个版本对比输出质量。我见过一个团队用这个方法把失效模式枚举的准确率从85%逐步优化到93%每次优化都有数据支撑。7. 这套模式对功能安全从业者意味着什么功能安全咨询公司卖AI Agent这件事对行业里的不同角色影响是不一样的。对咨询公司的老板来说这是毛利率的提升和交付周期的缩短。对资深功能安全工程师来说这是从做分析到审分析的角色转变。对刚入行的工程师来说这既是威胁也是机会——威胁在于那些重复性的分析工作会被Agent替代机会在于Agent的运维和优化需要新的技能。我个人的判断是功能安全的核心判断力在可预见的未来仍然是稀缺的Agent替代的是分析的执行而不是分析的决策。一个能设计安全架构、能跟客户就安全目标达成一致、能在标准条款和工程现实之间找到平衡点的资深工程师他的价值不会因为Agent的出现而降低反而会因为Agent把他从重复劳动中解放出来而提升。但前提是这个工程师愿意去理解Agent是怎么工作的愿意去学Prompt怎么写愿意去调工具怎么用。我见过一些资深工程师对AI有天然的抵触觉得机器做的东西不可靠。这种抵触在短期内是合理的因为Agent确实会犯错。但长期来看拒绝理解Agent的工程师可能会发现自己越来越难跟那些会用Agent的年轻工程师竞争。功能安全这个行当有一个特点它的知识更新很慢ISO 26262从2011年第一版到2018年第二版中间隔了七年。这意味着经验的价值很高一个做了十年功能安全的工程师他的经验在十年后仍然大部分有效。但AI工具的出现正在加速这个行当的工具化进程那些能被工具化的环节会迅速被工具化剩下的环节会变得更加稀缺和值钱。所以我的建议是如果你在功能安全领域不管你是做咨询的还是做工程的花点时间把Agent这套东西跑通。不需要成为AI专家但需要知道Agent能做什么、不能做什么、怎么跟Agent协作。这个技能在接下来几年里会从加分项变成必备项。