一人成军_从零搭建基于 OpenClaw 的功能安全 Agent(4)知识体系搭建-夜雨聆风

一人成军_从零搭建基于 OpenClaw 的功能安全 Agent(4)知识体系搭建

PDF 转 Markdown 全流程 · 活动卡框架设计 · 标准章节精确引用 · Lessons Learned 机制

──────────────────────────────────────

前三篇搭好了多 Agent 架构和 VR/CR 审查机制——Agent 能跑起来了，Spawn、调度、审查闭环都有了。

但一个扎心的问题随之而来：

Agent 执行安全活动时，依据是什么？怎么才能确保Agent不会“已读乱回”？

以TSR举例，它输出的 TSR 格式从哪来的？需求写”shall not exceed 100ms”这个 100ms 从哪来的？如果不是有明确的参考依据和可靠的引用来源，怎么确保TSR输出的需求是与目标系统相匹配的？

总而言之，Agent不是“阿拉丁神灯”，不是单靠许愿就能执行并且输出可靠又准确的安全活动产物。

正所谓大海航行靠舵手，而我们这些经验丰富的功能安全从业者，才是带领Agent顺利靠岸的“舵手”！

而这一章节，就是与大家分享如何制作一张准确又可靠的“航海图”，给Agent指引正确的航行方向。

整篇围绕五个核心主题展开：

1. PDF → Markdown 转换：把 ISO 标准从”机器看不懂的 PDF”变成”AI 能精确定位的结构化文本”

2. 不同活动的标准章节引用：TSC 查 Part 4，安全计划查 Part 2，SSR 查 Part 6——每张活动卡精确到子条款级别

3. 活动卡的搭建与内容设计：从空白到 63 张卡，五个核心字段的设计逻辑和迭代过程

4. Lessons Learned 的定义与引用思路：开口项不是备忘录，是强制执行的质量约束机制

5. 活动卡框架全景：四角色、三层级的完整架构

这五个主题不是并列的，而是一条递进链：有了 MD 标准文本→才能精确引用→才有活动卡内容→跑出开口项→形成完整框架。

──────────────────────────────────────

一、PDF → Markdown 转换：知识体系的基石

1.1 为什么不能直接用 PDF

很多人在搭建 AI 知识库时第一反应是把 PDF 直接丢进去，这个做法是完全错误的，原因有三：

第一，检索效率极低。 LLM 对 PDF 的文本提取不稳定——它看到的不是原生的文本流，而是经过 PDF 解析器”猜测”排列后的碎片。表格经常被拆散成混乱的单词列表，条款编号（如 §6.4.1.1）可能被解析为两行独立文本。而功能安全最依赖的就是条款编号的精确性——少一个子编号就可能指向完全不同的要求。

第三，无法二次加工。直接使用 PDF 意味着每次引用标准都必须重新解析——工程师 A 看一遍，工程师 B 又看一遍。更致命的是，不同解析轮次可能产生不一致的结果：第一次提取的 §6.4.1 有 3 段，第二次只剩 2 段——因为 PDF 文本布局在不同分辨率下表现不同。

1.2 选型：为什么是 MinerU

选工具时对比了几个主流方案：

方案	表格保留	公式保留	标题层级	条款编号	离线部署
PyMuPDF 直接提取	❌ 拆散	❌ 丢失	❌ 无层级	⚠️ 不稳定	✅
Marker (开源)	⚠️ 部分	✅	✅	⚠️ 部分	✅
MinerU	✅完整	✅ 完整	✅ 完整	✅ 保留	✅
商业 API (Mathpix等)	✅	✅	✅	✅	❌ 需联网

最终选了 MinerU，核心理由三条：

表格结构不丢失：ISO 26262 里有大量矩阵式表格——ASIL 分解表、验证方法选择表、硬件架构度量目标值表。MinerU 的输出里，这些表格是完整的 Markdown table，LLM 可以直接按行列索引读取。

