旗舰场景分析决策行业 · 通信运营商

NW-01 · 故障处置报告初稿

从工单流水与告警记录里攒证据，不从空白文档里写起

痛点　处置事件只花一小时 · 攒证据写报告要熬三天

① 场景引入

一、这件事现在是什么样

网络运维与割接 · 真实业务触发

无线一级故障处置完成后 48 小时内要出正式报告，网络部值班经理还会追问「影响范围到底多少用户」——这个数必须从网管和 BOSS 里各导一份才能对上。

二、痛点 · 每条都有来源

从告警发生到报告归档，「处置 1 小时、报告 3 天」：八成精力耗在事后流程，工程师处置完下一单已经来了，报告只能熬夜补
依据：「处置事件只花一小时，攒证据写报告要熬三天」：80% 精力耗在事后流程
代维要同时登录代维管理系统和 EOMS 两套系统处理同一张工单，回单内容在两处各填一遍；写报告时还要再翻一遍微信群的处置通报
依据：集中化故障管理流程：代维双系统回单、事故报告法定栏位（报告单位盖章、时间精确到分、主送单位、是否上报通管局）
报告从 V1 写到 V10，领导说还是 V5 好——因为每次补的都是同一个数：影响范围，而这个数从来没有一次是从系统里算出来的
依据：故障报告从 V1 写到 V10、领导说还是 V5 好——报告目的是应付上级不是复盘
事故报告要「报告单位盖章、报告时间精确到分、主送单位、是否已上报当地通管局」，栏目是法定的，但填数的人手里只有碎片记录
依据：集中化故障管理流程：代维双系统回单、事故报告法定栏位（报告单位盖章、时间精确到分、主送单位、是否上报通管局）5历史故障报告归档后无人问津，新故障发生时没人想起来 3 个月前修过同样的东西——

「knowledge cliff」：老师傅退休，隐性知识跟着走依据 · 海外电信圈 knowledge cliff 讨论：老师傅退休带走隐性知识，事件知识散落在多系统孤岛，记录不完整、缺事后验证

三、换个做法之后

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

✕ 现在的做法

从告警发生到报告归档，「处置 1 小时、报告 3 天」：八成精力耗在事后流程，工程师处置完下一单已经来了，报告只能熬夜补
代维要同时登录代维管理系统和 EOMS 两套系统处理同一张工单，回单内容在两处各填一遍；写报告时还要再翻一遍微信群的处置通报
报告从 V1 写到 V10，领导说还是 V5 好——因为每次补的都是同一个数：影响范围，而这个数从来没有一次是从系统里算出来的
事故报告要「报告单位盖章、报告时间精确到分、主送单位、是否已上报当地通管局」，栏目是法定的，但填数的人手里只有碎片记录

✓ 交给 Agent 之后

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

四、场景闭环

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

要素校验 · 先判断这些记录能不能拼成一条时间线三份来源的时间戳两两比对，缺口不阻塞，但要算出缺了哪几段
口径归一 · 把两套系统的工单状态对齐到同一套状态字典代维系统的「回单」与 EOMS 的「归档」差在哪，逐单说明
时间线拼装 · 从告警发生到工单闭环的完整链条每一步带出处：工单号 / 告警流水号 / 通报原文
影响范围核算 · 用户数与小区数从网管口径算出这是领导一定会追问的那个数，算法与口径要写进报告附录第5 步历史案例召回 · 从归档报告里找同类故障的先例写清上次怎么修的、当时谁经手、这次哪些特征相同
留证与签批 · 生成可盖章的正式报告初稿法定栏目齐套，责任认定与处理意见两栏留空

要准备什么：EOMS 工单流水导出（xlsx，含派单/受理/处理/回单时间戳）两套系统的流水对不上时间戳是常态，要先对齐再拼时间线网管告警流水导出（xlsx，设备号 / 告警类型 / 发生与恢复时间）这是「影响范围」栏的唯一权威来源，平时躺在监控中心电脑里微信群处置通报（txt 转写，值班经理每小时口播）非结构化、口语化，但藏着系统里没有的现场细节历史故障报告归档包（docx，近 12 个月）星标素材——平时没人翻，同类故障的处置先例都在这里

为什么这个场景值得做

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

最大差异点：不要求先建故障知识库再上系统。历史工单导出件、告警流水、微信处置通报的原件直接扔进来，时间线由 Agent 对齐拼装，每一步都标注出处工单号，写不进时间线的记录单独列出。

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

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

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

五、会产出什么

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

