这个提示词用来做什么

刚刚处理完一次线上故障或 agent 跑偏，团队写了复盘文档，但下一次几乎不会再有人打开它

提示词全文

我刚刚经历了一次故障。请你帮我把复盘变成「下次能自动拦住它」的产物，而不是一份读过就忘的文档。

## 输入
发生了什么：{时间线、现象、影响范围}
怎么发现的：{监控告警 / 用户反馈 / 自己看到}
根因：{目前最可信的判断，以及你还不确定的部分}
当时的止血动作：{做了什么让服务恢复}

## 输出
1）先区分三类信息：已确证的事实、目前的推断、仍未确认的部分。推断必须标明「需要什么证据才能升级为事实」。
2）写出一个最小复现：用最少的步骤 / 数据把问题重现出来，写清前置条件、输入与预期失败的信号。
3）把它翻译成一条回归用例：触发条件、观测指标、判定失败的阈值；如果无法自动判定，写清人工判定的步骤与判据。
4）指出这次事故暴露的是「缺检测」「缺回退」还是「缺权限 / 流程」，并各给一条能在一周内落地的最小改动。
5）列出同类风险：这个根因还可能以什么别的形式出现在哪里（不要只盯同一个模块）。
6）给出一句话结论：这次真正该改的是哪一件事，以及如果不改、下次会以什么形式再来一次。

怎么用

  1. 把上面的提示词全文复制到对话窗口或工作流里。
  2. 把花括号占位符（如 {任务描述}）替换成你自己的内容。
  3. 条目越具体，产出越稳定；不需要的条目可以直接删掉。

输出示例

这类输出的价值在于第 3 与第 4 步：把「复盘」变成「回归用例加最小改动」。很多团队复盘写得很好，但因为没有可判定的失败信号，问题会在几周后以另一个面貌回来。

基本信息

  • 分类：工程
  • 标签：事故复盘 · 回归用例 · 可复现 · 防御设计 · 流程
  • 收录日期：2026-10-04

同类提示词