复盘模板：项目复盘会议怎么开（附议程和 5Why 分析法）

凌晨 2 点，上线出了事故。到早上，火总算灭了，有人约了一场标题为“复盘”的会。每个人走进会议室时都提心吊胆，等着某个人的名字和这次故障绑在一起。大多数复盘会开不好，恰恰就是因为这种恐惧。

复盘会议本该让团队变得更聪明，而不是让人人自危。开得好，它能把一次痛苦的事件变成一份简短的改进清单，让同样的故障不再发生第二次；开得不好，它就成了一场无声的审判，大家只学到一个教训：下次什么都别承认。这两种结果的差别不在议程，而在于会议室里是否足够安全，让人敢说真话。

简单来说，复盘会议应在事件解决后 24 到 72 小时内召开，时长 60 到 90 分钟：先讲明不追责的原则，再依次梳理时间线、做得好的地方和出问题的地方，用 5Why 分析法找到根本原因，最后定下 3 到 5 项有负责人、有截止日期的待办事项。文末附一份可直接复制的复盘模板。

复盘会议是什么

复盘（post-mortem）是指在某个具体事件之后召开的结构化回顾会，目的是还原事情经过，并决定要改什么。关键在于“触发”：复盘不按日程定期开，而是因为发生了某件事才开，比如产品上线了、服务宕机了、项目到了终点。

还有一点常被忽略：复盘不只是出了大事才开。最好的团队在顺利上线之后、在事故或宕机之后、在项目收尾之后都会复盘，不管结果如何。一次顺利的上线，可能掩盖了一些这次碰巧管用、下次未必管用的决定。复盘一次成功，才能看清哪些靠的是本事，哪些靠的是运气。

也要分清复盘不是什么。回顾会议（retrospective）按固定节奏开，通常每个迭代一次，不管有没有出问题，都会全面审视团队的工作流程。复盘则聚焦于单个事件，由事件触发：一次事故、一条时间线、一个根本原因。经验教训文档（lessons learned）则是产出物，是把心得写下来归档，方便以后的团队查阅。会议产出经验教训，文档负责保存。成熟的团队三样都用，也不会假装其中某一样能取代另外两样。

复盘的底线：对事不对人的不追责文化

如果这篇文章你只记住一点，就记住这一点：不追责的复盘（blameless post-mortem）关注的是哪里出了错，而不是谁错了。它要查的是哪些系统、流程和缺失的信息让错误溜了过去，而不是把事件归咎到某个人身上。

这不是图个和气的软性偏好。这个理念来自医疗和航空业：在这些行业里，一个被掩盖的错误可能会出人命，所以每一次差错都被当作加固系统的机会。这套逻辑放到任何团队都成立。人一旦害怕被当众批评或被开除，就不会再主动暴露问题。事故被捂住，组织背上的隐藏风险只会更多，不会更少。不追责，就没有了隐瞒的动机。

这种转变很具体。不说“你的部署把结账功能搞挂了”，而是问“为什么一次部署就能在没有任何防护的情况下把结账功能搞挂？”前一种说法会让对话就此结束，后一种才会引出真正的修复方案：也许需要一道预发布环境的卡点，也许需要一个更早触发的告警，也许需要一个几秒钟而不是一小时就能完成的回滚。追责找到的是“罪人”，不追责找到的是漏洞，而漏洞才是你真正能补上的东西。

提示：现场就把“谁”换成“什么”。 作为主持人，随时准备好一句话：“我们换个角度，把它当成系统问题来看。”有人说“Jordan 忘了打开那个功能开关”时，你可以接着说：“也就是说，流程允许一次发布带着一个很容易漏掉的手动步骤上线。什么机制本来能拦住它？”你不是在袒护 Jordan，而是把大家的精力引向能修复的地方。

复盘会议怎么开：一份不跑题的议程

好的复盘每次都走同样的流程，这正是它管用的原因之一：结构可预期，大家才放得开。时长控制在 60 到 90 分钟，开会前先定好两个角色：一位中立的主持人，负责让讨论保持平衡；一位记录员，负责记下每一个事实和每一项决定。流程如下。

1. 定基调（2 分钟）