正式件本体：故障处置报告初稿.docx 法定栏目齐套 · 责任认定留空
可派发清单：故障时间线与出处清单.xlsx 每步带工单号与告警流水号 · 可派发核对
可派发清单：同类故障案例召回表.xlsx 历史先例与新故障的特征比对 · 供复盘归档

这套东西不承诺什么：不替人填「责任认定」与「处理意见」两栏——那是值班经理和分管领导的字。报告初稿只到「事实时间线 + 影响范围 + 历史案例引用」，定性部分留白给人工。也不自动提交 EOMS 归档，闭环动作必须人工确认。

② Live Demo（演示逐步）

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

案例设定：南江通信云山分公司网络部。2026-08-14 滨湖新区 CR-2608-014 割接当晚，BH-JH-02 机房一级故障历时 9.5小时（EOMS-2608-1573），处置已结束——现在是 8 月 15 日上午，48 小时报告归档倒计时开始。

故障工单EOMS-2608-1573 · 一级故障历时9.5 小时 · 超一级限额 1.5 小时影响用户网管 3.2 万 · BOSS 6.9 万归档时限处置完成后 48 小时内

输入运营商条线手上能拿到的东西

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

01_EOMS工单流水_割接当晚.xlsx EOMS 与代维系统当晚的工单流水，派单、受理、回单时间戳两套各一份值班调度导出 · 故障当晚
02_网管告警流水_滨湖片区.xlsx 网管系统当晚滨湖片区全量告警，含影响范围两口径统计监控中心导出· 故障恢复后
03_值班群处置通报_0814-0815.txt 值班经理当晚在值班群的逐小时口播通报转写，藏着系统里没有的现场细节值班群 · 口播转写
04_历史故障报告归档_近12个月.docx 近 12 个月同类故障的归档报告原件——平时没人翻，同类故障的先例都在这里网络部归档 · 上次整理还是半年前

注意标橙色那一份 —— 04_历史故障报告归档_近12个

月.docx。它网络部归档 · 上次整理还是半年前，平时压根不在核对范围里。这个场景的价值，很大一部分就来自把它读进来。

提示词就说这么几句

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

这是今天凌晨滨湖片区一级故障的处置材料：EOMS 工单流水、网管告警导出、还有值班群的处置通报文本，三份都给你。帮我拼一条从告警到闭环的完整时间线，每一标都注明出处。影响范围那栏，网管和 BOSS 口径对不上的话别硬选，把两个算法都列出来。再翻一下过去一年的故障报告归档，看有没有同类故障的先例。责任认定和处理意见留空，我来写。报告先别提交系统。

短是因为专业规则都写在能力包里了。你只需要说清这是什么事。

触发处置 9.5 小时已经结束 · 攒证据的 48 小时刚开始

三个来源的时间戳从来没有被并排看过

故障处置本身 15 日上午已经闭环，但按制度，一级故障报告须在处置完成后 48 小时内归档，报告单位盖章、时间精确到分。网络部手里的原料是三份各说各话的记录：EOMS 工单流水、网管告警流水、值班群口播通报——过去写报告的方式是一个人对着一堆碎片从空白文档里回忆。

第 1 步 · 要素校验 · 三份来源先对表，缺口不阻塞但要算清

两套系统的时间戳差多少，先摆出来再拼

演示数据（表格原文）来源记录区间与首发告警的关系缺口判定EOMS 工单流水23:52 → 次日 10:05派单晚 5 分钟无缺口 · 流转完整网管告警流水23:47 → 次日 09:17首发告警即起点无缺口 · 恢复确认在案值班群通报23:50 → 次日 10:00 共 6 条首条晚 3 分钟口语化 · 需结构化后引用历史归档报告近 12 个月 3 份同类不参与时间线归档一无处理意见批注三份来源可以拼成完整时间线；唯一要提前说明的是业务恢复时点的取数口径——回单 09:40 是流程动作，网管恢复确认 09:17 才是业务口径。先把口径的坑摆在明处「回单时间」和「业务恢复时间」差 23 分钟，历年报告里两种写法都出现过——这次在拼时间线之前就定死：业务恢复以网管 09:17 为准，回单仅作流程记录，写进报告附录，省得领导审阅时再问一遍。

第 2 步 · 口径归一 · 回单与归档的 25 分钟差在哪，逐单说明

代维系统的「回单」与 EOMS 的「归档」不是一回事

