回归范围严格限定为：①git diff标出的含/test/、/api/v3/、/src/composables/路径或含// regress required注释的文件；②基于inc-20260708-012根因推导出的3个风险扩散层（字段依赖、状态机跃迁、调用链路）；③按服务调用链分级锁定：①级强验证、②级弱验证、③级跳过。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
你需要让通义千问生成一份能直接嵌入测试方案文档、明确界定本次回归边界、避免“核心模块全量覆盖”这类无效描述的回归范围说明，而不是靠人工二次筛选或口头补充。
用Git diff结果锚定真实变更面
打开本次发布的Release Tag（如v3.1.0），在终端执行：git diff v3.0.0 v3.1.0 --name-only，把输出结果完整粘贴到提示词最开头。这一步不能省——模型若没看到真实文件列表，会默认启用“订单/用户/支付”三模块泛化模板，漏掉你刚重构的/src/utils/date-format.js这种关键工具链。
从diff结果中手动标出三类必须纳入回归的路径：【含/test/或__test__.py的文件】→【路径含/api/v3/或/src/composables/的TS文件】→【被修改且含// REGRESS REQUIRED注释的行所在文件】。这三类之外的文件，模型必须跳过，不写“建议关注”“酌情检查”等模糊指令。
这一步操作起来很简单，直接复制终端输出，用Ctrl+F搜“.test.ts”“/api/v3/”“REGRESS REQUIRED”就能圈出全部目标。
按故障根因反向推导风险扩散层
把最近一次线上事故报告（SRE编号：INC-20260708-012）的根因分析段落原样粘贴进提示词，紧接一句：“请基于该段落，识别本次代码变更中可能复现相同故障路径的3个风险扩散层。”
方法一：字段依赖层
例如事故根因为“优惠券核销时未校验user_id与coupon_id绑定关系”，则模型必须输出：“src/api/coupon/use.ts → 传入coupon_id后未调用checkBinding(userId, couponId) → 需验证DB中coupon_usage表是否仍存在user_id为空的记录”。
方法二：状态机跃迁层
例如事故触发点为“订单从shipped误跳至cancelled”，则模型必须定位src/stores/order.ts中statusTransitionMap里被修改的分支，并强制写出：“当order.status === 'shipped'且cancelReason === 'logistics_failed'时，是否仍阻断transitionTo('cancelled')”。
注意：若事故报告中出现‘数据错乱’‘幂等失效’‘时序竞争’等关键词，模型必须在对应层输出中显式包含SQL语句或Promise.race()调用片段，否则视为范围遗漏。
按服务调用链路分级锁定验证深度
第一步：识别本次变更直接影响的上游调用方，标为①级（强验证）
第二步：识别被①级服务透传调用的下游服务，标为②级（弱验证）
第三步：识别仅被②级服务间接引用、且本次未修改其接口定义的模块，标为③级（跳过）
例如：本次修改了payment-service的/refund接口 → ①级：order-service调用该接口的refundOrder()方法；②级：notification-service通过payment-service的webhook接收退款成功事件；③级：reporting-service从notification-service拉取日志但未改动任何字段。
模型输出时，必须用“→”串联调用路径，且每个层级只保留一个真实服务名和一个真实方法名，禁止出现“相关服务”“周边模块”等虚词。
