你的第一次 AI 事故：事后复盘模板
你的 AI 一定会出事故。这不是“会不会”的问题，唯一的问题在于：这次事故是让你学到东西，还是只让你付出代价。
AI 事故看起来不同于经典的宕机。系统并没有停摆，它一直都在线，一直在响应、在生成——只是生成的是错的。可能持续了数小时，甚至数天，才被人发现。数据库宕机是喧闹的，而 AI 事故是寂静的；寂静的事故才是昂贵的，因为它们在被人看见之前会运行更久。
事后复盘就是把寂静的事故转化为教训的方式。下面这个模板是我在用的，它专为 AI 事故的特殊形态而设计：不问“什么坏了”，而是问“什么出错了、持续了多久、以及为什么我们没有更早发现”。
五个部分
第一部分：它本应做什么。一段话，不加渲染。任务、预期行为、它被构建来达成的质量标准。这一部分的存在，是为了让复盘从共识出发——系统是为什么而存在的——而不是一上来就追责。
第二部分：它实际做了什么。行为、持续时间、影响范围。产出了多少、持续了多久、影响了什么。AI 事故的寂静特性在这里暴露无遗——这一部分常常以“我们不确定它具体是什么时候开始的”开头，而填补这个缺口的方法，就成了行动项的一部分。
第三部分：我们是怎么发现的。发现的故事。是客户投诉？是审核员察觉到了不对劲？还是某个指标终于越过了红线？这一部分最有价值，因为它告诉你你的检测是如何失灵的。持续了三天的那个事故，不是模型故障，而是检测故障，而这一部分会把它点明。
第四部分：为什么会发生。根因，不带指责地写。模型变了，数据漂移了，提示词漂移了，阈值设错了，评估套件漏掉了这个案例。点明原因，也点明促成因素——缺失的信号、未被监控的指标、反应太慢而没察觉的审核队列。
第五部分：接下来要交付什么。行动项，每一项都要具体、有负责人、有期限。不是“改进监控”，而是“周五前把覆盖率的信号加到仪表盘上，由操作员负责”。复盘的唯一任务就是产出这一部分，而只有当条目足够具体时，这一部分才算真实。
复盘的任务不是解释事故，而是让下一次事故更便宜——更短、更小、更早被发现。五个部分，不追责，并且行动项要真正落地。
让复盘真正奏效的评审节奏
写完就归档的复盘，只是一份文档；被反复评审的复盘，才是一套系统。区别就在于节奏。
即时评审在事故还新鲜时进行——团队走一遍这五个部分，争论“为什么”，并分派行动项。然后是三十天后的跟进：行动项落地了吗？检测改进没有？同样的事故明天还可能发生吗？三十天检查正是复盘通常“阵亡”的地方——劲头没了，事故成了旧闻，行动项也逾期了。这个检查的存在，就是为了让闭环保持诚实。
然后是季度性的模式评审：把最近几次事故放在一起看。AI 事故会扎堆出现。同样的检测缺口、同样的未监控信号、同样的评估盲点——每起事故单独都能解释，合在一起就成了一个有名字、有解法的模式。季度评审正是让个体教训转化为系统改进的地方。
让“不追责”原则真正落地
没有“不追责”原则，AI 事故复盘就会失败。而这条原则必须明文规定，因为人的本能就是去找出那个人——没察觉的操作员、交付模型的工程师、批准了错误输出的审核员。追责感觉很有成效，其实不然。它只会确保下一次事故被隐瞒，而不是被上报。
行之有效的表述是：是系统失败了，而这个系统是我们的。模型、监控、阈值、审核流程、训练——这一切都是团队设计的，而事故是对这套设计的一个发现。第一个上报事故的人是英雄，而不是罪人。内化这一点的团队能获得早期报告和快速的教训；做不到的团队得到的只有沉默和反复发生的事故。
收尾每一次复盘的那个问题
用同一个问题结束每一次复盘：如果这个一模一样的事故明天再次发生，我们怎样才能更快发现它？
答案就是行动项的总结。如果答案是“和我们这次发现它的方式一样”——一次客户投诉或某个审核员的直觉，那这次复盘就失败了，因为检测依然是被动的。如果答案是“覆盖率信号会在第一天就捕捉到它”，那这次复盘就成功了，因为下一次事故在发生之前就已经变得更便宜。