DM-05 · 异常分级与升级归口

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

W

场景总览

异常分级与升级归口 Skill · 可复现的完整素材包

一句话调用 · 一套引擎吃三类入口（客户投诉 / 现场停线 / 跨部门久拖）· 输入就是微信原话和会议记录 · 合并重复上报 → 反向检索历史判是第几次发生 → 三级分级含降级 → 归口建议与排除理由 → 可直接贴群的协调稿 + 对外话术 + 含重复次数的台账。

Skill 核心理念

中小企业没有"升级机制"，只有老板的微信。所有异常汇到同一个人，而他没有筛子。这个 Skill 的设计基于三个真实判断：① 一线倾向把问题说重是理性的（说轻了怕没人管），所以真正的工作量不在发现紧急的，在把不紧急的挡回去——分级的价值在降级；② "是否重复发生"是最有分量、也是唯一没有数据字段的判据，只能靠按设备号、部位、客户去历史记录里反向检索，而第3 次发生的问题性质和第 1 次完全不同；③ 归口涉及组织权力，Agent 不能替老板派活，只能给"建议归 X，因为不是 Y 也不是 Z"，理由摆出来让老板自己判——尤其是跨部门谁都不认的问题，硬派一个部门恰恰是它三次没解决的原因。

SKILL v1.0.0

三入口一套引擎

P1/P2/P3 三级

重复性反向检索

强制降级判定

归口只建议不派活

STEP 1读原文并去重

STEP 2反向检索历史

STEP 3四维判据分级

STEP 4归口 + 排除理由

STEP 5协调稿 + 台账

1Skill 完整包

异常分级与升级归口 Skill · 完整 zip 包

SKILL 主本 + 2 份 references + 3 个 test cases · 一键下载 · 解压即用

版本 v1.0.0

incident-triage-escalation.zip

下载后解压即得完整 skill 目录 · 直接放到 WorkBuddy 的技能中心导入即可

zip 包内含· 一次拿全

SKILL.md · 主本（六步法 / 三类入口统一处理 / 合并规则 / 重复性检索键与三个高价值信号 / 四维判据 / 三级分级 /归口排除逻辑 / 9 条硬规则 / 常见坑）

_meta.json · Skill 元信息（slug / version / domain / role / scene）

references/分级与归口规则.md · 为什么只设三级（含 80%→15% 的真实教训）+ 三级判定条件详解 + 四维判据取数口径 + 降级判定的三种典型情形 + "需管理层指定"的判定标准，可直接作为企业《异常分级与升级管理规范》

references/协调稿与话术模板.md · 协调稿 300 字结构与四个写法要点 +对外话术五段式（含"主动承认历史重复"的写法对比）+ 决策包五要素 + 台账列结构与自检断言

test_cases/ · 六条上报三类入口 / 无历史台账时的降级运行 / 跨部门谁都不认不得硬派

用法

下载 zip · 解压得到 incident-triage-escalation/ 目录

WorkBuddy → 技能中心 → 我的技能 → 导入这个 Skill

之后直接说 "群里这些异常帮我理一下，哪几件今天必须我管"

建议每周一上午例行跑一次，把上周积压的异常一次分完级

三级的判定阈值可按企业实际调整。P1 占比是这套机制的健康指标——每周 P1 超过 3 件说明阈值需上调

2. 原始素材 · 输入就是群里那些话

这个场景的素材刻意做成"没整理过"的样子

它不是规范表单，是微信原话、电话口头转述、周会记录里的一句话——语气和事实混在一起，每条都显得很急。这就是中小企业真实的输入形态，Skill 必须能直接吃：

💬原始记录6 条 / 3 入口

🏷️客户背景等级 + 占营收比

📚历史记录判重复性的唯一依据

📐分级规则企业自己的

📥

2026-08-09 异常分级数据包

6 条上报 → 5 件事 · "两条该合并""两条该降级""三件都是第 3 次"三处反差已埋好 · 数据脱敏

共 4 份

XLS

异常事件原始记录.xlsx

6 条 · 描述栏全部为原文照录："语气很不好""我先把人调去别的工位了""每次周会都提，每次都没结论" · 三类入口混在一张表里 · 其中 EV-0801 与 EV-0806 是同一件事（后者是客户要找老板的升级信号）

6 行

XLS

客户与订单背景.xlsx

