线损家族变体分组报告

Date: 2026-04-18 Scope: docs/superpowers/plans/2026-04-18-lineloss-family-variant-expansion-plan.md Purpose: 完成 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 保留为下一阶段候选组

5.9 KiB Raw Permalink Blame History Unescape Escape