问题：AI 拆任务时，缺的不是“知识”，是“优先级”

工程师用 AI Agent 一段时间后，会撞到同一堵墙：模型不缺知识，缺的是工程优先级判断。

最直接的用法，是把问题直接丢给它：

某个模块异常，帮我分析一下。

AI 会列出十几种可能原因。方向不一定错，但优先级不一定对，建议也不一定适合当前工程阶段。

第二阶段，我加了一层“需求拆解 Agent”——先把口语化想法整理成结构化任务单，再交给执行 Agent 去读代码、改代码、跑检查。这一步有效，但仍然不够：拆解 Agent 是按通用经验做的，它不知道哪个失效后果最严重，哪个路径不能动，哪个检测手段最直接。

也就是说，它能列任务，但未必能列出正确的收敛顺序。

真实工程问题里，难点从来不是“有哪些可能”，而是：

• 哪个风险最严重？
• 哪个失效模式必须先排除？
• 哪些动作不能做？
• 哪些路径已经验证过，不应轻易改？
• 根因不能立刻定位时，下一步该验证什么？

这些判断，普通 prompt 解决不了。

DFMEA 正好是那块缺失的拼图

DFMEA（Design Failure Mode and Effects Analysis，设计失效模式及影响分析）本质上不是一张 Excel 表，而是工程团队对系统失效模式的结构化认知：列举可能的失效、后果、根本原因、现有控制措施、检测手段，并对风险做优先级排序。

它原本就是为了回答“先查什么、先防什么”而存在的工具。

如果把 DFMEA 脱敏后做成风险知识库，再交给需求拆解 Agent 使用，AI 的任务拆解能力会发生质变。

原流程是：

口语化问题 → 通用任务拆解 → 执行 Agent

新流程变成：

口语化问题 → DFMEA 风险知识库 → 风险驱动任务拆解 → 执行 Agent → 验证与闭环

我把这个过程称为：风险驱动的任务接口设计（Risk-Driven Task Interface）。

为什么是 DFMEA，而不是 FTA、Checklist 或事故库

DFMEA 不是唯一的工程风险知识形态。FTA、Checklist、事故库也都有价值，但它们解决的问题不同。

这几类知识形态是互补关系，不是竞争关系。

一个更完整的 AI 工程协作流程，可以这样组织：

口语化问题   ↓事故库快速匹配：这个问题以前遇到过吗？   ↓DFMEA 风险库做拆解：按风险优先级出任务单   ↓执行 Agent 落地   ↓FTA 做根因收敛：确认是哪一支   ↓Checklist 守住提交门：确保改动可发布

DFMEA 最适合放在中间这一步：把模糊问题转成有优先级的任务清单。

FTA 太重，事故库覆盖不全，Checklist 不抓优先级。DFMEA 的优势在于，它原本就是围绕“设计中可能出现哪些失效、后果多严重、如何预防和检测”来组织的。

当然，DFMEA 也有两个真实弱点：

• 很多团队的 DFMEA 是为审计写的，从不更新。 喂给 AI 之前，先确认它没有变成死文档。
• DFMEA 抓的是“预想中的失效”，真实 bug 中相当比例是“没预想到的”。 被 DFMEA 锚定后，AI 可能比无约束时更难发现盲区。这就需要事故库补充，它专门记录“原 DFMEA 没覆盖到的失效”。

三层结构：工程资产不能无差别暴露给 Agent

这里有一个容易被忽略的边界：DFMEA 是工程资产，不能整张丢给所有 Agent。

我把它拆成三层。

第一层：完整 DFMEA（私有）

这是原始工程资产，可能包含真实设计信息、失效后果、检测盲区、改进措施。它应该作为本地私有工程资产保存，不默认交给通用 Agent 或执行 Agent。

第二层：脱敏风险知识库（给拆解 Agent）

去掉项目细节，只保留通用失效模式、典型现象、优先检查路径、禁止动作、推荐验证方法。

这是需求拆解 Agent 的“思考脚手架”。

它不需要知道完整设计，只需要知道：遇到某类现象时，哪些失效模式优先级更高，哪些动作不能做，哪些证据最值得先收集。

第三层：当前任务片段（给执行 Agent）

执行 Agent 不需要看到完整风险库，只需要拿到本轮任务相关的内容：

• 风险映射
• 检查步骤
• 禁止事项
• 输出要求
• 验收标准

完整工作流可以这样组织：

完整 DFMEA（本地私有）       ↓ 脱敏抽取脱敏风险库（拆解 Agent 加载）       ↓ 按需切片当前任务单（执行 Agent 执行）       ↓ 产出日志 / diff / 测试结果（人工验证）

AI 可以使用工程知识，但不应该拿到完整设计底牌。交给它的是当前任务所需的风险判断，而不是完整工程档案。

脱敏风险库长什么样

