周五晚上十一点线上服务报警。你带着同事定位问题、回滚发布、扩容节点等服务恢复时已经是凌晨两点。这时候还有一件躲不掉的事写故障复盘。第二天一早开会报告要发出来所有人都在等。于是你只能硬撑着把值班群的聊天记录、监控截图、发布平台的变更日志翻出来一条一条对时间再写出一份像模像样的文档。最近很多团队开始尝试把这件苦差事交给 AI。做法也很直接把故障材料一次性丢给大模型让它生成故障复盘报告再进一步一点的会用 AI Agent 自动拉取上下文。方向没问题但真正落地时会发现一个很容易被忽略的事实AI 写故障复盘报告最难的从来不是“写”而是“怎么把散落在聊天、日志、监控和变更记录里的信息组织成 AI 能理解的结构化输入”。如果这一步没有做透AI 生成得越快复盘报告里藏着的错误可能就越多。下面这篇内容我想从一个偏工程落地的视角把 AI 辅助故障复盘到底该怎么做讲清楚先解决什么问题、怎么搭最小流程、怎么防止 AI 编造事实、以及哪些场景其实不应该用。1. 故障复盘真正的瓶颈不是写报告而是把散落信息还原成因果链1.1 手动复盘为什么总是又慢又容易漏先说实话手动整理一份复杂故障复盘最耗时间的不是打字。真正耗时间的是“建立时间线”和“还原因果链”。一次典型线上故障相关信息会散落在至少五六个位置值班群的聊天记录、监控平台的告警截图、发布系统的变更单、服务日志里的异常栈、负责人手里的操作记录。这些信息来源的时间粒度不一样格式不一样甚至记录人的口径都不一样。你要做的是把这些碎片按时间顺序排好找出哪里出现了异常哪个变更可能触发了它然后区分“现象”和“原因”。这个过程对记忆和注意力的要求很高。你刚处理完一次凌晨故障脑子的状态本来就不算好还要去回忆“当时是先看到告警还是先收到变更通知”“那行报错到底是哪个服务打出来的”。这种工作看起来是在写文档实际上是在做一轮高负荷的信息检索和关系抽取。很多人把复盘写得很难受不是因为文笔差而是因为信息没有沉淀下来每一次都要从原始状态重新梳理一遍。这不仅是时间成本也是质量风险漏掉一个关键时间点整条因果链可能就会判断错方向。1.2 AI 生成报告本质上是一次信息重构而不是内容创作搞清楚手动复盘的痛点之后再看 AI 的位置就会更清楚。大模型生成故障复盘报告本质上是做“信息重构”你把一段已经发生的事实材料交给它它负责把这些事实按照一定结构重新表达出来。它不是一个能直接读取你系统内部状态的工具它看不到你的服务、数据库、监控后台它能看到的一切都在你提交给它的 prompt 或者检索结果里。这里有一个容易踩的认知偏差。很多人以为 AI 报告写得流畅说明 AI“懂”了这次故障。其实不是。模型只是在材料允许的范围内把几个事件之间的关联用通顺的文本表达了出来。一旦材料里缺了某个关键事件它不会像人一样主动说“我这里缺信息”而更可能顺着已有内容补上一句看似合理的话。这就是为什么把一堆没整理过的原始日志直接扔给模型报告里会出现“可能原因”写得很专业、但实际方向完全不对的情况。所以AI 辅助复盘的第一步不是先调模型参数也不是先找最好的 Agent 框架而是先把输入材料管好。材料组织得越清晰模型重构出的报告才越接近真实情况。顺着这个理解你可以得到一条很实用的经验如果你发现 AI 生成复盘的效果不稳先别急着换模型先看看你喂进去的材料是否足够完整。材料里没有的信息模型一般不会凭空得到。一个能帮你少踩很多坑的检查方法是把材料想象成你要交给一位远程协助工程师的资料包如果资料包缺了某张截图对方就只能靠猜。2. 一条从“原始素材”到“可发布报告”的四步处理链路2.1 先采集把五种原始素材收齐在常见实践里一份复杂故障复盘至少需要五类素材事件时间线记录通常是值班群或者协作工具里的聊天记录包括从告警出现到恢复的所有关键节点。变更发布记录来自发布平台或 CI 系统重点是谁在什么时候发布了什么是否带有配置变更。监控告警和指标截图最好转成文本方便后续拼接和处理。关键日志片段主要指报错、异常栈、关键服务调用链路上的有效输出。处理动作记录也就是每个人在故障期间做了什么操作比如回滚、扩容、重启。采集阶段的核心要求是“宁可多不可少”。可以先不分级把相关材料全部收集到同一个目录里。文件命名尽量带上时间戳和