把协议分清楚
我会把开发工具分成两类：一类按 Anthropic 原生 API 说话，另一类按 OpenAI-compatible 协议说话。Claude Code 的配置要看 Anthropic 官方文档，不能因为名字里有 Claude，就假设它能吃任何 OpenAI 风格 endpoint。
OpenAI-compatible 更像一套事实标准：很多网关会模仿 OpenAI 的路径、鉴权和请求字段，让 Cursor、Continue、Aider、LiteLLM 这类工具少改代码接入多模型。但「能发请求」不等于「所有高级能力都一样」。
| 字段 | 作用 | 常见错误 |
|---|---|---|
base_url | API 根地址 | 多写 /v1 或少写 /v1 |
api_key | 鉴权和计费 | 用错供应商 key |
model | 路由到具体模型 | 模型名和网关不一致 |
| headers | 供应商扩展 | 缺版本号或 beta 标记 |
支持 OpenAI-compatible 的工具怎么配？
先找工具文档里的三个词：custom endpoint、OpenAI compatible、base URL。看到这些，再改配置。没看到就不要猜。
一个典型配置长这样：
OPENAI_BASE_URL=https://api.example.com/v1
OPENAI_API_KEY=sk-xxx
OPENAI_MODEL=claude-sonnet-or-gpt-model如果工具把 base_url 固定写死，你有两个选择：换支持自定义 endpoint 的工具，或者在本地起一层代理，把工具请求转到真正的模型供应商。后者适合团队，个人 PoC 不一定值得。
Claude Code 相关场景怎么处理？
按 Claude Code 官方文档配置。需要多模型、统一计费或路由时，不要在文章或 runbook 里写「Claude Code 一定支持 OpenAI-compatible」。更稳的表达是：Claude Code 走它支持的官方配置；其他支持 OpenAI-compatible 的开发工具走自定义 base_url；两边在网关层统一日志和预算。
如果你确实要把多家模型纳入一套开发栈，我建议这样拆：
| 场景 | 推荐做法 |
|---|---|
| Claude Code 生产使用 | 按 Anthropic 文档配置 |
| Cursor / Continue | 使用工具支持的 custom endpoint |
| 团队统一额度 | LiteLLM 或自建网关 |
| 成本审计 | 网关记录 user、model、token |
怎么验证配置没跑偏？
第一，跑一个最小请求，确认不是 401 或 404。第二，跑 streaming，看长输出会不会半路断。第三，跑工具调用或代码修改任务，因为这比普通聊天更容易暴露协议差异。第四，看账单和日志，确认模型没有被路由到错误档位。
开发环境可以接一家Cursor / Claude Code 国内可用的 API 中转做快速验证，但上线前仍要保留 provider 抽象。以后换官方 key、备用网关或不同模型时，别让业务代码跟着大改。