feat: add generated scene skill platform hardening

This commit is contained in:
木炎
2026-04-21 23:19:06 +08:00
parent 118fc77935
commit 956f0c2b68
439 changed files with 61974 additions and 3645 deletions

View File

@@ -0,0 +1,217 @@
# 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 画像稳定后,才进入后续整改或更大范围迁移。