数字防雷平台要同时做对两件事：一是把"什么异常、有多严重、多久内必须处置"判断清楚，这叫告警分级；二是把"谁接单、怎么处理、处置结果怎么回填、什么时候复核关闭"跑通，这叫工单闭环。两者不是一回事——分级是判断，闭环是执行。分级不准，闭环只会高效地空转；闭环缺失，再准的分级也只能停在屏幕上。告警分级在知识库中有明确锚点（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 评分与四维标签；闭环则要把触发、派单、处置、回填、关闭连成可核对的数据链。分级为闭环设定优先级，闭环用回填数据反过来校准分级——两者共同决定平台是"只报不理"还是"报而必闭环"。