演示数据（表格原文）EOMS 状态代维系统状态时间差本报告采用口径派单 23:52受理 23:586 分钟以 EOMS 派单为准处理记录 01:20现场处置中—以代维记录为现场依据业务恢复（网管）09:17回单 09:4023 分钟业务恢复以网管为准归档 10:05—回单后 25 分钟归档为流程终点，不计入故障历时两套系统对同一张工单各记一遍，历来是报告返工的头号原因——口径列写进附录后，这次对不上的地方全部有了说法。排除性结论 · 传输侧可以排除学府路光路瞬断（AL-2608-33409）持续 1 分钟自愈，值班通报原话「与本次无关」，且该光路与故障小区拓扑无交集——传输班组这一轮排查可以整体省掉，报告里写明依据即可。

第 3 步 · 时间线拼装 · 从 23:47 到 09:17，每一步带出处

领导追问的每一个时间点，都能翻到原始记录

演示数据（表格原文）时间事件出处08-14 23:47电源模块告警（首发）告警 AL-2608-3341708-14 23:49载频退服告警 AL-2608-3341808-1423:52EOMS 一级派单工单 EOMS-2608-157308-14 23:58代维接单出动代维系统流转记录08-15 00:05邻区参数失配告警告警AL-2608-3342208-15 01:20电源模块倒换处理中工单处理记录08-15 03:30省公司值班室电话过问值班通报第 3 条08-15 07:47一级故障 8 小时限额到点制度时限推算08-15 09:17业务全部恢复网管确认 · 值班通报第 5 条历时23:47 → 09:17 = 9.5 小时超限额 1.5 小时（07:47 后）超时段 07:47 → 09:17 共 1.5 小时逐分钟落在时间线上——这一段将来若是代维考核认定的争议段，报告就是第一手证据。把超时段翻译成钱超时的 1.5 小时不是靠人回忆出来的，是 23:47 首发 + 8 小时限额推算出来的。这段直接关联代维考核的扣分认定，按结算口径每 1 分对应月度服务费扣减 2.4%——将来对账单上真金白银的争议，就落在 07:47 到 09:17 这一段上。现在钉死在时间线里，就是给后续对账留的第一手证据。

第 4 步 · 影响范围核算 · 3.2 万还是 6.9 万，两个口径都摆出来

领导一定会追问的那个数，从来没有一次是从系统里算出来的

演示数据（表格原文）口径算法影响用户影响小区网管口径故障时段激活态用户计数3.2 万18 个BOSS口径按计费账户归属基站6.9 万26 个两口径差—3.7 万8 个两个口径的算法差异写进报告附录：网管数的是故障时段在线的人，BOSS 数的是归属这些基站的所有计费账户——后者包含当时未开机的用户。该拦的地方拦住了影响范围一栏两个口径差 3.7 万用户，这份报告现在还不能盖章上报。附录里两个算法并列、各自标注统计时点，人选定口径后再出终稿——比按某个数上报后被追问「到底是多少」再返工，要省一整个来回。

第 5 步 · 历史案例召回 · 5 月那次「建议更换」没闭环，这次同特征再现

归档报告里躺着三次预警，没有一次被执行

演示数据（表格原文）归档时间事件与本故障的相同特征当时处置2026-05-18BH-JH-02 电源模块告警同机房同设备族 2 号模块手动倒换恢复，历时 42 分钟；建议换模块，批注「暂缓」2026-03-02滨湖邻区参数失配告警类型相同（失配）参数回退，处置历时 2.5小时2025-12-09全市电源专项巡检BH-JH-02 在列、模块老化结论「纳入换季更换清单」，未执行三次预警指向同一个 2号电源模块，处置建议栏的「暂缓」与「未执行」是本次报告建议部分最硬的依据。从历史归档里想起了踩过的坑5 月那份报告的处理意见栏写着「采购未列预算，暂缓」，报告人陈工已调省公司——这条不靠当年经手的人还在不在职：归档里有。本次同一设备族同一模块再故障，报告的建议栏可以直接引用 GS-2026-05-078 的原文，采购立项的理由由三次归档记录共同构成。

第 6 步 · 留证与签批 · 法定栏目齐套，定性两栏留白

责任认定与处理意见是值班经理和分管领导的字

演示数据（表格原文）法定栏目本次填写情况说明报告单位 · 报告时间已生成（精确到分）以网管恢复确认为处置完成时点故障经过与处理过程已生成 · 逐句带出处引用第 3 步时间线影响范围两口径并列 · 待人选定算法见附录责任认定留空值班经理填写处理意见留空分管领导填写是否已报当地通管局留空 · 提示核对按故障等级规定执行初稿连同时间线出处清单、案例召回表一并送签；EOMS 归档动作仍由值班调度人工执行。这份报告现在还不能盖章上报 —— 影响范围一栏两个口径差 3.7 万用户办法一：以网管口径 3.2 万为主线（故障时段激活态用户，与故障时段直接对应），BOSS 口径 6.9 万进附录并写明差异原因，今天内可出终稿送签；办法二：等两套系统对账后选定口径，报告至少晚一个工作日——48 小时归档时限只剩 36 小时左右，且「晚」不改变两口径本来就并存的事实。建议办法一：口径之争不该由报告挡枪，该由人选定并签字。之后这一次跑完，公司多了什么

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

