中转站api怎么使用

刚注册完一家中转站，页面上一堆 Key、Base URL、模型名，复制到代码里却报 401 或者模型不存在——这类卡点基本都出在同一环节。这篇按「先看懂要抄哪三样东西、再手动跑通一次、最后接进自己工具」的顺序走，帮你把第一次调用做完，至于站点靠不靠谱、钱怎么分，另有专门的文章。

刚注册完一家中转站，页面上到处是 Key、Base URL、模型名，好不容易复制到代码里，一跑就弹回 401 或者「模型不存在」。这类卡点十有八九不在代码水平，而在开头那一步：你没抄全该抄的东西，或者抄错了地方。下面按「看懂要抄哪三样、手动跑通一次、接进自己工具、出问题怎么查」的顺序走一遍，照着做基本能把第一次调用做完。

先划清边界：这篇只讲怎么用，不评站点靠不靠谱、不聊计价方式、也不讨论充值怎么操作，那些站内另有页面专门写。你只要盯住一件事——让第一行请求成功返回内容，剩下的就好办了。

先搞清楚要抄哪三样东西

一家中转站要能调起来，本质上只需要三样：一个 Key、一个接口地址（有人叫 Base URL、有人叫端点）、一个可用的模型名。其余像超时、温度、最大长度都是可选项，调通了再慢慢加。新手最常见的错误是把「网页登录状态」和「API Key」当成一回事，网页能点不代表代码能用。

Key

在「令牌 / API Keys」页生成的一串字符，是代码的身份凭证，跟你的账号密码不是一回事

Base URL

接口地址，告诉你请求发到哪里；注意有的站给的是带版本路径的完整地址，有的只给域名

模型名

请求里声明用哪个模型，必须和站点「模型列表」里写的完全一致，大小写和横杠都别改

• 先把三样东西分别找到，写在记事本上对齐，再动手改代码，比边试边找快得多
• 接口地址以「接入文档」页给出的示例为准，首页宣传图上的地址经常只是展示用
• 模型名去「模型列表」页复制，别凭记忆敲；很多「模型不存在」就是手打错一个字母
• 不确定选哪个模型时，先挑站内标注为通用、支持对话的那个，别一上来就挑名字最长最贵的
• 生成 Key 后立刻复制保存，多数站点只完整显示一次，关掉页面就看不到原文了

用最简单的方式跑通第一次调用

代码之前先做一次「网页试跑」。大多数中转站有自带的在线调试或试跑页面，在里面发一句话，能返回内容就说明 Key、额度、模型这条链路是通的。这一步的价值在于把「站点问题」和「你自己代码的问题」分开，省掉大量无谓排查。

1. 站内试跑打开站内的在线调试页，选一个模型发一句简单问题，确认有返回内容；这一步报错就直接找客服，别往下走
2. 命令行手动发一次用 curl 或 Postman 按文档示例发一次请求，重点核对请求头里的鉴权字段写法，是 Bearer 还是别的形式，以及接口路径拼得对不对
3. 换个模型再试一次同样请求换个模型名，确认这个 Key 有权限调多个模型，也顺便验证站点模型名和你以为的是不是一个
4. 用临时脚本兜底如果命令行不方便，用官方 SDK 的示例程序建个临时脚本跑一次，跑通再往正式项目里迁

curl -X POST "把接口地址粘这里" -H "Authorization: Bearer 把Key粘这里" -H "Content-Type: application/json" -d '{"model":"把模型名粘这里","messages":[{"role":"user","content":"你好"}]}'

第一次调用千万别直接接进生产代码。临时脚本或试跑页面的意义就是隔离变量，出错了你知道问题只在配置，不掺业务逻辑。跑通之后再迁移，心里有底。

接进常用客户端和脚本

大多数中转站的接口按官方格式兼容，所以配置思路可以简化成一句话：原来填官方地址的地方换成中转站地址，原来填官方 Key 的地方换成站点发的 Key，其余参数不动。理解了这一点，换任何工具都是同一套动作。

• 优先用环境变量或配置文件存 Key 和地址，别硬编码进代码，避免分享时把 Key 一起发出去
• 同一台机器接多家站点时，给每家单独建一份配置或 profile，别在同一个变量里来回改
• 把配置文件加进忽略清单，防止误提交到代码仓库
• 换工具时先小范围试跑一次再正式用，工具自身的适配问题往往在跑起来才暴露
• 记录下这次成功的地址、模型名、SDK 版本，换机器时直接复用

调不通时的排查顺序

排查最怕跳步。按「Key → 地址 → 模型名 → 额度 → 网络」这个顺序往下走，前面的没确认就别怀疑后面的。绝大多数新手卡点都集中在前三项，直接跳到网络层查是浪费时间。

拿错误原文去问客服，比自己猜快得多。把请求的接口路径、用的模型名、返回码和完整报错一起贴过去，对方基本能一步定位，不用来回追问。比起描述「我调不通」，给原文能让沟通轮次少一大半。

跑通之后该做的事

第一次成功返回内容，只代表这条路是通的，不代表能长期用。接下来要做的是把配置固化下来，同时给自己留后路，别让整条链路吊在一家站点上。

• 把这次成功的配置记下来，包括地址、模型名、SDK 版本，下次换机器或换工具直接复用
• 先用真实但小规模的任务跑几天，观察延迟和稳定性，别刚跑通就大批量压上去
• 同时准备第二家的 Key 作为备份，切换时只改地址和 Key，其余代码不动
• 定期回站点看模型列表和公告有没有变化，模型下架或改名会直接让你的代码报错
• 判断站点值不值得长期依赖的标准和当时的对比数据，到 /sites 核对

这套顺序里唯一不能省的是「站内先试跑」和「命令行再试一次」这两步。跳过它们，后面所有报错你都会怀疑是代码问题，实际上大多只是少抄了一个斜杠或者 Key 复制漏了尾巴。

先让最简单的请求成功返回一次，再谈接进项目和规模化，顺序反了就是无穷无尽的猜。