AI 起草的事故复盘读起来像新闻稿：平衡、整齐，每一个让人不舒服但有用的事实都被剃掉了。模型会把”周五下午 5 点没评审就上线”圆成”近期一次变更与基础设施发生了非预期交互”。这种”圆滑”不是你写一次 prompt 就能根治的小毛病。大语言模型预测的是统计上最可能的下一个词，一旦丢掉了与具体来源的联系，它就会把彼此独立的事件并成一个整齐的故事——研究者管这叫”虚构”（confabulation），在真实场景的 LLM 回答里约占 31%，在复杂领域里还要高得多。而复盘恰恰是这种失误代价最大的复杂领域。
这套流程把 AI 当成快速产稿引擎，但每一行”诚实比舒适更重要”的地方都交给事故指挥者（IC）。做对了，一个 4 小时、600 条 Slack 消息的事故，能在 60-90 分钟内出一份立得住的文档，而不是手写 3 小时以上。
太长不看（TL;DR）
- 先让模型做带来源的时间线，再谈叙述。每一行都引用一条 Slack 消息、IC 笔记或看板。这是挡住”虚构”的唯一一条硬规则。
- 写摘要、影响、根因时只用这份时间线，并加一条硬约束：“要推测就写
[需 IC 输入]”。 - 5 Whys 让 AI 当提问者，不当写手——否则它收敛太快，走到一个整齐答案；而软件故障很少是线性的。
- IC 拿完稿对照原始素材通读，把任何”比证据更舒服”的句子重新写硬。说不出口给团队听的话，就不要发。
- 平台型工具（Rootly、incident.io）会在事故进行中自动采集时间线；用它的话，就从它的初稿起步，再套同一套评审纪律。
这篇主要解决什么问题
一个用 AI 把原始事故素材（Slack 频道、oncall 文档、时间线笔记、用文字描述的看板数据）转成结构化复盘的流程，沿用 Google SRE 标准章节：摘要、影响、时间线、根因、贡献因素、改进项。目标是又快又不洗掉那些让文档值得写的教训。
这篇适合谁看
凌晨两点被叫醒后要写文档的 IC、做无指责文化的 SRE、要负责跟进改进项的工程经理、没有专人做事故流程、每个人偶尔都是 IC 的小团队。
什么时候适合用
- 需要写文档的事故：影响用户、数据丢失、多小时不可用、反复出现的险情。
- 已有复盘模板的团队。AI 填一份已知结构，比从零写快得多。
- Slack 频道是主要事实来源、手翻 600 条消息要 90 分钟的情况。
什么时候不建议用
- 安全事故。 措辞涉及法律责任，不能交给 AI。
- 根因是人际问题（交接漏、升级没做）。AI 读不出房间气氛，会把最重要的地方平滑掉。
- 极小事故（5 分钟波动、零客户影响）。不用写。
出复盘的三条路
怎么出稿，取决于你的事故工具是否已经自动采集了时间线。截至 2026 年 6 月：
| 方式 | 时间线来源 | 出稿耗时 | 虚构风险 | 适合谁 |
|---|---|---|---|---|
| 纯手写、不用 AI | IC 手翻 Slack | 3 小时以上 | 无（但慢、易因疲劳出错） | 极小团队、敏感事故 |
| 通用对话模型（本流程） | 你贴素材，模型建带来源时间线 | 60-90 分钟 | 不写来源则高；加来源规则则低 | 用 Claude/ChatGPT、没买付费事故平台的团队 |
| 平台原生 AI（Rootly、incident.io） | 现场自动采集：告警、上线、Slack、通话转写 | 评审 10-15 分钟 | 较低（基于已采集事件），但仍需 IC 评审 | 已在为事故工具付费的团队 |
下面的对话模型路用 Claude Opus 4.7 或 Sonnet 4.6（1M token 上下文，整份 Slack 导出一般装得下），或 GPT-5.5 Thinking。这几个都能处理多语 Slack 线程；纪律比模型更重要。
开工前
- 把素材集中到一处：Slack 事故频道导出、当时用的 oncall 文档 / runbook、IC 当场记的时间线、用文字写出的看板截图描述、最终修复（commit SHA 或 PR 链接）。
- 准备模板。Google SRE 的五段（摘要、影响、时间线、根因、改进项）是不错的默认；你公司用哪套就把哪套给模型。
- 提前定好谁评审才能扩散——至少 IC + 一个全程动手的工程师。
- 事故发生后 48 小时内留 60-90 分钟来写。记忆衰减得很快，而记忆是你最值钱的输入。
具体步骤
- 把素材一次性贴上。 导 Slack 频道、贴 oncall 文档、贴时间线笔记。每段加标签，让模型知道在读什么。
- 先只要”时间线”，不要叙述。 “按时间戳和单行事件构建时间线。每行引用来源（Slack 消息或笔记）。先不要解读。“漏的数据这步就会暴露，后面一切都以它为根基。
- 评审时间线。 补缺——IC 总记得没进 Slack 的细节。用
[IC 注：...]标记加进来，下一轮当权威信息处理。 - 再要摘要、影响、根因。 “只用上面的时间线。不要发明时间线里没有的因素。要推测就写
[需 IC 输入]。“这是最关键的约束，直接对冲模型”把事件并成貌似合理却错误的故事”的倾向。 - 让 AI 当陪练做 5 Whys，不让它当写手。 “这是直接原因。问我五次 ‘why’，我每次答，然后总结。“思考留给你。注意：5 Whys 假设是线性链条，而软件故障通常有好几个贡献因素，所以把它的输出当一个输入，不是判决。
- 让 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 从 Slack 写根因。Slack 时序乱，结果就是文档含糊。
- 跳过”必须引用来源”。模型虚构，推测读起来很合理，错的”根因”进了团队民间传说。
- 接受 AI 软化的措辞，因为它显得专业。复盘的全部意义就是读起来不舒服。
- 改进项无 owner。永远没人做。
- 让 AI 主导 5 Whys。它收敛太快，会走到一个整齐答案。让它只问。
- IC 不评审就分享。这一条规则能挡掉大多数复盘质量回退。
FAQ
- 无指责文化怎么办？ 无指责是不把责任摊到个人，不是隐藏发生了什么。“上线没评审”既无指责又准确。领导层用指责性语言，是复盘文化崩坏最常见的原因，所以文档要做出相反的示范。
- 要不要直接用 Rootly 或 incident.io，而不是贴进对话模型？ 如果你已经付费了，就用——它在事故进行中现场自动采集时间线、基于已采集事件起草，把评审压到 10-15 分钟。本文的评审纪律照样适用：AI 初稿是起点，不是定论。
- AI 能主持复盘会议吗？ 不能。文档当会议输入，会议由人主持。
- Slack 消息是别的语言怎么办？ GPT-5.5 和 Claude 都能很好地处理多语 Slack 线程，但要核对时间戳和引用的字符串对得上。混合语言团队，Slack 里的信号往往比正式文档还丰富——两边都留。
- 改进项要不要自动进追踪系统？ 要，但 IC 评审后。AI 的”改进项草稿”是选项不是承诺。
- 同一份文档里能写对外口径吗？ 分开更好。对外稿短、过法务；内部复盘诚实、详细。
相关阅读
外部参考：无指责框架见 Google SRE 复盘文化章节，可直接套用的模板见 Google SRE 复盘示例。