工单智能分诊

问题背景

客户支持队列里，同一批工单往往混着登录失败、重复扣费、功能咨询和「能不能接 Slack」——人工先读一遍再转组，既慢又容易把企业客户的生产故障当成普通 how-to。你需要的是：在工单进队列的第一时间，把意图、实体和账户层级读出来，给出可执行的类别、优先级和路由，而不是只贴几个标签。

技能如何工作

ticket-triage 处理原始工单（主题、正文、客户元数据、附件说明），先做文本规范化（去签名、引用块、样板话），再抽取订单 ID、错误码、URL 等结构化字段。

核心流程可以概括为六步：

• 解析与清洗 — 统一可读文本，保留业务关键信息。
• 意图与实体 — 区分 bug、计费争议、功能请求、操作指导；识别产品名、API、错误信息；标记情感（含紧急）。
• 类别映射 — 主类别落在 billing / bug / feature-request / how-to；多意图时标主类与次类。
• 优先级矩阵 — P0～P3，结合影响面与紧急程度；企业账户在矩阵上通常上调一级。
• 团队路由 — 计费→财务支持；bug 按 P0/P1 与 P2/P3 分工程分类或产品支持；功能请求→产品管理；how-to→客户教育；可附内部备注。
• 草拟首次回复 — 确认问题、说明预期响应节奏、链知识库或状态页；语气随情感调整。

批量场景下，输出通常是表格化摘要：主题、类别、优先级、目标团队、建议回复文案，便于值班同学直接采纳或微调。

适用边界

• 多意图工单：按更高优先级意图定主类，次要问题建议拆关联工单，避免计费与工程各看各的。
• 非英语、垃圾邮件、仅附件无正文：需语言检测与翻译、spam 关闭、或标记人工审核，不宜低置信度硬分。
• 24 小时内重复/跟进工单：应合并线程再分类，附加上下文常改变类别或优先级。
• 分类决策最好留推理记录，便于人工纠错后迭代规则；P0 若短时无人认领，应触发升级（如呼叫值班）。