夜雨聆风问题：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，通常会得到一份“可能原因”列表：
可能的原因包括：
节能模式状态变量被卡住 负载检测信号异常 输出配置异常 采样链路异常 保护误触发 参数配置错误 温度或其他限制条件触发 退出条件判定逻辑问题 中断或调度问题……
方向不一定错，但问题是：列表平铺，没有优先级。根因虽然在列表里，但位置靠后。工程师如果按顺序排查，前面大量方向都会消耗时间。
拆解方式 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 重要得多。