需求变更转回归清单 (ym-change-regression-list)
把"这次改了什么"翻译成"上线前必须验一遍什么"。每个回归点都标明它受哪个变更点影响、怎么验证、优先级多高，而不是罗列一堆功能名。
何时使用
- 用户说「这个改动要测什么」「列个回归清单」「变更影响范围」「这次上线风险点」时
- 用户贴了一段改动说明、PR 描述、需求变更文档，问"还需要验哪些"时
- 用户做上线前评审、写测试计划，需要把变更映射到回归点的时候
运行前提
- 依赖：无第三方依赖，纯文本分析
- 不读取任何本地代码库或文件，除非用户明确给出片段或路径
- 不联网、不上传任何数据
输入契约
| 项 | 必需 | 说明 |
|---|---|---|
| 变更描述 | 必需 | 改了什么：自然语言描述、改动清单、涉及的接口/文件/表结构、或 diff 摘要 |
| 系统模块划分 | 可选 | 有哪些业务模块、服务、页面；缺则按通用 Web 应用分层推导并标注假设 |
| 相关接口/表清单 | 可选 | 已知接口、数据库表、定时任务、第三方依赖；有则推导更准 |
| 上线时间压力 | 可选 | 是否赶发版；影响"可跳过"档的判断口径 |
缺失处理：
- 只有模糊描述（如"优化了下单一块"）→ 先列出需要澄清的问题，同时给出基于常见结构的初步清单并标注"待确认"，不沉默跳过
- 无模块信息 → 按通用 Web 应用分层（接入层/业务层/数据层/调度/报表）推导，并标注"此为假设，待你确认"
- 变更描述与受影响面明显不匹配（如只改了文案却推导出大量回归点）→ 回头重读变更点，缩小范围
- 无任何变更信息 → 直接拒绝生成，列出需要提供的信息，绝不凭空编造模块
执行步骤
-
拆解变更点 — 把变更拆成原子项并编号（C1、C2…）：字段变更、接口变更、规则变更、状态流转、权限变更、数据迁移。这一步必须先做，后面每个回归点都要能回溯到某个 C 编号。
-
四方向推导影响面 — 对每个变更点，按
references/impact-four-directions.md的推导提问，过一遍四个方向：直接影响 / 上下游 / 数据面 / 非功能。任一方向判断不出，标"待确认"而不是猜。 -
生成回归点 — 每个回归点写四列：功能点 / 关联变更点（C 编号）/ 验证方式（手工、接口、脚本、数据核对）/ 优先级。优先级按第 4 步三档归类。
-
定优先级 — 三档：
- 必须回归：核心链路、资金与数据一致性、权限
- 建议回归：边缘功能、展示类、低频路径
- 可跳过：与改动无关联路径（仍列出并说明为何可跳过，便于评审人推翻）
- 上线时间紧时，"可跳过"可作裁剪依据，但必须在清单里保留并标注"因时间压力暂缓"。 -
补易漏项 — 套用
references/impact-four-directions.md的"最常被漏掉的检查项清单"（导出、定时任务、缓存、第三方回调、权限边界、空值与极值、历史单据展示、报表口径等），逐项核对本变更是否触发，触发的补进清单。 -
数据一致性核对 — 若涉及字段变更或数据迁移，单独列"数据一致性核对项"：存量数据条数、脏数据、历史单据展示、统计口径，并标注核对方式。
-
硬性约束核对 — 输出前确认：没有"测完就没问题"这类断言；没有编造系统里不存在的模块；所有无法判断的影响面都标了"待确认"。
输出格式
套用 templates/regression-checklist-template.md，Markdown：
一、变更点拆解（C1/C2…）
二、回归清单表（功能点 | 关联变更点 | 验证方式 | 优先级）
三、数据一致性核对项（如有）
四、最容易漏的三项
五、待确认问题
能力边界
- 不执行测试、不生成自动化测试代码（除非用户明确要求）
- 不接入项目代码库自动分析（除非用户给出代码片段）
- 不做性能压测、不做安全测试，非功能项只列"需验证"，不给结论
- 不保证覆盖所有隐藏依赖；标注为"待确认"的项需用户结合代码确认
常见坑
- 只列功能名不标关联 — 现象：清单写成"登录、下单、支付"一堆名词，看不出为什么验。原因：没做第 1 步变更点拆解。规避：每个回归点必须带 C 编号，写不清关联就标"待确认"。
- 漏掉数据面 — 现象：改了字段却没人验历史单据展示和报表口径。原因：只看了直接影响和上下游，忘了数据面方向。规避：第 5 步强制套易漏项清单，数据迁移必出核对项。
- 缓存和定时任务被忽略 — 现象：改了配置或逻辑，但缓存未刷新、定时任务仍跑旧规则导致线上异常。原因：非功能与调度类不在常见思维路径里。规避：易漏项清单里把"缓存失效""定时任务/批处理"列为固定检查项。
- 把"可跳过"写成"不用管" — 现象：直接删掉无关联项，评审人无法判断是否有遗漏。原因：把裁剪当成删除。规避：可跳过项保留在表里并注明跳过理由，方便上线压力时决策。
- 模糊描述硬编清单 — 现象：用户只说"优化了一下"，却产出十几条具体回归点。原因：缺少变更信息时仍在猜系统结构。规避：缺信息先出澄清问题，初步清单一律标"待确认"。
- 第三方回调与权限边界漏验 — 现象：改了下单逻辑，但支付回调、退款回调、越权访问路径没验。原因：上下游只想到同步调用，忽略异步回调和横向权限。规避：易漏项清单固定包含第三方回调、权限边界两行。
验收用例
- 正常：「订单新增优惠券字段」→ 覆盖下单、支付、退单、订单列表、导出、报表、历史单据展示，且每项带关联变更点与优先级
- 边界 1：「优化下登录」（模糊）→ 先出澄清问题，清单标"待确认"
- 边界 2：纯文案改动 → 回归点很少，明确说明影响面小，"可跳过"占多数
- 失败：无任何变更信息 → 拒绝生成，列出需要提供的信息
目录说明
references/— 影响面四方向推导表、最常被漏掉的检查项清单templates/— 回归清单输出模板（直接复制填充）scripts/— 已删除（本技能为纯文本分析，无需脚本）
