AI 生成代码最危险的一点，不是“写错”，而是“局部正确、全局回归”。
所以你需要的不是更多“感觉不错”，而是固定回归集。
这篇尤其适合两类读者：
- 没有完整自动化测试、但 AI 改动已经很多的小团队
- 有测试意识，但每次上线前总靠“手感检查”的开发者
AI 倾向于“局部最优”：
- 看到当前文件上下文能跑，就认为任务完成
- 不一定知道跨页面依赖、隐式状态、历史约定
如果没有回归集，评审只能靠主观经验。
- 主路径可完成（从入口到成功反馈）
- 关键按钮/表单可交互（禁用态、loading 正确）
- 核心数据读写一致（刷新后状态符合预期）
- 空输入/非法输入处理正确
- API 异常时有可恢复提示（重试/回退）
- 并发点击不会重复提交或状态错乱
- 首屏无明显劣化（关键指标不退步）
- 移动端核心交互可用（点击区域/滚动）
- 改动文件范围符合预期（无越界修改）
- 可按文件/模块回退（不影响无关功能）
如果每次改动都“全量深测”，团队很快会疲劳。建议按风险优先级分层执行。
核心原则：不是“测得越多越好”，而是“高风险先覆盖”。
适用于日常高频 AI 改动：
- 第 0~3 分钟：确认变更范围（文件与模块）
- 第 3~10 分钟：执行用例 1~6（功能与异常）
- 第 10~13 分钟：执行 9~10（可维护与回滚）
- 第 13~15 分钟：记录结论与阻断项
如果任一 P0 用例失败，直接阻断合并，不进入“再看看”。
把回归结论结构化后，评审成本会明显下降，责任边界也更清晰。
一旦编号固定，团队沟通会更快：不再说“把那个异常也测一下”，而是直接说“补跑 和 ”。
如果你们现在完全靠手测，不必一步到位全自动，可以按下面顺序升级：
- 先固定 10 条手工回归编号
- 再把最稳定的 2~3 条主流程做成脚本
- 最后把 P0 项接入 CI 或发布前任务
这样做的好处是：先建立“统一标准”，再逐步提高执行效率，而不是反过来。
如果你更想看真实场景，可以参考这个例子：
改动内容：AI 帮你重写了联系表单提交逻辑。
最少必跑项：T-01 主流程提交、T-02 loading 态、T-04 空输入、T-05 接口异常、T-06 重复点击、T-09 文件范围、T-10 回滚可行。
可以后置项：若没有改移动端布局，则 T-08 可放到第二轮。
症状：
- 主流程看似通过
- 线上用户网络抖动后提交失败且无法重试
根因： 回归集缺少“异常可恢复”测试。
修复：
- 补充异常态 UI 与重试逻辑
- 固化到 T-05，用作每次 AI 改动必测项
很多读者卡住的不是“不知道测什么”，而是“不知道哪些一定要先测”。这也是为什么风险分级比全量罗列更重要。
先做手动最小回归集，后续再逐步自动化。
比线上故障排查快得多，尤其在 AI 高频改动场景。
先让它输出“本次对应的 10 条回归覆盖情况”，再执行。
仅限 P2 级别且不影响主流程；P0/P1 失败应先修复再合并。
不是必须原样照搬，但建议保留“主流程、异常、越界、回滚”这 4 类骨架。
- 固定 10 条最小回归编号，不再每次临时想
- 每次 AI 改动后先判定 P0/P1/P2，再决定测试范围
- 把回归结果写进 PR，不让测试结论停留在口头
发布者：Ai探索者，转载请注明出处：https://javaforall.net/243199.html原文链接：https://javaforall.net
