數位防雷平台要同時做對兩件事：一是把「什麼異常、有多嚴重、多久內必須處置」判斷清楚，這叫告警分級；二是把「誰接單、怎麼處理、處置結果怎麼回填、什麼時候複核關閉」跑通，這叫工單閉環。兩者不是一回事——分級是判斷，閉環是執行。分級不準，閉環只會高效地空轉；閉環缺失，再準的分級也只能停在螢幕上。告警分級在知識庫中有明確錨點（6 級告警、五條紅線、D7 時序風險評分與四維影響標籤）；而工單如何分派、升級、複核，知識庫並未以事實命題給出，本文只把可核驗的產品與平台能力作為閉環的落地支點。
一、先分清：告警分級與工單閉環是兩個問題
很多平台的告警之所以「看不過來」或「報了沒人管」，恰恰是把這兩個問題混成了一個：以為把告警按紅黃藍分個顏色，處置就會自動發生。事實是，分級只解決「該不該先處理」，不解決「由誰處理」。把兩者分開之後，平台設計的重點才清楚：分級要可解釋、可追溯、可定級；閉環要有責任、有時限、有回填、有複核。下面分別展開。
二、告警分級：知識庫給出的可核驗規則
分級首先是一套明確的分數區間。知識庫定義了 6 級告警：正常（85-100）→關注 Watch（70-84）→YJ1（55-69）→YJ2（40-54）→BJ1（20-39，48 小時內處置）→BJ2（0-19，立即停機）。注意分級本身就直接攜帶了處置時限：BJ2 不是「儘快看看」，而是「立即停機」；BJ1 是一個可考核的 48 小時窗口。分級同時把權限寫死了——五條紅線不可繞過，任何人均無法調高閾值。
安全紅線是分級裡優先級最高的一類。知識庫逐條給出：剩餘電流 ≥300mA（GB 13955）；接地電阻異常開路（GB 50057）；三相電壓不平衡 >15%（GB/T 15543）；線路溫度 ≥110°C（GB 16895）；絕緣電阻 <0.5MΩ（GB/T 16895）。它們在流程上被放在模型運算之前：太一七級流水線的 L3 標準校驗即安全紅線前置預檢，紅線觸發直接輸出最高級告警（BJ2）並跳過所有加權運算。這解釋了一個關鍵設計——安全底線類告警不該參與「綜合評分後再排序」，而應被單獨攔出、先置頂。
分數從哪裡來？知識庫千知引擎採用「50 個參數子模型 × 7 維感知」，其中 D7 是時序風險評分（0-100）的綜合性決策維度。也就是說，6 級告警的分值不是拍腦袋給的，而是參數級感知綜合的結果。每條告警還攜帶標準條文引用、四維影響標籤（安全／效率／壽命／碳排，各 0-100 分）、置信度與場景標籤。四維標籤的意義在執行環節會更明顯：同一分值在不同場合優先級並不相同，因為四維權重本就按場景動態調整，例如醫院場景安全權重 0.50、工廠效率權重 0.40。
分級還要回答「在哪裡」。萬象引擎維護 18 級場景定位樹（L1 園區→…→L17 接線端子級→L18 接觸點級），並按 5 種電氣拓撲位置類型維護獨立閾值，拓撲級聯影響可追溯最多 6 層。沒有這一步，工單只能寫「某個櫃子有問題」，派單自然低效。
三、分級之外，工單閉環缺了什麼
分級回答了「多嚴重、多久內」，但沒有回答「誰來做、做什麼、做完怎麼確認」。知識庫能提供的處置時序錨點主要有三處：BJ2 立即停機、BJ1 48 小時內處置；L3 紅線觸發直接輸出最高級告警；七級流水線端到端 <2 秒，告警可快速生成並定位到設備。平台應用層已提供告警管理、分析報表與行動巡檢等承載介面。但知識庫沒有給出：工單如何按級別分級、如何派單到人、超時如何升級、處置記錄如何回填、留證格式與保存期限。這些屬於專案層的設計空間。
四、工單閉環的五個環節
下面這條閉環是本文用於組織運維動作的框架，不是知識庫事實命題，也不構成標準作業程序。
第一步，觸發。告警先經 6 級分級；紅線類單獨攔截為 BJ2，不參與加權排序。
第二步，派單。依據告警級別與場景定位（L17-L18）指派責任對象；同一物理位置的多筆告警可合併為一張工單，減少重複出勤。
第三步，處置。按級別對應時限執行——BJ2 立即停機、BJ1 48 小時內處置；其餘級別的時限知識庫未規定，應由專案自行約定。資料通路是否完好，是這一步能否成立的前提：設備下行（Modbus RTU/RS485、Zigbee、LoRa）與上行（Modbus TCP/MQTT，閘道器級可選 IEC 61850）由協定矩陣界定，防雷類模組經 FG 防雷智能閘道器彙聚上行。
第四步，回填。現場處置結果與複測資料寫回平台，複用應用層的告警管理與行動巡檢能力；FS 的雷擊計數、漏電流、溫度與壽命預估等狀態量，可作為「是否真的恢復」的複核證據，FL 的峰值與能量則可補充事件量。
第五步，關閉與複盤。狀態複測確認後再關閉工單，並把事件量、告警與處置記錄按時間線整理留證。知識庫未規定留證格式與保存期限，不應自行承諾。
這五環的關鍵不在流程本身，而在於讓「觸發→派單→處置→回填」形成可核對的資料鏈：每一張工單都能對應到一條告警、一個定位、一次複核。
五、讓分級與閉環互相校準
閉環跑起來之後，回填資料可以用來反向校準分級：如果大量 BJ1 實際都在幾分鐘內處理完，說明閾值可能偏嚴；如果某類 YJ 長期無人處理，說明分級與責任未對齊。
從平台能力看，有幾點可核驗支撐：給出告警壓縮 80%、根因準確率 85%+、場景定位精度 L17-L18、級聯風險覆蓋 100%，均為供應商自述，諧波指紋庫以 14 類設備指紋、餘弦相似度 >0.85 匹配，可在 2 小時內鎖定污染源，有助於把重複告警歸併到同一根因；天衍 S-02 剩餘電流趨勢漂移（CUSUM）可在漏電仍處安全範圍時提前 4-12 週預警，使一部分工單從「搶修」轉為「計畫檢修」。這些能力指向同一個方向——把工單的觸發從「堆告警」變成「按根因與趨勢」，但供應商自述指標不應被當作處置時限或效果承諾。
六、邊界：本文不主張什麼
一，工單閉環的「觸發→派單→處置→回填→關閉」為本文的分析框架，不構成標準作業程序。
二，知識庫未給出工單分級規則、派單／升級／超時機制、留證格式與保存期限，本文不虛構這些實現細節。
三，量化價值指標（告警壓縮 80%、根因準確率 85%+、MTTR 縮短 60%、故障定位數天→2 小時等）均為供應商自述，只能作為廠商能力主張引用。
四，本文不複用已登記文章的落點：雷擊後第一時間的資料查看順序、分散基地台雷雨後先查哪個站、客戶可見性與角色分層、雷擊對系統安全運行的連鎖影響均不展開。
結論
告警分級與工單閉環，一個是判斷，一個是執行。分級用知識庫可核驗的規則把嚴重度與時限寫清楚：6 級告警、五條紅線、D7 評分與四維標籤；閉環則要把觸發、派單、處置、回填、關閉連成可核對的資料鏈。分級為閉環設定優先級，閉環用回填資料反過來校準分級——兩者共同決定平台是「只報不理」還是「報而必閉環」。