条款编号完整保留： §6.4.1.1 → §6.4.1.2 → §6.4.1.3 的层级关系在 Markdown 中以标题层级（## → ### → ####）呈现，AI 可以沿着标题树精确导航到目标子条款。

离线部署，数据不出本机：转换过程完全依赖本机，所有转换的文档不会在云端留存，从根本上确保数据安全。

1.3 MinerU 的实际部署与调用

MinerU 的安装走 Conda 虚拟环境，避免污染系统 Python：

# 安装（在独立环境中） conda create -n mineru python=3.10 conda activate mineru pip install –upgrade pip pip install uv uv pip install -U ‘mineru[all]’ # 验证 mineru –version

安装后，我们封装了一个 Python 调用脚本 pdf_parser.py，把 MinerU 的命令行接口包装成可编程的 API：

# 核心调用逻辑（简化版） def parse_to_markdown(file_path, output_dir): cmd = [ “mineru”, “-p”, file_path,# PDF 路径 “-o”, output_dir,# 输出目录 “-b”, “hybrid-auto-engine”,# 混合引擎（自动选择最优） “-l”, “en”,# OCR 语言 “-f”, “true”,# 启用公式识别 “-t”, “true”,# 启用表格提取 “-d”, “cpu”,# 强制 CPU（避免 GPU 兼容问题） ] result = subprocess.run(cmd, capture_output=True, text=True, timeout=3600) # 读取输出的 .md 文件 md_file = list(Path(output_dir).rglob(“*.md”))[0] return md_file.read_text()

实际转换命令示例：

python pdf_parser.py ‘{ “name”: “pdf_to_markdown”, “arguments”: { “file_path”: “/home/administrator/iso-26262-4.pdf”, “output_dir”: “/home/administrator/.openclaw/references/standards/” } }’

一份 100 页左右的 ISO Part（如 ISO 26262-4），MinerU 转换耗时约 3-5 分钟，输出 ~107KB 的 Markdown 文件。

1.4 转换后的质量检查

转换完不是直接扔进 references/ 就完事了。每一份转换后的 MD 都要过三道检查：

第一道：结构完整性。用 grep 检查关键章节编号是否全部出现。例如 ISO 26262-4 的 §6.4.1 到 §6.4.9 共计 9 个子章节——如果缺了 §6.4.5，说明转换有遗漏，需要重跑或手动补齐。

grep -c “^## 6\\.4\\.” iso-26262-4.md# 应返回 ≥9

第二道：表格可读性。抽查 3-5 个关键表格，确认 LLM 能正确解析行列对应关系。ISO 26262-5 Table 4（SPFM targets）是最常用的——如果这个表格的数值对不上原始 PDF，后面所有 FMEDA 计算都会偏。

第三道：公式完整性。 ISO 26262 Part 5 和 Part 11 里有概率计算公式（如 PMHF 的 λ 推导）。MinerU 的公式引擎使用 LaTeX 渲染，输出是 $…$ 或 $$…$$ 包裹的 LaTeX 数学表达式——确认公式没有被截断或错位。

1.5 当前转换清单

截至撰写时，已完成 8 份 ISO 26262 Part 的转换：

references/standards/ ├── iso-26262-2.md(133KB, 2466 lines) — 功能安全管理 ├── iso-26262-4.md(107KB, 2143 lines) — 系统层面产品开发 ├── iso-26262-5.md(256KB, 4655 lines) — 硬件层面产品开发 ├── iso-26262-6.md(161KB) — 软件层面产品开发 ├── iso-26262-7.md( 51KB) — 生产与运营 ├── iso-26262-8.md(163KB) — 支持过程 ├── iso-26262-9.md( 77KB) — 安全分析 ├── iso-26262-10.md(235KB) — 指南 └── ISO_26262_11.md(607KB) — 半导体安全指南

