在 IDE 里接 Mellum2.1 做代码补全，遇到不补全、补出半句、光标一直转圈时，先不要判断模型能力。更有效的顺序是把两件事拆开：IDE 插件负责何时触发、把请求发到哪个地址、带哪个模型标识、等多久；模型服务负责监听端口、加载权重、按接口路径返回内容。只要有一个能独立验证的中间点，问题就能缩小到一侧。

建议固定一条处理顺序：先从插件设置读出服务地址和模型名，再用 curl 对同一 endpoint 发一次最小请求，最后回服务端日志确认请求是否到达。这三次观察分别对应插件配置、网络与服务、模型加载三类问题。适用场景是本地或自建的补全服务；如果服务端还不能独立响应，就不要继续在 IDE 里调参数，否则改动会互相干扰。

在 IDE 补全插件里定位服务地址和模型名字段

补全插件的配置通常分散在两处：IDE 设置页和一份可直接编辑的配置文件。字段名各家不同，但语义集中在四项，先读出当前值再改动其他开关：

• 服务 URL：协议、主机、端口、路径前缀。注意末尾是否带 /v1 这类前缀，多写或少写会导致 404。
• 模型名：请求体里的 model 字段，需与服务端实际加载的模型标识一致。
• API key 占位：自建服务可能不校验，但插件若要求非空，留空会导致请求根本没发出去。
• 超时时间：单位常为毫秒或秒，字段名里有 timeout 的就是它。

多数插件允许在设置页搜索 completion、endpoint、server、model 等关键词定位字段。配置文件可参照下面这个通用骨架，字段名按实际插件替换，不要直接复制：

{
  "completion": {
    "enabled": true,
    "endpoint": "http://MODEL_HOST:PORT/v1/completions",
    "model": "MODEL_NAME",
    "apiKey": "API_KEY_PLACEHOLDER",
    "timeoutMs": 3000
  }
}

如果某个字段本来就是空的，插件可能会回退到默认地址或其它服务，这种行为需要结合插件自身的说明确认，不能假定它连的就是 Mellum2.1。链路各环节该看什么，可以对照下表：

用 curl 或等价命令验证补全服务可达性

这一步把问题从 IDE 缩小到服务和网络层。在能访问模型主机的终端里执行，替换 endpoint、模型名和提示内容三处占位即可，不要加插件特有的字段：

curl -i -X POST "http://MODEL_HOST:PORT/v1/completions" \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer API_KEY_PLACEHOLDER" \
  -d '{"model":"MODEL_NAME","prompt":"def add(a, b):","max_tokens":64,"temperature":0}' \
  `--max-time` 10

结果按下面的方式读，不要只看有没有返回内容：连接被拒绝通常说明端口没监听或地址写错；连接超时说明网络或主机不可达；401/403 说明鉴权字段有问题；404 多半是路径前缀不对；400/422 说明请求体字段名与服务端期望的不一致；200 但响应体为空，则要回到模型加载和服务端日志查。Completions 与 Chat Completions 的请求体结构不同，endpoint 和字段必须配套，混用会导致服务端解析失败。

对照模型服务日志确认请求是否到达

curl 能通、IDE 不通，或者两边都不通，下一步看服务端日志。访问日志通常包含时间、客户端地址、请求方法、路径、状态码、耗时；错误日志会给出模型加载失败、显存不足、请求体解析异常等信息。日志格式由部署方式决定，字段名需要以实际输出为准。

• 日志里没有对应时间点的请求：插件没发出请求，回到第 1 节检查是否启用、key 是否为空、触发条件是否满足。
• 有连接记录但没有应用层请求：可能被中间层拦掉或路由到了别的服务。
• 请求到达但状态码非 2xx：看错误日志里的具体异常，多半是模型名不匹配或请求体字段不符。

对比 curl 那次请求和 IDE 那次请求的路径与模型标识，两者不一致就是配置错位的直接证据。

检查插件侧超时、触发方式和补全上下文长度

服务端正常但 IDE 里补全断片或干脆不出，问题常在三个通用项上。改的时候一次只动一项并立刻重试，否则无法判断哪项起了作用：

1. 超时时间：大于服务端首个 token 返回的时间。首次加载模型时响应偏慢，超时过短会表现为无提示。
2. 触发方式：自动触发还是手动快捷键。可先改手动触发确认链路通，再恢复自动。
3. 上下文截断参数：前置行数、最大 token 数一类字段。截得过短会让补全缺少函数签名等关键信息。

另外留意请求间隔或防抖延迟参数，设置过大会让人误以为插件没有响应。

做一次最小补全闭环并记录可复现结果

新建一个单文件，只写一行函数签名，例如 def add(a, b):，把光标停在行尾，用一个简单的返回语句作为观察目标。观察点是：IDE 是否出现请求中的状态提示、多久出现补全、补全内容是否完整、服务端日志是否在同一秒出现对应记录。

成功时保存四样东西：插件里生效的配置片段、curl 命令与返回状态码、服务端该次请求的日志行、当前扩展版本。失败时同样保存这四样，并额外记下具体表现是在哪一步断的：没有请求、请求超时、请求报错、返回内容被截断。下次环境变动或换机器时，用这份基线重跑一次 curl，就能快速分清是配置漂移还是服务侧变化。