IDE 里接入 Mellum2.1 报错时，最耗时间的不是修错，而是判断错在哪一侧。插件配置写错、网络不可达、模型服务没加载、返回结构与插件预期不符，这四类问题在 IDE 弹窗里往往都是同一句笼统提示。可行的做法是先把报错原文留全，再用一条命令行请求把“插件问题”和“服务问题”分开，最后只改一侧复测。判断依据应来自插件日志、模型服务日志和实际响应体，而不是凭印象猜。

接入 Mellum2.1 报错时，建议按“插件配置 → 网络可达 → 模型服务 → 响应格式”的顺序分层定位：先在 IDE 插件日志和状态栏找到报错原文与首次出现时间，再逐项核对服务地址、模型名、密钥占位和补全开关，然后用命令行向同一地址发一条最小请求，看状态码与响应体。若命令行正常而 IDE 报错，问题多在插件配置或返回格式兼容；若命令行也失败，再查模型服务日志与监听地址。全程只改一侧配置并记录复测结果，避免同时改动导致无法归因。

复制完整 IDE 报错并标记首次出现位置

IDE 报错最容易被截断成一句话，比如“请求失败”“模型不可用”“connection error”，这种文本不足以定位。建议在触发报错的那一刻，把三处信息一起留存：弹窗或通知里的完整文本、状态栏或输出面板的状态提示、插件自身日志中的对应行。同时记录触发动作，例如是打开补全、保存文件、手动触发对话，还是 IDE 刚启动时的初始化请求。

记录时注意保留首次出现的位置和时间点，因为同一句报错可能在后续请求里被覆盖成更模糊的版本。可以用下面的最小记录格式，把信息集中到一个临时文件里，便于后面按时间戳对照服务日志：

时间：2026-xx-xx 10:12:03（本地时间）
触发动作：在 editor 中手动触发补全
IDE 弹窗原文：（完整粘贴，不要删减）
状态栏提示：（完整粘贴）
插件日志行：（含 request id 或 trace id 的话一并保留）
是否首次出现：是 / 否，之前是否成功过

这一步的价值在于把“猜”变成“对照”。如果报错文本里出现 401、403、404、422、500 这类状态码，后面的分类会快很多；如果只有一句连接失败，也能通过后续命令行请求补上状态码。

检查插件配置中的地址、模型名、密钥占位

在动服务之前，先排除最直接的配置缺失。IDE 插件的配置项名称各异，但通用核对项大致相同，建议逐项对照，不要一次改多项：

• 服务地址（endpoint / base URL）：协议、主机、端口、路径前缀是否完整，末尾是否多写或少写斜杠。
• 模型名：填的是 Mellum2.1 对应的模型标识，而不是示例里残留的其他模型名。
• API key：是否为空、是否仍是示例占位（如 your-key-here）、是否被引号或空格包裹。
• 补全与对话开关：报错来自哪个功能，就优先确认该功能是否启用、是否指向同一个服务地址。
• 超时与重试：超时设得过短时，长响应会被插件自己判为失败，表现类似服务不可用。

核对方式是逐项对照并保存一次，再触发同一动作复测。地址和模型名属于高频拼写错误点，尤其是自建服务常见的 /v1 前缀遗漏。密钥占位问题则常表现为鉴权失败，但如果插件把鉴权错误吞成通用失败，就要靠后面的命令行请求确认。

用命令行请求同一地址观察状态码和响应体

命令行请求的目的不是替代插件，而是把“IDE 环境下的失败”还原成一个可观察的 HTTP 结果。请求骨架只保留三处占位，替换成插件里配置的同一组地址、模型名和密钥：

curl -i -X POST '<endpoint>' \
  -H 'Content-Type: application/json' \
  -H 'Authorization: Bearer <api-key>' \
  -d '{"model":"<model-name>","messages":[{"role":"user","content":"ping"}],"max_tokens":16}'

看结果时按状态码分流：连接被拒绝或超时，说明地址、端口或服务监听有问题；401 或 403，说明密钥或鉴权头格式不对；404 常见于路径前缀或模型名不匹配；422 或 400 通常说明请求体字段与模型服务预期不一致；5xx 则要回到模型服务日志看加载与运行状态。

如果命令行返回 200，但响应体结构与插件预期不同——例如缺少插件读取的字段、流式响应格式不一致——那就属于响应格式不符，问题在插件与服务的接口约定上，而不是网络。此时建议保留完整响应体，作为下一轮比对的依据。

在模型服务日志里搜索同一时间点的请求

拿到状态码之后，回到模型服务一侧确认请求是否真的到达。检索关键词建议组合使用：首次报错的时间戳（注意时区差异，服务端日志常用 UTC）、请求路径、状态码、请求里的模型名。很多服务日志会记录请求 ID，如果插件日志里也带同一个 ID，对应关系会很明确。

• 日志中有对应记录且状态码正常：请求到达且被处理，重点转向 IDE 侧的响应解析。
• 日志中有记录但报错：直接看日志里的错误信息，通常是模型未加载、显存或资源不足、参数校验失败。
• 日志中完全没有记录：说明请求没到服务，检查网络出口、端口映射、服务监听地址是否绑定在预期网卡上。

服务监听地址这一项常被忽略。服务只监听 127.0.0.1 时，本机命令行能通，IDE 在容器或远程开发场景下就可能不通。判断方式是分别在 IDE 所在环境和命令行所在环境各请求一次，对比结果，而不是只看其中一侧。

按错误分类只改一侧配置并复测

分类之后，每次只改一侧，改完立刻用同一动作、同一请求复测，并记录结果。下面这张表用于归类和确定先查哪一侧的日志：

复测时的最小记录建议包含：改了什么、改前改后的命令行状态码、IDE 是否仍报错、报错文本是否变化。报错文本从“连接失败”变成“解析失败”，本身就说明请求已经打通，问题转移到格式层，这比反复重启插件更有信息量。

需要说明边界：以上流程只依赖可观察的配置、日志、状态码和响应体，不涉及具体版本的接口细节。Mellum2.1 的实际字段要求、是否支持流式、密钥头格式，需要结合你部署的模型服务版本和插件版本来确认。若某一侧日志本身不可见，先解决日志可见性，再继续排查，否则分类只能停在猜测层面。