企业官网建设流程全解析

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：根据整车影响，评估严重度S（1-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计算和排序：为什么这部分不该交给LLM

RPN（风险优先数）的计算是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协作。这个技能在接下来几年里会从"加分项"变成"必备项"。