乐于分享
好东西不私藏

AI 工单助手:先做推荐,不要一上来自动派单

AI 工单助手:先做推荐,不要一上来自动派单

AI 工单助手:先做推荐,不要一上来自动派单

第7讲封面图
满屏工单与AI分类卡片

老板说:"让AI自动处理工单,全自动闭环!"

听起来是不是很爽?AI帮你分类、派单、处理、关单,一条龙服务,客服团队直接躺平。

但做起来会很惨。

为什么?因为自动闭环意味着AI对结果负责。它决定派谁处理、修不修、退不退钱——每一步都是客户体验的雷区。

一旦出错,客户投诉升级,你连回退路径都没有。


更稳的第一步:让AI做助手,不是执行者

正确的姿势是这样的👇

AI摘要问题 → 判断分类 → 识别优先级 → 发现SLA风险 → 推荐处理人 → 等人工确认

这一圈走完,客服主管拿到的是一张结构化卡片,而不是几十行原始文字。

他只需要点"确认"或"修改",工单就下去了。

AI是提效工具,不是决策主体。 这是企业AI落地第一道安全门。

AI工单助手流程

架构位置:老系统不动,AI嫁接进来

第2讲搭了MCP Tool Center——把老系统能力标准化成MCP工具。工单助手就是这个架构的第一个真实出口:

老系统工单事件(CRM/呼叫中心/售后系统)
        ↓ MCP Tool Center推送TicketEvent
        ↓ TicketAgentService分析
        ↓ 分类/优先级/SLA风险/推荐处理人
        ↓ 等待人工确认
        ↓ 派单执行(回写到工单系统)
老系统通过MCP旁路接入AI能力

关键点: 没有直接连老系统数据库。所有交互通过MCP标准事件通道走。

这就是旁路原则——老系统不动,AI能力嫁接进来。


代码一览:7个类,各司其职

TicketAgentService        ← 主流程:事件→分析→推荐
TicketClassifier          ← 分类:PAYMENT/ORDER_DELIVERY/GENERAL
TicketPriorityPolicy      ← 优先级:HIGH/MEDIUM/LOW + SLA风险
TicketMaskingService      ← 脱敏:手机号、地址等
AssignmentPolicy          ← 处理人推荐 + 推荐理由
AssignmentConfirmationService ← 人工确认后才派单
TicketAuditService        ← 审计日志
AI工单助手代码结构

主入口是 analyze(event),它编排全流程,但不执行派单。派单必须走 confirm(),且必须传 confirmedBy——谁确认的,进审计日志。


核心逻辑①:分类——关键词,不是模型

关键词
分类
🔴 "支付"或"未支付"
PAYMENT
🟡 "发货"或"物流"或"延迟"
ORDER_DELIVERY
⚪ 其他
GENERAL

为什么不用模型? 三个理由:

  1. 1. 可审计——逻辑写在代码里,业务负责人能review
  2. 2. 可配置——运营人员看懂"包含支付进支付组"
  3. 3. 稳定——不受模型版本漂移影响

上线第一天,关键词比模型靠谱。


核心逻辑②:优先级与SLA风险

条件
优先级
🔴 分类=PAYMENT
HIGH
🟡 含"三天"或"延迟"
MEDIUM
⚪ 其他
LOW

🔴 HIGH优先级天然带SLA风险;🟡 content含"三天"也触发。

注意:"三天"是硬编码的业务阈值,不是AI自己理解的。 这就是可控性。

优先级与SLA风险仪表盘

核心逻辑③:处理人推荐+理由

分类
推荐处理人
推荐理由
🔴 PAYMENT
pay-team-lisi
支付团队值班,具备回调和对账经验
🟡 ORDER_DELIVERY
order-team-zhangsan
订单履约值班,熟悉仓库和物流排查
⚪ GENERAL
service-desk
通用服务台先接收

必须返回推荐理由。 没有理由的推荐,跟随机派单没区别。

演进路径:硬编码 → 值班表配置 → 技能标签匹配 → 历史数据加权


核心逻辑④:流程顺序——为什么是这样排

① 脱敏 → ② 分类 → ③ 优先级 → ④ SLA风险 → ⑤ 推荐 → ⑥ 审计
→ WAITING_FOR_HUMAN_CONFIRMATION

顺序不是随便排的:

  • • ① 脱敏必须排第一——合规风险,不脱敏后面全白做
  • • ② 分类在优先级之前——优先级依赖分类结果
  • • ③ 优先级在SLA之前——SLA依赖优先级
  • • ④ 推荐在最后——需要同时看分类+优先级
  • • ⑤ 审计在最后——一次性写入全量信息

两个Demo跑一遍

工单一:支付成功但订单显示未支付

输入含手机号13800000000,标题含"支付""未支付"。

{
"category":"PAYMENT",
"priority":"HIGH",
"slaRisk":true,
"recommendedAssignee":"pay-team-lisi",
"maskedFields":["mobile"],
"status":"WAITING_FOR_HUMAN_CONFIRMATION"
}

工单二:订单延迟发货咨询

输入含"三天""延迟""发货",无敏感字段。

{
"category":"ORDER_DELIVERY",
"priority":"MEDIUM",
"slaRisk":true,
"recommendedAssignee":"order-team-zhangsan",
"maskedFields":[],
"status":"WAITING_FOR_HUMAN_CONFIRMATION"
}
两个工单Demo结果

两个工单最终状态都是 WAITING_FOR_HUMAN_CONFIRMATION

AI算完了,但不自己动手。这是设计,不是缺陷。


为什么必须人工确认才能派单?

三个理由:

  1. 1. 责任边界清晰——AI推荐+人工决策+系统执行,回溯链路清楚
  2. 2. 准确率有上限——80%准确率的20%落在高优工单上就是投诉
  3. 3. 信任建立机制——点一下确认3秒,但建立了信任

confirm() 必须传 confirmedBy。谁确认的,进审计日志。没有这个字段,系统拒绝派单。

AI推荐后人工确认

五个坑,踩一个就翻车

⚠️ 坑一:让AI自动关闭工单——关闭=宣告已解决,客户还在投诉就升级

🔴 坑二:高优工单不经确认直接派——派错人比派慢了损失更大

⚠️ 坑三:工单原文裸给模型——手机号地址订单号必须脱敏

⚠️ 坑四:推荐不输出理由——必须返回 assignee + reason

⚠️ 坑五:跳过审计日志——全量记录既是合规要求,也是迭代数据基础

AI工单五个坑

从Demo到落地:四条工程路径

  1. 1. SLA规则引擎——从硬编码到可配置表,业务人员可维护
  2. 2. 历史相似工单RAG——新工单→embedding→检索相似历史方案→推给处理人
  3. 3. 自动派单门槛设计——GENERAL + LOW + 置信度>0.9 + 非首次咨询 + 确认率>95%
  4. 4. 工单系统集成——飞书/钉钉/企微/JIRA/自研,通过MCP双向通道

小结

工单AI落地不是全自动处理,而是:

工单事件 → 脱敏 → 分类 → 优先级 → SLA风险 → 推荐 → 审计 → 人工确认 → 派单

AI是提效工具,不是决策主体。

真正的工程难度在于:把业务规则翻译成稳定可维护的代码,并设计好人工确认的边界。

这是企业AI落地和Demo的分水岭。


💬 你现在的工单系统是全自动还是半自动?欢迎评论区聊聊你的踩坑经历。


往期回顾: