要让Codeium生成分层覆盖的回归测试清单，需三步：第一步锁定变更范围与依赖路径，粘贴git diff摘要并说明调用关系；第二步定义三级影响层级并强制分组输出；第三步排除已知稳定区且限定测试项须匹配现有框架结构。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
要让Codeium生成的测试回归清单真正按影响范围分层覆盖，不能只写“请生成回归测试清单”，必须明确告诉它哪些代码变动了、哪些模块可能被波及、哪些是核心路径。
第一步：锁定变更范围与依赖路径
在提示词开头直接粘贴本次提交的git diff摘要（或至少列出修改的文件路径），例如：【src/utils/dateFormatter.ts、src/api/orderService.ts、src/components/OrderSummary.vue】。这一步不可省略，Codeium无法自动推断你改了哪几行，更不会知道dateFormatter的输出被orderService和OrderSummary同时消费。
紧接着说明调用关系：“dateFormatter.format() 被 orderService.submitOrder() 调用，submitOrder() 的结果渲染到 OrderSummary.vue 的订单状态区域”。没有这句，Codeium大概率只会罗列单个文件的单元测试，漏掉跨组件的数据流验证。
第二步：定义影响层级并强制分组输出
用清晰的层级指令约束输出结构，避免它生成混在一起的扁平列表：
方法一：用符号锚点引导格式
“请按以下三级影响范围输出，每级用‘===【直接影响】===’、‘===【间接影响】===’、‘===【潜在全局影响】===’开头，每组下仅列测试项名称（不写步骤），每项前加‘●’：”
方法二：用动词限定验证深度
“【直接影响】：针对修改文件本身的行为验证（如dateFormatter.format(‘2024-03-15’)是否仍返回‘2024/03/15’）；【间接影响】：必须包含调用链下游的集成验证（如submitOrder()传入异常日期时，OrderSummary是否显示‘日期格式错误’）；【潜在全局影响】：检查所有引用dateFormatter的非直系文件（如src/router/index.ts中是否有守卫逻辑依赖其返回格式）。”
第三步：排除已知稳定区，聚焦风险点
主动声明“以下模块近期无变更且无共享状态，本次无需回归：src/store/modules/user.ts、src/assets/icons/”。Codeium默认倾向保守覆盖，不加这句话，它会把整个store目录都列进清单，浪费执行时间。
补充一个硬性过滤条件：“所有测试项必须能通过现有测试框架直接运行（即匹配 Jest/Cypress 的 describe/it 命名模式或 Playwright 的test.describe() 结构），禁止生成需手动构造mock的新用例。”
这一步做完，Codeium输出的清单就会严格落在变更引发的真实影响路径上，而不是凭空猜测。
