标准场景报告文书岗位 · 产品

VA-03 · 事故复盘初稿

痛点　事故复盘停在「下次注意」—— 三个月后同类事故再来一次 · 复盘的价值在改进项闭环，初稿是闭环的起点

① 场景引入

一、这件事现在是什么样

验收与发布 · 真实业务触发

周四 15:23，运维群弹出告警：标准版部分客户的巡检上报超时。17:40 恢复，影响 9 家客户、累计异常 96 分钟。陈默要求周五上午出复盘。以往复盘的流程是：江晓连夜翻群消息和告警记录、凭记忆拼时间线、初稿写到凌晨两点 ——而上上次复盘的三条改进项，有一条「建立发布检查执行留痕」落空了（VA-02 这次才补上）。复盘本身，也到了该被复盘的时候。

二、痛点 · 每条都有来源

1复盘的通病是「只停留在口头，下次还会重演」：同类事故二次发生的根因不是没复盘、是改进项没有跟踪闭环依据· Agent 项目的行业失败率：麦肯锡统计超 90% 企业 Agent 试点即失败，「Demo 惊艳、两周被叫停」的复盘直指责任归属无人敢碰 —— 每个场景必须有人拍板点2初稿的体力活占了大头：翻告警、对群消息、拼时间线 —— 两小时的会议开完，写初稿又要一个凌晨依据 · 连锁反应式灾难上线判例：跨域限制只在生产环境生效导致数据服务失效 ——需求评审时没拉出影响范围图，一行代码的变更踩了别人的线；「上线后 24 小时手机不要静音，你是第一责任人」是产品经理的自保实录3《如期上线》的复盘基线要求时间线/影响面/根因/改进项四要素 —— 而多数复盘死在「根因写成现象、改进项写成态度」依据 · 发布管理的实操基线：《如期上线》复盘模板要求发布前核对影响范围、回滚预案与灰度计划；需求确认书（In/Out of Scope）是对外交付的护身符

三、换个做法之后

变化不在「快」，在「参与的角色」和「覆盖的范围」

✕ 现在的做法

复盘的通病是「只停留在口头，下次还会重演」：同类事故二次发生的根因不是没复盘、是改进项没有跟踪闭环初稿的体力活占了大头：翻告警、对群消息、拼时间线 —— 两小时的会议开完，写初稿又要一个凌晨《如期上线》的复盘基线要求时间线/影响面/根因/改进项四要素 —— 而多数复盘死在「根因写成现象、改进项写成态度」✓ 交给 Agent 之后多来源文件一次读入，先做口径与完整性校验，再开始算每条结论绑定来源文件、字段或条号，可以被审产出是企业真会流转的正式件（带签批栏），不是一张展示用的表该拦的地方给出「现在还不能提交」，并给不用干等的替代方案

四、场景闭环

5 步 · 每一步的产出都是下一步的输入

时间线梳理 · 每个节点带证据15:23 告警→15:31 响应→16:05 定位→17:40 恢复 —— 每个节点配群消息或告警的原始引用
影响面量化 · 客户/时长/业务9 家客户、96 分钟、上报受影响的工单数 —— 数字化的影响面，不写「部分用户」
5Why 辅助 · 每层给证据不给结论超时→连接池耗尽→发布引入的配置未生效→检查清单没有环境项→模板两年未升级 —— 每层标证据强度
历史改进项审计 · 闭环检查上上次的三条改进项逐条核对状态—— 落空的标出（本次事故与其相关性）
复盘会材料 · 事实在前定性在后初稿只摆事实与证据链，根因与改进项留白给会议 —— 「复盘会开在事实上」

要准备什么：告警与监控记录时间戳最硬的证据 —— 原样扔进来事故期间的群消息运维群/研发群/客服群的原始记录受影响客户与工单影响面的量化 —— 客服侧的对照上上次复盘的改进项清单该闭环的先审 —— 复盘的连续性

为什么这个场景值得做

