事故复盘看似简单，实际操作中却极易偏离正轨。许多复盘文档要么写成时间线、原因、动作混杂的“一锅乱炖”，要么充斥着“可能”“或许”等主观推测，令人难以厘清责任归属，更无法为流程优化提供有效支撑。

若要确保模型（或团队）严格依据真实时间顺序，逐步还原事件全貌，必须将“时间锚点”这一基本功钉牢。

核心要点其实只有一句话：在撰写事故复盘提示词时，务必让模型清晰区分时间线、因果链和分工职责。否则，复盘结果要么遗漏关键责任节点，要么掩盖真实的故障路径。下面直接提供四个实操步骤，按此执行基本不会出错。

第一步：锁定时间锚点

编写提示词时，开篇即明确起止时间。格式须精确到分钟：【2024-06-12 14:23:05】至【2024-06-12 14:47:19】。切忌使用“下午时段”等模糊表述，否则模型会按笼统时段自行推演，导致动作顺序混乱，复盘彻底失效。未写入具体时间戳，模型默认会模糊化处理，进而打乱事件序列，使复盘失去实际意义。

紧接着用一句话清晰界定事件性质。例如：“这是一次因数据库主从切换失败引发的订单支付超时事故。” 避免添加修饰或主观判断，仅陈述客观事实。类比写病历，应先写“患者发热”，而非“患者好像感冒了”。

第二步：强制分层输出结构

此环节为硬性规定。要求模型严格按照三层结构组织内容：时间线 → 原因归因 → 动作清单。三层缺一不可，且顺序不可调换。

时间线部分必须采用“时间戳 + 事件简述”格式，逐条对齐。禁止将多条事件合并表述，也禁止使用任何描述性语言修饰。例如，“14:23:05，监控告警触发”，表述干净利落。

原因归因部分每条前加“→ 原因：”，且仅写可验证的技术事实。可验证指能从日志或监控中查到的数据，如“MySQL binlog position 同步延迟达127秒”。避免写“可能是网络波动”，此类推测不属于归因。

动作清单按“角色 + 动作 + 时间偏移”列出。例如：“SRE张伟 → 手动触发failover脚本 → +03:12”。时间偏移从起始时间起算，单位为分:秒，便于清晰了解动作发生的精确顺序和间隔。

第三步：注入关键约束条件

此步相当于给模型戴上“紧箍”，防止自由发挥。以下三种方法建议同时使用。

方法一：用否定式排除干扰项。在提示词末尾直接写明：“不输出任何推测性语句（如‘可能’‘或许’‘疑似’），不出现‘后续优化建议’‘改进方向’等无关内容，不合并多个动作为一句描述。” 这样直接堵住模型“闲聊”和“自我演绎”的路径。

方法二：用正向指令固化格式。明确要求：“时间线中每个条目必须独立成行；原因归因不得超过3条，且每条必须对应时间线中至少一个时间点；动作清单中所有时间偏移值必须基于起始时间计算，单位为分:秒。” 将格式框定得严丝合缝。

方法三：植入校验钩子。此方法非常实用，追加一句：“若某动作未标注执行角色，则该动作视为系统自动行为；若某原因未在时间线中找到对应时间点，则该原因视为无效归因。” 这样模型不仅输出内容，还需自我验证，输出质量显著提升。

第四步：喂入最小必要上下文

仅有格式远远不够，模型还需明确分析对象。因此要提供最核心的上下文——注意是“最小必要”，避免一股脑全塞进去。

需提供三样内容：

① 系统架构简图：用纯文本描述核心组件关系。例如“支付服务（Java）→ 调用订单中心API → 查询MySQL主库（M1）→ 写入Redis缓存”。 无需画图，文字描述清楚调用链即可。

② 关键日志片段：粘贴3行真实报错日志，附带时间戳和错误码。例如“[14:25:33] ERROR c.p.s.PaymentService - DBConnectionTimeoutException: wait timeout after 3000ms”。 这能帮助模型精准定位故障点。

③ 人工操作记录：仅列执行人、命令、时间。例如“李婷，mysql -u root -e 'STOP SLAVE;'，14:26:01”。 绝对避免心理描写或背景说明。

缺少其中任何一个要素，模型都会通过“脑补”来填补缺失环节，导致复盘结果不可靠。