演示数据（表格原文）✓故障报告归档从「文件夹里的死文件」变成可检索的案例库：本次时间线与处置动作结构化入库✓影响范围口径第一次写明算法，下次同类故障直接复用✓一条历史教训被真正用上：5 月那次「建议更换电源模块」的未闭环建议被重新拎出✓岗位角色变了：从「熬夜凭记忆补报告」变成「核对 Agent 拼好的时间线、只写定性两栏」追问现场可能被问到的答不上来的问题，比答得漂亮的问题更能决定这场演示的结果报告写得再快，领导不是只看影响范围那个数吗？是——所以那个数的算法与两个口径的差异被单独放进附录，领导追问时翻附录就能答，不用再打电话问监控中心。能不能让它自动把 EOMS 工单也回填了？不能。工单闭环是审计留痕动作，虚拟闭环等于虚假记录，这个边界在强监管行业碰不得。历史报告我们归档很乱，格式都不一样，能用吗？能。召回靠的是故障特征（设备族 / 告警类型 / 拓扑位置）不是格式，格式乱的归档件同样能被结构化后入库。

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

1. Skill 能力包

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

故障处置报告初稿 —— 从工单流水与告警记录里攒证据，不从空白文档里写起 · Skill

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

版本 v1.0

fault-report-draft.zip

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

包内结构

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

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

2. 原始素材

这些就是运营商条线手上真实能拿到的东西 —— 格式不统一是常态，不是问题

📁NW-01 · 演示素材

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

共 4 份

01_EOMS工单流水_割接当晚.xlsx EOMS 与代维系统当晚的工单流水，派单、受理、回单时间戳两套各一份 XLS02_网管告警流水_滨湖片区.xlsx网管系统当晚滨湖片区全量告警，含影响范围两口径统计
03_值班群处置通报_0814-0815.txt 值班经理当晚在值班群的逐小时口播通报转写，藏着系统里没有的现场细节
04_历史故障报告归档_近12个月.docx 近 12 个月同类故障的归档报告原件——平时没人翻，同类故障的先例都在这里

怎么用

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

3. 提示词卡片

这是今天凌晨滨湖片区一级故障的处置材料：EOMS 工单流水、网管告警导出、还有值班群的处置通报文本，三份都给你。帮我拼一条从告警到闭环的完整时间线，每一标都注明出处。影响范围那栏，网管和 BOSS 口径对不上的话别硬选，把两个算法都列出来。再翻一下过去一年的故障报告归档，看有没有同类故障的先例。责任认定和处理意见留空，我来写。报告先别提交系统。

为什么这么短就够了：短是因为专业规则都写在能力包里了。你只需要说清这是什么事。

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

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

自己组织输入的三步法

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

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

4. 预期输出

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

📋正式交付物

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

共 3 份

NW-01_故障处置报告初稿.docx 正式件本体 · 法定栏目齐套 · 责任认定留空
NW-01_故障时间线与出处清单.xlsx 每步带工单号与告警流水号 · 可派发核对
NW-01_同类故障案例召回表.xlsx 历史先例与新故障的特征比对 · 供复盘归档

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

输入清单：EOMS 工单流水导出（xlsx，含派单/受理/处理/回单时间戳）两套系统的流水对不上时间戳是常态，要先对齐再拼时间线网管告警流水导出（xlsx，设备号 / 告警类型 / 发生与恢复时间）这是「影响范围」栏的唯一权威来源，平时躺在监控中心电脑里微信群处置通报（txt 转写，值班经理每小时口播）非结构化、口语化，但藏着系统里没有的现场细节历史故障报告归档包（docx，近 12 个月）星标素材——平时没人翻，同类故障的处置先例都在这里

人工边界：不替人填「责任认定」与「处理意见」两栏——那是值班经理和分管领导的字。报告初稿只到「事实时间线+ 影响范围 + 历史案例引用」，定性部分留白给人工。也不自动提交 EOMS 归档，闭环动作必须人工确认。

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

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

网络运维与割接 · 产出即下一步输入

NW-02 · 割接方案初稿与审批链校验：历史方案是私有资产，别再从空白文档写起

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

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

其他行业的同类场景 · 分析决策

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

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

看通信运营商其他场景