CY-03 · 跨部门事件处置复盘报告

① 场景引入

一、这件事现在是什么样

城运研判员 · 受理立案与督办 · 真实业务触发

区内发生重大或典型事件（内涝/燃气泄漏/群体性事件），需在事件处置完毕后 7 天内出具复盘报告——东西湖区巡察整改点名「高效处置一件事科学化不高」

二、痛点 · 每条都有来源

1. 痛点一：跨部门事件涉及气象、管网、工单、视频、处置记录多源，纯人工拼数据得花上一整周
   依据：新津部分社区月均报表 120 张，同一数据重复填 19 张表
2. 痛点二：复盘报告核心是「时间线还原」，但事件时间线分散在 6 个部门的处置日志里——格式不统一、口径不一致
   依据：东西湖区城运中心巡察整改通报第 3 条：「统筹『高效处置一件事』科学化精细化智能化水平不高」
3. 痛点三：复盘报告要附整改建议，但整改建议常常「加强管理」结尾——不被巡察组认可
   依据：《安全生产法》第 41 条：隐患排查治理情况须如实记录并向从业人员通报，是安全台账类场景的法律出处，也是台账造假被处罚的依据
4. 痛点四：复盘报告归档后无人调阅，下次类似事件又从零开始
   依据：蓬莱区官方自认闲置资产数据「分散在各镇街 Excel 和纸质材料中，领导问起来需临时电话调度」——真实主数据不在平台里

三、换个做法之后

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

✕ 现在的做法

• 痛点一：跨部门事件涉及气象、管网、工单、视频、处置记录多源，纯人工拼数据得花上一整周
• 痛点二：复盘报告核心是「时间线还原」，但事件时间线分散在 6 个部门的处置日志里——格式不统一、口径不一致
• 痛点三：复盘报告要附整改建议，但整改建议常常「加强管理」结尾——不被巡察组认可
• 痛点四：复盘报告归档后无人调阅，下次类似事件又从零开始

✓ 交给 Agent 之后

• 多来源文件一次读入，先做口径与完整性校验，再开始算
• 每条结论绑定来源文件、字段或条号，可以被审
• 产出是企业真会流转的正式件（带签批栏），不是一张展示用的表
• 该拦的地方给出「现在还不能提交」，并给不用干等的替代方案

四、场景闭环

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

1. 要素校验 · 处置日志完整度6+ 部门日志完整度检查，缺项标黄，催促补时补报
2. 口径归一 · 按事件时间戳对齐按事件发生时间与处置时间逐条对齐
3. 交叉核对 · 与工单与视频对齐工单分派时间与视频时间戳对齐，校验处置及时性
4. 异常识别 · 处置延误与跨部门断点处置延误超 24 小时标红，跨部门断点超 4 小时标黄
5. 留证与签批 · 复盘报告 + 整改建议含事件时间线、责任分析、整改建议（具体到文件/责任/验收）

要准备什么：多部门处置日志（6+ 部门）各部门的事件处置记录，格式不统一12345 工单关联记录相关工单的分派与办结情况气象/管网/视频数据事件相关的气象、管网、视频原始数据

为什么这个场景值得做

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

最大差异点：不要求各部门先整理数据。6 个部门的处置日志直接扔进来，Agent 按事件时间戳逐条对齐，时间线自动还原——人只校断点定性和整改指向。

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

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

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

五、会产出什么

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

• 正式件本体：事件复盘报告.xlsx 含时间线、责任分析、整改建议
• 可派发清单：跨部门断点分析.xlsx 处置延误与断点清单
• 可派发清单：整改建议清单.xlsx 具体到文件/责任/验收的整改动作

这套东西不承诺什么：不替复盘组判断事件责任归属（责任认定是组织行为）；不替代分管区领导的签发权；不自动生成巡察整改清单（整改清单权在区委办）。

② Live Demo（演示逐步）

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