决定同一事实的不同分级：客户等级 / 近 12 月采购额与占营收比（恒盛 18.2% vs 中兴 1.4%）/ 投诉次数 / 是否有质量协议 · 备注里有"去年曾因交期问题暂停下单 2 个月"这类高价值信息 · 第 2 个 sheet 是 6 张涉及工单的金额与交期

2 sheet

📚

历史异常处置记录.xlsx　← 关键文件

"是否重复发生"这个判据的唯一来源，系统里没有这个字段 · 7 条记录里藏着三组重复：门锁（7-03、5-21）、折弯机（6-18、4-09 临时补漏未换密封件）、喷涂（7-24、6-12 均"归口未明确、未闭环"）· 其中一条标注"记录不完整，经手销售已离职"

7 条

XLS

分级与归口规则.xlsx

企业自带的默认规则（可改）· sheet1三级判定条件 + 响应/决策时限 + 升级层级 + 通知范围 · sheet2 归口参考，每条都写明"为什么不是别的部门"，并明确列出"需管理层指定"这一档的适用条件

2 sheet

用法（演示路线）

四份文件全部拖到 WorkBuddy 对话框（或放到 D:\workbuddy_data\管理层\异常分级\）

先问客户一句："你们车间和客户那边出了问题，最后是怎么到你这儿的？"—— 十家有九家答"微信群"或"他们直接找我"，这时"老板没有筛子"这个定位就立住了

让客户自己先看那 6 条原文，问他哪几条今天必须管。多数人会答 4 条以上（外箱磕碰那条最容易被算进去，因为写着"客户投诉"）

然后跑一遍，重点看被降级的两条——外箱磕碰是 C 级客户占营收 1.4% 且已验收，焊接新人压根不是异常而是排班且班长已妥善处置。"把不该上来的挡回去"这个价值，客户自己刚才的回答就是最好的对比

再看三件 P1 的共同点：都是第 3 次。特别是折弯机——4 月那次"临时补漏未换密封件"，直接导致了 8 月这次漏油。这条因果链是从台账里翻出来的，任何系统都不会主动告诉你

最后看喷涂那条：Agent 没有硬派部门，而是说"这类问题的本质是标准空白，要拍的不是责任，是标准归属"。问客户一句"你们类似的事最后是怎么收场的"，通常答案是"还在讨论"

3. 提示词卡片

上周五到今天群里的异常我让行政摘出来了，客户投诉、车间停线、周会上拖着的都在里面。 帮我理一下：哪几件今天必须我管，哪几件让他们自己处理就行。 重复发生过的重点标出来 —— 我要知道哪些是老问题又犯了。 每件给个建议归口，但别直接派活，理由写清楚我自己判断。 再给我一段能直接发群里的，和一段销售回客户用的。 跨部门那种谁都不认的，别硬塞给某个部门。

为什么这么短就够了：三级分级的判定条件、三层升级路径、四维判据、归口参考规则与排除逻辑、协调稿的 300 字限制与必备要素，全都写在 Skill 和企业自己的《分级与归口规则》里。

最后那句是关键 · "跨部门那种谁都不认的，别硬塞给某个部门"——它直接决定了喷涂那条的输出形态。没有这句话，Agent 很可能会硬派一个部门（通常是品质部），而那恰恰是这个问题三次没解决的原因。

"别直接派活，理由写清楚我自己判断" · 把输出限定成建议 + 排除理由。归口涉及组织权力，替老板派活会被视为越权。

4交付物 · 能贴群的、能签字的、能查的

协调稿 + 升级通知单 + 异常台账

三份，各有各的用处：一份贴群、一份签字、一份留档

1 TXT + 1 PDF + 1 XLSX

TXT

对内协调稿.txt

正文 390 字，手机一屏能读完，纯文本可直接粘贴到工作群 · 三项 P1 每条含是第几次 + 归口 + 责任人 + 今日动作 +时点 · 末尾单独列2 项 P3 并写明"留现场处理不占今日会议"——降级判定只有被看见才有意义

390 字

PDF

异常升级通知单.pdf

三件 P1 逐件列决策包五要素：问题与影响范围（含工单号与金额）、已采取的临时措施、证据（含历史台账索引）、可选方案 A/B 与各自代价、建议决策与责任人 SLA · 下半页单独列 2 项 P3 及降级理由 · 含总经理签署栏，页脚印明"归口与最终处置由管理层确认"

1 页

XLS

异常台账.xlsx

