没有验证方式的「我们会加强」，等于没做。
复盘的目的不是"找责任人"
AI 功能的事故复盘最容易变成两件事：写一篇"我们以后会更小心"的文档 ✗，
或者把锅扣在"模型不稳定"上 ✗。两者都不会让下次不复发 ✗。
有用的复盘只回答三件事 ✔：当时发生了什么、为什么防线没挡住、加了什么防线。
一、把时间线写清楚（用日志，不用记忆）
· 什么时候开始异常（第一个失败请求的时间戳）；
· 什么时候被发现（谁发现的：告警 / 用户反馈 / 例行检查）；
· 什么时候恢复（以及恢复手段）；
· 影响范围（多少用户/请求、多少成本、多少脏数据）。
要点：全部来自日志与埋点 ✔；写"大约下午"这种描述等于没写 ✗。
二、问"防线为什么没挡住"（而不是"谁忘了"）
按层次逐条问：
1. 有没有监控到？（指标缺失 / 阈值太松 / 告警没人看）
2. 有没有护栏？（限流、超时、输入上限、预算告警）
3. 有没有降级？（上游挂了会不会整链断）
4. 有没有回滚？（能不能一键回退）
5. 是不是已知风险？（以前讨论过但没做 → 说明排期机制有问题）
回答完，根因通常落在"缺某类防线"，而不是"某人疏忽" ✔。
三、加防线（且必须是可验证的）
每条防线要落成具体动作 + 验证方式：
| 防线 | 验证方式 |
|---|---|
| 加输入长度上限 | 用超长输入跑一次，确认被拒且报错清楚 |
| 加成本告警 | 手工压测到阈值，确认告警真的发出 |
| 加租户配额 | 单租户压测，确认只影响该租户 |
| 加降级链 | 断开上游，确认逐层降级生效 |
没有验证方式的"我们会加强"，等于没做 ✗。
四、把事故变成测试用例
· 每个事故至少产出 1 条评测样本或 1 条红队样例（进样本库 ✔）；
· 相关的护栏动作接进流水线（见"评测集接进 CI"那篇 ✔）；
· 复发时能立刻判定"是不是同一类"，而不是从头查 ✗。
五、写作上的三条纪律
1. 只写事实与数据，不写情绪化评价；
2. 明确列出"我们不知道的部分"（别用推测填空）；
3. 结论可执行（有负责人、有时间、有验证方式）；做不到就写"暂不处理 + 理由"。
一个最小模板
```
发生了什么（时间线 + 影响面）
为什么防线没挡住（逐层检查 5 问）
加了什么防线（动作 + 验证方式）
产出了哪些测试用例（样本编号）
仍未解决 / 暂不处理（原因）
```
本文由云枢 AI导航整理，内容以官方来源为准。
相关文章
顺序阅读
← 上一篇：提示词里的「角色」设定到底有没有用
下一篇：向量检索之外：什么时候该用关键词、筛选与规则 →
第 45 / 171 篇