claw/docs/superpowers/reports/2026-04-18-r1-real-tq-lineloss-analysis.md

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 画像稳定后，才进入后续整改或更大范围迁移。