案例设定：2026-08-28（周四）暴雨，龙川路 45 号路段积水——12345 接诉 13 件 +网格上报 2 件，牵涉 4 个部门。

9-04，智慧治理中心要求出复盘报告：时间线怎么走的、断点在哪、责任怎么认、整改改什么。

相关工单13 件涉及部门4 家识别断点3 处整改建议4 条

输入城运治理与园区手上能拿到的东西

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

• 01_四部门处置日志.xlsx 四套系统各记各的日志——格式不统一、口径不一致各系统自动 + 手工记录 · 事件期间
• 02_12345相关工单清单.xlsx 13 件工单的汇总与回访——复盘的服务对象就是这 13 件平台归集 · 事件后回访补全
• 03_涉事点位基础信息.xlsx 点位的基础档案——复盘要回到物理世界市政档案 · 静态信息
• 04_往年同期内涝记录.xlsx 近两次强降雨的积水对照——排除「雨太大」这个自然归因城运中心归档 · 年度

注意标橙色那一份 —— 01_四部门处置日

志.xlsx。它各系统自动 + 手工记录 · 事件期间，平时压根不在核对范围里。这个场景的价值，很大一部分就来自把它读进来。

提示词就说这么几句

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

多部门处置日志扔进来，自动出时间线。 整改建议别写「加强管理」，写明改哪份文件、谁负责、什么时候完成。 跨部门断点超 4 小时，自动标黄。

短是因为时间线还原与责任分析都是后台能力，你只需要核对和签批。

触发13 件投诉、4 个部门、5 个半小时

回访不满意 1 件 + 车辆受损咨询 2 件，中心要求查明断点

复盘报告最容易被写成「各方都很努力」的记叙文。真正的复盘只有三个问题：时间怎么走的、哪一步拖住了、下次改什么。三个问题都要靠同一份东西回答：把四套系统的日志拼成一条时间线。

第 1 步 · 多源对齐 · 四套系统的时间先归一

格式不一的 14 条记录并成一条时间轴

第 2 步 · 断点识别 · 三个环节拖了后腿

分清「错」与「慢」，不能一锅端

第 3 步 · 责任分析 · 按环节不点名

每格「待核实」都涉及具体人的履职判断

第 4 步 · 整改建议 · 每条落到文件、人、时限、验收

四条建议，改的是三份文件和一次演练

建议责任时限验收修订《工单首派细则》第 12 条：积水类工单首派前核点位产权属性城运平台值班长9-30 前10 月首派准确率报表复核退单须附证据（到场照片或产权材料）写入《退单管理办法》城运中心主任办公会9-30 前10 月退单记录抽查管廊围堰施工的内涝风险会商纳入汛期例会水务局 + 住建局9-20 前建立机制下次围堰审批件附会商记录值班泵车备份与点位优先级规则写入《防汛应急预案》附件三应急管理局9-25 前更新9 月底桌面演练检验看点 · 把技术动作翻译成钱2026-07-22 降雨 58mm 同点位未积水、2025-07-19 62mm 积水——「雨太大」这个自然归因被对照记录排除，今年新增的变量是上游围堰。整改方向因此落到「围堰审批前会商」而不是「排水能力升级」：方向错了，整改的钱花在建泵站上，明年照样淹。

第 5 步 · 成报 · 时间线 + 断点 + 责任 + 整改四段

14 条记录、3 处断点、4 项待核实、4 条建议

报告板块内容来源条目时间线四部门日志14 条断点分析时间轴分段3 处责任分析（不点名）环节事实4 项待核实整改建议断点 + 待核实4 条看点 · 从历史记录里想起了踩过的坑2024-07、2025-07 同点位都有积水记录——这不是第一次。两年前的记录躺在台账里没人翻：如果 7 月那次 58mm 未积水之后，有人把「为什么今年不积水」问一句，围堰变量会更早进入视野。复盘报告把这条写进「历史对照」段——经验的失效不在于没人记得，在于没人去查。这条判断不靠当年经手人还在不在职，记录都在。

