AI 生成 bug 最麻烦的一点，不是它会出错，而是它的错误往往跨越多个层次：
- 表面上是按钮没反应
- 实际上是参数结构被改了
- 更深层可能是某个默认值、边界条件或副作用位置被改动了
所以你不能只问“哪里报错”，而要把排查过程拉回工程视角：先看改了什么，再看为什么会影响行为，最后再确认根因。
如果你已经读过 Cursor 最小回归集、Cursor + 单元测试工作流、代码质量门禁与 CI 集成 和 Cursor 常见报错与排查，这篇会更聚焦在“AI 改完后出现 bug”这个场景。
一、先接受一个现实：AI 生成 bug 不等于 AI 完全不懂项目
很多 AI 生成 bug 的问题，并不是低级语法错误，而是“局部合理、全局失配”。
比如：
- 某个字段名在当前文件看起来没问题，但与接口契约不一致
- 某个函数抽出去后逻辑更干净，但调用顺序被改变
- 某个默认值看似更安全，结果改变了页面初始化行为
这类 bug 的特点是：代码能跑，但行为错了。
二、排查第一步永远不是猜，而是先看 diff
当你怀疑是 Cursor 引入了 bug，第一步要做的不是继续问它“帮我修一下”，而是先审视它到底改了哪些地方。
一个有效的 diff 审查顺序是：
- 新增了哪些逻辑分支
- 删除了哪些旧逻辑
- 参数名、返回值、默认值有没有变化
- 副作用位置有没有移动
很多 bug 的根因，其实在 diff 里已经露出来了，只是你还没建立固定的看法。
三、复现要尽量缩成最短路径
如果复现步骤太长，排查成本会迅速上升。
更好的方式是把问题压缩成：
- 前置条件是什么
- 做哪个动作会出问题
- 正常应该看到什么
- 现在实际出现了什么
一个例子：
“登录页输入正确账号密码，点击提交后按钮一直 loading，不会跳转首页。”
这就比“登录功能有问题”有用得多。
四、从现象回到边界：先判断 bug 落在哪一层
排查时建议先分层：
| 层级 | 常见问题 | 排查重点 |
|---|---|---|
| UI 层 | 按钮状态、文案、显示错乱 | 事件绑定、状态切换 |
| 业务层 | 提交逻辑、校验流程 | 参数构造、分支条件 |
| 数据层 | 接口格式、响应处理 | 请求体、返回映射 |
| 基础层 | 工具函数、副作用、权限 | 公共逻辑是否被影响 |
如果你一上来就全仓库搜索，很容易把问题越查越大。
五、根因分析的关键：找“最早开始不对”的地方
根因不是最后一个报错点，而是最早偏离预期的地方。
例如页面表现为“保存后提示成功，但列表没刷新”，真正根因可能是：
- AI 把保存后的返回数据结构改了
- 列表刷新函数还在用旧字段
- 所以页面状态没有更新
这里最后看到的问题是“列表没变”，但最早不对的是“返回结构被改”。
六、失败案例：连续让 Cursor 自己修，结果问题越补越多
一个常见翻车流程是：
- Cursor 改了一版
- 出了 bug
- 继续把报错贴给它让它修
- 它又加了一层防御代码
- 表面不报错了，但逻辑更绕
这类问题的根因不是它不能修，而是你没有先明确这次 bug 的真正边界。
正确顺序应该是：
- 先看 diff
- 再缩短复现路径
- 明确问题发生在哪一层
- 找到最早开始不对的点
- 最后才决定让 Cursor 继续改，还是人工直接收口
七、一个可以直接复用的排查流程
| 步骤 | 问题 | 产出 |
|---|---|---|
| 看 diff | 这次到底改了哪些行为相关代码 | 影响面列表 |
| 做复现 | 最短复现路径是什么 | 明确的复现步骤 |
| 分层定位 | UI、业务、数据、基础哪层先出错 | 问题层级 |
| 找根因 | 最早开始偏离预期的是哪一处 | 根因结论 |
| 做回归 | 修完后哪些用例必须再跑 | 最小回归集 |
八、排查检查清单
- 是否先看了 diff，而不是直接继续让 AI 碰运气修
- 是否把问题压缩成了最短复现路径
- 是否判断了 bug 属于哪一层
- 是否找到“最早开始不对”的地方，而不是只盯着最后现象
- 修复后是否重新跑了关键回归用例
结语
Cursor 生成 bug 并不可怕，可怕的是你用没有结构的方式去追它。只要把排查顺序固定成“diff → 复现 → 分层 → 根因 → 回归”，AI 改动带来的大部分问题都能更快收敛，而不是越补越乱。
