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


老板说:"让AI自动处理工单,全自动闭环!"
听起来是不是很爽?AI帮你分类、派单、处理、关单,一条龙服务,客服团队直接躺平。
但做起来会很惨。
为什么?因为自动闭环意味着AI对结果负责。它决定派谁处理、修不修、退不退钱——每一步都是客户体验的雷区。
一旦出错,客户投诉升级,你连回退路径都没有。
更稳的第一步:让AI做助手,不是执行者
正确的姿势是这样的👇
AI摘要问题 → 判断分类 → 识别优先级 → 发现SLA风险 → 推荐处理人 → 等人工确认
这一圈走完,客服主管拿到的是一张结构化卡片,而不是几十行原始文字。
他只需要点"确认"或"修改",工单就下去了。
AI是提效工具,不是决策主体。 这是企业AI落地第一道安全门。

架构位置:老系统不动,AI嫁接进来
第2讲搭了MCP Tool Center——把老系统能力标准化成MCP工具。工单助手就是这个架构的第一个真实出口:
老系统工单事件(CRM/呼叫中心/售后系统)
↓ MCP Tool Center推送TicketEvent
↓ TicketAgentService分析
↓ 分类/优先级/SLA风险/推荐处理人
↓ 等待人工确认
↓ 派单执行(回写到工单系统)
关键点: 没有直接连老系统数据库。所有交互通过MCP标准事件通道走。
这就是旁路原则——老系统不动,AI能力嫁接进来。
代码一览:7个类,各司其职
TicketAgentService ← 主流程:事件→分析→推荐
TicketClassifier ← 分类:PAYMENT/ORDER_DELIVERY/GENERAL
TicketPriorityPolicy ← 优先级:HIGH/MEDIUM/LOW + SLA风险
TicketMaskingService ← 脱敏:手机号、地址等
AssignmentPolicy ← 处理人推荐 + 推荐理由
AssignmentConfirmationService ← 人工确认后才派单
TicketAuditService ← 审计日志
主入口是 analyze(event),它编排全流程,但不执行派单。派单必须走 confirm(),且必须传 confirmedBy——谁确认的,进审计日志。
核心逻辑①:分类——关键词,不是模型
为什么不用模型? 三个理由:
1. 可审计——逻辑写在代码里,业务负责人能review 2. 可配置——运营人员看懂"包含支付进支付组" 3. 稳定——不受模型版本漂移影响
上线第一天,关键词比模型靠谱。
核心逻辑②:优先级与SLA风险
🔴 HIGH优先级天然带SLA风险;🟡 content含"三天"也触发。
注意:"三天"是硬编码的业务阈值,不是AI自己理解的。 这就是可控性。

核心逻辑③:处理人推荐+理由
必须返回推荐理由。 没有理由的推荐,跟随机派单没区别。
演进路径:硬编码 → 值班表配置 → 技能标签匹配 → 历史数据加权
核心逻辑④:流程顺序——为什么是这样排
① 脱敏 → ② 分类 → ③ 优先级 → ④ 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"
}
两个工单最终状态都是 WAITING_FOR_HUMAN_CONFIRMATION。
AI算完了,但不自己动手。这是设计,不是缺陷。
为什么必须人工确认才能派单?
三个理由:
1. 责任边界清晰——AI推荐+人工决策+系统执行,回溯链路清楚 2. 准确率有上限——80%准确率的20%落在高优工单上就是投诉 3. 信任建立机制——点一下确认3秒,但建立了信任
confirm() 必须传 confirmedBy。谁确认的,进审计日志。没有这个字段,系统拒绝派单。

五个坑,踩一个就翻车
⚠️ 坑一:让AI自动关闭工单——关闭=宣告已解决,客户还在投诉就升级
🔴 坑二:高优工单不经确认直接派——派错人比派慢了损失更大
⚠️ 坑三:工单原文裸给模型——手机号地址订单号必须脱敏
⚠️ 坑四:推荐不输出理由——必须返回 assignee + reason
⚠️ 坑五:跳过审计日志——全量记录既是合规要求,也是迭代数据基础

从Demo到落地:四条工程路径
1. SLA规则引擎——从硬编码到可配置表,业务人员可维护 2. 历史相似工单RAG——新工单→embedding→检索相似历史方案→推给处理人 3. 自动派单门槛设计——GENERAL + LOW + 置信度>0.9 + 非首次咨询 + 确认率>95% 4. 工单系统集成——飞书/钉钉/企微/JIRA/自研,通过MCP双向通道
小结
工单AI落地不是全自动处理,而是:
工单事件 → 脱敏 → 分类 → 优先级 → SLA风险 → 推荐 → 审计 → 人工确认 → 派单
AI是提效工具,不是决策主体。
真正的工程难度在于:把业务规则翻译成稳定可维护的代码,并设计好人工确认的边界。
这是企业AI落地和Demo的分水岭。
💬 你现在的工单系统是全自动还是半自动?欢迎评论区聊聊你的踩坑经历。
往期回顾:
夜雨聆风