一份 Part 一个文件，命名规则 iso-26262-N.md。文件层面不写版本号——版本号信息记录在每张活动卡的 Standard References 字段里（如 ISO 26262-4:2018 §6.4.1.1），文件和卡各司其职。

1.6 转换的角色分工

一个重要的设计原则：Head 是唯一执行 PDF→MD 转换的角色。

Manager 和 Engineer 只接触 `references/` 下的 .md 文件，从来不见 PDF

每份标准只转换一次，全员共享同一份 MD

避免了”A 用 PyMuPDF 提取、B 用 MinerU 提取”导致的不一致

这条分工原则很简单：文本源头必须单一，否则下游的每一次引用都有失控的风险。

──────────────────────────────────────

二、不同活动的标准章节引用：精确定位是合规性的底线

2.1 核心设计原则：不让 AI 凭记忆引用标准

我在实际运行中至少纠正了三次错误的条款编号。AI 对 ISO 标准的”记忆”不可靠——它会自信地编造一个看起来很合理的子条款号（如 §6.4.5），但实际上那个条款根本不存在，或者内容完全不同。

（实话实说，AI实在太会胡编乱造了😄）

在普通对话中这可以一笑而过，但在功能安全 WP 中，引用错误条款等于整份产出作废。因为这个错误不只是”引错了编号”——它意味着 Engineer 是根据一个想象的条款在推导安全需求，产出的内容没有真实的合规依据。

解决方案是一条不可妥协的规则：

每条活动卡必须明确要求 `## Standard References` 字段里，必须精确写明该活动需要遵循的所有 ISO 条款——精确到子条款级别（§X.X.X）。Engineer 收到任务后，第一件事是按照活动卡里的条款编号，去 references/standards/ 下的对应 MD 文件中搜索并阅读完整原文。**

不是”AI 应该知道 ISO 26262-4″，而是”去 MD 文件里读 §6.4.1.1 到 §6.4.1.9，一字不漏”。

2.2 不同活动 → 不同标准 → 不同章节

下表来自实际运行的四张活动卡，展示了不同层面的活动如何精确引用不同的标准章节：

活动	角色	主要标准引用
TSC 制定 (01-tsc)	Sys Engineer	ISO 26262-4:2018 §6.4.1–§6.4.9（TSR+TSC+架构）; ISO 26262-8:2018 §6（需求管理）; ISO 26262-5:2018 §7（硬件指标）; ISO 26262-9:2018 §7-8（安全分析）
安全计划(create-safety-plan)	Process Engineer	ISO 26262-2:2018 §6.4.6（安全计划全部要求）
SSR 制定 (specify-ssr)	SW Engineer	ISO 26262-6:2018 §6（SSR 全流程）
硬件安全分析 (hw-safety-analyses)	HW Engineer	ISO 26262-5:2018 §7.4.3（硬件安全分析）; ISO 26262-9:2018 §8（FTA/FMEA 方法）; ISO 26262-9:2018 §7（DFA）
TSC 认可评审 CR (cr-tsc)	Head	ISO 26262-2:2018 §6.4.10, Annex C.6（仅 Part 2 — 认可评审不涉及技术条款）

注意上表最后一行：VR 和 CR 引用的标准完全不同。

·VR（技术验证）引用 Part 4/5/6/8/9 —— 验证技术产出是否满足标准技术要求

·CR（认可评审）只引用 Part 2 —— 判断是否提供令人信服的证据

2.3 为什么 TSC 要引用四份标准

以 TSC（技术安全概念）活动卡为例，它的 Standard References 不是只写 Part 4——它引用了四份不同的标准：

## Standard References ISO 26262-4:2018 §6.4.1, §6.4.2, §6.4.3, §6.4.4, §6.4.5, §6.4.6, §6.4.7, §6.4.8, §6.4.9 ISO 26262-8:2018 §6 ISO 26262-9:2018 §7, §8 ISO 26262-5:2018 §7

