先说一个核心判断：想让DeepSeek生成你直接粘贴进飞书看板、嵌入内部通报邮件、甚至当作SRE晨会发言素材的事故复盘报告，就别指望那些“加强管理、提高认识”的通用模板能派上用场。没有时间戳、没有系统名称、没有错误码的复盘文档，值班工程师扫一眼就会直接划走。真正的突破口，在于把提示词锚定在事故现场。
第一步：用三要素锁定事故现场
在DeepSeek对话框的第一行，必须把【角色】+【事故时间】+【系统模块】交代清楚。举个例子：“你是负责支付网关的SRE，2026年6月28日14:23–15:17发生超时熔断，影响订单创建接口（/v2/order/create）”。缺少任何一项，模型都会默认进入“通用故障分析”模式——那种只会输出“建议完善监控告警机制”的套话复读机。时间必须精确到分钟，写“上周”或“近期”只会让模型调取模糊知识库，而非聚焦本次事故的真实链路。
第二步：嵌入不可伪造的故障切片
这是让复盘从“纸上谈兵”升级为“现场重现”的核心手段。有三个方法可以结合使用。
方法一：粘贴真实错误日志片段
从Kibana中截取3行关键日志，比如：
“2026-06-28T14:23:41.128Z ERROR [payment-gateway] timeout after 3000ms on redis cluster ‘cache-01’”
“2026-06-28T14:23:42.001Z WARN [order-service] fallback triggered for /v2/order/create”
“2026-06-28T14:24:05.333Z INFO [alert-center] alert #ALERT-7892 fired: Redis latency > 2s”
方法二：填入真实监控截图数据点
在提示词中直接写明：“Prometheus中redis_cluster_latency_seconds_max指标在14:23:11突增至2.8s，持续17分钟；同时order_create_success_rate从99.97%跌至83.2%”。不写具体数值和时间点，模型会自行编造曲线图，那这个复盘就失去了回溯意义。
方法三：描述真实人工干预动作
写清楚：“值班工程师在14:25执行了redis cluster ‘cache-01’主从切换，14:32确认延迟回落至0.15s，但订单成功率未同步恢复”。这一步能迫使模型放弃“建议加强演练”这类空话，转而分析切换后为何未生效——这才是真问题所在。
第三步：指定输出结构并禁用虚词
要求模型按以下字段顺序输出，并用“|”分隔：故障现象|根因定位|影响范围|修复动作|验证方式|预防措施。每个字段都要加硬约束：
“故障现象”必须含HTTP状态码或错误码，比如“504 Gateway Timeout”；
“根因定位”必须引用具体配置项，比如“redis.conf中timeout=3000ms未适配新集群RTT”；
“预防措施”禁用“加强”“优化”“完善”这类空词，只允许动宾结构，比如“将timeout参数改为5000ms并加入CI校验”。
最后追加一句硬性要求：若某字段无法从提供的日志/数据中推导，则填‘无依据’，禁止推测。这条规则能彻底堵住模型“编故事”的冲动。
第四步：绑定可回溯的交付物
第一步，在提示词末尾明确要求：“所有修复动作必须对应Jira工单号，格式为‘PAY-7892’；所有验证方式必须含curl命令或Grafana Dashboard链接，例如‘https://grafana.company.com/d/redis-latency?from=now-30m&to=now’”。
第二步，输出后做可回溯校验：检查每行是否含且仅含5个“|”分隔符；抽查任意一行Jira工单号，打开链接确认存在；复制任一curl命令，在终端执行，确认返回HTTP 200。
第三步，验证预防措施的可执行性：把“将timeout参数改为5000ms并加入CI校验”这条措施发给运维同事，问他能不能立刻在CI pipeline里加上这条校验。如果对方说要改脚本或等排期，说明这条措施还不够落地——需要继续细化，直到对方能当场执行。