起草设计失效模式与风险措施表

这个场景能帮你做什么

设计失效模式与影响分析（DFMEA）需要把功能、失效、后果、原因和措施连起来。WorkBuddy 可以利用设计输入与历史失效起草初表，供跨专业团队评审，帮助少漏环节。

开始前需要准备什么

提供产品与系统边界、结构功能、设计要求、接口、历史失效及根因验证、现有预防与探测措施。评分方法、等级和行动优先规则使用企业实际标准，注明版本。

具体怎么做

第一步：明确功能与边界

先整理部件、功能、性能要求及上下层关系。没有具体功能时不要直接堆“断裂、泄漏、失效”等通用词。

第二步：逐功能推演失效链

分别列功能如何不满足、对部件/系统/用户的后果，以及候选原因。历史已验证与设计推演分开，不能把相似失效直接当成本项目根因。

第三步：对照现有控制

为每个原因检查现有设计预防、探测与验证证据。不能因为计划做测试就写“已控制”，也不能把措施名称代替有效性证据。

第四步：提出改进与确认任务

列措施候选、责任、完成条件和需要补的证据。评分可以整理已有人评结果及依据，未知不打分；严重度、发生度、探测度及风险接受由团队确认。

第五步：关联验证与变更

将措施对应到后续设计验证和变更资料，保留尚未关闭风险。设计变更后应重新评审相关链条，不能只修改一格描述。

一条失效链怎样写清楚

以下是用于理解字段的教学示例，不代表真实产品结论：假设已确认的功能要求是“连接处在规定工况下保持密封”。可以这样展开：

字段	示例记录
功能与要求	在企业规定的压力、温度和寿命条件下保持密封；具体条件引用设计要求
失效模式	连接处发生泄漏，即密封功能未满足
失效影响	部件介质损失，可能使系统无法维持规定工作状态；对用户的进一步影响待系统团队确认
候选原因	密封件压缩量可能不足；这是待验证假设，不能写成已查明根因
现有预防控制	已批准的尺寸链校核，填写实际报告版本；未提供报告则标“证据待补”
现有探测控制	已完成的密封验证及记录；只有测试计划时写“计划中，尚无结果”
改进与验证候选	复核尺寸链及公差组合，必要时修订设计并按批准条件重新验证；责任与期限由团队确定

这里“泄漏”回答怎样失效，“系统无法维持工作状态”回答后果，“压缩量不足”回答可能为什么发生。三者不能填在同一列。评分栏保留企业标准、评分依据和评审状态，示例不代替 S/O/D 评分。

可以直接交给 WorkBuddy 的完整要求

依据附件设计输入和历史失效，起草DFMEA：功能/要求—失效模式—后果—原因—现有预防/探测—改进候选。
逐项附来源，区分历史已验证事实与推演。计划措施不得标已完成，评分未知留待评审，不自定S/O/D或风险接受。
列证据缺口、责任和验证关联，按企业提供标准组织，不自动批准或关闭风险。

完成后会得到什么

一份可评审的 DFMEA 初表、证据缺口和措施候选。表格完整只代表讨论准备完整，不代表风险已受控。

结果应该怎么检查

专家逐项核对功能与失效链，检查后果、原因是否混淆，预防与探测是否有实际依据。查看遗漏接口、工况和历史失效，而非只看评分。

遇到这些情况怎么处理

结构未定时标假设边界。历史评分标准不同不直接搬分。原因未经验证时安排分析或试验，不能用 AI 文字关闭问题。

哪些必须人工决定

设计、质量与相关专业人员确认失效链、评分、措施及风险接受。AI 辅助查漏起草，不替代工程风险责任。