回归范围必须严格限定在三类边界内：① Git diff 标出的含 /test/、/api/v3/、/src/composables/ 路径或含 // REGRESS REQUIRED 注释的文件；② 基于 INC-20260708-012 根因推导出的 3 个风险扩散层（字段依赖、状态机跃迁、调用链路）；③ 按服务调用链分级锁定：① 级强验证、② 级弱验证、③ 级跳过。

想让通义千问生成一份能直接嵌入测试方案文档、明确界定本次回归边界、避免“核心模块全量覆盖”这类无效描述的回归范围说明？关键是用好提示词，而不是靠人工二次筛选或口头补充。

用 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 拉取日志但未改动任何字段。

模型输出时，必须用“→”串联调用路径，且每个层级只保留一个真实服务名和一个真实方法名，禁止出现“相关服务”“周边模块”等虚词。