OpenAI 兼容 API 是什么：Base URL、鉴权和返回格式怎么核对

“OpenAI 兼容 API”通常表示服务能够接受一部分与 OpenAI API 相近的请求约定，方便支持相同配置方式的客户端接入。它不是一个无限范围的承诺：不同服务对端点、模型、流式返回、工具调用、文件能力和错误格式的支持可能不同。把“兼容”理解成“每个功能都完全相同”，是 API 配置失败的常见起点。

兼容性至少要看四层

1. Base URL：客户端需要的是接口前缀，而不是产品网页首页。地址是否包含 /v1，由客户端文档和服务说明共同决定。
2. 鉴权方式：API Key 的传递位置由客户端处理。不要把 Key 放进 URL、前端脚本、截图或仓库。
3. 协议与端点：一个客户端支持哪种请求形态，要以其当前版本为准。例如 Codex 的配置需要按它的 Responses 约定核对。
4. 返回格式：即使请求发出成功，也要用最小测试检查客户端能否正确解析响应与错误。

为什么 Base URL 经常配错

很多工具会在 Base URL 后自行拼接路径。如果再手动填写 /responses、/chat/completions，或重复附加 /v1，实际请求就可能落在错误地址。解决方法不是逐个试字符串，而是先读当前客户端字段说明，再用 Base URL 排错顺序检查最终路径。

如何验证“能接入”，而不是只验证“能打开页面”

1. 记录客户端和插件版本。
2. 填写脱敏的最小配置，不把业务资料放进首个请求。
3. 确认协议后只做一次短请求。
4. 观察状态码、返回结构和客户端日志；出现问题时沿着地址、鉴权、协议、权限的顺序逐项排查。

OpenAI 的开发者接口概念应以 OpenAI API 官方文档为准。若你用的是 Codex，还应看 Codex CLI 文档，不要把其他工具的字段名直接套进 Codex。

与 AI API 中转站的关系

中转站可以提供 OpenAI 兼容的服务入口，但仍需要你验证自己的客户端和目标协议是否匹配。需要继续比较入口时，阅读 AI API 中转站是什么；需要理解协议边界时，阅读 Responses API 与 Chat Completions 怎么选。当你已经确认本地配置条件，再前往 Shana 的 Codex 接入说明核对当前服务信息。