Django AI 做智能工单系统自动分类、重复合并、服务时限与人工审批实战OKOK大家好欢迎大家来到大鹏 AI 教育我是张大鹏。智能工单最容易做成一个“会聊天的页面”用户描述问题大模型给出答案看起来就像系统已经智能化了。但真正进入 CRM 后难点并不是聊天而是四件更具体的事工单应该分到哪一类、是否与已有问题重复、多久必须响应、什么时候必须由人审批。本文不做概念演示而是基于真实的 RuyiDjangoCRM 后端能力再加入一个可复现的 AI 建议层实验。边界先说清楚AI 只生成结构化提案Django 负责权限、规则和写入人确认以后系统才执行。真实项目已经具备哪些工单能力RuyiDjangoCRM 的工单模型并不是空壳。代码中已经定义了问题、故障和问题根因三类工单支持低、普通、高、紧急四档优先级以及新建、已分配、挂起、关闭、驳回、重复等状态。围绕这些字段项目还实现了四个关键能力确定性路由按组织、工单类型、优先级等条件匹配规则并支持只预演、不修改数据重复工单合并来源工单合并后标记为“重复”重复执行也有测试保护⏱️服务时限计算响应和解决时限由业务日历计算工单挂起时暂停计时✅关闭审批申请、批准、驳回、取消都有明确状态要求审批的工单不能被 AI 跳过流程直接关闭。这意味着我们不需要让 AI 重新发明工单系统只需要让它在现有业务能力之上提供建议。AI 应该放在哪一层一个可靠的智能工单流程可以拆成四层Django 查询当前用户有权限查看的工单和候选重复项普通 Python 规则裁剪字段、限制候选数量并计算服务时限AI 根据这些事实返回一份结构化提案Django 再次校验提案人确认后才调用分类、合并或审批接口。这里最重要的不是提示词而是权限边界。登录检查只能证明“你是谁”对象权限还要证明“你能否操作这张工单”。因此不能把全库工单交给模型也不能信任模型自己填写的组织编号。把模型输出收窄成可校验提案实验把 AI 输出限定为六个字段{case_type:INCIDENT,priority:HIGH,duplicate_of:1024,request_close_approval:false,summary:登录后持续出现 500 错误,confidence:0.92}其中工单类型和优先级必须来自白名单duplicate_of必须属于 Django 预先提供的、同一组织内可见的候选工单置信度不足时只展示建议不允许进入合并操作。ALLOWED_TYPES{QUESTION,INCIDENT,PROBLEM}ALLOWED_PRIORITIES{LOW,NORMAL,HIGH,URGENT}defvalidate_proposal(proposal,visible_candidate_ids):ifproposal[case_type]notinALLOWED_TYPES:raiseValueError(invalid case type)ifproposal[priority]notinALLOWED_PRIORITIES:raiseValueError(invalid priority)duplicate_idproposal.get(duplicate_of)ifduplicate_idandduplicate_idnotinvisible_candidate_ids:raisePermissionError(duplicate target is not visible)ifduplicate_idandproposal[confidence]0.85:raiseValueError(confidence is too low)这样做之后模型输出就不再是一段无法验证的自然语言而是可以被 Django 拒绝、记录和测试的业务输入。自动分类建议与执行必须分开AI 可以根据标题和描述建议工单类型与优先级例如把“系统完全无法登录”判断为故障并建议高优先级。但它不能直接修改数据库。页面应先展示“当前值”和“建议值”再给用户一个明确的确认按钮。只有确认请求到达后端Django 才重新检查工单版本、用户权限和字段白名单。这样可以避免用户查看建议期间工单已经被其他人修改而导致覆盖。实验中如果没有传入confirmedTrue执行函数只返回预览不产生任何写操作。这个小约束比在提示词中写十遍“请谨慎操作”更可靠。重复合并候选必须由 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 输出经过白名单和候选集校验人确认后才执行分类、合并或申请审批。当“模型建议、规则校验、人工确认、后端执行”四步被真正分开智能工单才从演示功能变成可以上线、可以追责、也可以持续测试的业务能力。
