Django + AI 做智能工单系统：自动分类、重复合并、服务时限与人工审批实战

OK，OK，大家好，欢迎大家来到大鹏 AI 教育，我是张大鹏。

智能工单最容易做成一个"会聊天的页面"：用户描述问题，大模型给出答案，看起来就像系统已经智能化了。但真正进入 CRM 后，难点并不是聊天，而是四件更具体的事：工单应该分到哪一类、是否与已有问题重复、多久必须响应、什么时候必须由人审批。

本文不做概念演示，而是基于真实的 RuyiDjangoCRM 后端能力，再加入一个可复现的 AI 建议层实验。边界先说清楚：AI 只生成结构化提案，Django 负责权限、规则和写入，人确认以后系统才执行。

真实项目已经具备哪些工单能力

RuyiDjangoCRM 的工单模型并不是空壳。代码中已经定义了问题、故障和问题根因三类工单，支持低、普通、高、紧急四档优先级，以及新建、已分配、挂起、关闭、驳回、重复等状态。

围绕这些字段，项目还实现了四个关键能力：

🧭 确定性路由：按组织、工单类型、优先级等条件匹配规则，并支持只预演、不修改数据；
🔗 重复工单合并：来源工单合并后标记为"重复"，重复执行也有测试保护；
⏱️ 服务时限计算：响应和解决时限由业务日历计算，工单挂起时暂停计时；
✅ 关闭审批：申请、批准、驳回、取消都有明确状态，要求审批的工单不能被 AI 跳过流程直接关闭。

这意味着我们不需要让 AI 重新发明工单系统，只需要让它在现有业务能力之上提供建议。

AI 应该放在哪一层

一个可靠的智能工单流程可以拆成四层：

Django 查询当前用户有权限查看的工单和候选重复项；
普通 Python 规则裁剪字段、限制候选数量并计算服务时限；
AI 根据这些事实返回一份结构化提案；
Django 再次校验提案，人确认后才调用分类、合并或审批接口。

这里最重要的不是提示词，而是权限边界。登录检查只能证明"你是谁"，对象权限还要证明"你能否操作这张工单"。因此，不能把全库工单交给模型，也不能信任模型自己填写的组织编号。

把模型输出收窄成可校验提案

实验把 AI 输出限定为六个字段：

json 复制代码

{
  "case_type": "INCIDENT",
  "priority": "HIGH",
  "duplicate_of": 1024,
  "request_close_approval": false,
  "summary": "登录后持续出现 500 错误",
  "confidence": 0.92
}

其中工单类型和优先级必须来自白名单；duplicate_of 必须属于 Django 预先提供的、同一组织内可见的候选工单；置信度不足时，只展示建议，不允许进入合并操作。

python 复制代码

ALLOWED_TYPES = {"QUESTION", "INCIDENT", "PROBLEM"}
ALLOWED_PRIORITIES = {"LOW", "NORMAL", "HIGH", "URGENT"}

def validate_proposal(proposal, visible_candidate_ids):
    if proposal["case_type"] not in ALLOWED_TYPES:
        raise ValueError("invalid case type")
    if proposal["priority"] not in ALLOWED_PRIORITIES:
        raise ValueError("invalid priority")
    duplicate_id = proposal.get("duplicate_of")
    if duplicate_id and duplicate_id not in visible_candidate_ids:
        raise PermissionError("duplicate target is not visible")
    if duplicate_id and proposal["confidence"] < 0.85:
        raise ValueError("confidence is too low")

这样做之后，模型输出就不再是一段无法验证的自然语言，而是可以被 Django 拒绝、记录和测试的业务输入。

自动分类：建议与执行必须分开

AI 可以根据标题和描述建议工单类型与优先级，例如把"系统完全无法登录"判断为故障并建议高优先级。但它不能直接修改数据库。

页面应先展示"当前值"和"建议值"，再给用户一个明确的确认按钮。只有确认请求到达后端，Django 才重新检查工单版本、用户权限和字段白名单。这样可以避免用户查看建议期间，工单已经被其他人修改而导致覆盖。

