事故复盘必须严格按真实时间顺序还原事件脉络，自动识别因果链断点，并区分人为操作、系统响应与外部干预三类动作；第一步锁定精确时间锚点，第二步强制分层输出时间线→原因归因→动作清单，第三步用否定式排除干扰、正向指令固化格式、校验钩子验证有效性，第四步喂入最小必要上下文。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
写事故复盘提示词时，必须确保模型能按真实时间顺序还原事件脉络，自动识别因果链断点，并明确区分人为操作、系统响应与外部干预三类动作——缺一不可，否则复盘会遗漏关键责任节点或掩盖真实故障路径。
第一步：锁定时间锚点
在提示词开头直接给出精确到分钟的起始时间与终止时间，格式为“【2024-06-12 14:23:05】至【2024-06-12 14:47:19】”。【不写具体时间戳，模型将默认按模糊时段推演，导致动作错序】
接着用一句话说明事件性质：“这是一次因数据库主从切换失败引发的订单支付超时事故”。
第二步：强制分层输出结构
要求模型严格按三层结构组织内容：时间线→原因归因→动作清单。
时间线部分必须以“时间戳 + 事件简述”格式逐行排列，禁止合并、禁止描述性语言；原因归因部分每条前加“→ 原因：”，且只写可验证的技术事实（如“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”。【缺少其中任一要素，模型将虚构缺失环节】