拆开看每份标准的用途：

**Part 4 §6.4.1–§6.4.9**：TSR 规格书的全部 9 个子要求——从导出安全需求（§6.4.1）、指定安全机制（§6.4.2）、开发系统架构（§6.4.3）、到验证方法选择表（§6.4.9 Table 2）

**Part 8 §6**：安全需求的规范与管理——需求属性（ASIL、状态、验证方法等）的定义和格式要求

**Part 9 §7-8**：安全分析方法论——DFA（§7 依赖故障分析）、FTA/FMEA（§8 归纳/演绎分析）——TSC 中的安全分析衍生需求必须符合这些条款

**Part 5 §7**：硬件架构度量——SPFM、LFM、PMHF 的目标值定义——TSC Chapter B 中为每个 FSR 分配的硬件指标必须来自这里的 Tables 4/5/6

如果活动卡只写 Part 4，Engineer 产出的 TSC 会：

漏掉 Part 8 §6 要求的完整需求属性字段（导致 VR 检查项 #44 不通过）

漏掉 Part 9 安全分析衍生需求（导致 TSC 只有功能需求没有安全机制需求）

漏掉 Part 5 的硬件指标目标值（导致 Chapter B.x.2 Hardware Metrics 为空）

每一份标准的每一个条款，都在最终产出物里对应着具体的章节内容。这不是”多引了更严谨”，而是”少引了就会缺内容”。

不要担心引用过多导致VR结果报错，别忘了判断VR是否通过的决策者是你。

2.4 跨活动标准引用的一致性约束

不同活动引用同一份标准的同一章节时，必须保持一致。我通过两个机制保证这一点：

机制一：严禁在下发 task 时重复写标准引用。让 Engineer 自己去活动卡里读条款编号。下发链路中重复写标准编号极易引入不一致——Head task 里写了旧版本号，Manager 转述时又抄错了子条款号，Engineer 收到的是第三手信息，和活动卡原始引用已经对不上了。

✅ 正确：只指定”按活动卡执行” Task: 按活动卡 `01-tsc.md` 执行 TSC 生产（Stage 2）。标准引用见活动卡的 `## Standard References` 字段。 ❌ 错误：在 task 中重复写标准引用 Task: 按 ISO 26262-4 §6.4.1–§6.4.3 推导 TSR… → 如果活动卡后来加了 §6.4.4–§6.4.9，这个 task 就成了过期信息

机制二：每新增一份标准 MD 文件，全量对齐所有引用该标准的活动卡。比如转换完 Part 9 MD 后，发现之前只引了 “ISO 26262-9:2018 §8″，但 DFA 要求实际在 §7——不立即修正，相关活动的 VR 就会发现”明明标准里有要求，产出物里没体现”。

──────────────────────────────────────

三、搭建活动卡：从设计理念到实践

3.1 活动卡的本质：不是 Prompt，是结构化任务规范书

很多人第一反应是把活动卡理解成”一个写好的 Prompt”。这个理解偏差会带来一系列后果——因为 Prompt 是给 AI 的”提示”，而活动卡是给整个流水线的”接口协议”。

一张活动卡回答五个核心问题，对应五个字段：

注意”使用者”这一列——每个字段至少有两个角色在使用。活动卡不是只为 Engineer 存在的，它是整条流水线上所有角色共享的”接口协议”：

Prerequisites（Head 调度用） ↓ Description + Standard References（Engineer 执行用） ↓ Output（Engineer 产出目标 + Manager 完整性检查） ↓ Checklist（Manager VR 用 + Head CR 用）

3.2 一张实际活动卡的完整解剖

一张完整的活动卡应具备以下子章节：

Execution Flow 放在最上面。 TSC 活动有两个阶段（Stage 1: 审计 → 用户确认 → Stage 2: 生产），这个流程在活动卡的第一屏就必须完全清晰。不能让 Engineer 翻到卡片底部才发现”哦，还有个阶段”。

