跑项目突然炸出一片红色报错，你盯着堆栈信息发懵——这种时候最忌讳的是复制半句错误去搜索引擎瞎碰。用 Cursor，把整个报错连同上下文一起交给它，比你自己猜快得多，也更准。
准备清单：装好 Cursor（基于 VS Code，原来的插件和快捷键基本通用），打开你的项目文件夹，确保项目能正常索引（首次打开让它把文件扫一遍）。不需要额外装模型，内置的就够用。
第一步，复现报错并完整复制终端输出，从命令那行到最后的错误栈，别只挑一句。第二步，按 Ctrl+L 打开聊天侧栏，把报错整段粘贴进去，加一句人话指令：
这是我在运行 npm run dev 时的完整报错，请定位到具体文件和行号，给出最小改动修复，并解释原因。
关键在"定位到具体文件和行号"这句话——它逼模型去读你的真实代码而不是泛泛给建议。Cursor 会直接回链到文件，你点一下就能跳过去看它标红的那几行。
第三步，看它给的修复。靠谱的回答会写明"第 47 行少了 await，导致拿到的是 Promise 而非数据"，并给出补丁片段。你可以点 Apply 让它直接改到文件里，再重新运行验证。验收标准：报错消失、功能按预期跑通，且你能用自己话把"刚才为什么错"讲一遍——讲不出来就别急着过，说明没真懂。
进阶玩法：把常遇到的报错类型整理成项目里的 .cursorrules 文件，写清"本项目用 TS、禁止 any、数据库用 Prisma"，以后它给的修复会更贴合你的技术栈，少给跑偏的建议。长期下来，Cursor 不只是修 bug 的工具，更是把你踩过的坑变成团队默认规范的载体。
最后说一个边界：不是所有报错都该直接信它给的补丁。涉及权限、鉴权、数据安全的修复，比如"把校验关掉就不报错了"这类建议，千万别照做——它确实能消除报错，但代价是把门也拆了。正确做法是让它先讲清楚"为什么原来会报错"，你确认逻辑合理，再决定怎么改。另外，贴报错时尽量别把 .env、密钥、内网地址一起带进去，聊天记录可能比你想的更长寿。把 AI 当那个随时在线的、记性很好的搭档，但最终的判断权始终留在你手里，这才是用 Cursor 修 bug 不翻车的关键。