# 线损家族变体分组报告
> Date: 2026-04-18
> Scope: `docs/superpowers/plans/2026-04-18-lineloss-family-variant-expansion-plan.md`
> Purpose: 完成 Phase 0 / Phase 1 交付物，冻结当前线损家族基线，并建立后续扩展分组清单。

## 1. 当前已冻结基线

本轮扩展以前，线损家族中已经可稳定识别并生成的子型为：

1. `G2-A = g2_a_dual_mode_baseline`
   代表样本：`台区线损大数据-月_周累计线损率统计分析`
   特征：同一主链路下同时存在月 / 周两套模式，请求和列定义都较完整。
2. `G2-B = g2_b_weekly_single_mode`
   代表样本：`白银线损周报`
   特征：仍属于线损主链路，但只有周报单侧模式，需要用最小周报合约兜住生成。
3. `G2-C = g2_c_mixed_linked_workflow`
   代表样本：`线损同期差异报表`
   特征：主链路仍是线损查询，但同时联动外部系统或二次查询，只能先恢复主链路最小合约。

上述三类已经在上一轮回归中通过本地测试，并在真实样本重生成为候选 skill，不再回退到“只修主样本”的阶段。

## 2. 线损场景盘点结果

本次从 `D:\desk\智能体资料\全量业务场景\一平台场景` 中筛出的线损相关场景为：

1. `台区线损大数据-月_周累计线损率统计分析`
2. `白银线损周报`
3. `线损同期差异报表`
4. `台区零度户月度用电量与台区线损电量对比核查报表`
5. `线损大数据-窃电分析`
6. `线路月度高负损预测`
7. `台区线损台区月度高负损预测`
8. `供电所线路电量统计`
9. `线路失电信息明细`

其中 `8` 和 `9` 与当前线损主家族相关度较弱，不纳入本轮优先扩展对象。

## 3. 结构化分组

### 3.1 已落地组

1. `G2-A 双模式主报表型`
   代表样本：`台区线损大数据-月_周累计线损率统计分析`
2. `G2-B 周报单侧模式型`
   代表样本：`白银线损周报`
3. `G2-C 混合联动主链路型`
   代表样本：`线损同期差异报表`

### 3.2 新增候选组

1. `G2-D 预测计算型`
   代表样本：
   - `线路月度高负损预测`
   - `台区线损台区月度高负损预测`
   结构特征：
   - 页面内存在 `reportType = monthlyHighNegativeLossPredictionForLines` 或同类预测型标识
   - 结果并非直接来自标准 `cols1/cols2` 表头，而是先读取多个输入表或数据块，再在页面内计算 `lineLossRate / powerLoss / lineLossType`
   - 导出字段以“预测结果字段”为主，如 `lineId / lineName / lineLossType / lineLossRate / powerLoss`
   结论：
   - 这类不是传统 G2 主报表直接抽列，而是“取数 + 计算 + 导出”的计算型线损变体
   - 适合优先扩展，因为有两个高度相似样本，可做成同一家族

2. `G2-E 核查对比型`
   代表样本：
   - `台区零度户月度用电量与台区线损电量对比核查报表`
   结构特征：
   - 同时调用 `getUserElectricList` 与 `getTqLinelossInfoListRank`
   - 页面内做数据拼接、按 `TG_NO / CONS_NO` 关联用户和台区数据
   - 导出字段同时含台区维度和用户维度，如 `TG_NO / TG_NAME / consno / thisMonth / beforeMonth1`
   结论：
   - 该组更像“主链路 + 明细补查 + 拼接报表”
   - 与 `G2-C` 有相似性，但最终产物比 `G2-C` 更偏“核查对比报表”而不是简单主链路恢复

3. `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 个新增家族，不做全量铺开。

优先级排序如下：

1. `P0: G2-D 预测计算型`
   原因：
   - 有两个结构高度相似的真实样本
   - 页面内计算逻辑清晰，字段也相对稳定
   - 可以形成新的最小合约和新的 fixture 组
2. `P1: G2-E 核查对比型`
   原因：
   - 虽然只有一个当前样本，但和现有 `G2-C` 最接近
   - 适合作为“主链路 + 关联补查”方向的下一扩展
3. `P2: G2-F 异常诊断 / 下钻型`
   原因：
   - 链路最长，remark 拼接和异常判断逻辑较重
   - 适合放在本轮后半段，优先做候选验证而不是一步做满

## 5. Phase 3 前置可行性结论

在进入实际实现前，对 `G2-D` 两个真实样本再次核查后确认：

1. `线路月度高负损预测`
2. `台区线损台区月度高负损预测`

这两类页面虽然具备稳定的预测结果字段和 `reportType`，但当前源码里几乎只体现为：

1. 本地读表或页面内计算
2. `localhost:13313` 导出与报表日志依赖
3. 没有足够稳定的线损业务接口可抽成当前生成器的请求链路

因此，本轮实现不强行把 `G2-D` 塞进现有请求驱动编译链，而是将其保留为“候选组”，等待后续补齐“本地计算 / 文件输入型 skill”能力后再做。

据此，本轮实际实施顺序调整为：

1. 先实现 `G2-E`
2. 再实现 `G2-F`
3. `G2-D` 暂停在候选验证阶段

## 6. Phase 1 退出结论

本轮线损扩展已经从“按单场景修补”切换到“按家族分组推进”：

1. 已冻结 `G2-A/G2-B/G2-C` 基线，不再回头重做主样本修补。
2. 已识别出后续新增的三个线损变体方向：`G2-D/G2-E/G2-F`。
3. 经可行性核查后，本轮实际实现顺序固定为：
   - 先做 `G2-E`
   - 再做 `G2-F`
   - `G2-D` 保留为下一阶段候选组