别让 AI 帮你找背锅侠：一个真正能解决问题的复盘提示词
有些问题最可怕的地方，不是没人负责。
而是每个人都能拿出证据证明：
这事不是我的锅。
产品说需求写清楚了。
研发说按需求做了。
测试说用例都跑了。
运营说上线通知发了。
客服说用户反馈也同步了。
听起来大家都没错。
可页面还是崩了，用户还是骂了，老板还是黑脸了。
这才是组织里最危险的场面：所有人都安全落地，问题却还躺在地上。
AI 很强，但如果你只拿它来写责任划分，它只会帮你把锅甩得更漂亮。真正有价值的用法，是让 AI 帮你把问题拆开，找到下一次不再重演的办法。
这篇文章咱们就聊一个实用场景：怎么用 AI 做一次不甩锅、能落地的复盘。
一、解释原因，不等于解决问题
很多人复盘时喜欢问：
- 为什么会出错？
- 是谁没检查？
- 哪个环节掉链子？
- 谁应该承担责任？
这些问题不是不能问。
但如果只问到这里，很容易变成“事故考古”。大家拿着聊天记录、截图、邮件、会议纪要互相防御。
最后产出一份看起来很完整的报告：
由于沟通不充分、流程不完善、责任边界不清晰，导致本次问题发生。后续将加强沟通、完善流程、明确责任。
熟不熟？
这类话放在哪家公司都能用，放在哪个事故里都像对。
可下次还是会炸。
因为它没有回答一个关键问题：
我们要改掉哪个具体动作，才能让同类问题更难发生？
复盘不是写检讨。
复盘是改系统。
二、AI 最容易被误用的地方：帮人证明“我没错”
现在很多人会把事故材料丢给 AI，然后让它生成复盘报告。
常见提示词长这样：
请根据以下信息，分析本次事故原因，并指出相关责任方。
这句话看着没问题，实际很危险。
因为它默认了一个方向：问题一定来自某个责任方。
AI 会顺着你的问题往下写。
它可能会输出：
- 需求方描述不够清晰
- 开发方缺少异常处理
- 测试方覆盖不足
- 发布方缺少灰度机制
- 项目管理方跟进不到位
听起来很专业。
但这时候，会议室里的气氛通常会变成这样：
产品开始解释需求为什么没问题。
研发开始解释为什么时间不够。
测试开始解释为什么环境不一致。
项目经理开始解释为什么风险已经提醒过。
每个人都进入防守姿态。
然后呢？
没有然后。
大家散会，问题继续埋着。
三、把问题从“谁错了”改成“哪里让错误变得容易发生”
想让 AI 真正帮上忙，提问方式要换。
别急着问责任。
先问系统。
你可以这样问：
你是一名经验丰富的事故复盘顾问。
请不要以追责为目标。
请帮我分析：本次问题是在哪些流程、信息、工具、协作方式中被放大的。
请按照以下结构输出：
1. 事实经过：只写已发生的事实，不做情绪判断
2. 问题链路：从触发点到最终影响，逐步拆解
3. 系统漏洞：哪些机制让这个问题没有被提前发现
4. 可改动作：每个漏洞对应一个具体改法
5. 下次预警信号：以后看到哪些现象，就要提前介入
素材如下：
【粘贴事故记录、聊天截图摘要、时间线、用户反馈】
这段提示词的重点，不是“帮我写得好看”。
重点是把 AI 的注意力从人身上挪开，放到机制上。
不要问：
谁没做好？
要问：
为什么这个错误一路绿灯？
这才是真问题。
四、一个好用的 AI 复盘框架：事实、链路、漏洞、动作
咱们把它拆细一点。
你以后做复盘，可以直接套这个框架。
1. 事实：只写发生了什么
事实部分不要夹带情绪。
别写：
研发没有认真检查，导致线上接口异常。
换成：
20:10 发布新版本。20:23 监控出现接口 500 报警。20:28 客服收到用户反馈。20:35 研发开始回滚。20:50 服务恢复。
事实越干净，争吵越少。
因为大家最容易吵的，不是事实，而是解释。
你可以让 AI 帮你整理时间线：
请根据以下材料整理事故时间线。
要求：
- 只保留可验证事实
- 不加入主观评价
- 时间不明确的内容标注为“待确认”
- 用表格输出：时间、事件、来源、待确认点
输出效果大概这样：
| 时间 | 事件 | 来源 | 待确认点 | |---|---|---|---| | 20:10 | 新版本发布 | 发布记录 | 无 | | 20:23 | 接口 500 报警 | 监控系统 | 无 | | 20:28 | 客服收到用户投诉 | 客服群记录 | 用户影响范围 | | 20:35 | 开始回滚 | 运维记录 | 回滚触发人 | | 20:50 | 服务恢复 | 监控系统 | 无 |
这一步很关键。
先把事实摊平，别急着审判。
2. 链路：问题是怎么一路滚大的
一个线上事故通常不是单点失败。
它更像一串多米诺骨牌。
比如：
- 需求变更没有同步到测试
- 测试环境没有覆盖真实数据
- 发布前没有自动化校验
- 监控报警只发到了没人看的群
- 用户反馈比内部报警更早出现
如果你只抓住一个点骂，下一次换个地方照样炸。
让 AI 帮你画问题链路，可以用这个提示词：
请把本次问题拆成一条“问题链路”。
格式如下：
触发点 → 中间放大因素 → 未被发现的原因 → 最终影响
要求：
- 每个节点必须来自材料，不要脑补
- 如果缺少证据，请标注“需要补充信息”
- 不要写责任人姓名，只写角色或环节
好的输出应该像这样：
接口字段变更
→ 测试用例没有覆盖旧版本客户端
→ 发布前缺少兼容性检查
→ 监控只发现服务端错误，没有覆盖客户端白屏
→ 用户集中反馈无法下单
这比“测试不充分”有用多了。
因为它告诉你：下次应该补哪里。
3. 漏洞：不是谁粗心，而是哪道门没锁
很多复盘喜欢写“人员疏忽”。
这四个字特别省事，也特别没用。
人一定会疏忽。
人会累，会赶时间，会误解，会漏看消息。
一个成熟系统不能把安全寄托在“大家都认真一点”上。
你应该让 AI 帮你找“机制漏洞”。
提示词可以这样写：
请从机制角度分析本次问题。
不要使用“粗心”“意识不足”“不够重视”这类模糊描述。
请输出：
- 漏洞名称
- 漏洞表现
- 为什么现有流程没有挡住它
- 如果不改，可能再次出现在哪些场景
比如 AI 可能输出：
| 漏洞名称 | 漏洞表现 | 为什么没挡住 | 复发场景 | |---|---|---|---| | 变更同步漏洞 | 字段变更未同步到测试用例 | 缺少需求变更通知清单 | 接口改造、活动页上线 | | 发布校验漏洞 | 上线前未验证旧客户端兼容性 | 发布 checklist 没有兼容项 | App 多版本共存 | | 监控覆盖漏洞 | 报警晚于用户投诉 | 监控只看接口，不看关键业务路径 | 下单、支付、登录 |
看到没？
这才是能改的东西。
4. 动作：别写口号，写到谁明天能做
“加强沟通”不是动作。
“提高意识”不是动作。
“完善流程”也不是动作。
它们都太虚了。
真正能落地的动作，至少要包含四个元素：
- 做什么
- 谁来做
- 什么时候做
- 怎么验证完成
你可以让 AI 按这个格式输出：
请把复盘结论转成可执行改进项。
每条改进项必须包含：
- 具体动作
- 负责人角色
- 截止时间
- 验收标准
- 如果不做，会有什么风险
禁止使用：加强、提高、完善、优化、重视。
为什么要禁这些词？
因为它们太会糊弄人了。
好的改进项应该长这样：
| 具体动作 | 负责人角色 | 截止时间 | 验收标准 | 风险 | |---|---|---|---|---| | 在发布 checklist 增加“旧客户端兼容性验证” | 测试负责人 | 本周五 | 每次发版记录中必须有兼容性截图或日志 | 旧版本用户可能再次无法下单 | | 给下单链路增加模拟用户巡检 | 后端负责人 | 下周三 | 每 5 分钟自动跑一次下单流程，失败后通知值班群 | 内部接口正常但用户仍无法使用 | | 建立需求变更通知模板 | 产品负责人 | 本周四 | 每次字段、规则、页面变化都必须同步影响范围 | 测试用例继续漏掉变更点 |
这类内容才配叫复盘。
因为明天就能开干。
五、完整提示词：直接复制就能用
下面这版适合团队事故复盘、项目延期复盘、活动翻车复盘。
你可以直接复制到 ChatGPT、Claude、豆包、通义千问里用。
你是一名资深事故复盘顾问。
本次复盘目标：找到可执行的系统改进动作，而不是追责。
请严格遵守：
1. 不判断个人对错
2. 不使用“粗心、意识不足、不够重视、沟通不到位”这类模糊词
3. 所有判断必须基于我提供的材料
4. 信息不足时，请标注“需要补充信息”
5. 输出内容要能变成下周的行动清单
请按以下结构输出：
## 1. 事实时间线
用表格输出：时间、事件、证据来源、待确认点。
只写事实，不写评价。
## 2. 问题链路
用“触发点 → 放大因素 → 未被发现原因 → 最终影响”的格式描述。
## 3. 系统漏洞
用表格输出：漏洞名称、具体表现、现有机制为什么没挡住、可能复发场景。
## 4. 可执行改进项
用表格输出：具体动作、负责人角色、截止时间、验收标准、风险。
每条动作必须具体，禁止写口号。
## 5. 下次预警信号
列出 5 个以后看到就要提前介入的信号。
以下是复盘材料：
【在这里粘贴事故记录、聊天摘要、用户反馈、监控数据、会议纪要】
六、示例：把一段“甩锅复盘”改成“解决问题复盘”
原始写法
本次问题主要由于测试不充分导致。后续需要测试同学提高责任心，开发同学加强自测，产品同学加强沟通，避免类似问题再次发生。
这段话最大的问题是：看起来什么都说了，其实什么都没安排。
谁做？
做什么？
什么时候做？
怎么证明做完？
全都没有。
改成 AI 可执行版本
本次问题暴露出三个机制漏洞：
1. 测试用例未覆盖旧版本客户端
2. 发布 checklist 缺少兼容性验证项
3. 关键业务链路缺少自动巡检
改进动作：
- 测试负责人在本周五前补充旧版本客户端兼容性用例，覆盖登录、下单、支付三个路径
- 发布负责人在下次发版前更新 checklist，新增“旧版本验证截图”必填项
- 后端负责人在下周三前接入下单链路自动巡检，每 5 分钟执行一次，失败后通知值班群
这才像话。
少一点“谁的问题”，多一点“怎么不再发生”。
七、避坑清单：这些复盘写法，建议直接删掉
做 AI 复盘时，下面这些表达尽量别用。
❌ 1. “加强沟通”
太虚。
改成：
每次需求变更后，产品在项目群同步变更点、影响范围、需要回归的功能，并由测试确认收到。
❌ 2. “提高责任心”
没法验收。
改成：
发布前必须完成 checklist，缺一项不得上线。
❌ 3. “相关人员注意”
等于没人负责。
改成：
值班研发负责监控报警响应，5 分钟内确认，15 分钟内给出处理方案。
❌ 4. “避免再次发生”
愿望很好，没用。
改成：
增加自动化巡检，覆盖登录、下单、支付路径，异常时自动报警。
❌ 5. “流程不完善”
太宽泛。
改成：
发布流程缺少旧版本客户端兼容性验证项。
八、一个判断标准：复盘结束后，大家是在防御，还是在行动？
你判断一次复盘有没有价值，别看报告写得多漂亮。
看会后大家在干什么。
如果大家都在解释：
我当时已经说过了。
这个不归我管。
我是按流程来的。
那这场复盘基本偏了。
如果大家开始讨论：
checklist 加哪一项？
监控谁来接？
下次发版前怎么卡住？
哪个动作本周能完成？
那才对路。
AI 不是用来帮你找更精准的背锅对象。
它更适合帮你看清：为什么一个小问题能穿过那么多环节，最后砸到用户脸上。
一个问题，不会因为你找到了更精确的责任人，就突然不算问题。
解释原因，也不等于解决问题。
真正的复盘，是让下一次错误没那么容易成功。
