Cline 的设置页只需要填几个字段：API Provider、Base URL、API Key、Model ID。字段不多，排错却很容易混在一起。Base URL 写错会让请求落到不存在的路径；Key 不匹配通常返回 401；Model ID 不在当前端点的目录里会得到 404 或 model_not_found；端点虽然返回 200，但响应结构不兼容时，Cline 仍可能无法继续工作。
最省时间的办法不是反复改四个字段，而是在保存配置前先做两次预检：读取模型目录，再发送一个最小聊天请求。本文依据 Cline v4.0.11 的官方文档和当前源码说明字段边界，并用只监听 127.0.0.1 的本地 fixture 复现错误模型 404、正确模型 200。本文没有安装或执行本机 Cline 客户端，也没有请求任何线上 provider；结论只覆盖配置前的协议预检。
先按这 5 步检查
适用环境：你已经安装 Cline，准备选择 OpenAI Compatible，目标服务声明支持 OpenAI-compatible API，并提供自己的 Base URL、Key 和模型目录。
1. 先记录 Cline 版本和官方字段
Cline 官方 OpenAI Compatible 文档列出的核心设置是：
API Provider: OpenAI Compatible
Base URL: 目标服务提供的 API 根地址
API Key: 目标服务签发的凭据
Model ID: 目标服务实际开放的模型标识当前 v4.0.11 的设置源码仍能看到 Base URL 输入框、API Key 字段以及 Model ID 的选择或自定义输入。这里最重要的不是把示例值照抄进去，而是确认三个值来自同一个服务环境。测试环境的 URL、生产环境的 Key 和另一个供应商的展示名不能拼成一套可用配置。
2. 用 /models 检查 Base URL 与模型目录
先不要在 Cline 中发送长任务。根据目标服务文档，把模型目录地址组合出来：
curl -sS \
-H 'Authorization: Bearer <YOUR_API_KEY>' \
'https://your-endpoint.example/v1/models'只保留脱敏后的三个信号：HTTP 状态、最终路径、返回的模型 ID。成功示例应类似：
{
"object": "list",
"data": [
{"id": "your-exact-model-id", "object": "model"}
]
}如果这里是 401，先查 Key、认证头和权限；如果是 404，先查 Base URL 是否重复或缺少 /v1；如果返回 HTML、登录页或网关首页，说明你命中的不是 API 资源。此时继续在 Cline 里换模型名只会增加变量。
3. Model ID 必须复制目录中的精确值
模型展示名和 API 标识不是一回事。控制台里写"Coder Pro"，目录里可能是 vendor-coder-2026-07。Cline 的 Model ID 应使用服务端实际识别的字符串，并注意大小写、版本后缀和访问权限。
错误思路：凭产品页展示名猜模型 ID
正确思路：读取当前端点的模型目录，再复制精确 id若 /models 不开放，也要以服务方当前文档或控制台可见目录为准。不要把别的供应商文章中的模型名直接粘贴过来，也不要因为域名能打开就认定模型可调用。
4. 发送一个最小聊天请求
目录只证明模型 ID 被列出，不证明 Chat Completions 响应能被客户端解析。继续用同一个 Base URL、Key 和 Model ID 发一个最小请求：
curl -sS \
-H 'Authorization: Bearer <YOUR_API_KEY>' \
-H 'Content-Type: application/json' \
'https://your-endpoint.example/v1/chat/completions' \
-d '{
"model": "your-exact-model-id",
"messages": [{"role": "user", "content": "reply with OK"}],
"stream": false
}'成功信号至少包括：HTTP 200、响应体是 JSON、choices[0].message.content 可读。若 Cline 实际任务需要流式输出或工具调用，最小文本 200 只是第一关，不能代替 SSE、tool call 与上下文长度验证。
5. 最后再回到 Cline 保存配置
把刚才验证过的同一组值填入 Cline：
Base URL -> 与预检请求使用同一个 API 根地址
API Key -> 不截图、不提交到仓库
Model ID -> 从当前端点目录复制发送一条最短消息并观察 Cline 的实际错误。如果预检 200、Cline 仍失败，再检查 Cline 是否追加了不同资源路径、是否开启流式、供应商是否完整支持工具调用，以及代理或企业远程配置是否覆盖本地字段。不要回头把四个字段同时乱改。
本地实测：错误模型 404，正确模型 200
为了验证这套顺序，我运行了一个只绑定 127.0.0.1 的 OpenAI-compatible fixture。它公开一个合成模型 fixture-coder，并记录请求路径、模型 ID 和状态码，不记录认证值。
执行：
python3 06-evidence/probe_cline_preflight.py实际输出：
MODELS_HTTP=200
MODELS_IDS=fixture-coder
WRONG_MODEL_HTTP=404
WRONG_MODEL_ERROR=model_not_found
CORRECT_MODEL_HTTP=200
CORRECT_MODEL_TEXT=CLINE_PREFLIGHT_OK
ONLINE_PROVIDER_REQUEST=NO
这组证据能证明"先读目录、再用精确模型 ID 发最小请求"可以把 404 与 200 分开。它不能证明某个线上服务稳定，也不能证明 Cline 的流式和工具调用已经兼容。因为本机没有安装 Cline，本稿不会把协议预检写成"Cline 已跑通"。
常见失败路径
/models 返回 401
优先检查认证头格式、Key 是否属于这个端点、Key 是否有模型目录权限。不要在日志中打印完整 Authorization，最多记录头是否存在、状态码和 request id。
/models 返回 404
检查 Base URL 是否已经包含 /v1。有的客户端需要填写 https://host/v1，有的配置项期望 https://host 后自行追加资源路径；必须以当前 Cline 和目标服务文档为准。不要通过连续添加 /v1/v1、/api/v1 来碰运气。
目录有模型，聊天请求仍是 model_not_found
检查请求体中的模型字符串是否含空格、大小写是否一致、当前 Key 是否只有目录可见权但没有调用权。还要确认模型目录和聊天请求使用的是同一个 Base URL 与环境。
最小请求 200，Cline 仍然失败
继续查响应结构、流式 SSE、工具调用和上下文能力。Cline 是 Agent 工具，实际工作负载比"返回 OK"更复杂；文本请求通过只能说明基础链路成立，不能推导完整兼容。
可复制检查清单
[ ] 记录 Cline 版本与 OpenAI Compatible 配置入口
[ ] Base URL、Key、Model ID 来自同一个服务环境
[ ] /models 返回 200 且看到精确模型 ID
[ ] 错误模型与正确模型得到可区分的状态
[ ] 最小 chat/completions 返回 200 和可读 JSON
[ ] Cline 短消息通过后再测流式与工具调用
[ ] 日志和截图不包含完整 Key、Cookie 或用户数据总结
Cline 配置 OpenAI Compatible 时，先把"端点、认证、模型、协议"拆开。/models 用来核对 Base URL 和模型目录，最小聊天请求用来验证精确 Model ID 与基础响应。等两步都有明确成功信号，再把同一组值填进 Cline。这样遇到 401、404 或响应解析错误时，每个状态都有对应动作，不必靠反复改字段猜答案。