复盘报告提交前，待核实栏要过分管领导四项待核实涉及部门履职判断的具体情形，措辞分寸与核实路径须中心分管领导审定后发出——直接发出去就是替部门定性。两个不用干等的走法：方案一：今天 17:00 前送分管领导审定（重点圈出待核实栏），次日印发四家单位，9 月底的整改节点不受影响；方案二：先发「时间线与断点」事实部分给四部门核对（不含责任分析），责任与整改部分待审定后单独印发——事实部分先对齐，争议部分慢一天但更稳。两案都赶得上 9 月底的整改时限。

之后这一次跑完，公司多了什么

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

• ✓ 台账多了一条：复盘报告模板入库，下次类似事件快速套用
• ✓ 两条对齐规则被固定下来：时间戳对齐、断点判定
• ✓ 一条历史教训被真正用上：去年同类事件的根因分析
• ✓ 岗位角色变了：复盘组从「数据收集员」变回「分析者」，
• ✓ 时间线自动还原、人只校断点定性

追问现场可能被问到的

答不上来的问题，比答得漂亮的问题更能决定这场演示的结果

• 责任认定谁来做？ Agent 只做时间线还原与责任分析，最终责任认定由复盘组与分管区领导会议决定。
• 整改建议「加强管理」为什么不行？ 巡察整改要求具体动作——改哪份文件、谁负责、什么时候完成、拿什么验收，「加强管理」是无效建议。
• 跨部门数据怎么打通？ 需要各部门授权开放数据接口；Agent 不跨部门学习数据。

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

1. Skill 能力包

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

跨部门事件处置复盘报告 —— 一事件一份时间线 · Skill

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

版本 v1.0

cross-dept-incident-review.zip

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

包内结构

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

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

2. 原始素材

这些就是城运治理与园区手上真实能拿到的东西 —— 格式不统一是常态，不是问题

📁CY-03 · 演示素材

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

共 4 份

• 01_四部门处置日志.xlsx 四套系统各记各的日志——格式不统一、口径不一致
• 02_12345相关工单清
• 单.xlsx 13 件工单的汇总与回访——复盘的服务对象就是这 13 件
• 03_涉事点位基础信息.xlsx 点位的基础档案——复盘要回到物理世界
• 04_往年同期内涝记录.xlsx 近两次强降雨的积水对照——排除「雨太大」这个自然归因

怎么用

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

3. 提示词卡片

多部门处置日志扔进来，自动出时间线。 整改建议别写「加强管理」，写明改哪份文件、谁负责、什么时候完成。 跨部门断点超 4 小时，自动标黄。

为什么这么短就够了：短是因为时间线还原与责任分析都是后台能力，你只需要核对和签批。

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

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

自己组织输入的三步法

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

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

4. 预期输出

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

📋正式交付物

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

共 3 份

• CY-03_事件复盘报告.xlsx 正式件本体 · 含时间线、责任分析、整改建议
• CY-03_跨部门断点分析.xlsx 处置延误与断点清单
• CY-03_整改建议清单.xlsx 具体到文件/责任/验收的整改动作

Skill 里固化了什么：从历史里想起了公司踩过的坑该拦的地方拦住了排除性结论把技术动作翻译成钱

输入清单：多部门处置日志（6+ 部门）各部门的事件处置记录，格式不统一12345 工单关联记录相关工单的分派与办结情况气象/管网/视频数据事件相关的气象、管网、视频原始数据

人工边界：不替复盘组判断事件责任归属（责任认定是组织行为）；不替代分管区领导的签发权；不自动生成巡察整改清单（整改清单权在区委办）。

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

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

城运研判员 · 受理立案与督办 · 产出即下一步输入

• CY-01 · 城市运行体征周报自动编报：12 局数据汇一份报
• CY-02 · 领导批示件智能立项与督办台账：批示到办结闭环

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

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