夜雨聆风
从零搭建基于 OpenClaw 的功能安全 Agent(3)VR 验证审查与 CR 认可评审
VR 双参考审查 · 用户判定循环 · CR 认可评审 · Checklist 体系 · 开口项机制
───────────────────────────────────────
前两篇我们搭好了基础设施和多 Agent 调度架构。Engineer 吭哧吭哧产出了交付物，Manager 也按时收到了——但然后呢？
交付物质量谁来把关？怎么确认它真的符合 ISO 26262？改了某个地方之后，怎么保证没把别的东西搞坏？这些才是功能安全里真正要命的问题。
这一篇是整个体系的质量保障核心：VR（Verification Review，验证审查）和 CR（Confirmation Review，认可评审）。说穿了就是——我们不是让一个 AI 又当运动员又当裁判，而是设计了两层审查 + 用户判定的闭环。这套机制直接决定了你的 WP（功能安全 Work Products）的交付质量。
───────────────────────────────────────
一、为什么需要两层审查
传统功能安全项目里，验证和审查是不同角色干的：活动相关工程师检查产出是否符合满足技术要求，具备独立性的安全经理做认可评审保证全局一致性与合规。这叫独立审查——审查者跟执行者不是同一个人。
如果同一个 Agent 既写交付物又审交付物，约等于自己给自己打分，这就会让审查失去意义，也是功能安全无法接受的。
我的方案很直接：
|
审查层 |
执行者 |
审查什么 |
参考依据 |
|
VR 验证审查 |
Manager |
交付物是否符合活动卡要求、需求编写是否合规、标准条款是否满足 |
ISO 26262-4/5/8/9 技术标准 + 活动卡 Checklist（双参考，互为补充） |
|
CR 认可评审（Confirmation Review） |
Head |
交付物完整性、论证逻辑自洽性、上下游一致性、假设是否明确 |
ISO 26262-2:2018 §6.4.10, Annex C.6（认可评审 / confirmation review，不引用技术标准，与 VR 完全解耦）+活动卡checklist（活动卡的设计会在后续文章中详细描述） |
[WARNING] 关键原则：Manager/Head 只列不满足项，不做通过/不通过决定。判定权始终在用户。 这是当前阶段的设计——AI 是审查工具，不是签字人。每一份 WP 的最后一道关，必须是人来把。
这既可以帮助我们有效的识别这个全新Agent在执行活动时的漏洞，也可以帮助我们在识别到漏洞后，将这些漏洞有效反馈给Agent，帮助它实现“进化”。
───────────────────────────────────────
二、VR 验证审查 — Manager 的核心工作
2.1 VR 是什么
VR（Verification Review）是 Manager 收到 Engineer 交付物后执行的验证审查。目标不是毫无头绪的“找茬”，而是系统地检查交付物是否满足预定标准。
可以这样理解：Engineer 是「写作业的人」，Manager 是「对照答案和评分标准批改的人」。批改完了，Manager 把结果交给用户（老师），用户决定改还是不改、过还是不过。
2.2 双参考机制：Checklist + ISO 标准
当前设计中，VR 最大的特点是双参考：同时对照 Checklist 和 ISO 标准原文。这不是重复劳动——Checklist 是工程实践提炼出来的检查单，ISO 标准是权威依据。二者互补，缺一不可。
只用 Checklist 可能漏掉标准里的新要求；只用 ISO 标准原文，审查效率太低——标准写得太抽象，直接对着审很痛苦，也很容易遗漏具体技术内容。
双参考的工作流程：
1.读取该活动的 Checklist（如 vr_tsc.md），了解完整检查项列表
2.对照 ISO 标准原文，确认每个检查项的条款依据
3.逐项审查 Engineer 的交付物，记录 [Pass] 或 [Fail]
4.如 Checklist 中缺少标准要求的检查项 → 标记「Checklist 缺失」并上报
5.如活动卡的章节引用有误 → 在标准中定位正确章节 → 纠正活动卡 → 上报
一个实际的 VR 检查项示例：
Checklist 条目：
Are TSRs specified in accordance with the FSC and
systemarchitectural design? (ISO 26262-4 6.4.1.1)
审查方法：
对照 FSC 表中的每条安全目标，结合系统架构中安全链路与相关要素，确认 TSR 中有对应的条目。
技术实现。缺一条 → [Fail]。全覆盖 → [Pass]。
简洁、可执行。Manager 不需要理解什么叫「in accordance with」——它只需要对照FSC与架构，看TSR是不是全部有效覆盖。
2.3 VR 的输出格式
Manager 提交给 Head 的 VR 结果必须是结构化的。不能是一段散乱的文字——那就没法批量处理、没法统计、没法给用户看。
VR 结果 — S01 Technical Safety Concept
[Pass] 1. FSC 覆盖完整 — 31 条 FSR 均有对应 TSR
[Pass] 2. 安全机制已指定 — 检测/指示/控制三类齐全
[WARN] 3. 降级策略 — 覆盖了主要场景但缺少上电自检说明
[Fail] 4. 外部接口 — 未列出 I2C 接口的故障模式
→对应条款 ISO 26262-4 6.4.1.1.b
…
汇总：49 Pass / 14 Warn / 1 Fail
注意：[Pass] 不仅意味着通过，还附带了通过的理由——「31 条 FSR 均有对应 TSR」。这让用户不需要打开交付物原文就能理解审查结论的依据。这也是 WP 质量追溯的一部分：每个 Pass/Fail 都有根有据。
2.4 VR 结果必须写入文件
这是我在实战中暴露的一个重要教训。早期 Manager 通过 session 消息直接提交 VR 结果——结果长消息被截断，80+ 项检查用户只看到前 40 项，漏掉的恰好包含 Fail 项。
基于这个lesson learn，我新增了一条Rule：Manager 执行完 VR 后，必须将完整的 VR 结果写入文件（如 `VR_Result_vX.X.md`），再通知 Head。
Head 读取文件内容后转交给用户。
Manager 执行 VR → 写入 VR_Result_vX.X.md → 通知 Head → Head 读取文件 → 转用户
这个机制解决了三个问题：
·防截断：不受消息长度限制，全部检查结果完整保留
·可追溯：每轮 VR 结果作为独立文件存档，版本演进清晰可查
·可审计：用户可以在任何时候打开文件查看完整审查记录，不需要翻阅聊天记录
2.5 Task 措辞规范 — 不要给 AI 留解读空间
Head 向 Manager 下发任务时的措辞，直接影响 Manager 是否执行 VR。
我踩过一个非常具体的坑：
问题描述： Task 中写了「提交 Manager VR」——Manager 将此解读为「让 Engineer 把东西交给 Manager 做 VR」，于是两次直接跳过 VR，把 Engineer 的交付物原封不动转给 Head。
Root Cause： 「提交 Manager VR」在语法上可以被解读为对第三者（Engineer）的指令，而不是对 Manager 本人。AI 不会「理解意图」——写什么它就做什么，写模糊了它就猜。而猜的方向大概率不是你想要的。
新增的Rule：
·✅ 对 Manager 的 task 必须用第二人称直指：你必须执行 VR、你自己打开 {文件} 对照 checklist 逐项审查
·❌ 禁用模糊表述：提交 Manager VR、进行 VR 审查、确认一下
·✅ 明确指定操作对象与动作：打开 {文件路径}，对照 {checklist路径} 逐项检查
·✅ 明确指定产物：将 VR 结果写入 VR_Result_vX.X.md
总结：AI Agent中，提示词要像写代码一样精确，你的提示词一定要清晰描述你的意图，绝对不要寄希望于 AI “应该可以正确理解你的想法”。
2.6 Manager 不做的事
以下行为 Manager 绝对不能做——做了就会破坏审查的独立性，整条 VR 链就没意义了：
·不直接修改 Engineer 的交付物——只能列出问题，不能动手改。
·不做通过/不通过决定——那是用户的权力。
·不跳过 VR 直接让 Engineer 修改——必须先给用户看 VR 结果，用户说了算。
·不做流程要求外的审查——Manger的审查必须严格遵循活动卡checklist和ISO 26262，最大可能避免幻觉。
───────────────────────────────────────
三、用户判定与修改循环
3.1 为什么用户必须在循环里
功能安全有一个核心要求：最终提交的safety case是需要人来签字的。
（这应该也是各位同仁不用担心岗位被AI彻底取代的根本原因😄）
Head 收集 VR 结果后，必须反馈给用户。用户看到的是结构化的 VR 结果，然后做二选一：
·「通过」 → VR 结束，进入下一阶段（判断是否需要 CR）
·「修改 X、Y、Z」 → 启动修改循环
这个设计的关键在于：用户不需要看懂每一条 ISO 条款来判断。Manager 已经把不满足项和条款依据列清楚了——用户只需要判断「这些不满足项我能接受吗？」
一句话：AI 负责比对和整理，人负责决策。
3.2 修改循环的完整链路
当用户决定修改时，修改意见必须原封不动地沿链路传递。任何环节都不能自行解释或添加（充分避免AI自由发挥）：
User: “修改 #1: 补充上电自检的安全机制
修改 #2: 增加 I2C 接口故障模式分析”
↓
Head → Manager: 转发原文，不加不减
↓
Manager → Engineer: 转发原文，不加不减
↓
Engineer: 执行修改 → 提交
↓
Manager: 重新 VR
↓
Head → User: 新 VR 结果
[WARNING] 关键约束：Head 不改内容只转发，Manager 不改内容只传达。Engineer 是唯一执行修改的角色。 任何环节的「善意补充」都可能导致修改偏离用户原意。我实际踩过的坑：Manager 觉得「这个地方显然也应该改一下」顺手加了，结果用户想确认的就是为什么那个地方没改——信息被「好意」污染了。
3.3 修改后的 VR 为什么要全量重做
这里有一个直觉容易忽略的坑：修改 #1 修复了上电自检的安全机制，但它可能不小心引入了与现有看门狗机制的矛盾。如果只复查修改的那几条，这个新引入的问题就漏过去了。
所以这条Rule必须是：每次修改后，Manager 必须全量重新 VR。 即使有 49 条 Pass，也要重新逐条确认一遍。
听着很重？实际运行中，AI 跑完一轮完整 VR 只需 2-3 分钟。全量重做的时间成本远低于漏检一条安全需求的风险成本——后者可能意味着整车召回。
3.4 接口修改时的一致性检查
实战中暴露出一个隐蔽但致命的问题：用户要求修改某个安全接口的 ASIL 等级，Engineer 改了 ASIL 列和 Notes，但忘了同步修改 Signal 列和 Safety Mechanism 列。结果同一个接口在表格的不同列中描述了不同的安全机制——下游 Engineer 读到的是矛盾信息，产出的 TSC 基于错误的前提。
Rule：涉及接口修改时，VR 必须逐行检查一致性：
|
列 |
检查内容 |
|
ASIL |
修改后的等级是否与 FSC/FSR 中的分配一致 |
|
Signal / Data |
信号名称和数据字段是否与 ASIL 变更后的需求匹配 |
|
Safety Mechanism |
安全机制描述是否对应新的 ASIL 等级（如 ASIL 升级后是否需要更强的机制） |
|
Notes |
备注是否反映了本次修改的变更理由和依据 |
检查方法： 修改轮次的 VR 中增加一条专项检查——「接口修改一致性」。逐行对比修改前后的接口表，确认表格中的修改全部同步更新、无矛盾。
这个检查不能自动化——只有熟悉上下文的人（在这里是 Manager）才能判断产出活动的一致性。这也是 VR 审查不可替代的核心价值之一。
───────────────────────────────────────
四、CR 认可评审 — Head 的第二道防线
4.1 什么时候需要 CR
并非所有活动都需要 CR。判断标准很简单：
·直接参考标准第二章节中要求CR的WPs
Head 在 VR 通过后判断是否需要 CR。不需要 CR 的活动直接交付 WP。
4.2 CR 就是认可评审（confirmation review）
CR 的本质就是 ISO 26262-2 §6.4.10 和 Annex C.6 定义的认可评审。它不是技术的二次验证——那是 VR 的职责。CR 关注的是管理层面的问题：这份交付物是否完整、自洽、可追溯、假设合理？如果这些问题的答案都是「是」，那么认可通过。
CR 和 VR 必须完全解耦。CR 不引用任何技术标准（Part 4/5/8/9），只引用 Part 2 的认可评审条款。原因很简单：如果 CR 也看 Part 4，那和 VR 有什么区别？两层审查的意义就在于分工——各看各的，不重叠、不遗漏。
CR 审查的四个维度：
|
审查维度 |
检查内容 |
示例 |
|
交付物完整性 |
要求的产出是否齐全 |
TSC 产出要求含 SSI 和 FSR 两章，是否都有？ |
|
论证逻辑自洽性 |
文档内部有无矛盾 |
Chapter A 说 MCU 负责看门狗，Chapter B 说由外部 IC 负责？ |
|
上下游一致性 |
输入需求是否在输出中被满足 |
FSC 有 5 条安全目标，TSR 覆盖了几条？ |
|
假设明确性 |
假设是否陈述清楚、是否合理 |
「假设 MCU 不故障」——这个假设合理吗？需要论证 |
4.3 CR 不审查什么
明确 CR 的边界同样重要——知道不该看什么和知道该看什么一样关键：
·不重复 VR 的检查项——VR 已经查过的东西 CR 不再查。两遍检查同一个东西没有意义。
·不审查 Manager 的 VR 质量——那是用户判断的事。CR 不是给 VR 打分。
·不审查格式/措辞/排版——表面问题不影响安全，不值得 CR 花时间。
·不审查技术细节的正确性——那是 Engineer 和 Manager 的职责。CR 是管理评审，不是技术评审。
4.4 CR 的输出格式
和 VR 一样，CR 结果必须是结构化的：
CR 结果 — S01 Technical Safety Concept
[Pass] CR-1: 交付物完整 — 含 SSI(A.1-A.3) + FSR(B.1-B.X)
[Pass] CR-2: 论证自洽 — A.2 与 B.7 对 MCU 责任的描述一致
[Fail] CR-3: 上下游一致性 — FSC 安全目标 SG-03 (Brake
Overtravel)在 TSR 中无对应条目
[Fail] CR-4: 假设不明确 — “系统在正常供电下工作”
未说明供电范围、未论证合理性
…
不满足项汇总：CR-3, CR-4（共 2 项）
CR 结果同样送到用户面前。用户判断 CR-3 和 CR-4 是否可接受，或者需要打回到 Engineer 那里再改一轮。至此，一份 WP 经过 VR → 用户判定 → （修改循环）→ CR → 用户判定，才算真正完成交付。
───────────────────────────────────────
五、Checklist 体系与维护
5.1 Checklist 的本质
Checklist 是 VR/CR 的执行脚本。它把 ISO 标准中的抽象条款转化为可以逐项打勾的检查项。没有 Checklist，Manager 只能凭「记忆」审查——而 AI 的「记忆」跑不了多远就会丢东西，不可靠。
通俗地讲：Checklist 就是 Manager 手边的那份「批改清单」，不用每次审查都去翻 800 页的标准。
5.2 Checklist 缺失检测
这是体系的一个重要自我保护机制。Manager 执行 VR 时，如果发现 ISO 标准要求的检查项在 Checklist 中缺失，必须上报：
Checklist 缺失：S01 活动 / 标准要求检查：
ISO 26262-4 6.4.2.3 (潜伏故障预防) /
当前 checklist：vr_tsc.md
→ 用户决定：补充 checklist / 标注”此项不检查”
这个机制让 Checklist 不会因为疏忽而遗漏关键检查项，同时让用户对「为什么不查某项」有明确的认知和决策权。你不能假定 Checklist 是完美的——它可能漏东西，但漏了就得让用户知道。
───────────────────────────────────────
六、开口项机制（Lessons Learned）
这个机制可以通过安装Self-improvement这个skill来实现。
6.1 为什么需要开口项文件
先说一个我遇到的真实案例：
首次运行 TSC（Technical Safety Concept），Engineer 产出了 97 条 TSR，其中有 10 处违反了 R11（单句规则）——一条 TSR 包含多个「shall」，把多个安全需求塞进了同一句话。我们在 AGENTS.md 里写明了 R11，但 Engineer 忽略了。
Root cause： AGENTS.md 是通用规则文件。Agent 倾向于关注头部的硬指令（「你必须做 X」「你不能做 Y」），尾部堆砌的具体规则（比如需求编写规范）很容易被「略读」，这也是为什么很多人在使用Agent时，上下文越写越长，但实际效果越来越不明显的原因。
结论： 知识类规则不能放在 AGENTS.md 里。必须有专门的开口项文件，在执行具体活动时强制读取。
6.2 `-lessons.md` 文件的设计
每个 Engineer 活动卡配一个对应的 -lessons.md 文件：
# 01-tsc-lessons.md
# 历次 VR/CR 开口项
| # | 来源 | 问题 | 强制规则 |
|—|——|——|———-|
| 1 | VR#5 | TSR 含多个 shall | R11: 每条 TSR 只能有一个 shall |
| 2 | VR#12 | 使用了”should”弱词 | R5: 所有需求用 shall |
| 3 | CR#6 | 降级策略不完整 | 必须覆盖所有安全状态的过渡路径 |
…
6.3 开口项的强制读取
Head 在 spawn Engineer 的 task 中必须包含这个提醒：
[IMPORTANT]
Before starting, read: {yourWorkspace}/activities/01-tsc-lessons.md
This file contains ALL issues found in previous VR/CR rounds.
DO NOT repeat any of the mistakes listed there.
使用lesson learn机制后，效果非常显著：
第一轮 VR 发现 10 处 R11 违规。修复后第二轮仍然有残留——因为 Engineer 没记住。建立 -lessons.md 并强制执行后，第三轮零 R11 违规。9 条规则全部贯彻。
6.4 开口项的更新
每轮 VR/CR 结束后，新增的开口项写入对应的 -lessons.md：
·VR 发现的新问题 → Manager 写入
·CR 发现的新问题 → Head 写入
·每轮叠加，不覆盖历史记录
这样 -lessons.md 就成为该活动的「踩坑百科全书」。新 Engineer 被 spawn 出来执行活动时，先读这份文件，就能避免所有已知的坑。这也是 WP 质量持续改进的关键：不靠记忆，靠文件。
从长期主义的角度出发，lessons.md中的上下文也会越来越长，Agent使用到一定程度后，依然有潜在漏条目的风险，在这个基础上有必要针对内容进行二次优化，二次优化手段会在后续的文章中进行阐述。
───────────────────────────────────────
本篇小结
本篇建立的质量保障体系是 FUSA Agent 的最后一公里的质量关卡。核心机制如下：
|
# |
机制 |
说明 |
|
VR |
验证审查 |
Manager 对照 Checklist + ISO 标准，逐项审查 Engineer 交付物 |
|
用户判定循环 |
决策闭环 |
VR 结果必须经过用户确认。修改链路 Head→Manager→Engineer 零损耗传递 |
|
CR |
认可评审 |
Head 按 ISO 26262-2 确认交付物完整性、逻辑自洽性、上下游一致性、假设明确性。与 VR 完全解耦，不重复技术验证 |
|
Checklist 维护 |
自我修正 |
自动检测缺失项 + 章节纠错机制 |
|
开口项机制 |
持续改进 |
-lessons.md 强制读取，确保不重犯历史错误。每轮 VR/CR 后增量更新 |
有了这套机制，AI 不再是「帮你写需求然后你自己看着办」——而是有明确质量标准的工程流水线。Agent会通过不同角色的职责定义，自动进行VR 和 CR，并列出所有不满足项。
你只需要决定：接受还是修改。
───────────────────────────────────────
*下一篇：Part 4 — 知识体系建设：ISO 标准库、活动卡架构、Checklist 自动化*
────────────────────────────────────────
© 2026 本文档内容受知识产权保护，未经作者许可，严禁以任何形式转载、复制或用于商业用途。