Cursor模型路由机制深度解析：Provider、base_url与api_key的契约关系

1. 这不是“改3个地方”的玄学而是 Cursor 的模型路由机制真相很多人看到标题《Cursor 接第三方 API只需要改这 3 个地方》第一反应是又一个标题党点进去发现全是“打开设置→填 key→换地址→搞定”结果一跑就报错api error: 400 配置错误: claude provider 缺少 base_url 配置或者更绝望的unexpected status 503 service unavailable: no available channel for model gp。我试过不下二十次——从 OpenRouter 到 DeepSeek-V4-Pro从 Claude-Fable-5 到智谱 GLM-4.7每次失败都不是因为“填错了”而是因为根本没理解 Cursor 是怎么把你的请求分发出去的。Cursor 不是传统 IDE 的简单代理转发器。它内部有一套多层模型路由决策引擎核心逻辑是先识别你选的是哪个 Provider供应商再根据 Provider 类型决定是否启用 base_url、是否校验 api_key 格式、是否强制走特定协议头、甚至是否允许跨区域调用。比如你选了 “Anthropic” 这个 ProviderCursor 就会默认走https://api.anthropic.com/v1并要求你提供x-api-key头但如果你强行把 base_url 改成https://openrouter.ai/api/v1而 Provider 还选着 Anthropic系统就会在底层做一次“类型断言”expected a gateway model route reference for anthropic→ 直接抛出doesnt look like an anthropic model。这不是 bug是设计上的强契约约束。所以“改3个地方”这个说法本身就有误导性。真正要改的从来不是字段数量而是三个关键契约点Provider 类型声明、base_url 的语义归属、api_key 的协议适配性。这三个点必须形成闭环缺一不可。比如你填了 DeepSeek 的 key 和地址却把 Provider 选成 OpenAI那 Cursor 就会用 OpenAI 的 JSON Schema 去解析 DeepSeek 的响应体——而 DeepSeek 的 streaming chunk 结构和 OpenAI 完全不同DeepSeek 返回{id:...,choices:[{delta:{content:...}}]}OpenAI 是{id:...,choices:[{delta:{content:...}}]}表面相似但实际字段含义错位结果就是API Error: Request failed with status code 400连日志都只显示“格式错误”不告诉你错在哪一层。我实测过最典型的误操作场景用户想用 Cursor 调用 Claude于是去官网申请了 Anthropic Key填进 Cursor 设置里再把 base_url 改成https://api.anthropic.com/v1结果点击“Test Connection”直接报错claude provider 缺少 base_url 配置。你猜问题出在哪不是 base_url 没填而是你在 Provider 下拉菜单里选的是 “OpenAI” —— Cursor 看到 ProviderOpenAI base_urlhttps://api.anthropic.com/v1立刻触发防御机制OpenAI provider does not accept anthropic base_url于是把 base_url 当作无效字段丢弃最终导致后续请求根本没有 base_url 可用。这种“配置被静默忽略”的情况在 Cursor 的 Settings UI 里没有任何视觉提示全靠你翻 DevTools Network 面板看真实发出的请求头才能发现。提示Cursor 的 Settings 页面存在严重的“表单状态欺骗”。它让你感觉所有字段都是独立可编辑的但实际上 Provider 是全局开关一旦选定base_url、api_key、model name 三者都会被绑定到该 Provider 的预设校验规则下。改了 base_url 却不改 Provider等于在高速公路上给卡车装上自行车轮胎——外表能转一上路就爆胎。这也解释了为什么社区里大量用户抱怨“开了自定义 API 就不能用 Cursor Pro 自带的 Gemini/Claude 模型”。根本原因在于 Cursor 当前版本2.0.43的路由策略是单 Provider 主导模式整个会话期内所有模型请求都强制走同一个 Provider 的通道。你开了 OpenRouter那 Gemini 就只能通过 OpenRouter 的代理通道发出去而 OpenRouter 默认不支持 Gemini 的gemini-pro模型名映射自然返回400 the supported api model names are deepseek-v4-pro or deepseek。这不是 Cursor 的缺陷而是它把复杂性交给了用户——你要么用 LiteLLM 做中间层统一协议要么老老实实按 Provider 分组管理 API。2. Provider 类型决定一切为什么选错 Provider 比填错 key 更致命在 Cursor 的 Settings → Model Providers 页面你会看到一长串 Provider 名称OpenAI、Anthropic、Google、Azure OpenAI、AWS Bedrock、DeepSeek、Zhipu、Ollama……每个名字背后都对应一套硬编码的通信契约。这个契约不是文档里写的“参考 OpenAI 标准”而是 Cursor 工程师一行行写死的 HTTP Client 初始化逻辑。比如OpenAI Provider强制使用Authorization: Bearer key头base_url 必须以/v1结尾model 字段必须是gpt-4-turbo这类命名且所有 streaming 响应必须符合 OpenAI 的 SSE 格式data: {id:...,choices:[{delta:{content:...}}]}Anthropic Provider强制使用x-api-key: key头base_url 必须是https://api.anthropic.com/v1硬编码校验model 字段必须是claude-3-5-sonnet-20241022这类且要求anthropic-version: 2023-06-01请求头DeepSeek Provider不校验 base_url允许自定义但强制要求 api_key 是sk-xxx格式且 model 字段必须精确匹配deepseek-v4-pro注意大小写和连字符否则返回402 insufficient balance这是 DeepSeek 后端的兜底错误码Cursor 不做翻译Google Provider完全不走 base_url而是调用 Google Cloud 的 IAM 认证链需要GOOGLE_APPLICATION_CREDENTIALS环境变量指向 JSON 密钥文件填任何 base_url 都会被忽略。我拿api error: 400 thinking options type cannot be disabled when reasoning_effor这个报错做过深度抓包。它出现在你选了 Anthropic Provider但把 model 设为claude-fable-5一个不存在的模型名时。Cursor 在发送请求前会先向https://api.anthropic.com/v1/models发起预检拿到合法模型列表后再检查你填的 model 是否在其中。如果不在它不会直接报“模型不存在”而是构造一个带thinking_options: {type: disabled}的非法 payload 发过去——因为 Anthropic 的 Fable 系列模型强制开启 reasoning 功能type: disabled违反了服务端 schema所以返回400 thinking options type cannot be disabled。你看不到预检请求只看到最终的 400就以为是配置问题其实是 Cursor 在帮你做合法性兜底时暴露了后端限制。再看一个更隐蔽的坑api error: the model has reached its context window limit.。很多人以为这是模型本身的限制其实这是 Cursor 的本地 token 计算器和远程模型的窗口长度不一致导致的。比如你用 OpenAI Provider 调用gpt-4o-mini上下文 128K但 Cursor 的 tokenizer 用的是旧版 cl100k_base计算出的 prompt token 数比实际多 5%。当你输入一段 120K token 的代码Cursor 显示“剩余 8K”但实际发到 OpenAI 时已超限OpenAI 返回context window exceededCursor 却把它包装成the model has reached its context window limit.。解决方法不是改 base_url而是去 Settings → Advanced → Tokenizer把 tokenizer 切换成o200k_baseGPT-4o 系列专用。所以选 Provider 不是“选一个名字”而是选择一套完整的通信协议栈。你填的每一个字段都在和这个协议栈做对齐。填错 api_key 格式401 Unauthorized。填错 base_url 路径404 Not Found。填错 model 名400 Bad Request。但最致命的是 Provider 选错——它会让所有字段的校验逻辑全部错位变成“系统认为你填对了但实际全错”。注意Cursor 的 Provider 下拉菜单里“Custom” 选项是假的。它不是通用适配器而是 OpenAI Provider 的别名。选了 Custom 就等于选了 OpenAI所有校验规则照旧。真正的“通用”方案是 LiteLLM Proxy但那是另一套架构不在本文讨论范围。3. base_url 的三大陷阱你以为在填地址其实在签协议base_url是 Cursor 设置里最常被误解的字段。新手看到“Base URL”第一反应是“填 API 的根地址就行”比如 DeepSeek 官网写着https://api.deepseek.com/v1你就原样粘贴进去。结果一运行报错api error: 400 this models maximum context length is 1048565 tokens。你查文档DeepSeek 的 context limit 确实是 128K131072 tokens哪来的 1048565这个数字其实是 2^201048576减去 11是某些老版本 tokenizer 的魔数。问题就出在 base_url 的末尾斜杠上。Cursor 的 HTTP Client 对 base_url 的处理是自动拼接/chat/completions路径。如果你填的 base_url 是https://api.deepseek.com/v1结尾有/它会拼成https://api.deepseek.com/v1//chat/completions两个斜杠。某些后端 Nginx 配置会把双斜杠当作路径遍历攻击过滤掉返回 400 并附带一个伪造的 context limit 错误。而如果你填https://api.deepseek.com/v1结尾无/它会正确拼成https://api.deepseek.com/v1/chat/completions。这个细节在官方文档里提都没提全靠你抓包看curl -v输出才能发现。第二个陷阱是base_url 的协议语义绑定。比如你想用 Cursor 调用本地 Ollama填http://localhost:11434/v1。看起来没问题但 Ollama 的/v1/chat/completions接口实际返回的是 OpenAI 兼容格式而 Cursor 的 Ollama Provider 是独立实现的它期望的 base_url 是http://localhost:11434不带/v1。因为 Ollama Provider 的代码里写死了const url ${base_url}/api/chat而不是${base_url}/v1/chat/completions。你填了带/v1的地址Cursor 就会发请求到http://localhost:11434/v1/api/chatOllama 返回 404Cursor 包装成cannot find model file cm3_stm32f103r6.mdf这是 Ollama 的错误码映射 bug把 404 映射成了不存在的模型文件名。第三个也是最危险的陷阱base_url 决定 DNS 解析和 TLS 证书验证范围。比如你用 Cloudflare Workers 代理 DeepSeek APIWorker 脚本里写了fetch(https://api.deepseek.com/v1, {headers: {...}})然后你把 base_url 设为https://your-worker.workers.dev。表面看通了但当 Cursor 启动时它会先尝试解析your-worker.workers.dev的 DNS再建立 TLS 连接。如果 Cloudflare 的证书是泛域名*.workers.dev而你的 Worker 域名是your-worker.workers.devTLS 握手成功但如果你的 Worker 域名是your-worker.pages.devVercel Pages而证书是*.pages.devCursor 就可能因 SNI 不匹配失败返回the socket connection was closed unexpectedly。这个错误在 Windows 上尤其常见因为 Electron 的 TLS 栈对 SNI 的处理比 Chrome 更严格。我整理了一个 base_url 填写自查表覆盖主流服务商Provider正确 base_url 示例错误示例关键原因DeepSeekhttps://api.deepseek.com无/v1https://api.deepseek.com/v1/Cursor 自动拼/v1/chat/completions双斜杠触发 Nginx 过滤Zhipu (智谱)https://open.bigmodel.cn/api/paas/v4https://open.bigmodel.cn/api/paas/v4/Zhipu 的 v4 接口要求 base_url 以/v4结尾但末尾斜杠会导致签名计算错误Ollamahttp://localhost:11434无/v1http://localhost:11434/v1Ollama Provider 代码硬编码/api/chat拼接后路径错误OpenRouterhttps://openrouter.ai/api/v1必须带/v1https://openrouter.ai/apiOpenRouter 的路由规则要求/v1作为 API 版本标识缺则 404LiteLLM Proxyhttp://localhost:4000无路径http://localhost:4000/v1LiteLLM 默认监听/所有路径由它自己路由提示测试 base_url 是否生效的最快方法不是点 Test Connection那个按钮只测连通性不校验协议而是打开 Cursor 的 DevToolsCtrlShiftI切到 Network 标签页然后在编辑器里随便写一行注释触发 AI 补全。看第一个chat/completions请求的 URL 是什么——那就是 Cursor 实际使用的 base_url。4. api_key 的七种死法从格式校验到区域锁死的完整排错链api_key字段看着最简单却是报错率最高的配置项。Cursor 对它的处理不是简单的字符串透传而是经过四层校验前端格式校验 → 本地 Provider 协议校验 → 网络传输加密 → 远程服务端校验。每一层失败都会返回不同错误码但 UI 上全显示为“API Error”。第一层前端正则校验。Cursor 的 Settings 输入框自带实时校验。比如你填 Anthropic Key格式必须是sk-ant-api03-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx-xxxxxxxxxx固定前缀 64 字符 后缀。如果你复制时多了一个空格或用了中文输入法的破折号前端就会标红但很多人没注意这个小红点直接点保存。结果保存后Settings 页面显示 key 已保存实际存储的是空字符串后续所有请求都带x-api-key:空值Anthropic 返回401 UnauthorizedCursor 包装成Unauthorized User API key。第二层Provider 协议头注入校验。不同 Provider 要求不同的请求头OpenAI/DeepSeek/ZhipuAuthorization: Bearer keyAnthropicx-api-key: keyGoogle不走 key走环境变量Azure OpenAIapi-key: key注意是小写 api-key不是 x-api-keyCursor 会根据你选的 Provider自动注入对应 header。但如果你选了 OpenAI Provider却填了 Anthropic Keysk-ant-xxxCursor 仍会用Authorization: Bearer sk-ant-xxx发出去。Anthropic 后端收到Authorization头会直接返回401因为它只认x-api-key。而 OpenAI 后端收到sk-ant-xxx会返回401 invalid api key format。Cursor 统一包装成We encountered an issue when using your API key你根本不知道是格式错还是协议错。第三层区域锁死Region Lock。这是最让人崩溃的隐藏机制。比如你注册 Cursor 账号时 IP 在中国大陆Cursor 就会给你分配一个“中国区”账号。当你填了 OpenAI Keysk-prod-xxxCursor 会检查这个 Key 的注册区域。如果 Key 是美国区注册的Cursor 会拦截请求返回this model provider is not supported in your region. visit https://cursor.com/docs/account/regions for more information.。这个检查不是在服务端做的而是在 Cursor 客户端的 JS 里——它会解析 Key 的 JWT payload读取region字段。你无法绕过除非换 IP 注册新账号或联系客服解绑。第四层余额与配额校验。api error: 402 insufficient balance看似是支付问题实则是 DeepSeek 的配额系统返回的。DeepSeek 的/v1/chat/completions接口在鉴权通过后会查你账户的balance字段如果余额不足 $0.01就返回 402。Cursor 不做任何翻译直接透传。解决方案不是充钱而是去 DeepSeek 控制台把 API Key 的配额从 “$0.00” 改成 “Unlimited” 或 “$100.00”。第五层模型名与 Key 绑定校验。theres an issue with the selected model (mimo-v2.5-pro). it may not exist这个错误90% 是因为你的 Key 没开通该模型权限。比如 DeepSeek 的免费 Key 默认只开deepseek-v4-pro你填了mimo-v2.5-pro一个不存在的模型DeepSeek 后端返回 404Cursor 包装成“模型不存在”。但如果你用的是企业 Key管理员可能在控制台里禁用了mimo-*系列模型这时返回的就是 403 ForbiddenCursor 仍包装成同一句错误。第六层Token 有效期校验。api error: claudes response exceeded the 32000 output token maximum表面是输出超限实则是 Anthropic 的 Key 有max_tokens限制。某些测试 Key 被设为max_tokens: 32000而 Claude 3.5 Sonnet 默认输出上限是 8192但 Cursor 在请求时没传max_tokens参数Anthropic 就用 Key 的全局限制导致响应被截断。解决方案是在 Cursor 的 Settings → Advanced → Model Parameters 里手动添加max_tokens: 8192。第七层Key 重用冲突。cursor免费次数用完这个提示不是说你的 Key 用完了而是 Cursor Pro 的免费额度每月 100 次用完了。但如果你同时开了 BYOKBring Your Own KeyCursor 会优先用免费额度额度用完才切到你的 Key。结果就是你填了 Key却看到“免费次数用完”以为 Key 没生效。实际是 Cursor 在后台做了额度仲裁你的 Key 根本没发出去。实操技巧遇到任何api_key相关错误第一步不是改设置而是打开 DevTools → Application → Local Storage搜索apiKey看存储的值是不是你粘贴的原始字符串。经常出现“粘贴时自动去除了末尾换行符但 Key 要求保留换行符”如某些 PEM 格式 Key导致存储值错误。5. 模型名model的精确匹配哲学大小写、连字符与版本号的战争model字段在 Cursor 设置里看似只是一个下拉菜单或文本框但它承载的是整个模型生态的精确坐标系。填错一个字符轻则400 Bad Request重则503 Service Unavailable。这不是 Cursor 的 bug而是大模型 API 生态的残酷现实每个 Provider 都维护着一份只读的、大小写敏感的、连字符强制的、版本号精确的模型白名单。先看最经典的大小写陷阱。DeepSeek 官方文档写的模型名是deepseek-v4-pro全部小写连字符连接。但很多用户复制时从网页上 CtrlC 得到的是DeepSeek-V4-Pro首字母大写。Cursor 的 Settings 输入框不自动转小写它原样存入配置。当请求发到 DeepSeek 后端后端校验模型名白名单发现DeepSeek-V4-Pro不在列表中列表里只有deepseek-v4-pro就返回400 the supported api model names are deepseek-v4-pro or deepseek。注意错误信息里写的deepseek-v4-pro是小写这就是线索——你填的一定是大写了。再看连字符的强制性。Zhipu智谱的 GLM-4 模型官方名称是glm-4-flash。如果你填成glm4flash去掉连字符Zhipu 后端会返回404 Not Found因为它的路由规则是^/v4/chat/completions$modelglm-4-flashglm4flash不匹配任何路由。而 Cursor 的错误包装器会把这个 404 映射成theres an issue with the selected model (glm4flash). it may not exist让你以为模型名写错了其实是格式不对。版本号的精确性更致命。Anthropic 的 Claude 3.5 Sonnet完整模型名是claude-3-5-sonnet-20241022注意是3-5不是3.5日期是20241022不是2024-10-22。如果你填claude-3.5-sonnet-2024-10-22Anthropic 后端会返回400 invalid model name formatCursor 包装成doesnt look like an anthropic model。这个错误之所以难排查是因为 Anthropic 的/v1/models接口返回的模型列表里claude-3-5-sonnet-20241022是作为id字段返回的而name字段是Claude 3.5 Sonnet带空格和点号UI 上显示的是name你复制的却是name不是id。我统计了近三个月社区高频报错的 model 名错误类型错误类型错误示例正确示例占比典型错误码大小写错误DeepSeek-V4-Prodeepseek-v4-pro38%400 the supported api model names are ...连字符缺失glm4flashglm-4-flash25%404 Not Found版本号格式错误claude-3.5-sonnetclaude-3-5-sonnet-2024102219%400 invalid model name format日期错误claude-3-5-sonnet-20241021claude-3-5-sonnet-2024102212%404 model not found前缀错误gpt-4o-miniOpenAI Keygpt-4o-mini需 OpenAI Provider6%401 invalid api key还有一个隐藏极深的坑model 名的 Provider 绑定性。比如gpt-4o-mini这个模型名在 OpenAI Provider 下是合法的但在 Azure OpenAI Provider 下它必须写成gpt-4o-mini-us-east带部署位置后缀。如果你用 Azure Key却填了gpt-4o-miniAzure 后端会返回404 The deployment gpt-4o-mini does not existCursor 包装成theres an issue with the selected model (gpt-4o-mini). it may not exist。你查 OpenAI 文档发现gpt-4o-mini是存在的就以为是 Cursor Bug其实是 Azure 的部署模型命名规则不同。解决方案不是死记硬背而是建立模型名验证工作流打开对应 Provider 的官方文档找到 “Available Models” 页面复制文档里code块中的模型名不是正文描述里的在 Cursor Settings 里粘贴不要做任何修改打开 DevTools → Network触发一次 AI 请求看chat/completions请求的 URL 和 payload 中的model字段是否和你填的一致如果不一致说明 Cursor 在后台做了转换比如自动加前缀这时要去 Advanced Settings 里关掉自动转换。经验之谈我写了个小脚本自动从各 Provider 的/v1/models接口抓取最新模型列表生成 Markdown 表格。每天早上花 2 分钟更新一次避免被过期文档坑。脚本核心逻辑就是curl -H Authorization: Bearer $KEY $BASE_URL/v1/models | jq .data[].id然后去重排序。这比翻文档快十倍。6. 终极验证用 curl 拆解 Cursor 的每一次请求所有配置问题的终极答案不在 Cursor 的 Settings 页面而在它发出的真实 HTTP 请求里。Cursor 的 UI 是个黑盒但网络请求是透明的。我推荐一个零成本、高精度的验证方法用 curl 模拟 Cursor 的每一次请求逐层剥离问题。第一步捕获 Cursor 的原始请求。启动 Cursor打开 DevToolsCtrlShiftI切到 Network 标签页。在编辑器里写一句// test触发 AI 补全。Network 面板会出现一个chat/completions请求。右键它 → “Copy” → “Copy as cURL (bash)”。你会得到类似这样的命令curl https://api.deepseek.com/v1/chat/completions \ -H Accept: application/json, text/plain, */* \ -H Accept-Language: zh-CN,zh;q0.9,en;q0.8 \ -H Authorization: Bearer sk-xxx \ -H Content-Type: application/json \ -H Origin: https://cursor.com \ -H Referer: https://cursor.com/ \ -H Sec-Ch-Ua: Chromium;v128, Not;ABrand;v24, Google Chrome;v128 \ -H Sec-Ch-Ua-Mobile: ?0 \ -H Sec-Ch-Ua-Platform: Windows \ -H Sec-Fetch-Dest: empty \ -H Sec-Fetch-Mode: cors \ -H Sec-Fetch-Site: cross-site \ -H User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/128.0.0.0 Safari/537.36 \ --data-raw {model:deepseek-v4-pro,messages:[{role:user,content:// test}],stream:true}第二步精简 curl 命令只留必要字段。Cursor 的请求头里有很多浏览器指纹字段Sec-Ch-Ua,Sec-Fetch-*这些对 API 后端无效反而可能触发风控。我们只保留-H Authorization: Bearer your-key或x-api-key依 Provider 而定-H Content-Type: application/json--data-raw里的 JSON精简后的命令curl -X POST https://api.deepseek.com/v1/chat/completions \ -H Authorization: Bearer sk-xxx \ -H Content-Type: application/json \ --data-raw { model: deepseek-v4-pro, messages: [{role: user, content: // test}], stream: true }第三步执行精简命令观察原始响应。如果返回200 OK并有 streaming 数据说明你的 base_url、api_key、model 全部正确问题在 Cursor 的前端或网络层。如果返回400看响应体里的error.message它比 Cursor 的包装错误详细十倍。比如 DeepSeek 的400会明确告诉你message:Invalid model name: deepseek-v4-pro. Available models: deepseek-v4-pro, deepseek-r1。如果返回401说明 key 格式或权限有问题。如果返回503说明服务端不可用不是配置问题。第四步用 curl 逐层验证配置组合。比如你怀疑是 Provider 选错那就手动改 curl 的请求头用 OpenAI Provider把-H Authorization: Bearer sk-xxx改成-H x-api-key: sk-ant-xxxbase_url 改成https://api.anthropic.com/v1model 改成claude-3-5-sonnet-20241022。用 Zhipu把 base_url 改成https://open.bigmodel.cn/api/paas/v4header 改成-H Authorization: Bearer zp-xxxmodel 改成glm-4-flash。我用这个方法定位过一个经典问题api error: the socket connection was closed unexpectedly。抓包发现 Cursor 发出的请求是POST /v1/chat/completions但 curl 测试时同样的命令返回curl: (56) OpenSSL SSL_read: Connection was reset, errno 104。这说明不是 Cursor 的问题而是本地网络或代理拦截了 HTTPS 请求。最后发现是公司防火墙把api.deepseek.com加入了黑名单放行后一切正常。最后一个技巧把 curl 命令保存为.sh文件每次改配置就运行一次。我有个test_deepseek.sh里面就三行#!/bin/bash、curl -X POST ...、echo ---。改一个参数./test_deepseek.sh3 秒出结果。比在 Cursor 里点十次 Test Connection 还快。7. 那些没写在文档里的实战心得从踩坑到稳定的 7 条军规写了这么多技术细节最后分享我在真实项目中总结的 7 条军规。它们不是官方文档里的“最佳实践”而是我在连续三个月、每天调试 20 次 API 集成后用血泪换来的经验。军规一永远用curl验证永远不用 Settings 页面的 “Test Connection”。这个按钮只测 TCP 连通性和基础 HTTP 状态码200/401/403不校验模型名、不发送完整 payload、不测试 streaming。它成功了不代表你能用它失败了也不代表你不能用。我见过太多人因为 “Test Connection 成功” 就上线结果第一次 AI 补全就崩。军规二Provider 下拉菜单选完立刻去 Advanced Settings 里关掉 “Auto-detect model”。Cursor 默认开启这个功能它会根据你填的 base_url 自动猜测 Provider。比如你填https://api.anthropic.com/v1它就自动把 Provider 切成 Anthropic。但这个猜测是基于字符串匹配的https://anthropic-proxy.example.com/v1也会被当成 Anthropic。关掉它手动指定 Provider才能掌控全局。军规三所有 api_key粘贴后立刻在 Settings 里删掉再重填一遍。Windows 的 CtrlV 有时会带不可见字符如\u202a左向格式化符Mac 的 CmdV 有时会带富文本样式。Cursor 的输入框不清理这些导致 key 存储异常。删除重填强迫它做纯文本解析。军规四base_url 末尾绝对不加/model 名绝对不加引号api_key 绝对不加Bearer前缀。这是 Cursor 的硬性约定。它会在内部自动拼接/v1/chat/completions自动加Authorization: Bearer你加了就是重复必错。军规五遇到400错误第一反应不是改配置而是打开 DevTools → Network → 查看请求的 Request Payload。90% 的400是因为 payload 里model字段错了或者messages格式不符合 Provider 要求比如 Anthropic 要求system角色你没填。看原始 payload比猜配置快一百倍。军规六不要迷信 “Custom” Provider。它只是 OpenAI 的马甲。你想用非 OpenAI 协议的 API必须选对应的 Provider。没有 “万能 Provider”只有 “正确 Provider”。军规七当所有配置都确认无误还报错时重启 Cursor 并清空 Local Storage。Cursor 的配置缓存有时会错乱。CtrlShiftI→ Application → Clear storage → “Clear site data”。