脱敏风险库不是把原始 DFMEA 原样复制一份，而是把其中的工程风险知识抽象出来。

一个失效模式可以设计成类似下面的结构：

- id: FM-004name: 故障锁存未按预期复位，输出保持禁用category: protectionphenomena:- 故障源已消失，系统仍不允许重启- 软件状态显示允许运行，实际无输出- 上层 fault flag 已清，底层保护标志仍置位causes:- 锁存类型与预期不一致- 软件清除时序错误- 底层触发源仍持续存在- 上层状态清除与底层保护清除不同步severity: highdetectability: lowpriority_hint: P1diagnostic_order:- 读取底层保护标志原始值- 确认触发源当前状态，而不是只看历史标志- 沿调用栈核对清除序列- 对比异常通道与正常通道的清除路径forbidden:- 不得在不清楚锁存源的情况下盲目清标志- 涉及功率级或安全边界时，必须先确认硬件条件再尝试恢复- 不得通过屏蔽保护来证明软件路径正确verification:- 故障源消失后，所有可观测保护链路均清零，再允许恢复- 恢复动作应可重复，不依赖下电重启related:- FM-007- FM-011

这里有几个设计原则。

1. phenomena 是反向索引

Agent 拿到现象描述时，要靠这个字段做“问题 → 失效模式”的映射。

所以现象不要写成教科书定义，要尽量接近工程师真实描述。例如“状态显示允许运行，实际无输出”比“输出控制异常”更有检索价值。

2. severity 和 detectability 共同影响优先级

不建议把优先级写死成一个简单公式。严重度、发生可能性、探测难度都要考虑，但最终仍要保留工程师判断空间。

尤其是可检测性低的失效，即使发生概率不高，也应优先排除。因为漏检代价大。

3. forbidden 是硬边界

这是 AI Agent 最容易越界的地方。

任何涉及保护、安全边界、功率级、关键状态机的写操作，都必须先要求验证，再决定是否执行。forbidden 的优先级应高于 diagnostic_order。

4. related 用来描述耦合失效

很多 bug 不是单一失效模式，而是两个或多个模式耦合。例如“状态条件错误”可能与“保护锁存未释放”同时出现。交叉引用能帮助 Agent 避免过早收敛到单一方向。

同一现象，三种拆解方式

下面用一个脱敏案例说明差异。

现象描述

某个控制模块在轻载时进入一种节能模式，以提升效率。问题是：一旦进入该模式，即便负载恢复到正常范围，系统仍不退出，需要重启才能恢复正常调制。

真实根因（事后回看）

退出判定条件使用了经过限幅后的控制变量。一旦该变量被限幅，实测值永远卡在限幅边界，永远跨不过退出阈值。

修复方式是：退出判定改为使用限幅前的原始变量，而不是限幅后的变量。

这是一个典型的“模式退出条件使用了 clamped 后变量”的失效模式。

拆解方式 A：直接问 AI

把现象直接丢给 AI，通常会得到一份“可能原因”列表：

可能的原因包括：

1. 节能模式状态变量被卡住
2. 负载检测信号异常
3. 输出配置异常
4. 采样链路异常
5. 保护误触发
6. 参数配置错误
7. 温度或其他限制条件触发
8. 退出条件判定逻辑问题
9. 中断或调度问题……

方向不一定错，但问题是：列表平铺，没有优先级。根因虽然在列表里，但位置靠后。工程师如果按顺序排查，前面大量方向都会消耗时间。

拆解方式 B：通用任务拆解 Agent

如果先让一个通用拆解 Agent 结构化问题，结果会好很多：

采样组：确认采样在轻载和负载恢复时是否正常状态组：确认节能模式状态变量在负载恢复时是否更新保护组：确认是否有保护或限制条件误触发配置组：对比模式参数与设计意图执行组：确认输出刷新在状态变化后是否执行

这比直接问 AI 好，因为它已经把任务分组了。

但问题仍然存在：每组内部还是平铺，没说先看哪一组，也没说状态组里应该先核查“退出判定使用的是哪个变量”。

拆解方式 C：DFMEA 风险驱动拆解

当拆解 Agent 加载风险库后，会先做现象映射。

例如，将“进入某模式后无法退出”映射到候选失效模式：

• FM-011：退出条件使用 clamped 后变量 —— 高度匹配
• FM-007：状态机非法或缺失转移 —— 部分匹配
• FM-004：故障锁存未复位 —— 弱匹配，因为没有明确 fault 记录

然后按风险优先级输出任务：

[P1] 任务 1：核查模式退出判定逻辑  - 同时记录 clamp 前后两个变量值  - 对照判定逻辑使用的是哪一个  - 检查滞回区与限幅区是否重叠  禁止：不得通过加大滞回回差掩盖问题  验证：限幅状态下，退出阈值仍应可被理论达到[P1] 任务 2：核查状态机完整性  - 列出当前模式可接收的所有事件  - 与设计状态图或状态表对照  禁止：不得新增兜底状态隐藏未处理事件[P3] 任务 3：对比正常退出与异常情况下的运行数据

