137 lines
5.9 KiB
Markdown
137 lines
5.9 KiB
Markdown
# 线损家族变体分组报告
|
||
> 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` 保留为下一阶段候选组
|