该模型用于事故分析，直接用作设计方法有边界
别名: Swiss cheese model limitations · FRAM · hindsight bias
概念解释
瑞士奶酪模型是一个事后解释工具：它擅长把一次已经发生的事故拆解成若干层失效的巧合叠加，帮助调查者理解"为什么这次没被拦住"。但它不是一套事前设计方法——模型本身不会告诉设计者一个新系统应该设几层防护、每层放在哪里、多厚才够。把这个模型直接翻译成设计清单——"我们已经有三层防御，符合奶酪模型，足够安全了"——是对模型定位的误用，这条边界需要单独讲清楚，因为它决定了这个模型在设计流程里该扮演什么角色，而不是被当作一种可以打勾的合规标准。
机制
这个边界的根源在于模型的证据来源。奶酪模型是从大量已发生事故的回溯性叙事中归纳出来的——先有事故，调查者回头找出哪几层失效了、漏洞是怎么对齐的，再把这条轨迹画成图。这种叙事在事后总能被构造出来，因为任何结果都可以被追溯出一条促成因素链；但反过来，它并不提供一种方法，让设计者在事故发生之前就预判出这个系统会在哪几层出现漏洞、这些漏洞会不会对齐。模型没有给出层数与风险降低幅度之间的定量关系，也没有说明如何判断两层是否真正独立——这些恰恰是设计阶段最需要回答的问题。用一个只能事后叙述、不能事前预测的模型去指导设计决策，容易产生虚假的信心：团队会因为画出了三层而觉得足够安全，却没有真正验证这三层是否共享失效原因、是否覆盖了实际会出现的漏洞类型。
怎么研究
安全科学领域对这个边界有明确的批评：以 Hollnagel 为代表的学者指出，奶酪模型是一种线性、静态的失效叠加图景，难以刻画复杂系统中各部件实时互相调整、性能随情境弹性伸缩的动态过程，因此后续发展出功能共振分析（FRAM）等替代框架，专门处理奶酪模型解释不了的"系统在正常波动中如何自己滑向失效"这类问题。这提示一个方法论要点：如果研究目的是解释一次已发生的事故，奶酪模型及其叙事结构是合适的工具；如果研究目的是预测或生成一个新系统该有的防护配置，需要转向能给出层数、独立性判据或概率估计的方法（如故障树分析、失效模式与影响分析），奶酪模型本身不提供这些输出。
边界
即使作为事后分析工具，奶酪模型也依赖调查者事后补全的叙事，容易受后见之明偏差影响——知道结果之后，几乎任何一个环节都能被重新描述成本可以拦住却没拦住的一层，这让层数和漏洞位置的划分带有相当的主观性，不同调查者复盘同一起事故可能画出不同的图。作为设计方法使用时，这个主观性会被放大：没有事故结果做锚点，需要几层、放在哪完全取决于设计者的想象，缺少可验证的依据。
怎么落地
把这个模型的使用限定在两个场景：一是复盘已发生的差错或事故时，用它作为组织叙事和沟通的框架，帮助团队看见这不是一个人的错，是几层防御同时出了问题；二是在设计评审时，用它做一次定性检查——如果这一层被绕过，后面还有没有别的层能接住——而不是用它来决定具体设几层、每层的技术指标是什么。真正的设计阶段决策，改用能给出具体判据的方法：对高后果操作做故障树分析或失效模式分析，逐条列出可能的失效路径与各自的发生概率，再据此决定防护层数与独立性要求。验证办法：检查设计评审记录里但凡出现"符合瑞士奶酪模型"这类表述的地方，是否伴随着具体的失效路径分析和独立性论证；如果只是画了几层示意图就作为安全性结论收尾，说明模型被当成了它不能承担的角色。