AI 生成代码最危险的一点，不是“写错”，而是“局部正确、全局回归”。
所以你需要的不是更多“感觉不错”，而是固定回归集。
这篇尤其适合两类读者：
- 没有完整自动化测试、但 AI 改动已经很多的小团队
- 有测试意识，但每次上线前总靠“手感检查”的开发者
结论先说：至少跑 10 条最小回归用例
| 类别 | 用例数 | 目标 |
|---|---|---|
| 核心功能路径 | 3 | 保证主流程可用 |
| 边界与异常 | 3 | 防止输入或状态越界 |
| 兼容与性能 | 2 | 防止体验下降 |
| 回滚与可维护性 | 2 | 防止不可逆改动 |
为什么 AI 改动特别容易回归
AI 倾向于“局部最优”：
- 看到当前文件上下文能跑，就认为任务完成
- 不一定知道跨页面依赖、隐式状态、历史约定
如果没有回归集，评审只能靠主观经验。
最小回归集（可直接复制）
A. 核心功能（3 条）
- 主路径可完成（从入口到成功反馈）
- 关键按钮/表单可交互（禁用态、loading 正确）
- 核心数据读写一致（刷新后状态符合预期）
B. 边界异常（3 条）
- 空输入/非法输入处理正确
- API 异常时有可恢复提示（重试/回退）
- 并发点击不会重复提交或状态错乱
C. 兼容性能（2 条）
- 首屏无明显劣化（关键指标不退步）
- 移动端核心交互可用（点击区域/滚动）
D. 回滚维护（2 条）
- 改动文件范围符合预期（无越界修改）
- 可按文件/模块回退（不影响无关功能）
回归优先级矩阵：先测什么，后测什么
如果每次改动都“全量深测”，团队很快会疲劳。建议按风险优先级分层执行。
| 风险等级 | 触发条件 | 必测项 | 允许放后项 |
|---|---|---|---|
| P0 | 登录/支付/核心提交链路改动 | 1~6 + 9 + 10 | 7~8 可后置 |
| P1 | 页面交互与状态改动 | 1~6 + 8 + 9 | 7 可抽样 |
| P2 | 文案/样式微调 | 1 + 2 + 9 | 其余按需 |
核心原则：不是“测得越多越好”，而是“高风险先覆盖”。
执行节奏建议：15 分钟快速回归法
适用于日常高频 AI 改动：
- 第 0~3 分钟：确认变更范围（文件与模块）
- 第 3~10 分钟：执行用例 1~6（功能与异常）
- 第 10~13 分钟：执行 9~10（可维护与回滚）
- 第 13~15 分钟：记录结论与阻断项
如果任一 P0 用例失败，直接阻断合并，不进入“再看看”。
与发布流程对齐：回归结果怎么写进 PR
## Regression Summary
- Covered Cases: T-01, T-02, T-03, T-04, T-05, T-06, T-09, T-10
- Failed Cases: None
- Risk Level: P1
- Rollback Plan: Revert files A/B/C
- Decision: Ready for merge
把回归结论结构化后，评审成本会明显下降，责任边界也更清晰。
建议给 10 条用例固定编号
| 编号 | 用例 | 默认优先级 |
|---|---|---|
| T-01 | 主流程成功 | P0 |
| T-02 | 按钮/表单状态 | P0 |
| T-03 | 数据读写一致 | P0 |
| T-04 | 空输入/非法输入 | P0 |
| T-05 | API 异常恢复 | P0 |
| T-06 | 重复点击/并发提交 | P0 |
| T-07 | 首屏性能不退化 | P1 |
| T-08 | 移动端核心交互 | P1 |
| T-09 | 改动范围未越界 | P0 |
| T-10 | 回滚可行 | P0 |
一旦编号固定，团队沟通会更快：不再说“把那个异常也测一下”，而是直接说“补跑 T-05 和 T-10”。
从手工到半自动：小团队的升级顺序
如果你们现在完全靠手测，不必一步到位全自动，可以按下面顺序升级：
- 先固定 10 条手工回归编号
- 再把最稳定的 2~3 条主流程做成脚本
- 最后把 P0 项接入 CI 或发布前任务
这样做的好处是：先建立“统一标准”，再逐步提高执行效率，而不是反过来。
用例模板（推荐）
用例编号：T-05
目标：API 异常时可恢复
前置：模拟接口 500
步骤：提交表单 -> 观察错误提示 -> 点击重试
预期：提示可读；重试后可恢复；无死循环
如果你更想看真实场景，可以参考这个例子：
改动内容：AI 帮你重写了联系表单提交逻辑。
最少必跑项：T-01 主流程提交、T-02 loading 态、T-04 空输入、T-05 接口异常、T-06 重复点击、T-09 文件范围、T-10 回滚可行。
可以后置项：若没有改移动端布局，则 T-08 可放到第二轮。
失败案例：只测 Happy Path
症状：
- 主流程看似通过
- 线上用户网络抖动后提交失败且无法重试
根因： 回归集缺少“异常可恢复”测试。
修复：
- 补充异常态 UI 与重试逻辑
- 固化到 T-05，用作每次 AI 改动必测项
验收标准（DoD）
- 10 条最小回归全部通过
- 无新增 console error
- 关键指标无明显退化
- 改动范围与任务说明一致
- 回滚演练可在 5 分钟内完成
很多读者卡住的不是“不知道测什么”，而是“不知道哪些一定要先测”。这也是为什么风险分级比全量罗列更重要。
FAQ
Q1：没有自动化测试怎么办？
先做手动最小回归集，后续再逐步自动化。
Q2：每次都要跑 10 条会不会慢？
比线上故障排查快得多，尤其在 AI 高频改动场景。
Q3：怎么和 Cursor 配合？
先让它输出“本次对应的 10 条回归覆盖情况”，再执行。
Q4：失败用例可以“先合并后修”吗？
仅限 P2 级别且不影响主流程；P0/P1 失败应先修复再合并。
Q5：是不是每个项目都必须固定这 10 条？
不是必须原样照搬，但建议保留“主流程、异常、越界、回滚”这 4 类骨架。
小团队先做这 3 件事
- 固定 10 条最小回归编号，不再每次临时想
- 每次 AI 改动后先判定 P0/P1/P2，再决定测试范围
- 把回归结果写进 PR，不让测试结论停留在口头