主持人一开场就明确说出不追责的原则，不要当成一句客套话带过。直接说：我们今天是来弄清楚系统哪里出了问题，不是来追究谁的责任，谁要是开始追责，我会把话题拉回来。一开始就把话说在前面，主持人后面执行起来才有底气。

2. 还原时间线和事实（15–20 分钟）

按顺序梳理事件经过，从出现第一个信号一直到彻底解决。从日志、聊天记录、工单时间戳和项目文档里取材，让时间线建立在事实上，而不是记忆上。看似无关紧要的事件也要写进去，小细节往往才是关键转折点。这一步先别急着下结论。目标是在大家讨论“为什么”之前，先对“发生了什么”达成一致。

3. 哪些做得好（10 分钟）

即使结果很糟，这部分也要实事求是地谈。哪些监测手段起了作用？谁在压力下做了正确的判断？把做得好的地方说出来，既能保住值得保留的做法，也是在告诉大家：这场会不是来惩罚人的。

4. 哪些出了问题（10–15 分钟）

直接列出哪些环节出了问题，把它们当作系统事件，而不是个人过失。“错误率飙升 40 分钟后告警才触发”是有用的描述，“运维反应太慢”则没有用。

5. 用 5Why 分析法做根因分析（15–20 分钟）

这一步要深挖。5Why 分析法是指连续追问“为什么”，大约问 5 次，直到找到症状背后出问题的流程，而不是停在症状本身。5 不是什么神奇数字，它的意思是“一直挖，挖到结构性的问题为止”。

每天用这个方法的人都会告诉你一条铁律：人永远不能当作根本原因。“人为失误”“B 组的错”“有人没注意”，这些答案都说明你停得太早了。如果某个“为什么”落到了某个人身上，就接着问：为什么系统会让这个人出错？举个简单的例子：

• 结账页面宕机了。为什么？
• 一个有问题的配置发布到了生产环境。为什么？
• 它通过了评审，却没人发现里面的拼写错误。为什么？
• 配置变更没有自动化测试来校验。为什么？
• 我们一直没建这样的测试，因为配置“很少改”。根本原因：高风险、低频率的变更缺少自动化防护。

注意，最后的答案是缺了一套机制，而不是某个工程师粗心。这正是 5Why 分析法的意义所在。

6. 定下待办事项和负责人（10 分钟）

会议一定要以具体行动收尾，否则就是走过场。每一项待办事项都要有具体的负责人和截止日期。一句含糊的“我们应该加强测试”只会烂在文档里，“在 CI 里加一个配置校验测试，负责人 Priya，7 月 10 日前完成”才会真正落实。整整一小时的会，要产出的就是这份清单。

提示：待办事项最多 3 到 5 项。 一场复盘列出 20 项跟进事项，等于一项都不会跟进。逼着大家挑出最能改变结果的那几项改动，再分配下去。以后随时可以再开一次复盘，但一份塞得满满的清单，你永远落实不了。

主持复盘会议：怎样守住心理安全感

议程只是骨架，主持得好不好，决定了它在一支压力很大的团队面前能不能撑住。下面几个做法，能让“安全感”真正落地，而不只是嘴上说说。

邀请所有受事件影响的人。每个受影响的部门都派一位代表到场，免得哪个部门因为缺席成了大家甩锅的对象。主持人要中立，最好没有负责过这次被复盘的工作，因为一个要为自己决定辩护的人，没法公正地当裁判。注意措辞，带头把“你”换成“流程”，直到大家开始自觉这么说。还要让离故障最近的人先发言，并且能放心地发言：他们掌握着最有用的细节，而只有当第一个承认疏漏的人得到感谢而不是围攻时，他们才愿意说出来。

还有一件不起眼但很重要的事：把所有内容记在大家都看得到的地方。时间线和决定当场记录、实时共享，一周后就没人再为事实争来争去，待办事项也不会不了了之。靠记忆，就谈不上问责。

复盘会议记录：决定成败的一环

复盘会上，事实和待办事项就是一切。如果时间线模糊不清，或者负责人一直没写下来，那你开的只是一场吐槽会，而不是复盘。麻烦在于，最有价值的讨论往往发生在主持人全神贯注参与对话、没空打字的时候，而记录员一分心，就会漏掉一半的因果链条。