优先级评分：痛感 4 × AI 适配 4 ÷ 落地难度 2 = 8.0

最大差异点：不要求先有 APM 系统。告警记录、群消息截图、工单导出扔进来 —— 时间线 30 分钟成稿，复盘会开在事实上而不是记忆上。

评分口径：痛感看「这事没做好谁会生气、生气到什么程度」；

AI 适配看「输入是否非结构化、是否要跨部门取数、错了能不能当场看出来」；

落地难度是分母 —— 需要客户先做数据治理的场景，分数会被压得很低。

五、会产出什么

判断标准只有一个：这份东西能不能直接进企业的流程

正式件本体：事故复盘初稿.xlsx 时间线 + 影响面 + 5Why 证据链
可派发清单：历史改进项审计表.xlsx 上上次的改进项逐条核状态 · 落空项与本次的关联
可派发清单：复盘会材料包.txt 事实部分成稿 · 根因与改进项留白 · 会议议程建议

这套东西不承诺什么：不做「根因认定」—— 5Why 的每一层都给证据链，最终归因是复盘会上人的共识。也不做「责任判定」—— 初稿只摆事实，定性留给人。

② Live Demo（演示逐步）

演示模式 · 可视化预演 本页展示的是「应该怎么跑、每一步看什么、交付什么」，用的是真实业务格式的脱敏构造数据，不宣称已接入客户生产系统，也不承诺任何效率提升百分比。

案例设定：驭数科技（虚构）事故日：周四 15:23，运维群弹出告警 —— 标准版部分客户的巡检上报超时。17:40 恢复，影响 9 家客户、累计异常 96 分钟。陈默要求周五上午出复盘。以往复盘的流程是江晓连夜翻群消息、凭记忆拼时间线、初稿写到凌晨两点 —— 而上上次复盘的三条改进项，有一条落空了。

影响面9 家 · 96 分钟直接投入8 人时 · 14 条工单时间线节点8 个 · 全带证据结论根因第三层待验证 · 初稿不替会定论

输入产品手上能拿到的东西

不需要整理格式、不需要改文件名 · 直接拖进对话框

01_告警与监控记录.xlsx 时间戳最硬的证据 —— 时间线的骨架监控系统导出 · 2026-08-27
02_事故响应群消息.txt 处置过程的现场 —— 时间线的血肉微信运维群 · 2026-08-27
03_受影响客户与工单.xlsx 影响面的量化 —— 客服侧的对照客服工单导出 · 2026-08-27
04_运维配置变更记录.xlsx 根因的第一现场 —— 昨天那次批量配置运维平台导出 ·2026-08-26
05_上上次复盘改进项.txt 改进项闭环的审计基准 —— 那条落空的改进项v3.2 事故复盘 · 2026-05

注意标橙色那一份 —— 02_事故响应群消息.txt。它微信运维群 · 2026-08-27，平时压根不在核对范围里。这个场景的价值，很大一部分就来自把它读进来。

提示词就说这么几句

没有模板、没有表单 · 专业规则由 Skill 兜底

昨天那个上报超时的事故，告警记录、运维群和研发群的消息、客服那边的工单都在这，周五上午要复盘，帮我出个初稿。时间线先拼直：每个节点配上群消息或告警的原始引用，别靠我回忆；影响面给我数字化：几家客户、多长时间、多少工单 —— 别写「部分用户」这种话； 5Why 每层都给我证据，没证据的标「待验证假设」，别拿假设当根因；上上次复盘的三条改进项帮我核一遍状态 —— 落空的那条跟这次有没有关系，要说清楚；初稿只摆事实，根因和改进项留白给会议 —— 我要的是开会十分钟就进入讨论，不是先对事实吵半小时。

短是因为「时间线证据结构、5Why 分层规则、改进项闭环审计」都在能力包里。产品经理只要把原始记录扔进来。触发96 分钟的事故 vs 凌晨两点的初稿

复盘的体力活外包给取数 —— 人留着力气讨论根因