Output Structure 定义了产出物的章节骨架。这是活动卡和 WP 的直接桥梁——Chapter A（SSI）有 A.1/A.2/A.3 三个子章节，Chapter B 有 B.x.1/B.x.2/B.x.3 三个要素。Engineer 照着这个结构输出，产出的 .md 文件天然就是 WP 对应章节的草稿。

Standard References 精确到子条款。不是 “Part 4″，是 “§6.4.1, §6.4.2, §6.4.3, §6.4.4, §6.4.5, §6.4.6, §6.4.7, §6.4.8, §6.4.9″。每一节都要有，因为每一节都对应产出物的具体内容段。

Checklist 引用是文件名，不是模糊描述。“vr_tsc.md” 是一个具体可打开的文件——Manager 不用猜测”该用哪个 checklist”，直接打开这个文件逐项勾。

3.3 活动卡的三层级体系

当前体系不是一堆扁平的卡片列表，而是一个三层级、四角色的树状结构：

每个 Engineer 活动 (如 01-tsc) ├── 对应的 -lessons.md 文件（开口项记录，Engineer 执行前必读） ├── 对应的 Manager VR 活动卡（如 03-vr-tsc） │└── 对应的 VR checklist（如 checklists/vr_tsc.md） └── 对应的 Head CR 活动卡（如 05-cr-tsc） └── 对应的 CR checklist（如 checklists/cr_tsc.md）

示例：以 TSC 活动为例的完整三层卡片链：

三层级的关系不是”一个干完另一个才开始”的串行——而是：

活动卡定义了产出标准（Engineer 照着做）

VR checklist 对照标准检查技术质量（Manager 对照 Part 4/5/8/9 逐项审）

CR checklist 对照 Part 2 检查合规证据（Head 判断”是否提供令人信服的证据”）

这三个层级的设计保证了一条底线：同一份产出物，被三个不同角色用三个不同视角审查过。没有任何一个角色能单独拍板”这没问题”。

3.4 活动卡的迭代演进

实操过程中，不需要一口气定义所有活动卡，毕竟每一个功能安全活动的特性不同，需要引用的特定标准和规范也不同（有时候也包括模板），我们可以逐活动进行推进。

3.6 活动卡的维护规则

活动卡是活文档，每跑一次流程都可能需要更新。四条维护规则：

1. 章节引用错误 → 执行者自行在标准 MD 文件中定位正确章节，纠正活动卡，并上报 Head

2. Checklist 缺失 → VR/CR 执行时发现标准要求的检查项在 checklist 中缺失，立即上报

3. Prerequisites 不完整 → 发现缺前置依赖时，补充并通知全部下游活动卡

4. 不要因为”AI 应该知道”而省略引用——把一切写明确，写到任何一位 Engineer 拿到卡就能独立执行的程度

──────────────────────────────────────

四、Lessons Learned：为特定活动定制的”开口项”机制

4.1 问题起源：AGENTS.md 里的规则没人看

在最早的设计中，需求编写规则（如 R11 单句规则、R5 弱词规避）是写在 Engineer 的 AGENTS.md 文件里作为”通用规则”的。

实际情况： Engineer spawn 后读取活动卡、读取标准、开始执行——AGENTS.md 里的通用规则被系统提示冲刷到了上下文底部，Engineer 根本”看不到”。产出的 TSR 里遍地都是多 shall 句子和弱词，Manager VR 逐条打回。

花了两轮返工后我意识到一个根本问题：通用规则放在通用文件里 = 特定活动看不到。解决问题最好的办法不是把字体加粗或把规则提前——而是把规则绑定到活动卡上。

4.2 Lessons Learned 文件的设计

每个工程师活动活动卡旁都有一个同名的 -lessons.md 文件，例如：

