Cursor 最小回归集：AI 改代码前，先把 10 条必测用例钉住

很多团队第一次把 Cursor 用到真实项目里，最容易犯的错不是“提示词写得不够好”，而是没有先定义回归边界。

于是你会看到这类情况：

登录页样式修好了，但埋点没了
列表排序加上了，但分页错乱了
组件重构更干净了，但移动端按钮点不到

本质上，AI 改代码的风险和人工改代码一样，甚至更大：它执行快，所以越需要先定义验证面。

结论先说：最小回归集不是“全量测试”，而是守住高风险断点

最小回归集的目标，不是覆盖所有可能性，而是用最低成本守住最容易出事故的关键链路。

回归层	关注点	最低要求
页面层	页面能否正常打开	关键入口不白屏、不报错
交互层	主流程能否完成	CTA、表单、筛选、提交可用
数据层	请求与状态是否正确	不多发、不漏发、不写坏
布局层	样式是否明显回退	关键断点不破版
指标层	性能与日志是否异常	无新增 console error，核心指标不过度退化

如果你每次 AI 改动都能守住这 5 层，绝大多数“改对局部、破坏整体”的问题都能提前拦下。

为什么 AI 改动更需要“先定断言，再写代码”

传统开发里，很多人习惯先改、再测；而在 AI 协作里，这个顺序通常会放大成本。

原因很简单：

$$ AI\ 的生成速度 > 人类\ 的逐行审查速度 $$

当输出速度远大于审查速度时，你唯一能降低风险的方法，就是先把“什么算通过”写清楚。

如果没有断言，Review 会退化为：

“大概没问题”
“页面看起来还行”
“先合了再说”

而这些说法，最后通常都会变成线上事故的前奏。

最小回归集的 10 条必测用例

下面这 10 条，不是理论模板，而是适合大多数前端/建站/内容站项目的基础版本。

1. 关键页面可打开

首页
核心落地页
关键详情页
404 / 异常页

2. 首屏主 CTA 可点击

按钮可见
链接正确
点击后行为符合预期

3. 表单可提交流程正常

正常提交
异常提示
必填校验
提交成功后的反馈

4. 列表/筛选/排序不回退

默认列表可渲染
筛选后结果正确
排序不会打乱分页或统计

5. 路由与导航无断链

顶部导航
页脚导航
文章内链
面包屑与返回路径

6. 关键埋点或日志不丢失

CTA 点击埋点
表单提交事件
页面曝光事件

7. 响应式断点不破版

375px 手机
768px 平板
1280px 桌面

8. 数据请求无新增异常

无重复请求
无 4xx/5xx 异常激增
加载态与错误态仍可用

9. 控制台无新增错误

console error
hydration warning
资源加载失败

10. 性能不过度退化

首屏 LCP 无明显上升
关键资源体积未异常膨胀
长任务数未明显增加

这 10 条已经足够构成一个实用的“最小回归集”。对中小团队来说，它比追求完美测试体系更现实。

把回归集按任务类型拆开，成本会更低

不同任务，最小回归集不该完全一样。

任务类型	应重点验证	可降低优先级
UI 样式调整	断点、CTA、视觉回退	深层数据逻辑
表单与交互改动	提交、校验、异常提示	大范围样式扫描
数据请求改动	请求成功率、状态一致性	静态图文内容
SEO/内容改动	title、description、内链、H1	复杂业务交互
多文件重构	路由、状态、公共组件回归	非核心边缘页

这张表的意义是：

不要每次都从零想“测什么”，而是按任务类型调用对应回归子集。

推荐工作流：Cursor 改动前后各做什么

改动前

写明允许修改的文件范围
指定本次最小回归集
把“必须人工确认”的项单独列出

改动中

要求 Cursor 先输出计划
每次只改 1~2 个文件
每一步都说明潜在影响面

改动后

先跑最小回归集
再看 diff 是否越界
最后才决定是否合并

如果你把顺序反过来，通常会浪费大量时间在“先看了一大堆改动，再倒推要测什么”。

可直接复制的回归说明模板

## Minimal Regression Suite

### 必测页面
- /
- /pricing
- /contact

### 必测交互
- Hero CTA 可点击
- 联系表单成功/失败路径可走通
- 导航跳转无错误

### 必测设备
- Mobile 375px
- Tablet 768px
- Desktop 1280px

### 必测质量项
- 无新增 console error
- 无关键资源 404
- 首屏无明显视觉回退

把这一段直接放进任务单、PR 描述或 AI 指令里，都能显著减少“说了要验证，但没人知道具体验什么”的问题。