WGCAT v1.3.0 引入 AI 派单：让工单先找到合适的经办人

工单系统最常见的瓶颈，往往不在“能不能创建工单”，而在“谁该先处理它”。WGCAT v1.3.0 增加 AI 派单能力，把工单标题、描述和上下文转化为可执行的分派建议，帮助团队减少人工分拣和反复转派。

WGCAT 延续了简单实用的定位：所有账号都可以新建工单，系统也提供对外工单提交接口；在流转期间，参与者可以评论，工单每次流转会通知对应经办人。AI 派单加入后，工单入口到经办人的这段链路可以更自动化，但仍应保留人工确认和兜底规则。

AI 派单解决的不是“自动回复”

AI 派单的核心任务是分类和路由，而不是替代工程师处理问题。一个有价值的派单结果通常至少应包含三部分：

• 工单分类：例如故障、权限申请、部署请求、咨询或功能建议。
• 优先级判断：基于影响范围、紧急程度和业务关键词给出建议等级。
• 候选经办人或处理组：根据服务边界、历史职责和当前值班安排确定去向。

例如，“生产环境支付接口持续 502，影响下单”不应和“测试环境账号需要重置密码”走同一条路径。前者需要快速进入支付服务的值班队列，后者更适合分派给支持或账号管理人员。

这类能力的直接收益是缩短首次响应时间。但更重要的是，派单逻辑从个人经验逐渐沉淀为团队可检查、可调整的规则与知识。

对外提交接口是自动化入口

WGCAT 提供对外工单提交接口，这意味着监控告警、业务系统异常页、内部自助门户都可以成为工单来源。AI 派单适合放在“工单创建后、首次分派前”的位置：外部系统负责提交事实，AI 给出结构化判断，工单系统执行流转和通知。

下面的 curl 是一个按常见 REST 风格编写的改造示例，字段名和实际路径需要以你的 WGCAT 部署接口文档为准。它展示了调用方应提交哪些有助于派单的上下文。

curl -X POST "https://wgcat.example.com/api/tickets" \
  -H "Authorization: Bearer $WGCAT_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "title": "生产支付接口返回 502",
    "content": "从 10:12 开始，下单页面调用 /api/payments 持续失败，影响华东区域用户。",
    "source": "monitoring",
    "labels": ["production", "payment", "incident"],
    "priority": "high"
  }'

运行前需要替换域名、接口路径、鉴权方式以及请求字段。即使系统支持 AI 派单，也建议调用方传入 source、环境、服务名和标签等确定性信息。模型擅长从自然语言中补全语义，但不应承担本可由系统明确提供的事实。

可以这样实践：为 AI 输出加一层可审计约束

AI 直接输出“把工单交给张三”并不稳妥。人员变动、值班轮换和服务边界调整都会让静态结论过期。更可靠的做法是让 AI 输出分类、优先级和处理组建议，再由业务规则映射到当前可用的经办人。

下面是一个可直接运行的 Python 示例。它不依赖特定厂商模型接口，而是模拟 AI 返回 JSON，并在本地校验派单结果。接入真实模型时，只需将 ask_ai() 替换为你的模型调用代码。

import json

ALLOWED_GROUPS = {"payment-oncall", "account-support", "platform-ops"}


def ask_ai(ticket: dict) -> str:
    # 示例输出：生产环境支付故障应进入支付值班组。
    return json.dumps({
        "category": "incident",
        "priority": "P1",
        "assignee_group": "payment-oncall",
        "reason": "生产支付接口 502，且明确影响用户下单"
    }, ensure_ascii=False)


def route_ticket(ticket: dict) -> dict:
    suggestion = json.loads(ask_ai(ticket))
    group = suggestion.get("assignee_group")

    if group not in ALLOWED_GROUPS:
        return {
            "action": "manual_review",
            "reason": "AI 返回了未注册的处理组",
            "suggestion": suggestion,
        }

    if suggestion.get("priority") not in {"P1", "P2", "P3", "P4"}:
        suggestion["priority"] = "P3"

    return {
        "action": "assign",
        "group": group,
        "category": suggestion["category"],
        "priority": suggestion["priority"],
        "reason": suggestion["reason"],
    }


ticket = {
    "title": "生产支付接口返回 502",
    "content": "下单受影响，错误从 10:12 开始持续出现。",
    "labels": ["production", "payment"],
}

print(json.dumps(route_ticket(ticket), ensure_ascii=False, indent=2))

这段代码刻意把“模型建议”和“执行派单”分开。生产接入时，可以继续增加几条硬规则：

• P1 工单必须通知值班人员，不能只依赖普通队列分配。
• 涉及账号、隐私或敏感数据的工单应限制可见范围，并避免将原始敏感内容发送给外部模型。
• AI 置信度不足、候选组不存在或内容不完整时，进入人工分诊队列。
• 保存模型建议、最终分派结果和人工改派记录，用于审计与后续优化。

从建议派单开始，而不是一步到位全自动

上线初期，建议采用“AI 推荐 + 人工确认”模式：系统展示分类、优先级、候选处理组和理由，由分诊人员一键接受或修改。积累一段时间的数据后，再把高一致性场景自动化，例如明确的监控告警、固定服务的常见故障，或格式规范的权限申请。

评估效果时，不要只看自动分派比例。更值得跟踪的是首次响应时长、首次分派正确率、平均转派次数、超时工单比例，以及人工覆盖 AI 建议的原因。若模型经常把工单分给错误团队，通常不是简单调高提示词就能解决，而是服务目录、处理组边界或工单输入字段本身仍不够清晰。

WGCAT v1.3.0 的 AI 派单为工单流转增加了一个智能入口。把它放进可审计的规则框架中，保留人工兜底，并持续用真实改派数据校正路由策略，才能让“自动派单”真正减少团队的协调成本。