如何在 LingCode 中用 AI 解释终端报错？

选中、右键、解释

在终端面板中，选中报错文本——可以高亮相关行，也可以把光标放在那一行上直接右键。上下文菜单顶部附近会显示 用 AI 解释。

点击它。一个悬浮弹窗出现在选中位置旁边，先显示小转圈，随后解释内容流式呈现。

一个概念，三句话

解释刻意保持简短：

• 报错的含义——将堆栈轨迹或厂商特有的表述翻译成通俗语言。
• 最可能的原因——代码或环境中通常在什么情况下会触发这个报错。
• 第一步该尝试什么——一个具体的下一步操作。不是长篇大论，就是"检查 X"。

弹窗刻意不是一次调试会话。它给你读懂报错所需的方向感，然后让路。如果第一步尝试没有奏效，再升级到对话——真正的诊断属于那里。

选得多不一定选得好

模型最擅长处理精准选取的实际报错内容，而不是整段 200 行的日志。最佳实践：

• 选中报错信息那一行，加上其上方 2–4 行的上下文（原因通常藏在那里）。
• 避免选中整个构建日志——那只会用无用输出填满上下文。
• 避免只选错误编号（如 error: 1024）——去掉所有说明只留代码，解释就失去了信号。

如果解释太模糊，换更宽的选取范围重试。如果解释跑偏了，换更窄的范围重试。

快速查阅，而非调试

适合用弹窗的场景：

• 你见过这个报错，但忘了是什么原因导致的。
• 报错来自一个你不常用的工具（链接器、GPG、dtrace）。
• 你想先搞清楚"这是什么"，再决定值不值得深入研究。
• 这条报错与当前聊天任务无关，你不想打断它。

不适合用弹窗的场景：

• 报错出现在你正在编写的代码里——用对话更好，因为助手已经有文件上下文。
• 你想要完整诊断并附带代码修改建议——用对话更好，因为弹窗刻意不提出编辑。
• 这是一系列报错中的第三条，你需要连续性——用对话更好，因为你需要历史记录。

三种后续路径

读完弹窗后，你有三种合理的下一步：

1. 立即尝试建议。如果建议是"检查文件是否存在"，而你可以运行 ls，那就直接做。关掉弹窗，运行命令，继续前进。
2. 打开对话深入研究。如果解释指向了一个真实但非平凡的原因，就升级到对话。弹窗告诉了你是哪类问题；对话是真正解决它的地方。
3. 关掉弹窗，忽略它。有时候报错无关紧要——一个警告、一条非致命日志、什么无害的东西。解释确认了这一点，你可以继续前进。

发送了什么内容

弹窗只将你选中的文本发送给已配置的 AI 提供商。没有周围的文件内容，没有环境变量，没有之前弹窗的历史记录。只有你的选中内容。

如果你的终端输出碰巧包含敏感信息——比如某条命令意外打印了 API 密钥——请注意选取范围。这里需要和复制粘贴到任何聊天时一样的谨慎。