5.9 KiB
5.9 KiB
线损家族变体分组报告
Date: 2026-04-18 Scope:
docs/superpowers/plans/2026-04-18-lineloss-family-variant-expansion-plan.mdPurpose: 完成 Phase 0 / Phase 1 交付物,冻结当前线损家族基线,并建立后续扩展分组清单。
1. 当前已冻结基线
本轮扩展以前,线损家族中已经可稳定识别并生成的子型为:
G2-A = g2_a_dual_mode_baseline代表样本:台区线损大数据-月_周累计线损率统计分析特征:同一主链路下同时存在月 / 周两套模式,请求和列定义都较完整。G2-B = g2_b_weekly_single_mode代表样本:白银线损周报特征:仍属于线损主链路,但只有周报单侧模式,需要用最小周报合约兜住生成。G2-C = g2_c_mixed_linked_workflow代表样本:线损同期差异报表特征:主链路仍是线损查询,但同时联动外部系统或二次查询,只能先恢复主链路最小合约。
上述三类已经在上一轮回归中通过本地测试,并在真实样本重生成为候选 skill,不再回退到“只修主样本”的阶段。
2. 线损场景盘点结果
本次从 D:\desk\智能体资料\全量业务场景\一平台场景 中筛出的线损相关场景为:
台区线损大数据-月_周累计线损率统计分析白银线损周报线损同期差异报表台区零度户月度用电量与台区线损电量对比核查报表线损大数据-窃电分析线路月度高负损预测台区线损台区月度高负损预测供电所线路电量统计线路失电信息明细
其中 8 和 9 与当前线损主家族相关度较弱,不纳入本轮优先扩展对象。
3. 结构化分组
3.1 已落地组
G2-A 双模式主报表型代表样本:台区线损大数据-月_周累计线损率统计分析G2-B 周报单侧模式型代表样本:白银线损周报G2-C 混合联动主链路型代表样本:线损同期差异报表
3.2 新增候选组
-
G2-D 预测计算型代表样本:线路月度高负损预测台区线损台区月度高负损预测结构特征:- 页面内存在
reportType = monthlyHighNegativeLossPredictionForLines或同类预测型标识 - 结果并非直接来自标准
cols1/cols2表头,而是先读取多个输入表或数据块,再在页面内计算lineLossRate / powerLoss / lineLossType - 导出字段以“预测结果字段”为主,如
lineId / lineName / lineLossType / lineLossRate / powerLoss结论: - 这类不是传统 G2 主报表直接抽列,而是“取数 + 计算 + 导出”的计算型线损变体
- 适合优先扩展,因为有两个高度相似样本,可做成同一家族
-
G2-E 核查对比型代表样本:台区零度户月度用电量与台区线损电量对比核查报表结构特征:- 同时调用
getUserElectricList与getTqLinelossInfoListRank - 页面内做数据拼接、按
TG_NO / CONS_NO关联用户和台区数据 - 导出字段同时含台区维度和用户维度,如
TG_NO / TG_NAME / consno / thisMonth / beforeMonth1结论: - 该组更像“主链路 + 明细补查 + 拼接报表”
- 与
G2-C有相似性,但最终产物比G2-C更偏“核查对比报表”而不是简单主链路恢复
-
G2-F 异常诊断 / 下钻型代表样本:线损大数据-窃电分析结构特征:- 先取
getTqLinelossInfoListRank - 再调用
tqAutoDiagnoseAnalyse/search、stealElecAnalyse/getFlqdyhDetailList、stealElecAnalyse/userVoltsAndElecflowMoniter/search - 页面中通过多次诊断接口拼装
remark - 导出字段核心列为
TG_NO / LOSS_PQ / LINELOSS_RATE / remark结论: - 该组属于“线损主表筛选后进入异常诊断和明细下钻”的复合流程
- 二次、三次请求显著多于
G2-C,复杂度高于本轮已落地三类
4. 本轮实施映射
按当前 plan 的 Phase 3 约束,本轮只选择最容易形成“分组复制”的 1 到 2 个新增家族,不做全量铺开。
优先级排序如下:
P0: G2-D 预测计算型原因:- 有两个结构高度相似的真实样本
- 页面内计算逻辑清晰,字段也相对稳定
- 可以形成新的最小合约和新的 fixture 组
P1: G2-E 核查对比型原因:- 虽然只有一个当前样本,但和现有
G2-C最接近 - 适合作为“主链路 + 关联补查”方向的下一扩展
- 虽然只有一个当前样本,但和现有
P2: G2-F 异常诊断 / 下钻型原因:- 链路最长,remark 拼接和异常判断逻辑较重
- 适合放在本轮后半段,优先做候选验证而不是一步做满
5. Phase 3 前置可行性结论
在进入实际实现前,对 G2-D 两个真实样本再次核查后确认:
线路月度高负损预测台区线损台区月度高负损预测
这两类页面虽然具备稳定的预测结果字段和 reportType,但当前源码里几乎只体现为:
- 本地读表或页面内计算
localhost:13313导出与报表日志依赖- 没有足够稳定的线损业务接口可抽成当前生成器的请求链路
因此,本轮实现不强行把 G2-D 塞进现有请求驱动编译链,而是将其保留为“候选组”,等待后续补齐“本地计算 / 文件输入型 skill”能力后再做。
据此,本轮实际实施顺序调整为:
- 先实现
G2-E - 再实现
G2-F G2-D暂停在候选验证阶段
6. Phase 1 退出结论
本轮线损扩展已经从“按单场景修补”切换到“按家族分组推进”:
- 已冻结
G2-A/G2-B/G2-C基线,不再回头重做主样本修补。 - 已识别出后续新增的三个线损变体方向:
G2-D/G2-E/G2-F。 - 经可行性核查后,本轮实际实现顺序固定为:
- 先做
G2-E - 再做
G2-F G2-D保留为下一阶段候选组
- 先做