Django AI 做智能工單系統(tǒng)自動(dòng)分類、重復(fù)合并、服務(wù)時(shí)限與人工審批實(shí)戰(zhàn)OKOK大家好歡迎大家來到大鵬 AI 教育我是張大鵬。智能工單最容易做成一個(gè)“會(huì)聊天的頁面”用戶描述問題大模型給出答案看起來就像系統(tǒng)已經(jīng)智能化了。但真正進(jìn)入 CRM 后難點(diǎn)并不是聊天而是四件更具體的事工單應(yīng)該分到哪一類、是否與已有問題重復(fù)、多久必須響應(yīng)、什么時(shí)候必須由人審批。本文不做概念演示而是基于真實(shí)的 RuyiDjangoCRM 后端能力再加入一個(gè)可復(fù)現(xiàn)的 AI 建議層實(shí)驗(yàn)。邊界先說清楚AI 只生成結(jié)構(gòu)化提案Django 負(fù)責(zé)權(quán)限、規(guī)則和寫入人確認(rèn)以后系統(tǒng)才執(zhí)行。真實(shí)項(xiàng)目已經(jīng)具備哪些工單能力RuyiDjangoCRM 的工單模型并不是空殼。代碼中已經(jīng)定義了問題、故障和問題根因三類工單支持低、普通、高、緊急四檔優(yōu)先級以及新建、已分配、掛起、關(guān)閉、駁回、重復(fù)等狀態(tài)。圍繞這些字段項(xiàng)目還實(shí)現(xiàn)了四個(gè)關(guān)鍵能力確定性路由按組織、工單類型、優(yōu)先級等條件匹配規(guī)則并支持只預(yù)演、不修改數(shù)據(jù)重復(fù)工單合并來源工單合并后標(biāo)記為“重復(fù)”重復(fù)執(zhí)行也有測試保護(hù)??服務(wù)時(shí)限計(jì)算響應(yīng)和解決時(shí)限由業(yè)務(wù)日歷計(jì)算工單掛起時(shí)暫停計(jì)時(shí)?關(guān)閉審批申請、批準(zhǔn)、駁回、取消都有明確狀態(tài)要求審批的工單不能被 AI 跳過流程直接關(guān)閉。這意味著我們不需要讓 AI 重新發(fā)明工單系統(tǒng)只需要讓它在現(xiàn)有業(yè)務(wù)能力之上提供建議。AI 應(yīng)該放在哪一層一個(gè)可靠的智能工單流程可以拆成四層Django 查詢當(dāng)前用戶有權(quán)限查看的工單和候選重復(fù)項(xiàng)普通 Python 規(guī)則裁剪字段、限制候選數(shù)量并計(jì)算服務(wù)時(shí)限AI 根據(jù)這些事實(shí)返回一份結(jié)構(gòu)化提案Django 再次校驗(yàn)提案人確認(rèn)后才調(diào)用分類、合并或?qū)徟涌?。這里最重要的不是提示詞而是權(quán)限邊界。登錄檢查只能證明“你是誰”對象權(quán)限還要證明“你能否操作這張工單”。因此不能把全庫工單交給模型也不能信任模型自己填寫的組織編號(hào)。把模型輸出收窄成可校驗(yàn)提案實(shí)驗(yàn)把 AI 輸出限定為六個(gè)字段{case_type:INCIDENT,priority:HIGH,duplicate_of:1024,request_close_approval:false,summary:登錄后持續(xù)出現(xiàn) 500 錯(cuò)誤,confidence:0.92}其中工單類型和優(yōu)先級必須來自白名單duplicate_of必須屬于 Django 預(yù)先提供的、同一組織內(nèi)可見的候選工單置信度不足時(shí)只展示建議不允許進(jìn)入合并操作。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)這樣做之后模型輸出就不再是一段無法驗(yàn)證的自然語言而是可以被 Django 拒絕、記錄和測試的業(yè)務(wù)輸入。自動(dòng)分類建議與執(zhí)行必須分開AI 可以根據(jù)標(biāo)題和描述建議工單類型與優(yōu)先級例如把“系統(tǒng)完全無法登錄”判斷為故障并建議高優(yōu)先級。但它不能直接修改數(shù)據(jù)庫。頁面應(yīng)先展示“當(dāng)前值”和“建議值”再給用戶一個(gè)明確的確認(rèn)按鈕。只有確認(rèn)請求到達(dá)后端Django 才重新檢查工單版本、用戶權(quán)限和字段白名單。這樣可以避免用戶查看建議期間工單已經(jīng)被其他人修改而導(dǎo)致覆蓋。實(shí)驗(yàn)中如果沒有傳入confirmedTrue執(zhí)行函數(shù)只返回預(yù)覽不產(chǎn)生任何寫操作。這個(gè)小約束比在提示詞中寫十遍“請謹(jǐn)慎操作”更可靠。重復(fù)合并候選必須由 Django 提供讓 AI 在全庫里自由搜索重復(fù)工單既浪費(fèi)上下文也容易越權(quán)。更穩(wěn)妥的方式是先由 Django 按組織、狀態(tài)和關(guān)鍵詞篩出少量候選再讓 AI 在候選中判斷相似度。本次實(shí)驗(yàn)最多傳入 5 個(gè)候選只保留編號(hào)、標(biāo)題、類型和狀態(tài)并把描述截?cái)嗟?800 個(gè)字符。模型只能從這些編號(hào)中選擇目標(biāo)不能憑空生成一個(gè)工單編號(hào)。確認(rèn)合并時(shí)仍然調(diào)用項(xiàng)目原有合并邏輯來源工單被標(biāo)記為“重復(fù)”目標(biāo)工單保留主記錄。AI 不接觸底層關(guān)聯(lián)遷移也不決定跨組織合并。服務(wù)時(shí)限必須由 Django 計(jì)算服務(wù)時(shí)限屬于確定性業(yè)務(wù)規(guī)則不適合交給大模型心算。真實(shí)項(xiàng)目中的默認(rèn)首次響應(yīng)時(shí)限是低優(yōu)先級 24 小時(shí)、普通 8 小時(shí)、高優(yōu)先級 4 小時(shí)、緊急 1 小時(shí)默認(rèn)解決時(shí)限分別是 72、48、24、4 小時(shí)。實(shí)際截止時(shí)間還會(huì)受到工作日歷和掛起時(shí)段影響。AI 可以解釋“為什么這張工單需要優(yōu)先處理”但最終截止時(shí)間必須由 Django 的服務(wù)時(shí)限函數(shù)計(jì)算。否則同一個(gè)問題在不同時(shí)間詢問模型可能得到不同答案。關(guān)閉工單先進(jìn)入人工審批當(dāng) AI 判斷問題可能已經(jīng)解決時(shí)它最多只能建議“申請關(guān)閉”不能直接把狀態(tài)改成關(guān)閉。后端收到確認(rèn)后創(chuàng)建待審批記錄審批人可以批準(zhǔn)、駁回或取消。只有滿足項(xiàng)目原有關(guān)閉條件狀態(tài)才會(huì)真正變化。這個(gè)流程把 AI 的價(jià)值放在減少閱讀和判斷成本上同時(shí)保留責(zé)任明確的人工作業(yè)點(diǎn)。我用 15 項(xiàng)實(shí)驗(yàn)測試了哪些邊界為了避免文章只停留在流程圖我寫了一個(gè)不依賴外部模型和 API 密鑰的最小實(shí)驗(yàn)并用固定模型輸出驗(yàn)證編排邊界。它不證明某個(gè)模型的分類準(zhǔn)確率只證明系統(tǒng)在模型出錯(cuò)時(shí)能否守住業(yè)務(wù)規(guī)則。15 項(xiàng)測試覆蓋了這些場景 非法工單類型和優(yōu)先級會(huì)被拒絕 跨組織或不可見的重復(fù)目標(biāo)會(huì)被拒絕 低置信度建議不能觸發(fā)重復(fù)合并 未確認(rèn)時(shí)分類、合并和審批都不會(huì)寫入 確認(rèn)后只能執(zhí)行白名單操作 AI 只能申請關(guān)閉審批不能直接關(guān)閉工單 服務(wù)時(shí)限始終由確定性規(guī)則計(jì)算。實(shí)驗(yàn)最終 15 項(xiàng)測試全部通過。來源與證據(jù)除了新增實(shí)驗(yàn)我還在 RuyiDjangoCRM 當(dāng)前提交上運(yùn)行了工單合并、審批、訪問控制、服務(wù)時(shí)限和路由相關(guān)測試共 125 項(xiàng)全部通過。這兩個(gè)數(shù)字代表不同證據(jù)125 項(xiàng)測試證明真實(shí) Django 后端已有能力沒有被文章想象出來15 項(xiàng)測試證明新增 AI 建議層在越權(quán)、誤合并和未確認(rèn)寫入等關(guān)鍵邊界上可以被程序驗(yàn)證。行動(dòng)與驗(yàn)證如果你也在給 Django CRM 增加 AI建議按下面的順序做先把分類、合并、服務(wù)時(shí)限和審批做成獨(dú)立、可測試的后端能力再設(shè)計(jì)嚴(yán)格的 AI 輸出結(jié)構(gòu)不接受任意字段候選數(shù)據(jù)由 Django 按對象權(quán)限篩選模型不能自行擴(kuò)大范圍所有寫操作先預(yù)覽再由用戶明確確認(rèn)用固定錯(cuò)誤輸出測試越權(quán)、幻覺和重復(fù)執(zhí)行而不只測試正常路徑最后才接入真實(shí)模型并單獨(dú)評估分類準(zhǔn)確率和成本?？偨Y(jié)Django AI 做智能工單真正有價(jià)值的不是讓模型替代整套業(yè)務(wù)系統(tǒng)而是讓它在受控范圍內(nèi)完成閱讀、歸納和建議。工單事實(shí)、對象權(quán)限、服務(wù)時(shí)限和狀態(tài)變化仍由 Django 掌握AI 輸出經(jīng)過白名單和候選集校驗(yàn)人確認(rèn)后才執(zhí)行分類、合并或申請審批。當(dāng)“模型建議、規(guī)則校驗(yàn)、人工確認(rèn)、后端執(zhí)行”四步被真正分開智能工單才從演示功能變成可以上線、可以追責(zé)、也可以持續(xù)測試的業(yè)務(wù)能力。