江晓把告警记录、响应群消息、影响面、配置变更、旧改进项全部扔进来 —— 初稿的骨架五份原料里四份是现成的系统记录。

第 1 步 · 时间线梳理 · 八节点全带证据

从配置变更到恢复 —— 每个节点可点开原文

演示数据（表格原文）时间节点证据08-26 22:15配置变更（埋雷）运维平台记录08-27 15:23告警触发监控15:31响应启动群消息16:05根因定位（1台未生效）群消息（谭锐）16:32配置重推群消息17:40恢复确认监控时间线的第一个节点是前一天的配置变更 —— 事故的起点不在告警响起时，在变更发生时 —— 复盘的时间线从「埋雷」画起，改进项才能改对地方。

第 2 步 · 影响面量化 · 不写「部分用户」

9 家 × 96 分钟 × 14 工单 —— 每个数字可核对

指标数值口径受影响客户9 家（标准版 96 家中的 9.4%）按实例归属累计异常时长96 分钟（15:23-17:40）监控口径客户工单14 条（安抚 + 重报指引）客服记录直接处置投入8 人时（运维 3 + 研发 4 + 客服 1）群消息与工时折算影响面的四个数字全部带口径 —— 「9.4%」的分母是 96 家标准版客户，私有化 44 家因独立部署未受影响 —— 数字化的影响面是后续一切讨论（赔付、告知、改进优先级）的地基。

第 35 步 · Why 辅助 · 每层给证据

第三层标「待验证」—— 拿假设当根因是复盘最大的病

演示数据（表格原文）层级追问证据强度Why1上报为什么超时？—— DB 连接池耗尽监控+群消息Why2连接池为什么耗尽？—— 1 台实例配置未生效（上限偏低）运维平台记录Why3为什么没发现未生效？—— 平台显示「成功」待验证：状态校验机制缺失？Why4为什么显示成功？—— 配置下发无生效核验待验证（需运维平台方确认）Why5为什么没有核验？—— 制度与工具双缺制度层 · 复盘会讨论5Why 的五层里三层带证据、两层标待验证 —— Why3/Why4 涉及运维平台的机制细节，需要平台方确认后才能定稿。「待验证」不是初稿的瑕疵，是诚实的标志 —— 会上没人反驳的假设会固化成『真相』，那才是复盘最大的病。

第 4 步 · 历史改进项审计 · 落空的那条

「为什么改进项会落空」—— 本次复盘的元问题

演示数据（表格原文）旧改进项状态与本次的关联发布检查配置生效验证VA-02 已落实若本次是发布引发则可拦配置变更双人复核执行中昨晚变更走了复核，未拦住变更后 24h 加严监控落空若闭环，今晨即可发现第三条改进项的落空与本次事故直接相关 ——更有意思的是第二条：双人复核执行了但没拦住（复核的是「操作正确」不是「生效结果」）—— 改进项要「可验收」才有意义，「加严监控」这种没有责任人和验收标准的写法，落空是宿命。

第 5 步 · 复盘会材料 · 事实在前定性在后

初稿摆事实 —— 根因与改进项留白给会议

演示数据（表格原文）材料结构状态时间线 + 影响面 + 5Why 证据链已成稿根因认定（Why3-5 待验证项）留白 · 会议讨论改进项清单留白· 建议从「配置生效核验」与「改进项验收标准」两题入手责任认定不预设 · 事实部分已含各环节响应时长初稿的克制：响应时长（告警到响应 8 分钟、定位 34 分钟）都在合理区间的事实已经摆在时间线里 —— 「运维响应慢」这类伤人的定性不需要写 —— 排除性的数据自己会说话。初稿还不能交陈默 —— 5Why 的两层「待验证」没闭环Why3/Why4（运维平台的状态校验机制）是根因链的腰部 ——没验证就上会，会议会花半小时争论「显示成功为什么没生效」这个本该会前确认的事实问题；而带着错误假设开复盘会，得出的根因和改进项会整体跑偏 —— 上次「改进项落空」的教训之一就是根因定性太快。给出的不是干等：方案 A（今晚会前闭环·推荐）：让运维小周今晚找平台方确认状态校验机制（一次内部沟通）—— Why3/Why4 定稿，明早的会直接从「为什么没有核验机制」的第五层开始 —— 会议效率最高的形态；方案 B（带假设上会）：初稿照交，Why3/Why4 标注「待验证」并在会上安排 10 分钟现场确认 —— 会议多花的时间换所有人的现场共识。两案差一晚 —— 而「30 分钟出初稿」置换「凌晨两点」的体力账，两种方案都已经赚回来了。之后这一次跑完，公司多了什么

