智能工单分诊

问题背景

客服团队每小时可能收到几十张工单：有人登录失败，有人被重复扣款，有人提功能建议。人工分诊常暴露三个问题：意图归类不统一——「被扣了两次钱」可能被算作 billing，也可能被算作 bug；优先级判断主观——企业客户的生产故障有时被当作普通 P2 排队；首次回复质量参差——不管优先级，所有工单都要等一轮人工处理。工单量一上来，人工 triage 的成本和延迟会迅速失控。

核心能力与工作流程

这个技能把工单 triage 拆成六个步骤，每一步都有明确的输入和输出：

• 解析与规范化：接收 subject、body、客户元数据（account tier、plan、tenure）和附件，剥离签名、引用回复与样板文本，抽取 order ID、error code、URL 等结构化字段。
• 意图与实体抽取：判断主意图属于 bug、billing、feature-request 还是 how-to，识别产品区域、API 端点、具体报错信息，并标注情感倾向。
• 分类：映射到标准类目；多意图工单标注主类与次类，保证相关团队都能看到。
• 优先级矩阵：按影响和紧急度从 P0 到 P3 打分——生产中断或数据丢失是 P0，单个企业账号核心功能故障是 P1，有临时方案的降级体验是 P2，常规咨询是 P3。企业账号自动升一级。
• 路由：billing 进 Finance Support；P0/P1 的 bug 路由 Engineering Triage，P2/P3 路由 Product Support；feature-request 进 Product Management；how-to 进 Customer Education，并附带上下文与内部备注。
• 生成首次回复：按优先级给出响应时间预期，附上 KB 或状态页链接，语气对齐客户情感，信息不足时追加澄清问题。

批量输入同样支持：示例中一次 triage 5 张工单，输出包含分类、优先级、路由队列和建议回复的表格。

适用边界与注意点

• 附件型工单：正文为空、只有截图或日志时置信度低，应标记人工复核，而不是强行自动分类。
• 多意图工单：bug 与 billing 并存时，按高优先级意图归类，次级问题建关联工单。
• 重复工单：同一客户 24 小时内的跟进应合并到原线程，避免重复 triage。
• 元数据是关键输入：缺少 account tier 时，企业客户的 P0/P1 判断容易偏保守，建议始终携带。
• 决策要留痕：记录 triage 的推理过程，方便人工修正后用于微调。
• 规则兜底：15 分钟内未确认的 P0 应自动 page on-call manager。