5 件事逐条 15 列 · 按等级填色 · 关键是「是否重复发生（第几次）」和「前次发生日期」两列——这两列在任何ERP/MES 里都没有，而一旦持续积累，下次同类问题进来就不用再靠谁的记忆了

5 行 / 15 列

这三份东西为什么这么设计

协调稿必须是纯文本且≤300 字 —— 中小企业的沟通载体就是微信群，一份要打开附件才能看的报告在群里等于没发。生成脚本里内置了字数断言，超长直接不出文件

决策包五要素缺一不可 —— 一次没有信息包的升级，等于把判断责任转移给了信息最少的那个人。老板最常被问

的"到底怎么办"，答案在"可选方案 A/B 与各自代价"这一栏

方案 A 往往是"历史上实际做过的那个" —— 比如喷涂那条的方案 A 就是"指定某部门负责降低返工率"，并注明"前两次实质如此，均无结论"。把失败过的路径明确写出来，比只推荐正确答案更有说服力

台账的"第几次"列是这张表存在的理由 —— 它必须靠检索填入，但一旦积累起来，重复性判据就从"靠人回忆"变成"查一列"

生成脚本内置自检：合并逻辑（原始 6 条 → 5 件事）、分级数与事件数守恒、每条 P1 必须有责任人与 SLA、协调稿字数上限。跑不过就不出文件——本次实跑时协调稿第一版 454 字被断言拦下，精简到 390 字才通过

⚠️这套东西不承诺什么（建议在客户面前主动讲）

不替你派活。归口只给"建议 + 为什么不是别的部门"，指派部门是组织权力，最终由管理层确认。

跨部门谁都不认的，不硬派。这类问题的本质是标准空白，硬派一个部门恰恰是它反复没解决的原因。Agent 会把它转化为"哪项标准该由谁定"这个可拍板的问题。

没有历史台账就判不了重复性。这是最有分量的判据，但它没有系统字段。缺台账时 Skill 会明确说"本次重复性判据不可用，分级可能低估"，不会拿"上个月也有过"这种原话当证据。

不做根因分析。"为什么会出这个缺陷"属品质异常分析场景（9.1），本场景只做分级与归口。

不要求车间新增录入动作。输入就是群里的原话和会议记录——任何要求一线多填一张表的方案，最后都会被弃用。5相关联 Skill

🔗

下游联动 Skill

分完级之后，每一类 P1 都有它的去处

共 4 份

📄

企微等 IM 分部门通知 · SKILL.md

分完级的下一步就是通知到人：按归口部门与责任人推送带时点的待办，P1 的 2 小时响应时限靠它落地

SKILL

查看 →

📄

品质异常分析 · SKILL.md

品质类 P1 的去处。门锁那条"第 3 次必须开 NCR 查根因"就是交给它做——本 Skill 只分级不归因

SKILL

查看 →

📄

排产与插单调整 · SKILL.md

停线类 P1 的去处。折弯机停机压着三张工单，这三张怎么重排、会挤掉谁，交给它算

SKILL

查看 →

📄

经营复盘 · SKILL.md

往上看：一个月内出现三件"第 3 次"，这本身就是经营信号。用它把异常重复率纳入月度复盘，从"每周救火"转向"逐月改善"

SKILL

查看 →

Skill 组合调用

第一步：异常分级与升级归口 Skill → 得到分级、归口建议、协调稿、台账

第二步：企微等 IM 分部门通知 Skill → 按归口推送到人，P1 两小时内必达

第三步：品质类 P1 → 品质异常分析 Skill 开 NCR 查根因出 8D；停线类 P1 → 排产与插单调整 Skill 重排受影响工单第四步：月底用 经营复盘 Skill 回看 —— 这个月有几件"第 3 次"、上月的 P1 闭环了没有。这才是这套机制真正的产出异常分级与升级归口 Skill · 可跨场景复用

本 Skill 不是只为制造业异常定制的 —— 它覆盖所有"多个非结构化事件涌进来、需要判轻重缓急并归口到人"的场景，可以复用到：

客服 · 客户工单分级同一套四维判据（影响面/紧迫度/复杂度/是否重复）· 重复投诉的客户优先级完全不同

IT · 故障工单归口同一套三级 SLA + 归口排除逻辑 · "谁都不认的故障"同样要拍板定归属

HR · 员工反馈与投诉分级重复出现的同类反馈指向制度问题而非个案· 归口建议 + 排除理由同样适用

项目管理 · 风险与问题清单收敛把"待讨论事项"转化为"待拍板问题"这个动作，是通用的

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