codeium需精准锁定回归范围：第一步锚定变更实体与上下游契约，第二步强制分层输出并绑定验证动作，第三步排除无风险区且限定输出粒度。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
要让Codeium输出的回归范围说明精准锁定本次发布影响边界，而不是堆砌“需覆盖核心链路”“建议全量回归”这类空洞表述，必须切断它默认调用通用质量保障话术的路径——它不会主动识别你改的是支付超时逻辑还是灰度开关配置，更不会知道订单履约服务和风控引擎之间存在强耦合依赖。
第一步：锚定变更实体与上下游契约
在提示词开头直接粘贴本次发布的最小变更单元，例如：【src/services/payment/TimeoutHandler.ts、config/feature-flags.json 第47行】。这一步不可省略，Codeium无法从commit message中提取出“timeoutMs字段从3000改为5000”这种关键数值变动。
紧接着用箭头链明确写出该变更触发的数据流终点：“TimeoutHandler.setDeadline() → OrderFulfillmentService.execute() → WMSAdapter.sendPickupRequest() → 仓库拣货系统告警看板”。没有这句，Codeium大概率只会罗列TimeoutHandler的单元测试，漏掉WMSAdapter因超时阈值变化导致的重试风暴风险。
补充一句硬性约束：“所有提及的模块名、方法名、配置项名必须与代码库中完全一致，禁止使用‘相关服务’‘下游系统’等模糊指代。”
第二步：强制分层输出并绑定验证动作
方法一：用符号锚点控制结构输出
请严格按以下三级结构输出，每级以“◆【直接影响】”“◆【间接影响】”“◆【潜在跨域影响】”开头，每组仅列模块+验证动作（不写步骤），每项前加“✓”：
◆【直接影响】
✓ TimeoutHandler.setDeadline() 输入3000/5000/8000三档值，断言deadline计算结果
✓ feature-flags.json中payment_timeout_ms字段修改后，应用启动时加载值为5000
◆【间接影响】
✓ OrderFulfillmentService.execute() 在timeoutMs=5000时，触发WMSAdapter重试次数从1次升为3次的边界验证
✓ 仓库拣货系统告警看板中“超时未响应订单数”指标在压测场景下增幅是否突破阈值
◆【潜在跨域影响】
✓ 风控引擎中RuleEngine.checkOrderRisk()是否仍能正确解析TimeoutHandler返回的error code格式
✓ 支付网关回调通知中timeout_reason字段是否被上游误判为“网络异常”而非“业务超时”
第三步：排除已知无风险区并限定输出粒度
第一步：列出本次无需回归的模块清单
以下模块近期无变更且与timeout逻辑无共享状态或调用关系，本次回归说明中禁止出现：
src/store/modules/user.ts
src/assets/icons/
src/router/index.ts（守卫逻辑不依赖超时配置）
第二步：限定输出必须可执行
所有验证动作必须满足：① 能通过现有测试框架直接运行（匹配Jest describe/it命名或Cypress cy.visit()结构）；② 不引入新mock或新工具类；③ 验证目标字段名与代码中完全一致（如timeoutMs非“超时毫秒数”）。【若某项验证需新增测试桩或修改已有fixture，则该项自动剔除】
