当你被控制台满屏的红色报错信息弄得焦头烂额时，CodeBuddy 提供了三条真正实用的救命路径：一是将日志粘贴进去，它自动定位异常并生成可直接复用的修复补丁；二是在 IDE 中右键或使用快捷键，一键完成诊断和应用；三是调试中断后，通过观察变量值逐步进行交互修正。三种方式各有独特优势，下面逐一详细讲解。

想象一下这个典型场景：你像往常一样运行代码，控制台突然爆出一大堆红色错误，光标停留在哪里、哪一行出了问题、应该如何修改，全都毫无头绪。这时 CodeBuddy 就能大显身手——根据错误日志或你选中的代码块，精准定位异常根源，并直接告诉你该修改哪一行、改成什么样子。

粘贴日志→自动定位→生成修复补丁

这种方法最适合你手上已经拿到了完整的报错输出——比如 Java 的堆栈跟踪或 Python 的 traceback——但尚未打开对应文件，或者调用栈太深、手动追踪会耗费大量精力。具体操作分为四步：

第一步，复制终端里完整的错误日志。注意务必包含异常类型（例如 【NullPointerException】）、以 at 关键字引导的调用行（比如 at com.example.service.OrderService.process(OrderService.java:57)），以及如果存在，还要带上 Caused by 异常链。缺少这些关键信息，定位的精确度会明显下降。

第二步，打开 CodeBuddy Chat 界面，输入固定指令：“请分析以下错误日志，定位异常发生的具体文件、函数和行号，并给出最小改动修复方案。”这条指令经过验证，直接照搬即可。

第三步，将刚才复制的日志粘贴进去并发送。CodeBuddy 会解析出源码路径、触发异常的变量名以及上下文状态，然后返回带行号标注的修复代码块。它不会笼统地说“加个判空”，而是直接给出 if (user != null) { ... } 这类能够直接复制粘贴的具体语句。

第四步，点击补丁中的「复制」按钮，回到原文件对应位置，手动替换原有代码。这里有一个容易踩的坑：不要全选整段函数然后整体覆盖，只替换它明确标记为「替换」的那几行，否则很可能误删其他正常逻辑。

IDE 内右键→一键诊断→应用修复

这种方式适合你已经在编辑器里看着报错文件，光标停留在波浪线下面，希望立刻知道如何修复。现场感很强，操作也非常干脆。有两种触发方式：

方法一：快捷键触发。把光标放在报错行上，按下 【Ctrl+Shift+R（Windows/Linux）或 Cmd+Shift+R（macOS）】，弹出浮动面板后选择“Diagnose & Apply Fix”。

方法二：鼠标右键触发。右键点击报错行 → 选择「CodeBuddy → 修复此代码块」 → 等待 2～4 秒 → 查看弹窗里“修改前/后”的对比，确认无误后点击“应用修复”。

这一操作非常直接，相当于直接把补丁打入代码中。不过有一个细节需要留意：如果当前文件尚未保存，修复可能会失败。因此务必先按 Ctrl+S 保存一下，再执行修复。

调试器中断→变量监视→交互式修正

当报错本身不够明确——比如返回值是 None 但期望是 dict，或者错误仅在特定输入下才触发——单纯依靠静态分析很容易遗漏判断。这时必须进入运行时环境，亲眼观察变量的真实状态。以下四个步骤是标准做法：

第一步：设置断点。在疑似出问题的函数入口行，或关键计算行左侧的灰色区域单击，出现红点即表示断点已生效。

第二步：启动调试。右键文件 → 选择「Debug Python File」或「Debug Java Class」等对应语言的调试项，程序会运行至断点处暂停。

第三步：查看变量面板。右侧 Variables 面板会列出当前作用域中所有变量的值。重点检查报错涉及的变量是否为 None、空列表、未初始化对象——许多难以排查的 bug 根源就藏在这里。

第四步：用 CodeBuddy 交互修正。复制当前变量值和错误描述（例如：“user_id=123，但 user_info 返回 None”），发送给 Chat。它会结合断点上下文指出缺失的数据加载逻辑，并给出 user_info = get_user_by_id(user_id) or {} 这类带兜底的修复写法。这种交互方式特别适合排查那些“偶尔出现、难以复现”的运行时 bug。