分诊规则要外置
工单分诊的可靠做法是把规则表写出来（影响范围 × 紧急程度 → 优先级），模型只负责按规则执行判定并给出依据，不负责发明标准。规则外置的好处是改规则不用重写提示，也便于拿历史工单校准。提醒一点：分诊结果如果直接触发告警或通知，必须加复核环节，误报会让通知渠道失去关注度。
基本信息
| 级别 | P0-P3 四档，每档给出可判定条件 |
|---|---|
| 输出 | 优先级 + 一句话依据 |
| 关键 | 规则表与判定依据分开维护 |
| 校准 | 抽 10-20 个历史工单验证规则，再上线 |
| 风险 | 分诊直接触发通知前需要兜底复核 |
典型使用场景
- 运维工单：核心业务中断判 P0，单人受影响且有绕过方案判 P2
- 安全事件：涉及数据泄露风险的直接升级，不等用户确认影响范围
- 客服升级：涉及资金或账号安全的请求优先转人工
- 批量巡检结果：把巡检发现按影响面分级，决定修复顺序
- 值班排班：高优先级工单触发即时提醒，其余进日间队列
分诊规则模板
分诊规则模板
按规则判定工单优先级（P0-P3）：
- P0：核心业务中断且无绕过方案
- P1：主要功能受影响，或多位用户受影响
- P2：单人受影响且有绕过方案
- P3：咨询、优化建议
输出：{"priority": "P1", "reason": "一句话依据"}
# 边界要量化：“多位用户”写成不少于 3 位这类可数标准
# reason 必须引用工单里的原文特征，便于复核
# 规则外的情形归入 P2 并标注“规则未覆盖”，不要硬套
工单：<ticket>……</ticket>级别与判定条件
| 级别 | 判定条件 | 处置 |
|---|---|---|
| P0 | 核心业务中断且无绕过方案 | 立即响应，通知值班负责人 |
| P1 | 主要功能受损或影响多位用户 | 当日响应，进入优先队列 |
| P2 | 单人受影响且有绕过方案 | 正常队列处理 |
| P3 | 咨询与优化建议 | 排期处理，不打断当前任务 |
规则里的模糊词（「严重」「尽快」）会让判定随措辞波动；换成可数标准（影响人数、功能范围、是否有绕过方案）。
分诊结果直接触发通知时要有兜底复核：误报会让告警频道失去关注，真实故障反而被忽略。