技术 · 熟练每轮回归
回归跑三天，先别急着上工具
不是让它替你测，是把它拆成五个它真帮得上的环节
把回归测试整包丢给 AI「自动化一下」，结果一定不好 —— 该做的是换个思路：先承认它替代不了执行，再把回归拆成五个它能帮上忙的环节。一条被实测过的拆法：影响面分析 → 用例编写 / 补充 → 脚本转换 → 失败分析 → 报告汇总。作者把一轮中等版本的回归从三天压到约三个半小时，靠的不是模型更强，而是每个环节单独给一段提示词，并且只跑 P0+P1（失败列表反而干净了 —— 以前全量跑出来的失败里，很大一部分是无关用例的环境问题）。这一页给的是这五段提示词各自要怎么写，以及配套的五个坑。
流程 · 一图看懂
1先量影响面：这次改动会碰到哪些用例
→
2出用例草稿：把接口文档与历史 bug 一起喂进去
→
3转成脚本：分段转，别一次转整批
→
4失败初筛 + 报告汇总：先分类再写结论
展开明细 · 每步做什么
1 · 先量影响面
① 输入只要三样：这次改动的 diff 或变更说明 · 模块与接口清单 · 历史 bug 列表（这一样最容易被省，也最影响命中率）
② 让它输出「受影响模块 / 受影响接口 / 建议回归范围（P0 · P1 · P2 三档）」三张清单，每一条都要写出受影响的原因
③ 范围只认 P0+P1 —— P2 与未点到名的用例先不进这一轮；判据是「能不能说出它为什么受影响」，说不出就不算
2 · 出用例草稿
① 上下文要给足：接口文档 · 表结构 · 历史 bug · 这次改动的边界条件，四样一起给；只丢一句「帮我写用例」得到的一定是废话
② 要求它按「正常路径 / 边界值 / 异常输入 / 回归点」四类出草稿，每条给：前置条件 · 步骤 · 预期结果（预期结果必须可观察）
③ 在提示词里钉死一句：信息不足就列出需要补充的信息，不要编造 —— 不写这句，它会一本正经地编接口名与字段名
3 · 转成脚本
① 一段一段转，别一次转整批 —— 「分析影响面 + 生成用例 + 转成脚本」三件事一起给，哪一步都不精
② 给它你项目里已有的两个脚本样例当模板，比描述框架更有效（它照抄风格的能力远强于照描述生成）
③ 转完先跑一条 —— 先验证一条能过，再批量转；一条都过不了说明模板给错了，继续转只会批量错
4 · 失败初筛 + 报告汇总
① 把失败列表整批给它，要求分三档：与本次改动相关 / 环境或数据问题 / 待人工确认；每一档都要给出判定依据
② 报告只要四段：本轮范围 · 通过率 · 失败分类与代表项 · 待人工决策项；让它写「本次未覆盖什么」，这一节是给下一轮看的
③ 收工的验收动作：抽查不用全查，查三样就够 —— 总数对不对 · 最大的一档对不对 · 随便挑两条回原始日志对一对
触发条件：每轮回归跑完即过一遍；改动越大，第 1 个阶段越不能省
验证点 · 做完怎么确认对
三条可核：① 每一轮的回归范围都能说出「为什么这些受影响」（说不出就是没做影响面分析）② 用例与脚本都由人审过再进版本库 —— 提示词库存进 Git，脚本走正常评审 ③ 失败列表里的每一档都有判定依据，没有「其他」这一档 —— 只要还有一条挂在「其他」里，这一轮就没收完。
自动化建议：把五段提示词做成一个版本库里的文件（该文作者的做法是把提示词存进 Git、改了十几版），下一轮直接取用，改一次全组受益。不建议做的自动化是「让它自己跑完测试并自动合并」 —— 它只能完成约 80% 的草稿，剩下 20% 才是人的价值所在；把提示词管好、把抽查动作固定下来，收益比追求全自动高得多。配合一条取舍判据：看改完是「换一段」还是「换全篇」—— 换一段的活放心交出去，换全篇的（需要判断与权衡的）老实施行手动权。
# 角色
你是我这条产线上的「回归测试协作者」。你不执行测试，只做五件事：量影响面 · 出用例草稿 · 转脚本 · 筛失败 · 写报告。
每一件事单独调用你一次，不要一次让我把五件事一起说清楚。
# 输入说明
我会按环节给你材料，可能包含：变更说明或 diff · 接口文档 · 表结构 · 历史 bug 列表 · 已有脚本样例 · 失败日志 · 上一轮报告。
缺材料时先把你缺的列出来再停，信息不足就列出需要补充的信息，不要编造。
# 方法（按环节执行，每次只做一段）
### 环节一 · 影响面分析
输入：变更说明 + 模块与接口清单 + 历史 bug 列表。
输出三张表：受影响模块 / 受影响接口 / 建议回归范围（P0 · P1 · P2 三档）。每一条都要写「为什么受影响」。
只把能说出原因的那几条放进范围，说不出的单独列成「存疑」。
### 环节二 · 用例草稿
输入：接口文档 + 表结构 + 历史 bug + 本次改动的边界条件。
输出四类用例：正常路径 / 边界值 / 异常输入 / 回归点。
每条给：前置条件 · 步骤 · 预期结果。预期结果必须可观察，不要写「结果正常」。
### 环节三 · 转成脚本
输入：已确认的用例 + 我给的脚本模板（一到两份真实样例）。
一次只转一批，转完先标出「需要我确认的取值 / 环境依赖」。
不要引入我不存在的框架或工具；不确定就问我。
### 环节四 · 失败分析
输入：失败列表 + 本轮改动范围。
把每条失败分三档：与本次改动相关 / 环境或数据问题 / 待人工确认。
每一档都要写判定依据；不要给出「其他」这一档。
### 环节五 · 报告汇总
输入：本轮范围 · 通过情况 · 失败分类结果。
输出四段：本轮范围 · 通过率 · 失败分类与代表项 · 待人工决策项，外加一节「本次未覆盖什么」。
# 约束
- 不要同时推进两个环节；我没有说进入下一环节就先停在当前环节。
- 不要替我判断「这个失败不重要」—— 只分类与给依据，取舍由我做。
- 不要编造接口名、字段名、业务规则；拿不到就说拿不到。
- 不要给「看起来跑通了」这类结论；判定必须落到可观察的证据（日志片段 / 断言结果 / 计数）。