要用 AI 开展根因分析，应让模型帮助整理证据、暴露缺口、生成相互竞争的系统性假设，并设计能够证伪它们的检查。不要让 AI 自行宣布根因；合格人员必须保存证据、判断因果关系、选择纠正措施，并验证措施是否真正减少复发。

关键要点

用可测量差距、范围和时间边界定义问题。

先冻结带来源的证据，再作解释。

分开标记观察、解释、假设和推测。

五问法和鱼骨图只用于扩展候选原因，不用于证明结论。

优先设计能区分竞争解释的检查。

分析相互作用的系统条件，不把某个人当作终点。

用结果指标和意外风险检查验证纠正措施。

重要安全边界： 涉及安全关键系统、监管报告、法律保全、事故、网络安全、临床、环境或其他专业调查时，必须使用组织批准的程序和合格调查人员。本通用流程不替代紧急响应、法定报告、证据保存、劳动保障、法律意见或专业判断。

本文只讲普通运营和流程分析。软件缺陷请使用独立的AI 辅助代码调试流程。输入最小化和人工责任可参考可复核 AI 工作指南。

AI 在根因分析中应扮演什么角色？

AI 可以充当一位有条理的“第二读者”。它可以统一时间戳、把陈述对应到证据 ID、找出矛盾、生成问题、归类原因因素，并对照检查清单比较各个假设。在来源资料包受控时，这些都是有用的提速工作。

AI 不应判定发生了什么、评估证人的可信度、认定过错、改动原件或批准纠正措施。它无法接触完整的环境，可能会根据不完整的证据编出一个连贯的故事。NIST 的 AI 风险管理框架强调在使用全过程中治理、映射、衡量和管理风险，包括有效性、可靠性、透明度、隐私和问责。［1］

OSHA 建议调查深层的系统原因，而不是止步于“粗心”或“未遵守程序”。它指出，设备、程序、培训、管理、设计和其他项目条件往往相互作用。［2］即使在与安全无关的运营工作中，这条系统边界也很重要：“Alex 输入了错误的数值”描述的是一个事件，而不是流程为何允许一次输入就造成损失。

分析台账应记录什么？

维护三份相互关联的记录。

证据台账

证据 ID	来源	采集时间	直接显示的内容	可靠性限制	保管负责人
E-01	已批准的订单导出	14:05 UTC	重复订单 ID 进入队列	导出不含已删除行	运营负责人

假设台账

假设 ID	候选原因	支持证据	相反证据	区分性检查	状态
H-01	重试产生重复项	E-01、E-04	两个案例没有重试日志	开启日志后复现	未决

纠正措施台账

措施 ID	处理因素	控制措施	负责人	到期日	成功指标	新风险检查	批准状态
A-01	接受重复项	拒绝重复订单 ID	流程负责人	约定日期	测试集中接受的重复项为零	合法重新提交仍可用	待批准

这些台账能防止精致的叙述跑在证据前面。它们也让之后的审阅者看得出某个候选为何被否决，以及某项措施处理的是已证实的因素，还是仅仅是一个症状。

如何分九步用 AI 开展根因分析？

步骤 1：精确定义问题

描述预期状态、观察到的状态、可测量的差距、起止时间、受影响的流程和影响。使用中性语言。“10:00 至 14:00 UTC 之间，有 18 个订单的发货确认超出了批准的两小时目标”，比“履约团队又失职了”更好。

记录哪些内容不在范围内，以及谁授权了这次分析。把影响遏制与原因调查分开。你可能需要立即制止正在发生的损害，同时保留“它为何发生”这个问题。

列出分析要支持的决策：恢复服务、修改某项控制、修订培训、通知主管部门，或启动专门调查。不要暗示一次根因分析能满足所有目的。

步骤 2：冻结并盘点证据

在清理、合并或总结之前，先保存原件。给每条记录一个稳定的 ID，并记录来源、保管人、时间基准、时区、保留要求、访问限制和已知缺口。例如日志、工作记录、变更审批、设备状态、访谈、照片、政策和以往的未遂事件报告。

OSHA 的雇主指南从保护和记录现场开始，然后收集信息，再确定原因并实施纠正措施。［3］对于普通的流程工作，“现场”可能是一份冻结的导出、配置快照、队列状态或已批准的文档集。