activities/ ├── 01-tsc.md ├── 01-tsc-lessons.md← 开口项记录 ├── 02-perform-system-safety-analyses.md ├── 02-perform-system-safety-analyses-lessons.md← 开口项记录 └── …

这个文件不是”事后总结文档”，它是 Engineer 执行活动前必须读取的强制性前置文件。来看 01-tsc-lessons.md 的实际结构：

# 01-tsc 活动开口项记录 ## 需求编写规则（强制执行）以下规则来自 How_to_Write_NL_Requirements_v17.1.md， **每条 TSR 必须逐条满足，不得合并、不得跳过**： | # | 规则 | 违反后果 | |—|——|———| | R11 | 每条需求只写一句话，一个段落只含一个 shall 子句 | ❌ 被退回重写 | | R5| 禁用弱词：approximately/maybe/probably/should… | ❌ 被退回修改 | | R16 | 禁用定性形容词：fast/slow/good/robust… | ❌ 被退回修改 | | … | … | … | ## 标准引用规则 | # | 规则 | |—|——| | S1 | TSC 活动的正确标准是 ISO 26262-4:2018 §6.4.1–§6.4.3 | | S2 | 验证方法表引用 ISO 26262-4:2018 §6.4.9 Table 2 | | S3 | PMHF/SPFM/LFM 目标值引用 ISO 26262-5:2018 Tables 4, 5, 6 | ## 历次 VR / CR 开口项（避免重复犯错） | # | 来源 | 问题 | 正确的做法 | |—|——|——|———–| | 1 | VR #4| 未考虑产品配置性/变体 | §A.1 讨论产品变体/校准数据 | | 2 | VR #5| 未做失效×运行模式分析 | 增加组合分析表 | | 3 | VR #17 | 诊断间隔 tbd 过多 | 给出设计目标值 | | … | … | … | … | ## Phase 1 审计（提交前必做） 1. [ ] 解析全部输入文档 2. [ ] 列出所有安全相关接口 3. [ ] 逐条 FSR 绘制完整安全链路 4. [ ] 标记缺口和未文档化假设 5. [ ] 提交 Manager 经 User 确认后进入 Phase 2 ## 自检流程（提交前逐项过） 1. [ ] Phase 1 审计已获 User 确认 ✅ 2. [ ] 每条 TSR 只含一个 shall 子句（R11） 3. [ ] 无弱词（R5 / 对照禁用词表） 4. [ ] 无定性形容词（R16） …

4.3 Lessons Learned 的四种内容类型

分析现有的 lessons 文件，可以归纳为四种内容类型：

类型一：强制执行规则。从参考文档中提取的关键规则，用表格形式列出规则编号 + 规则内容 + 违反后果。Engineer 必须逐条对照自检，不是”建议遵守”而是”不遵守就打回”。

类型二：标准引用纠正。前序执行中纠正过的标准章节号错误。每个纠正都是一条”以后别走错路”的路标。例如 S1：TSC 的正确标准是 §6.4.1–§6.4.3，不要引用 §7.4（那是系统集成测试）。

类型三：历史开口项。 VR/CR 中发现的每一个问题，以”问题→正确做法”的格式沉淀。Engineer 再次执行活动时，这些开口项就是现成的”不要犯同样的错误”清单。例如 #5：”每条假设标注 owner（角色）、status（确认/待确认）、来源”。

类型四：自检清单。把前三类内容转化为 Engineer 提交前的逐项自检。用 [ ] Markdown checkbox 格式，供 Engineer 逐条打勾。这不是”检查别人的代码”——是”检查自己的产物”。提交 Manager 前如果自检清单有任何未勾的项，等于自曝问题。

4.4 Lessons Learned 的生命周期

一张 lesson 从诞生到生效，走以下路径：

VR/CR 发现问题 ↓ Manager/Head 在审查报告中列出具体项 ↓ 如果用户确认需要修改 → Engineer 修改产出物 ↓ 同时：该问题被写入对应活动的 -lessons.md 文件 ↓ 下次执行同一活动时，Engineer 先读 -lessons.md ↓ 问题不会再次出现

