Cursor 的 Bug 修复通常有两种入口：一是选中可疑代码后使用行内修复，二是直接把报错信息扔进侧边栏对话。实际开发中，两者经常搭配使用。
快速修复操作
选中报红或逻辑异常的代码块，按 Ctrl/Cmd + K 呼出行内编辑框，输入 fix 或 fix bug 并回车。Cursor 会自动分析上下文，给出修复后的代码差异，点击 Accept 即可应用。如果代码旁边有 ESLint / TypeScript 的红色波浪线，也可以直接将光标停在错误处，按 Ctrl/Cmd + K 让 AI 针对该诊断信息给出修复方案。
利用报错日志精准定位
遇到运行时崩溃，不要只告诉 AI "这段代码报错了"。最实用的做法是：
- 把终端或浏览器控制台的 完整 Error Stack 复制下来；
- 回到 Cursor，在侧边栏（
Ctrl/Cmd + L）粘贴报错信息； - 补充一句 "报错发生在哪个文件、什么场景下"（例如："登录接口在用户名为空时触发 TypeError"）。
Cursor 会根据调用栈定位到具体文件和行号，结合上下文给出根因分析和修复代码。如果项目里多个文件存在相似写法，它还会提醒你检查其他位置是否存在同类隐患。
分步处理复杂问题
对于时隐时现的并发 Bug 或状态管理混乱，不要一次性把上千行代码塞给 AI。更可靠的做法是：
- 先让 AI 解释 当前函数的执行流程（3.3.1 节方法），确认它是否理解了业务意图；
- 再圈出你认为最可疑的 20–50 行，要求 "检查这里的空值/异步/边界条件"；
- 如果修复后仍报错，直接把新的报错信息回复给 AI，利用多轮对话逐步收敛。
需要人工把关的情况
AI 对语法错误、空指针、常见 API 误用（如把 map 写成 forEach）修复成功率很高。但如果 Bug 涉及资金计算、权限校验、数据库事务、并发竞争等业务敏感逻辑，AI 给出的修复往往只是"能跑通"，不一定符合业务规则。此时务必自己 Review diff，确认后再提交代码。
一句话建议：把报错日志给全，把怀疑范围缩小，修完后一定要跑一遍复现步骤，不要盲信 AI 的"应该没问题"。