只使用获授权的输入。在 AI 处理之前，删除无关的个人数据和机密。如果证据受法律保全、特权、安全规则或正式监管链要求约束，就停下来，改用指定的程序。

步骤 3：建立时间对齐的事件线

在不覆盖原件的前提下统一时间戳。记录来源时钟、时区、时钟偏差、精度，以及某个时间是观察所得还是估计值。把行动、状态变化、告警、决定和外部条件放到同一条序列上。

让 AI 找出缺口、不可能的先后顺序和相互矛盾的说法，但要求每个事件都附上证据 ID。提示词可以写：“只返回台账直接支持的事件。时间有冲突的保留为不同的行。不要选择看起来更合理的说法。”

不要把先后顺序当作因果关系。事件 B 发生在事件 A 之后，只说明顺序，而不说明 A 导致了 B。用时间线来提出问题和定位缺失的数据。

步骤 4：分离观察和假设

把每条陈述标注为观察、解释、假定、假设或决定。观察应描述来源直接支持的内容。“E-07 中的审批字段为空”是观察；“审核人因工作量太大而跳过了审批”是假设。

让 AI 标出缺少证据引用的因果动词。把过早的结论改成可检验的表述。如果证人提供的是一种解释，就把它作为此人的陈述保留，而不是转换成事实。

当多个团队使用不同术语时，这种分类尤其有价值。建立一份术语表，并记录有争议的含义，而不是让模型悄悄统一它们。

步骤 5：用结构化方法生成候选原因

使用五问法、鱼骨图、屏障分析、变更分析或事件树，扩大候选范围。方法是提问工具，不是证明工具。当下一个回答缺乏证据、超出范围，或变成“文化”之类的笼统标签时，就停止这条五问法分支。

围绕相关的系统维度组织鱼骨图的分支：流程、工具、信息、环境、人员配备、监督、激励、接口和控制措施。只有当你能说明什么证据会支持或削弱某个候选时，才把它加进来。

OSHA 的根因分析说明指出，成功的分析可能找出不止一个根因，并列出多种工具，包括头脑风暴、检查清单、时间线、顺序图、原因因素判定，以及逻辑树或事件树。［4］当相互作用的多个因素更符合证据时，不要硬凑一个整齐的答案。

步骤 6：设计区分性检查

对每个未决的假设，问：如果这个解释成立，而不是其最有力的替代解释成立，哪种结果会更可能出现？有用的检查会改变各候选之间的相对支持度。

例如比较受影响和未受影响的案例、在受控环境中复现某个条件、查看一份独立的日志、审查某个变更的边界，或检查该因素在更早的未遂事件之前是否已经存在。在执行检查之前，先记下每个候选下的预期结果。

避免只是收集更多同类证据的检查。如果 H-01 和 H-02 都预测队列会延迟，再多一张队列延迟图也无法区分它们。优先安排安全、可逆、获授权的检查；当测试可能造成伤害时，请专家参与。

步骤 7：记录已排除和未决原因

不要删除被否决的假设。记录检查、结果、审阅人和排除理由。之后的证据更正可能让它重新变得相关。

使用未决、有支持、被削弱、已排除、未解决或超出范围等状态。“已排除”应表示某项明确的检查与该候选相矛盾，而不是团队不喜欢它。当证据不足时，“未解决”是可以接受的结果。

请一位没有投入于领先解释的审阅者检查相反证据。如果小组只寻找确认性证据，AI 就会为受青睐的说法生成越来越流畅的支持，从而加速确认偏差。

步骤 8：形成多因结论和纠正措施

把结论写成一条附有证据和置信边界的因果链。区分直接原因、促成条件、失效或缺失的控制措施，以及更深层的组织因素。不要把某个人的名字当作最终原因。

纠正措施应针对已核实的因素，并优先采用更强的系统控制，而不只是提醒。NIOSH 的控制层级把消除、替代和工程控制排在行政控制和个人防护装备之前，因为较高层级的控制较少依赖个人的反复行动。［5］这套层级未必能对应每一种办公流程，但原则是有用的：先重新设计条件，而不是只依赖“更小心一点”。

为每项措施写明负责人、到期日、批准权限、实施证据、成功指标和可能的新风险。把临时遏制措施与永久纠正措施分开关联。

步骤 9：验证纠正措施有效