关键设计点：只有用户确认需要修改的开口项才写入 lessons。用户说”这条我接受，不改”的项不进 lessons——这是为了保持 lessons 的精简性，只记录真正构成质量问题的项，不把”可接受的风险”和”必须避免的错误”混为一谈。

4.5 案例：FMEA 的 Lessons Learned（FM Source 归属问题）

来看一个具体的 lessons learned 案例——来自安全分析活动：

场景：系统级 FMEA 中，接口分类为 Cat 3（模拟信号）时，FM Source 被错误标注为 MCU SAN（MCU 安全应用笔记）。VR 审查发现这些接口的源端实际上是电源轨和 TFT LCD，MCU 是接收方——MCU ADC 自检是检测机制（Detection Control），不是失效模式来源。

写入 lesson：

效果：下次执行 FMEA 活动时，Engineer 在开始前读到此 lesson → 分类每个接口时先判源端/目标端 → 不会再犯同样的归属错误。

4.6 为什么 Lessons Learned 不能放在 AGENTS.md 里

这是一个反复验证的结论：AGENTS.md 是角色级通用规则，lessons.md 是活动级特定约束。

教训：把活动特定的约束放在角色通用文件里 = 给每个活动都加上不相关的负担。如果你把 R11（单句规则）放在所有 Engineer 的 AGENTS.md 里，SW Engineer 写代码时也会看到”每条 TSR 只含一个 shall”——这条规则对写 C 代码毫无意义，但它占据了上下文窗口。

──────────────────────────────────────

五、活动卡和 WP 的关系

一个经常被问到的问题：这些活动卡和最终交付给客户的 Work Product（WP）是什么关系？

答案是：活动卡的 Output Structure 就是 WP 对应章节的内容骨架，Output 字段标注的产出物文件名就是 WP 章节的具体文件。Engineer 照着活动卡执行，产出的内容自然落进 WP 的对应位置，不需要事后拼装。

这不是事后映射——而是从活动卡设计之初，Output Structure 就是按 WP 的章节结构倒推出来的。 “WP 应该长什么样”直接决定了”活动卡应该要求 Engineer 产出什么”。

──────────────────────────────────────

六、本篇小结

本篇围绕知识体系，从五个递进的维度完成了完整展开：

1. PDF → MD 转换：MinerU 离线部署，保留表格/公式/条款编号，一份标准只转一次，Head 统一执行，全员共享同一份 MD。这是所有精确引用的物理基础。

2. 不同活动的标准章节引用：例如TSC 引 4 项标准（Part 4/5/8/9），安全计划引 1 项（Part 2），SSR 引 1 项（Part 6），硬件安全分析引 2 项（Part 5/9）。每份活动卡的 Standard References 精确到子条款，杜绝 AI 猜测。VR 和 CR 引用完全解耦（VR = Part 4/5/6/8/9 技术条款，CR = Part 2 认可评审）。

3. 活动卡搭建与内容设计：每个活动一张卡，五个核心字段（Description / Standard References / Prerequisites / Output / Checklist），三层级体系（Engineer 执行→Manager VR→Head CR）。活动卡的 Output Structure 天然对应 WP 章节结构。

4. Lessons Learned 机制：每个活动卡配有同名的 -lessons.md，包含强制执行规则 + 标准引用纠正 + 历史开口项 + 自检清单。Engineer 执行活动前必读——不放在 AGENTS.md（角色级通用文件），只放在活动卡旁（活动级特定约束）。

下一篇将进入实战——完整运行一次从 IC 安全手册分析到 TSR 规格书输出的全流程，展示这个体系从输入到产出的每个环节。

──────────────────────────────────────

Next: Part 5 — 实战实例：完整 S17→TSC 全流程演示

────────────────────────────────────────