这正是 AI 会议记录工具的用武之地。Laxis 这类工具会录制并转写整场会议，把关于时间线的讨论逐字记下来，再自动提取待办事项、决策和下一步计划，并标明负责人。不用再有人手忙脚乱地边听边记，主持人可以专心主持，大家商定的改进措施会整理成一份清晰的摘要，直接放进你的经验教训文档。它支持 Zoom、Google Meet 和 Microsoft Teams，支持 100 多种语言，如果跟进事项需要进入 HubSpot 或 Salesforce，也能同步过去。重点不在于记录有多漂亮，而在于修复措施真正被记录下来、分配出去，同样的故障才不会重演。

复盘模板（可直接复制）

把下面的模板粘贴到文档或会议工具里，边开会边填。它和上面的议程一一对应。

复盘会议议程和模板

事件： [上线 / 事故 / 项目名称]
事件日期： [日期] | 复盘日期： [24–72 小时内]
主持人： [姓名] | 记录员 / 记录工具： [姓名或工具]
参会人： [每个受影响的部门一位代表]

0. 基本原则（开场时念出来）： 这次复盘不追责。我们关注系统和流程，不针对个人。

1. 影响概述： 影响了什么、持续了多久、谁受到了影响。

2. 时间线（只写事实）：
[时间]：[发生了什么]
[时间]：[发生了什么]
[时间]：已解决

3. 做得好的地方： [这些要保留]

4. 出问题的地方： [写系统事件，不追责]

5. 根本原因（5Why 分析法）：
为什么？→ [ ]
为什么？→ [ ]
为什么？→ [ ]
为什么？→ [ ]
为什么？→ 根本原因： [缺失的机制，绝不是某个人]

6. 待办事项（最多 3–5 项）：
[行动]，负责人：[姓名]，截止日期：[日期]
[行动]，负责人：[姓名]，截止日期：[日期]

7. 本文档存放位置： [经验教训归档的链接]

自动记录时间线和改进措施

Laxis 会录制并转写你的复盘会议，自动提取待办事项、决策和负责人，从开会到修复，什么都不会丢。你只管专心主持，会议记录交给它。

免费试用 Laxis

总结

检验一场复盘的，不是会议本身，而是 6 周之后发生了什么。如果下一次复盘时，你发现同一个根本原因换了个样子又冒了出来，那上一次复盘就没起作用，不管当时讨论得多好。只有当待办事项真正落地，悄悄堵上一个不会再出问题的口子，这场复盘才算数。把每一次复盘都当成对未来的自己许下的承诺，再看你有没有兑现它。

常见问题

复盘会议是什么？

复盘会议是在某个具体事件之后召开的结构化回顾会，比如产品上线、服务宕机或项目收尾，目的是还原事情经过，并决定怎样防止不好的部分再次发生。它针对的是具体事件，核心内容是基于事实的时间线、根因分析，以及一份有负责人和截止日期的待办事项清单。

复盘会议什么时候开？

等尘埃落定、但记忆还没模糊的时候开，最好在事件解决后的 24 到 72 小时内。这个时间点既晚到足以让情绪冷静下来，又早到大家还记得细节。任何一次上线、事故或项目收尾之后都可以开，不管结果好坏。

不追责的复盘是什么意思？

不追责是指复盘调查的是系统和流程，而不是个人，也就是对事不对人。这个原则起源于医疗和航空业，在这些行业里，失误可能致命。人们不担心受罚，才会如实上报问题，你才能修复导致故障的条件，而不是找一个人当替罪羊。

复盘和回顾会议有什么区别？

回顾会议按固定节奏开，比如每个迭代一次，不管有没有出问题，都会回顾一段固定时间内的团队流程。复盘则由某个具体事件触发，深挖一次事件的时间线和根本原因。很多团队两种都用：回顾会议用来做日常调整，复盘用在重大里程碑或重大故障之后。

复盘中的 5Why 分析法是什么？

5Why 分析法是一种根因分析方法：连续追问“为什么”，通常问 5 次左右，直到找到症状背后出问题的流程，而不是停在症状本身。核心规则是：人永远不能当作答案。如果“为什么”落到了人为失误上，就继续追问，找出是什么机制让这个失误有机会发生。