踩过的坑要"固化"，而不是"记住"
每次线上出问题，团队都会开个复盘 ✔ —— 结论常常是"以后注意" ✗。
三个月后同样的问题再来一次 ✔，因为结论没有变成可执行的检查 ✔。
把踩过的坑固化成"边界用例库" ✔：每条坑对应一个可复跑的用例 ✔。
一、一条用例要包含五样东西
① 输入（能复现问题的最小输入 ✔）
② 期望行为（正确的表现是什么 ✔）
③ 曾经的错误行为（当时发生了什么 ✔）
④ 关联信息（事故编号/日期/影响 ✔）
⑤ 归属（属于哪一类失败 ✔ —— 见失败分类那篇 ✔）
第 ③ 项很关键 ✗→✔：它让后人理解"为什么要有这条用例" ✔，
否则容易被当成"多余的测试"删掉 ✔。
二、用例从哪来（四个来源）
- 线上事故（每次事故至少一条 ✔）；
- 人工审核的修改（审核员改得最多的类型 ✔ —— 见审核队列那篇 ✔）；
- 用户反馈（点踩 + 人工确认过的 ✔ —— 见反馈回填那篇 ✔）；
- 红队/对抗测试（注入、越权、极端输入 ✔ —— 见红队那篇 ✔）。
要点：来源要与"实际发生过"挂钩 ✗ ✔，而不是凭空设计 ✔。
三、怎么让它不腐烂
- 进评测集（每次改动都跑 ✔ —— 见评测接进 CI ✔）；
- 有归属类别（同类坑集中看，能发现系统性原因 ✔）；
- 定期复查（功能变了、用例过时了 → 更新或退役 ✔，但要留记录 ✔）；
- 公开可见（谁都看得见"我们踩过哪些坑" ✔ —— 这对新人是极好的教材 ✔）。
四、三个反模式
- 复盘只写文档 ✗（没有可执行用例 ✔）；
- 用例只增不整理 ✗（几千条跑不完，最后跳过 ✔）；
- 用例没有"曾经的错误"说明 ✗（被当成冗余删掉 ✔）。
五、一个务实起点
① 把最近 3 次事故各写成 1 条用例（共 3 条 ✔）
② 接进冒烟集（30 秒能跑完 ✔）
③ 以后每次事故/重大修改都补 1 条 ✔
④ 每季度整理一次：合并同类、退役过时 ✔
一条判据
半年前那次事故的触发输入 ✔，今天能否自动被检查出来 ✔？
不能，说明复盘结论没有固化成用例 ✗。