不讲省了多久 · 讲少了几个隐患、沉淀了什么

演示数据（表格原文）✓凌晨写初稿的体力活变成 30 分钟 —— 时间线每节点带证据，会议不再对事实吵架✓「假设当根因」被标红拦截—— 待验证的归待验证，会上没人反驳不会固化成真相✓落空的改进项与本次事故的关联被摆上桌 —— 「为什么改进项会落空」成为复盘的元问题✓「运维响应慢」被时间线排除 —— 火力从伤人转向改流程，复盘开出了改进的味道追问现场可能被问到的答不上来的问题，比答得漂亮的问题更能决定这场演示的结果复盘会后还要跑一遍吗？要 —— 会上定的根因与改进项回填初稿，终稿归档。终稿的改进项自动进跟踪表，下次复盘先审计。小事故也要这么重吗？影响面小的走轻量版：时间线 + 一层 Why + 改进项 —— 结构一样、深度打折，从不裸奔。改进项谁来跟？每条改进项落人限期（CH-02 的规则）—— 跟踪表季度审计一次，「落空」本身要进下一次复盘的议题。

③ 能力沉淀（Skill / 提示词 / 预期输出 / 人工边界）

1. Skill 能力包

导入之后，同类任务会自动按这套规则走 —— 提示词才能写得那么短

事故复盘初稿 · Skill

SKILL.md 主本 + references（输出骨架 / 判据 / 渲染脚本）· 符合 WorkBuddy Skill 规范

版本 v1.0

incident-postmortem.zip

在 WorkBuddy 里直接上传这个 zip 即可导入

包内结构

SKILL.md 主本 —— YAML 元信息 + 执行流程 + 硬规则 + 人工边界
references/output_template.md 输出骨架（sheet 名 / 分区顺序 / 列头）+ 可直接运行的渲染脚本
references/judgement_rules.md 判据与口径 —— 什么情况算异常、什么情况必须拦住

references 不会一次性全读进来 —— Agent 按需取用。所以 Skill 可以写得很细，不会拖慢每次对话。

2. 原始素材

这些就是产品手上真实能拿到的东西 —— 格式不统一是常态，不是问题

📁VA-03 · 演示素材

脱敏构造数据 · 真实业务格式 · 埋点可核验

共 5 份

01_告警与监控记录.xlsx 时间戳最硬的证据 —— 时间线的骨架
02_事故响应群消息.txt 处置过程的现场—— 时间线的血肉
03_受影响客户与工单.xlsx 影响面的量化 —— 客服侧的对照
04_运维配置变更记录.xlsx 根因的第一现场 —— 昨天那次批量配置
05_上上次复盘改进项.txt 改进项闭环的审计基准 —— 那条落空的改进项

怎么用

把素材全部拖进 WorkBuddy 对话框（不需要整理格式、不需要改文件名）
粘贴下方提示词发送
拿到正式件初稿 —— 签批栏留空，推荐意见留空，由你填

3. 提示词卡片

昨天那个上报超时的事故，告警记录、运维群和研发群的消息、客服那边的工单都在这，周五上午要复盘，帮我出个初稿。时间线先拼直：每个节点配上群消息或告警的原始引用，别靠我回忆；影响面给我数字化：几家客户、多长时间、多少工单 —— 别写「部分用户」这种话； 5Why 每层都给我证据，没证据的标「待验证假设」，别拿假设当根因；上上次复盘的三条改进项帮我核一遍状态 —— 落空的那条跟这次有没有关系，要说清楚；初稿只摆事实，根因和改进项留白给会议 —— 我要的是开会十分钟就进入讨论，不是先对事实吵半小时。