实验中，如果没有传入 confirmed=True，执行函数只返回预览，不产生任何写操作。这个小约束比在提示词中写十遍"请谨慎操作"更可靠。

重复合并：候选必须由 Django 提供

让 AI 在全库里自由搜索重复工单既浪费上下文，也容易越权。更稳妥的方式是先由 Django 按组织、状态和关键词筛出少量候选，再让 AI 在候选中判断相似度。

本次实验最多传入 5 个候选，只保留编号、标题、类型和状态，并把描述截断到 800 个字符。模型只能从这些编号中选择目标，不能凭空生成一个工单编号。

确认合并时仍然调用项目原有合并逻辑：来源工单被标记为"重复"，目标工单保留主记录。AI 不接触底层关联迁移，也不决定跨组织合并。

服务时限必须由 Django 计算

服务时限属于确定性业务规则，不适合交给大模型心算。真实项目中的默认首次响应时限是：低优先级 24 小时、普通 8 小时、高优先级 4 小时、紧急 1 小时；默认解决时限分别是 72、48、24、4 小时。

实际截止时间还会受到工作日历和挂起时段影响。AI 可以解释"为什么这张工单需要优先处理"，但最终截止时间必须由 Django 的服务时限函数计算。否则，同一个问题在不同时间询问模型，可能得到不同答案。

关闭工单先进入人工审批

当 AI 判断问题可能已经解决时，它最多只能建议"申请关闭"，不能直接把状态改成关闭。

后端收到确认后，创建待审批记录；审批人可以批准、驳回或取消。只有满足项目原有关闭条件，状态才会真正变化。这个流程把 AI 的价值放在减少阅读和判断成本上，同时保留责任明确的人工作业点。

我用 15 项实验测试了哪些边界

为了避免文章只停留在流程图，我写了一个不依赖外部模型和 API 密钥的最小实验，并用固定模型输出验证编排边界。它不证明某个模型的分类准确率，只证明系统在模型出错时能否守住业务规则。

15 项测试覆盖了这些场景：

🧪 非法工单类型和优先级会被拒绝；
🧪 跨组织或不可见的重复目标会被拒绝；
🧪 低置信度建议不能触发重复合并；
🧪 未确认时分类、合并和审批都不会写入；
🧪 确认后只能执行白名单操作；
🧪 AI 只能申请关闭审批，不能直接关闭工单；
🧪 服务时限始终由确定性规则计算。

实验最终 15 项测试全部通过。

来源与证据

除了新增实验，我还在 RuyiDjangoCRM 当前提交上运行了工单合并、审批、访问控制、服务时限和路由相关测试，共 125 项，全部通过。

这两个数字代表不同证据：125 项测试证明真实 Django 后端已有能力没有被文章想象出来；15 项测试证明新增 AI 建议层在越权、误合并和未确认写入等关键边界上可以被程序验证。

行动与验证

如果你也在给 Django CRM 增加 AI，建议按下面的顺序做：

先把分类、合并、服务时限和审批做成独立、可测试的后端能力；
再设计严格的 AI 输出结构，不接受任意字段；
候选数据由 Django 按对象权限筛选，模型不能自行扩大范围；
所有写操作先预览，再由用户明确确认；
用固定错误输出测试越权、幻觉和重复执行，而不只测试正常路径；
最后才接入真实模型，并单独评估分类准确率和成本。

总结

Django + AI 做智能工单，真正有价值的不是让模型替代整套业务系统，而是让它在受控范围内完成阅读、归纳和建议。工单事实、对象权限、服务时限和状态变化仍由 Django 掌握；AI 输出经过白名单和候选集校验；人确认后才执行分类、合并或申请审批。

当"模型建议、规则校验、人工确认、后端执行"四步被真正分开，智能工单才从演示功能变成可以上线、可以追责、也可以持续测试的业务能力。