AI 起草的事故复盘读起来像新闻稿：平衡、整齐，每一个让人不舒服但有用的事实都被剃掉了。模型会把”周五下午 5 点没评审就上线”圆成”近期一次变更与基础设施发生了非预期交互”。这套流程把 AI 当成快速产稿引擎，但每一行”诚实比舒适更重要”的地方都交给事故指挥者（IC）。
这篇主要解决什么问题
一个用 AI 把原始事故素材（Slack 频道、oncall 文档、时间线笔记、用文字描述的看板截图）转成结构化复盘——摘要、影响、时间线、根因、贡献因素、改进项——同时不让模型把那些让这份文档值得写的教训洗掉。
这篇适合谁看
凌晨两点被叫醒后要写文档的 IC、做无指责文化的 SRE、要负责跟进改进项的工程经理、没有专人做事故流程、每个人偶尔都是 IC 的小团队。
什么时候适合用
需要写文档的事故——影响用户、数据丢失、多小时不可用、反复出现的险情。已有复盘模板的团队；AI 填一份已知结构比从零写更快。Slack 频道是主要事实来源、手翻 600 条消息要 90 分钟的情况。
什么时候不建议用
安全事故——措辞涉及法律责任，不能交给 AI。根因是人际问题（交接漏、升级没做）——AI 读不出来房间气氛，会把最重要的地方平滑掉。极小事故（5 分钟波动、零客户影响）——不用写。
开工前
- 把素材集中到一处：Slack 事故频道导出、当时用的 oncall 文档 / runbook、IC 当场记的时间线、用文字写出的看板截图描述、最终修复（commit SHA 或 PR 链接）。
- 准备模板。五段（摘要、影响、时间线、根因、改进项）是标配；你公司用哪套就给哪套给模型。
- 提前决定谁评审才能扩散。至少 IC + 一个全程动手的工程师。
- 事故发生后 48 小时内留 60-90 分钟来写。记忆衰减得很快，而记忆是最值钱的输入。
具体步骤
- 把素材一次性贴上。导 Slack 频道、贴 oncall 文档、贴时间线笔记。每段加标签，让模型知道在读什么。
- 先只要”时间线”，不要叙述。“按时间戳和单行事件构建时间线。每行引用来源（Slack 消息或笔记）。先不要解读。“漏的数据这步就会暴露。
- 评审时间线。补缺——IC 总记得没进 Slack 的细节。用
[IC 注：...]标记加进来，下一轮当权威信息处理。 - 再要摘要、影响、根因。“只用上面的时间线。不要发明时间线里没有的因素。要推测就写 ‘[需 IC 输入]’。“这是最关键的约束。
- 让 AI 当陪练做 5 Whys，不让它当写手。“这是直接原因。问我五次 ‘why’，我每次答。然后总结。“思考留给你，提问留给 AI。
- 让 AI 起草改进项——但只作为按类别分组的选项列表（预防 / 检测 / 响应）。IC 来挑哪几条上。AI 倾向于堆改进项；砍到 3-5 条带 owner 的可执行项。
- IC 拿着完稿对照原始素材读一遍。任何”文档比素材自然”的地方就推回去。“Slack 里写得很清楚——告警被忽视了 22 分钟。文档就该这么写。“
能产出诚实输出的 Prompt
你在帮我起草一份事故复盘。我是 IC。
输入：
[SLACK 频道导出]
\{粘\}
[OnCall 文档]
\{粘\}
[IC 时间线笔记]
\{粘\}
[修复]
\{commit SHA + PR 链接 + 一行描述\}
输出：
1. 时间线——UTC 时间戳，一行一个事件，每行注明来源（Slack 消息、
IC 笔记、看板）。不在输入里的事件不要写。
2. 摘要（3-4 句）。说人话。不要软化原因。
3. 影响（数字——持续时长、受影响客户数、$ 如果有）。
4. 根因——一段话，只写时间线支持的内容。要推测就写
"[需 IC 输入]"，我来填。
5. 贡献因素——2-5 条列表。同样不准推测。
6. 改进项草稿——按 预防 / 检测 / 响应 分类。最多 8 条选项，我来砍。
每条给候选 owner 角色（不写人名——写 "平台团队"、"on-call 轮值"）。
规则：
- 无指责语气（指责语境里不写个人姓名）但不是无问责。"上线没评审"
这种说法是公允的。
- 不要把难听的事实圆掉。"告警被忽视了 22 分钟"原样保留。
- 输入里有自相矛盾的事实，把两边都摆出来并标 "[冲突 — 需 IC]"。质量检查
- 每个事实都能追到来源——Slack 消息、IC 笔记、看板、代码链接。无来源的或砍掉或标
[需 IC 输入]。 - 根因写出实际机制，不写委婉语。“为了快速上线移除了 canary 检查”可以。“我们的上线流程没能捕获这个问题”是同一事实的洗白版。
- 改进项有候选 owner 角色和分类。12 条没 owner 的列表是愿望不是工作。
- 5 Whys 如果做了，作为子章节保留 IC 实际的答复。不复述。
- IC 把每一句都读过，能对着团队为每一句辩护。说不出口的话，不发。
怎么把这流程沉淀下来
- 把 prompt 作为团队模板存起来。每次新事故从同一脚手架开始，只换输入。
- 写个小型”事故导出工具包”——脚本拉 Slack 频道、对修复 PR 跑
gh pr view、拼成一份可直接粘的文档。摩擦减 20 分钟。 - 每次写完复盘，回顾哪些章节 AI 做得接近、哪些需要 IC 大改。调 prompt。
- 维护一份”模型常用的洗白话术”——它常用、但会盖住真相的短语（“非预期交互”、“流程缺口”）。下一份 prompt 里禁掉。
建议的操作流程
素材收齐 → AI 出带来源的时间线 → IC 补缺 → AI 按不准推测规则写 摘要 / 影响 / 根因 → AI 作为提问者做 5 Whys → IC 从 AI 选项里挑 3-5 条改进项 → IC 对原始素材通读、加硬措辞。一个 4 小时事故、600 条 Slack 消息，60-90 分钟出稿，对比手写 3+ 小时。
容易踩的坑
- 不先做时间线、直接让 AI 从 Slack 写根因。Slack 时序乱，结果就是文档含糊。
- 跳过”必须引用来源”。模型推测，推测读起来很合理，错的”根因”进了团队民间传说。
- 接受 AI 软化的措辞，因为它显得专业。复盘的全部意义就是读起来不舒服。
- 改进项无 owner。永远没人做。
- 让 AI 主导 5 Whys。AI 收敛太快，会走到一个整齐答案。让它只问。
- IC 不评审就分享。这一条规则能挡掉大多数复盘质量回退。
FAQ
- 无指责文化怎么办？: 无指责是不把责任摊到个人。不是隐藏发生了什么。“上线没评审”既无指责又准确。
- AI 能主持复盘会议吗？: 不能。文档当会议输入。会议人来主持。
- Slack 消息是别的语言怎么办？: 现代模型多语 Slack 处理得不错，但要核对时间戳和引用的字符串。混合语言团队，Slack 里的信号往往比正式文档还丰富——两边都留。
- 改进项要不要自动进追踪系统？: 要，但 IC 评审后。AI 的”改进项草稿”是选项不是承诺。
- 同一份文档里能写对外口径吗？: 分开更好。对外稿短、过法务；内部复盘诚实、详细。