用 AI 写故障复盘报告：归因到机制

复盘报告最常见的两种失败：写成追责材料，或者写成"下次注意"的空话。两种都防不住同类问题再犯。用 AI 写复盘的价值不在文笔，在于它能把散落的记录整理成结构，逼你把归因落到机制上——但整理的原料和最后的判断，都得由人把关。

归因往下挖三层

"操作失误"不是原因，是结果。往下继续问三层：为什么这个操作会出错、为什么出错了没人拦、为什么拦住了还是影响到了用户。三个问题的答案落在"缺少校验""告警没覆盖""权限过大"这类可改的机制上，复盘才有产出。

一个判断标准：换一个人来做，同样的错误还会不会发生。会，问题在机制；不会，才可能是个人的问题。把这条标准写给 AI，让它按这个逻辑给每一条原因归类。

原因要分层写，不要混在一段里。直接原因回答"这次为什么发生"，深层原因回答"为什么一直没被发现"，两层之间常有空档——比如直接原因是配置改错，深层原因是改动没有审核环节。把这个空档写出来，改进项才有落点：给直接原因配的是修复动作，给深层原因配的是流程改动，两回事，混着写会让流程类的改进被眼前的修复挤掉。

报告的五个部分

五部分里，影响面和改进项最常被偷工。影响面决定了改进的优先级，改进项决定了下次同类事故还能不能被拦住，这两块省了，报告就只剩记录功能。

让 AI 整理记录的完整问法

把故障经过的原始记录粘给 AI，要求它做四件事：整理时间线，从首个信号到恢复；区分直接原因和深层原因，并指出哪些属于机制问题；列出改进项，每条注明责任人与时限；指出记录里缺失、但复盘需要的信息。同时加两句约束：不要把原因归结到个人，信息不足时不要下结论。它列出的"缺失信息"清单往往是最有价值的部分——那是你回头补调查的方向。

时间线和改进项的写法

时间线要基于日志和监控记录，不靠回忆拼凑，人在紧张状态下对时间的记忆极不可靠。改进项要能验证：写"某指标超过阈值时告警并通知到人"，不写"加强监控"，前者上线后能验收，后者永远无法验收。报告写完后在团队里过一遍，让没参与处理的人也能看懂——看不懂的报告起不到防复发的作用。

AI 帮不上的是什么

它无法补全没写进记录的事实，无法验证你给的记忆是否准确，也不会替你决定改进项的优先级——那涉及资源，资源分配是人做的事。它也不适合作为追责的依据来源，把它的整理结果直接当成结论，复盘会退回追责材料。

故障复盘速查

• "操作失误"是结果，归因继续往下挖
• 换一个人还会犯，就是机制问题
• 时间线依据日志，不靠回忆
• 改进项可验证：写告警阈值，不写"加强监控"
• 每条改进项要有责任人和时限

三个常被问到的问题

• 故障当天没来得及记时间线，事后补还准吗？：回日志和监控里对时间点，回忆只用来填背景。补出来的时间线要标注来源是日志还是回忆，两者可信度不同。
• 改进项太多排不过来怎么办？：按再发生概率和改动成本两个维度筛。高概率低成本的本周做，高概率高成本的排期并给出临时缓解手段，低概率的记录在案即可。
• 小团队没有正式复盘制度，还值得写报告吗？：值得，但可以砍到三段：时间线、机制层根因、一条可验证的改进项。结构在，追责化的倾向就难抬头。

这套挖因逻辑在别的数据场景同样用得上。用 AI 分析退货原因的归因方法是同一套思路换个对象；把一整段时间压缩成结构化结论，用 AI 做年度复盘的总结法与给合伙人看的年度经营总结各有一套现成的问法。