在实施之前，定义基线、目标、观察窗口、比较方法，以及回滚或升级的触发条件。衡量措施要改变的结果，而不只是任务是否被标为完成。

检查是否复发、出现未遂事件、变通做法、把负担转移给另一个团队、上报减少、新的故障模式和误报。一项压住了可见症状、却制造出隐藏手工工作的控制措施，并没有解决系统问题。

安排一次具名的复核；如果结果与结论相矛盾，就重新打开假设台账。对分析进行版本管理，而不是悄悄改写。最终结案属于依批准程序负责的负责人，绝不属于模型。

什么提示词能保持分析边界？

使用分阶段的提示词：

只使用所提供的证据台账，生成：（1）中性的问题陈述；（2）与证据关联的时间线；（3）区分观察与假设的清单；（4）相互竞争的系统层面候选原因。对每个候选，列出支持证据、相反证据、缺失证据，以及一项能把它与最有力的替代解释区分开的检查。不要选定根因、评估个人过错、编造事件，或在未说明所针对因素的情况下建议措施。

每个阶段分开运行，审阅后再进入下一阶段。使用 AI 事实核查方法把主张对应到来源，并要求结论和措施经过人工审批工作流。如果某项经过验证的修复成为可重复的操作控制，就通过 SOP 与清单流程记录下来。

总结

在寻找原因之前，先给出中性、可测量的问题陈述。
在让 AI 整理证据之前，先保存证据及其出处。
把时间线、观察、解释和假设分开。
生成多个系统层面的候选，并设计能区分它们的检查。
让被否决和未解决的解释保持可见。
针对已核实的因素制定纠正措施，并持续检验结果。
只要后果或监管有要求，就交给合格调查人员并使用批准的程序。

常见问题

AI 能自动找到根因吗？

不能。它可以整理证据并提出候选，但背景不完整和虚构内容可能产生一个令人信服的错误答案。因果支持由负责的调查人员判定，结论也由他们批准。

五问法分析做五次就够了吗？

不够。它对某些情况是有用的提问结构，但复杂事件可能需要时间线、屏障分析、变更分析、事件树、专业测试，或同时使用几种方法。

直接原因和根因有什么区别？

直接原因紧挨着事件本身，例如一个无效值进入了队列。更深层的原因说明，是哪种系统条件或哪项失效的控制措施让该事件得以发生，并留下了再次发生的风险。

根因可以是某个人的错误吗？

通常不应作为终点。准确记录该行为，然后检查塑造这些条件的界面设计、工作量、程序、培训、监督、激励、防护措施和恢复控制。

应保留多少候选原因？

保留当前范围内所有合理、可检验的候选，然后优先安排区分性检查。不要强求固定数量，也不要只为简化报告而舍弃替代解释。

两个解释无法区分怎么办？

把两者都记录为未解决，说明缺少什么证据，并决定风险是否值得进一步调查，或是否采用能同时处理两者的控制措施。不要制造确定性。

怎样知道纠正措施有效？

使用预先定义的结果指标、基线、观察窗口和意外风险检查。任务完成只能证明已实施，不能证明有效。

什么情况下必须停止通用流程？

当事项涉及安全关键系统、人身伤害、受监管的报告、法律保全、刑事或纪律指控、临床决策、环境损害，或其他专业调查边界时，就要停止。遵循指定的程序，由合格调查人员处理。

免责声明：安全关键、受监管、法律保全、事故、网络安全、临床、环境或专业调查必须采用组织批准的程序和合格调查人员。本指南不替代法定报告、证据保存、法律意见或专业判断。

来源：

NIST — AI Risk Management Framework — https://www.nist.gov/itl/ai-risk-management-framework
OSHA — Incident Investigation Overview — https://www.osha.gov/incident-investigation
OSHA — Incident Investigations: A Guide for Employers — https://www.osha.gov/sites/default/files/IncInvGuide4Empl_Dec2015.pdf
OSHA and EPA — The Importance of Root Cause Analysis During Incident Investigation — https://www.osha.gov/sites/default/files/publications/OSHA3895.pdf
CDC/NIOSH — Hierarchy of Controls — https://www.cdc.gov/niosh/hierarchy-of-controls/index.html

Sources checked 2026 年 8 月 30 日。

延伸阅读：

如何用 AI 开展根因分析，用证据检验假设而非归咎个人