为什么这么短就够了：短是因为「时间线证据结构、5Why 分层规则、改进项闭环审计」都在能力包里。产品经理只要把原始记录扔进来。

换成你自己的业务：把素材换成你手上的真实文件即可。导入 Skill 之后，

该走几步、什么口径、什么情况必须拦住，Agent 自己知道 —— 你只需要说清这是什么事。

自己组织输入的三步法

用自然语言说清核心需求 —— 就按平时跟同事交代活的方式说：什么事、什么文件、什么要求。不用讲究格式。
调用 Skill 补齐专业规则 —— 导入本页 Skill 后，流程、口径、硬规则 Agent 自己知道。
用「增强提示词」补全遗漏 —— 输入框旁边有增强按钮，把随口说的话补成更完整的表述。

分工：自然语言负责「这是什么事」，Skill 负责「该怎么做」，增强提示词负责「别漏了什么」。

4. 预期输出

不方便现场跑的时候可以直接拿这份给客户看 · 与实跑结果同结构

📋正式交付物

带签批栏 / 冻结首行 / 开筛选 —— 判断标准是「能不能直接进企业的流程」

共 3 份

VA-03_事故复盘初稿.xlsx 正式件本体 · 时间线 + 影响面 + 5Why 证据链
VA-03_历史改进项审计表.xlsx 上上次的改进项逐条核状态 · 落空项与本次的关联
VA-03_复盘会材料包.txt 事实部分成稿 · 根因与改进项留白 · 会议议程建议

Skill 里固化了什么：从历史改进项里「想起」了那条落空的该拦的地方拦住了排除性结论把技术动作翻译成钱

输入清单：告警与监控记录时间戳最硬的证据 —— 原样扔进来事故期间的群消息运维群/研发群/客服群的原始记录受影响客户与工单影响面的量化 —— 客服侧的对照上上次复盘的改进项清单该闭环的先审 —— 复盘的连续性

人工边界：不做「根因认定」—— 5Why 的每一层都给证据链，最终归因是复盘会上人的共识。也不做「责任判定」——初稿只摆事实，定性留给人。

升为客户真实案例还缺什么：客户当前真实输入文件（不要整理过的）岗位现行 SOP 与审批链（金额分档、谁签字）至少一次真实出过问题的案例客户当前正在用的正式输出模板客户确认的阈值口径（多少天算临期、多少金额算大额）

5. 同一角色下的其他场景

验收与发布 · 产出即下一步输入

VA-01 · 验收测试用例生成 — 没有专职测试的公司，验收就是产品经理拿自己的手机点一遍 · 「感觉没问题」是唯一的测试报告查看 →VA-02 · 发布检查清单执行留痕 — 「连锁反应式灾难」的复盘第一条：回滚预案没有 · 检查清单的价值不在列出来，在逐项核过并留下痕迹查看 →

上下游串起来就是完整链路。每一步的产出都是下一步的输入，不用在不同工具之间来回复制粘贴。

说明：以上为 WorkBuddy 官方岗位场景库三级页面（场景引入 / Live Demo / 能力沉淀）与库级页签的完整整理；均为官方脱敏演示件，用于讲解与交付底稿，不代表已接入客户生产系统、不承诺效率百分比。

场景内容基于 WorkBuddy 产品能力整理，演示中的企业、人物与数据均为虚构，不代表任何客户的实际成效；痛点引用的公开来源已做脱敏处理。网页版由原资料转换，部分演示表格以原文形式展示。

其他行业的同类场景 · 报告文书

想把这个场景在你们企业跑通？

顾问会先看你们的数据和流程够不够，再决定从哪一步开始。

看产品其他场景