调试往往比写代码更耗时，而 Cursor 的核心价值之一就是把“读日志、猜原因、试修复”的循环压缩到最短。以下方法都是日常排错中最直接有效的用法。
1. 把报错信息直接丢给 AI，不要只给代码片段
终端出现红字或堆栈报错时，不用逐行人工阅读。在终端选中完整错误信息，按 Ctrl/Cmd + L 唤起侧边栏，粘贴后追加一句“这段报错的原因是什么？如何修复？”。如果错误输出较长，可以直接用 @终端（输入 @Terminal）引用最近几条终端输出，让 AI 自动关联上下文分析。
2. 选中可疑代码，做定向诊断
对于没有明显报错但行为异常的逻辑，选中相关函数或代码块，按 Ctrl/Cmd + K 唤起行内编辑框，输入 /fix 或“检查这段代码的 Bug”。Cursor 会基于当前函数的上下文给出潜在问题点，例如空指针、异步顺序错误、边界条件遗漏等。你也可以在侧边栏选中代码后提问：“这段逻辑在某某场景下为什么会返回错误结果？”
3. 利用一键解释和 Bug 定位工具
如果不确定问题出在哪，可以直接右键代码 → Cursor → Explain（解释代码），先让 AI 帮你梳理逻辑。很多时候问题在你理清数据流后就已经暴露。确认可疑后，再使用 /fix 或 /debug 指令让 AI 给出修复建议（详见 3.3.1、3.3.2）。
4. 用 @文件 或 @代码库 补充业务上下文
孤立地贴一段代码，AI 只能做语法层面的排查。如果错误涉及跨文件调用或项目特有的业务规则，提问时通过 @文件名 引入相关模块，或者用 @Codebase 让 AI 检索整个项目上下文。例如：“用户登录后 token 没生效，这是登录接口 @auth.js 和中间件 @middleware.js，帮我排查。”
5. 让 AI 帮你生成调试探针或测试用例
一时看不出原因时，与其盲目加 console.log，不如让 AI 生成一组针对性的单元测试或日志打印方案。例如：“帮我写几个测试用例覆盖边界条件，定位为什么排序结果不对。”这不仅能快速复现 Bug，后续还能直接保留为正式测试（详见 3.7.1）。
6. 多轮追问，缩小范围
复杂 Bug 很少一次就能定位。第一问拿到方向后，继续追问“如果排除网络原因，问题可能在哪？”或“这个修复会不会影响上游的某某模块？”。利用 3.1.3 提到的多轮对话上下文，Cursor 会记住之前的排查路径，避免你重复铺垫背景。
注意边界
AI 对常见运行时错误和逻辑漏洞的识别率很高，但在涉及复杂并发、性能瓶颈或业务语义陷阱时，给出的修复建议可能只是“表面上能跑通”。采纳前务必在本地复现验证，关键路径的修改仍需人工 Review。