# R1 真实样本分析：台区线损大数据-月_周累计线损率统计分析

日期：2026-04-18

样本来源：`D:\desk\智能体资料\全量业务场景\一平台场景\台区线损大数据-月_周累计线损率统计分析`

生成输出：`examples/real_scene_batch_round1/skills/real-tq-lineloss-report-r1`

对标基线：

1. `tq-lineloss-report`
2. `P0-1 multi_mode_request.month_week_table`
3. `docs/superpowers/reports/2026-04-17-integration-test-report.md`

## 1. 执行结果

已完成一次真实生成，生成命令成功返回，产物已写入仓库内独立目录。

本次结论不是“生成失败”，而是“生成成功但业务语义恢复失败”，因此当前样本不能进入后续内网验证。

## 2. 结果等级

综合判断：`不通过`

原因：

1. archetype 判错
2. bootstrap 选错
3. endpoint 污染严重
4. modes 未恢复
5. request contract 未恢复
6. column defs 未恢复
7. 生成脚本不可达到 `tq` 级别业务语义

## 3. 与目标基线的核心偏差

### 3.1 archetype 误判

目标应接近：

- `multi_mode_request.month_week_table`

实际生成结果：

- `paginated_enrichment`

直接证据：

- `references/generation-report.md` 中写明 `Workflow archetype: paginated_enrichment`
- `references/generation-report.json` 中 `workflowArchetype = "paginated_enrichment"`
- 生成脚本中出现固定 `paginate -> secondary_request -> filter` 主链

影响：

1. 生成器把“月/周双模式报表”错误理解为“分页主列表 + 二次补数”
2. 后续 request builder、response parser、artifact 结构都会沿错误路径展开

### 3.2 bootstrap 落点偏离 `tq` 主业务面

目标基线：

- `tq-lineloss-report` 的 `scene.toml` 将 bootstrap 锚到 `20.76.57.61`
- `target_url` 指向线损业务页面入口

本次生成结果：

- `expected_domain = "20.77.115.36:31051"`
- `target_url = "http://20.77.115.36:31051"`

影响：

1. 生成器把其他页面/系统入口误当成主业务承载面
2. 即使后续请求里碰巧抓到线损接口，运行时 page context 也可能不匹配

### 3.3 endpoint 污染严重

目标状态：

- 只保留与线损月/周统计直接相关的主业务接口

本次生成结果：

1. 虽然抓到了 `getYearMonWeekLinelossAnalysisList`
2. 也抓到了 `fourVerEightHorLinelossRateList`
3. 但同时混入了大量无关 endpoint，包括：
4. 95598 工单接口
5. 其他业务系统登录页
6. 各类第三方库、文档、GitHub、StackOverflow 链接
7. `pako/jszip` 等静态资源里的外部 URL

影响：

1. endpoint candidate 污染后，主链排序会失真
2. 生成器最终把 `API_ENDPOINTS[0]` 和 `API_ENDPOINTS[1]` 当作主请求与补请求，但这只是“列表里前两个”，不是业务上正确的月/周接口矩阵

### 3.4 modes 完全未恢复

目标状态：

- 至少应恢复 `month/week` 模式
- 至少应恢复 mode switch field
- 至少应为不同模式恢复不同 request/column/response 口径

本次生成结果：

1. `scene.toml` 中没有模式结构
2. `generation-report.json` 中 `modes = []`
3. 虽然 `defaultMode = "month"`、`modeSwitchField = "period_mode"` 被挂上了默认值
4. 但实际脚本没有 `MODES`、没有 `detectMode()`、没有分模式请求

影响：

1. 这是最核心的语义缺失
2. 当前生成物本质上无法表达 `tq` 场景的主业务结构

### 3.5 request contract 未恢复

目标状态：

- 月模式与周模式应分别拥有独立请求体
- 应恢复关键字段，例如 `orgno`、`tjzq`、`level`、`rows`、`page`、`sidx`、`sord` 以及周期相关字段

本次生成结果：

1. `requestTemplate = null`
2. `params = []`
3. 脚本中的 `buildRequest()` 直接把 `args` 全量 `JSON.stringify`
4. 没有 mode-specific builder
5. 没有月/周不同字段

影响：

1. 请求合同没有闭合
2. 即使接口名对了，也无法形成正确请求

### 3.6 response 与列定义未恢复

目标状态：

- 线损月模式、周模式应各自拥有明确列定义
- 至少应恢复 `content` 路径和 mode-specific columns

本次生成结果：

1. `responsePath = "content"` 这一点是对的
2. 但 `columnDefs = []`
3. `normalizeRules.requiredFields = []`
4. 最终脚本用 `rows[0]` 的 key 动态拼 `column_defs`

影响：

1. 缺少业务列语义
2. 缺少 required field 约束
3. 无法达到 `tq` 基线中的导出与报表结构稳定性

## 4. 这次生成暴露出的真实问题

### 4.1 不是“完全识别不到线损”

本次结果说明，系统并不是完全抓不到线损语义。

正向信号仍然存在：

1. 抓到了 `branch_fields=tjzq, mode, week, month`
2. 抓到了线损核心接口名
3. 抓到了 `responsePath = content`

这说明底层“有感知”。

### 4.2 但当前仍停在“信号能抓到，主链不会重建”

也就是说：

1. 能看到线损相关 endpoint
2. 能看到 month/week 字样
3. 但不会把这些信号重建成 `multi_mode_request.month_week_table`
4. 反而被分页、补数、过滤等噪声信号夺走主导权

### 4.3 readiness=A 目前不可信

本次样本虽然给了 `Readiness: A`，但实际核心合同大量缺失。

这说明当前 readiness 仍偏结构乐观，不能代表“可运行”或“接近内网可运行”。

## 5. 当前是否可以进入内网验证

结论：`不可以`

原因很直接：

1. archetype 错
2. bootstrap 错
3. modes 空
4. request contract 空
5. column defs 空

在这五项没有过关前，进入内网验证只会得到伪失败结果，没有业务验证价值。

## 6. 对后续批量迁移的含义

这次真实样本验证说明：

1. 当前链路已经具备“从真实场景中抓取部分业务信号”的能力
2. 但还不具备“自动重建 `tq` 级主业务语义”的能力
3. 因此不能直接把 102 个场景送去大规模生成
4. 必须先把 `G2` 主样本的 archetype/mode/request/column 四件套打透

## 7. 下一步建议

下一步仍严格按既定 plan 走，不扩散：

1. 继续生成 `白银线损周报`
2. 再生成 `线损同期差异报表`
3. 对比这两个 `G2` 扩展样本是否复现同类偏差
4. 输出一份 `G2` 家族首轮 blocker 汇总

只有当 `G2` 家族的 blocker 画像稳定后，才进入后续整改或更大范围迁移。