工程师从 P1 任务 1 开始，就能直接命中关键线索：打印限幅前和限幅后的变量，发现判定使用的是限幅后变量。

需要说明的是，以上数字基于单一脱敏案例的事后估算，不是统计意义上的对照实验。单一案例不构成普遍证据。

但它说明了一个机制：当现象与风险库中某条失效模式高度匹配时，DFMEA 驱动拆解有结构性优势。

反过来，如果现象不在风险库覆盖范围内，方式 C 会退化到方式 B，甚至可能被错误匹配带偏。这也是为什么事故库和复盘库必须持续补盲。

边界：这套方法不解决什么

DFMEA 接入 Agent 不是银弹。

第一，它不替代工程判断。AI 给出的优先级仍然需要工程师拍板，尤其涉及保护、安全边界、硬件行为时。

第二，它不解决知识库本身的质量问题。脱敏后的风险库如果结构粗糙、覆盖不全，AI 的输出也会跟着粗糙。Garbage in, garbage out 在 AI 工作流里只会被放大。

第三，它不适合所有场景。全新设计、新功能探索，更多需要参考架构、设计假设和实现方案；而 DFMEA 驱动的方法更适合调试、复盘、健壮性增强、回归排查这类有明确风险面的工作。

第四，它不能绕过验证。AI 给出的根因假设，最终仍然要靠日志、diff、波形、测试结果或台架实验验证。否则，它只是更“像样”的猜测。

因此，必须给 Agent 明确划线：

• 高风险路径先只读分析
• 不确定的硬件连接不得猜测
• 未授权不得修改已验证路径
• 涉及保护或安全边界时，必须先输出验证建议，而不是直接修改
• 无法确认根因时，必须列出需要人工确认的证据

团队落地清单

如果要在团队里跑起来，可以按这个顺序做。

1. 盘点现有 DFMEA

多数团队都有 DFMEA，只是很多文档是为审计写的。第一步不是接入 AI，而是确认它是不是已经成为死文档。

如果文档多年未更新，先不要直接喂给 Agent。

2. 抽出脱敏风险层

不要追求一次覆盖全部风险。

先抽出 10～20 条最关键的失效模式，优先选择：

• 严重度高
• 探测难度大
• 历史上反复出现
• 修改风险高
• 容易被 AI 误建议的场景

3. 建立“已知盲区”清单

把 DFMEA 没覆盖但实际出过事故的失效模式单独列出来。

这就是事故库的初稿，也是防止 DFMEA 锚定效应的重要补充。

4. 接入需求拆解 Agent

把脱敏风险库加载到需求拆解 Agent 的上下文中。

注意：此 Agent 只负责拆任务，不负责直接修改代码。

5. 跑 3～5 个真实问题做校准

观察 Agent 的拆解是否合理。

如果 priority_hint 与工程师直觉冲突，要么修改风险库，要么调整 Agent 提示。不要急于认为模型错，也不要默认模型对。

6. 建立维护节奏

每次新事故、新 bug、新复盘，都应该反向更新风险库。

建议至少保持两个节奏：

• 每次重大问题后回填
• 每半年集中审视一次

工程师用 AI 的关键，不是 prompt，是知识结构

回过头看，三层东西解决的是三件不同的事：

三层叠起来，AI Agent 才开始接近“工程协作者”，而不是一个问答工具。

最终形成的不是一段神奇 prompt，而是一套可复用的工作方法：

用自然语言表达问题       ↓用风险知识库约束拆解       ↓用任务单限制执行边界       ↓用工具和日志验证结果       ↓用人工判断决定下一步

看起来多了一层流程，实际减少了大量无效试错。

因为每一步都在回答同一组问题：

• 现在最该查什么？
• 什么不能动？
• 结果怎样算有效？
• 失败后怎么继续收敛？

工程团队最有价值的资产之一，是失效经验。

问题是，这些经验常常分散在老工程师脑子里、审计文档里、事故复盘里、工单系统里。对 AI Agent 来说，如果这些经验没有被结构化，它们就是不可调用的。

把失效经验整理成 Agent 可加载的风险知识库，是比写 100 个 prompt 更高杠杆的工作。

需求拆解层解决的是：别让 AI 乱猜任务。DFMEA 风险库解决的是：别让 AI 按错误优先级做事。

AI Agent 的能力上限，不只取决于模型本身，也取决于它能否接入高质量的工程知识结构。

把脑子里的工程经验组织成 Agent 可调用的结构，比写漂亮 prompt 重要得多。

让天下没有难搞的电源