回归测试范围的确定，表面上看似乎很简单——修改了哪里，就测试哪里。但在实际编写测试方案时，很多人写出来的内容往往是“覆盖核心模块”“包含主要功能点”这类泛泛而谈的描述，测试人员看了等于没看，开发人员读了也是一头雾水。

要写出一份真正具备可操作性的回归测试范围说明，关键在于：用真实锚点，把模型框死。下面这四个步骤，均来自实战经验提炼，每一步都可以直接套用到你的测试方案中。

先锁定具体变更来源

打开本次需求或缺陷的原始文档，将影响模块、修改文件路径、关联接口名这三项手动摘录出来，逐行写入提示词开头。不要只写“根据需求文档”这种模糊表述——Gemini无法定位到具体哪一页哪一段。

这一步如果遗漏，后续所有细化工作都将是空中楼阁。模型无法判断你所说的“登录模块”是前端Vue组件还是后端Spring Boot的AuthController，给出的结果自然也无法直接落地使用。

用结构化指令替代模糊动词

另一个常见问题是：你让AI“说明范围”，它就会输出一堆“覆盖核心模块”这种空洞内容。正确的做法是，把指令转换为具体的输出格式要求。例如：“按以下格式输出，每项必填，缺项留空不补：①直接受影响页面/接口（列明URL或类名）→②间接受影响逻辑（描述调用链，如‘订单创建→触发积分计算→调用用户等级服务’）→③明确排除项（写清排除理由，例如‘支付回调通知未改动，且有独立幂等校验’）”。

动词越具体，输出越具有可执行性。“说明”“分析”“梳理”这类词等于没有要求——Gemini会按照自己理解的“说明”去应付，结果就是一堆正确的废话。

注入真实上下文锚点

更具工程感的做法是：粘贴一段真实的代码diff片段（不超过15行），加一句“以上是user-service模块中UserService.java第217-223行的修改，请据此推导回归范围”。这里有一个关键细节：必须带行号和文件路径。如果只写函数名如updateUser()，模型会误判作用域，将整个用户模块都划入范围。

另一个方法：提供本次发布的版本号加上前一版本号，写明“对比v2.3.1与v2.3.0的release note，提取其中标记为[IMP]或[BUGFIX]的条目，仅基于这些条目生成范围”。没有锚点的提示词，就像让快递员“送个东西到北京”却不给门牌号，他只能猜测。

强制分层输出并验证边界

最后这个步骤，是把笼统的范围拆解成可执行的清单。分三步走：

第一步，要求模型先输出“最小必要范围”——仅包含代码直接修改点及其紧邻调用方；

第二步，再输出“推荐扩展范围”——包含上下游强依赖服务、历史易出问题的同类功能；

第三步，给出每项范围的判定依据。例如“推荐扩展订单列表页：因本次修改了分页参数校验逻辑，而列表页是唯一消费该参数的前端页面”。

输出完成后，检查一下里面有没有出现“相关功能”“周边模块”这类词。只要出现，立刻删除并重写提示词——这是模型在编造借口的信号。