回归清单须基于git diff真实变更文件生成，聚焦test/、/api/v2/、/src/store/路径及含// todo: regression的代码行；强制绑定bug-4821、bug-4903验证；动作按文件或用户旅程驱动，每步明确动词、对象、断言；跳过规则写死并附可验证依据；输出为严格字段顺序的纯文本表格，行数=符合条件文件数×2。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
你需要让通义千问生成测试回归清单，但每次输出都堆砌“全面覆盖”“重点保障”“确保稳定”这类空转套话，清单里既没具体模块名、也没明确跳过条件、更不标出上一轮阻塞Bug的编号，开发拿到就皱眉——根本没法直接执行。
锁定回归范围：用真实交付物反推
打开你刚发版的Git Release Tag（比如v2.3.1），在命令行运行git diff v2.2.0 v2.3.1 --name-only，把输出结果粘贴进提示词开头。模型会据此识别实际变更文件，而不是凭空编造“核心模块需回归”这种废话。
从diff结果里手动圈出3类必回归项：【含test/或__test__.py的文件】→【路径含/api/v2/或/src/store/的JS/TS文件】→【被修改且带// TODO: regression comment的行】。这三类之外的文件，默认跳过，不写“酌情评估”这种模糊指令。
把上一轮测试阻塞的Bug编号（如BUG-4821、BUG-4903）直接写进提示词：“必须验证BUG-4821修复后订单状态机是否仍能响应支付超时事件；必须复测BUG-4903关联的地址簿导入导出链路”。漏掉任一编号，清单即失效。
定义回归动作：动词+对象+验证方式
方法一：按文件路径驱动
对每个被修改的API路由文件（如src/api/order.js），强制生成三行动作：
① 调用POST /api/v2/order/create → 输入含promotion_code字段的JSON → 断言返回code=0且data.order_id长度为16位字符串；
② 调用GET /api/v2/order/{id} → 传入上步返回的order_id → 检查response.data.status值是否为“pending”；
③ 调用PUT /api/v2/order/{id}/cancel → 传入相同order_id → 验证DB中orders表对应记录updated_at是否更新、status是否变更为“canceled”。
方法二：按用户旅程驱动
只保留真实线上高频路径，例如：
游客→填手机号获取验证码→输入6位码登录→进入个人中心→点击“我的优惠券”→下拉刷新→确认列表首条券状态为“可使用”。
每一步必须标注前端触发动作（如“点击‘获取验证码’按钮”）和后端验证点（如“检查sms_log表新增1条记录，content含‘【XX平台】您的验证码是’”）。
【严禁出现“检查功能是否正常”这种描述——它无法执行，也无法证伪】
声明跳过逻辑：写死条件，不许留白
直接在提示词里写明跳过规则，且每条规则附带可验证依据：
• 若某组件文件（如src/components/ChartCard.vue）自v2.1.0以来未被git blame标记过任何提交，则跳过其所有子组件回归；
• 若某接口在Swagger文档中标注deprecated=true，且last_modified_date早于2026-05-01，则跳过该接口所有用例；
• 若某页面路由（如/router/index.js中/old-report）在Sentry错误统计中过去30天0报错、PV＜50，则整页跳过。
所有跳过项必须在清单末尾单列一栏“Skip Reason”，写清依据来源（如“依据git blame -n src/components/ChartCard.vue第1行输出：2025-11-12 abc1234 feat: init chart card”）。
输出格式硬约束
要求千问输出纯文本表格，字段顺序固定为：模块路径|接口/页面|操作步骤|验证方式|Bug关联|Skip Reason。字段间用|分隔，禁止换行、禁止空格填充、禁止加粗或颜色。
第一行必须是表头，第二行起每行一条回归项，总数严格等于diff中符合前述三类条件的文件数×2（每个文件至少生成2条动作）。少于或多出任意一行，即判定为无效清单。
示例行：src/api/user.js|GET /api/v2/user/profile|1. 登录后调用接口 → 2. 检查Authorization header含Bearer token|断言response.data.avatar_url以https://cdn.example.com开头|BUG-4821|无
