生产事故发生时，AI 辅助根因分析的操作步骤，以及人工判断在哪些环节不能省略。
问题
事故场景下最危险的错误是：把 AI 生成的根因假设当作已确认的结论，然后基于错误的假设部署修复。AI 在模式匹配上很快，但它的”自信”不代表正确——它只是在已有训练数据中找到了最相似的模式。
生产环境的特殊性在于：每次事故的上下文组合几乎是唯一的。AI 找到的模式可能来自相似但不完全相同的场景，差异恰好就在根因所在的地方。
规则：AI 生成假设，人工验证假设，验证完成后才能定性根因。这条规则在时间压力下最容易被违反，也是最需要坚守的时候。
响应流程
第 1 步：收集上下文（人工）
在提交给 AI 分析之前，先整理以下信息：
- 错误日志：完整的错误信息和堆栈，不要截断
- 时间线：事故开始的时间点，与最近的变更记录（部署、配置变更、数据迁移）对照
- 影响范围：哪些服务、哪些用户、何种程度的影响
- 已排查的内容：已经确认不是根因的假设
这一步的输出是一份结构化的上下文摘要，而不是把原始日志全部粘贴给 AI。原始日志太长时，AI 会遗漏关键细节或抓错重点。
第 2 步：AI 根因分析
将结构化上下文提交给 AI，要求它：
给定以下错误信息、时间线和影响范围，生成可能的根因假设列表。
每个假设需要说明：
1. 假设的内容
2. 支持该假设的证据（来自已提供的上下文）
3. 验证该假设需要检查什么
不要只给一个假设，给出你认为可能性最高的 3-5 个，按可能性排序。
为什么要多个假设：单一假设会引发确认偏误——人工验证时会倾向于找支持它的证据，而忽略反驳证据。多个假设迫使验证过程是排除式的，而不是确认式的。
第 3 步：人工验证（人工）
逐一验证 AI 给出的假设。这一步不是”哪个看起来最像”，而是通过实际检查来排除：
- 检查对应的代码路径、配置、数据状态
- AI 辅助查找相关代码（”找所有处理这类请求的地方”）
- 对每个假设得出明确的”成立”或”不成立”结论，并记录依据
如果所有假设都不成立：回到第 2 步，提供新的约束（”以上假设均不成立，已确认 X 和 Y 正常，继续分析”）。
第 4 步：修复（AI 辅助，人工审查）
根因确认后：
- 让 AI 生成修复方案，要求它同时说明方案的风险和局限
- 人工审查修复方案，重点检查：是否只修复了症状而不是根因，是否可能引入新问题
- 部署前准备回滚预案
规则：即使时间紧迫，修复方案也需要至少一人审查。独自部署 AI 生成的修复是高风险操作。
第 5 步：复盘（人工主导，AI 辅助整理）
事故解决后，在 24 小时内完成复盘记录：
事故时间线：[开始时间 → 发现时间 → 响应时间 → 解决时间]
根因：[经过验证的根因，一句话]
根因类别：[代码缺陷 / 配置错误 / 外部依赖 / 容量问题 / 人为操作]
修复内容：[做了什么]
防止复发：[流程或代码层面的改进，明确负责人和时间]
AI 可以帮助整理格式和生成时间线摘要，但根因定性和改进措施必须由人工确认。
事故响应的常见失败模式
跳过收集步骤直接给 AI 分析：AI 拿到不完整的上下文，生成不完整的假设，验证假设时发现漏了关键信息，时间浪费在来回补充上。
把第一个 AI 假设当作答案：直接部署基于未验证假设的修复，事故解决了但不知道真实根因，同类问题会再次出现。
解决后不复盘：改进措施停留在口头，下次事故重复同样的错误和时间浪费。
复盘时 AI 定性根因：AI 的根因分析是假设，复盘文档里写的是已验证的结论。混淆两者会在后续对这个事故的引用中传播错误信息。