聊天

大多数文本对话、代码生成、问答类请求，都走这个接口。

如果你不知道该用哪个文本接口，优先从这页开始。对大多数用户来说，/v1/chat/completions 是最常用、也最容易验证的一条链路。

创建聊天完成 POST

地址：POST https://xiaolan.ainb.plus/v1/chat/completions

第一次测试前，先确认三项：

1. 你已经有一把可用 Key
2. 你已经从模型广场复制了真实模型名
3. 你知道自己当前用的是 OpenAI 兼容接口，而不是 Claude Code 的 Anthropic 根地址

这里的地址固定是：

https://xiaolan.ainb.plus/v1/chat/completions

如果你只是想先证明这条 OpenAI 兼容链路通不通，这一页的最小 curl 通常比先上桌面客户端更直接。

常用请求参数

• model：模型名称，从模型广场复制
• messages：对话数组
• temperature：可选，控制输出随机性
• stream：可选，是否流式返回

messages 结构

最常见写法：

[
  {"role": "system", "content": "你是一个代码助手"},
  {"role": "user", "content": "帮我写一个 Go 的 HTTP 服务"}
]

三种最常见的角色可以这样理解：

• system：提前说明规则、身份或输出要求
• user：用户本次真正提出的问题
• assistant：上一轮模型已经给出的回答

第一次联调时，不需要把多轮历史都带上。先发一条最短的 user 消息，确认接口能通，再继续加系统提示词和历史上下文。

很多“怎么一上来就又慢又贵”的问题，都是从第一条请求就把多轮历史一起带进去导致的。
第一次测试时，消息越短，越容易分清是配置问题，还是上下文本身太大。

示例请求

先把 MODEL 替换成你在模型广场复制的实际模型名：

MODEL="替换成模型广场里的实际模型名"

curl https://xiaolan.ainb.plus/v1/chat/completions \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer <你的 API Key>" \
  -d "{\"model\":\"$MODEL\",\"messages\":[{\"role\":\"user\",\"content\":\"你好，返回一段 Go hello world\"}]}"

如果你只是想判断配置有没有写对，第一次建议把内容写得越短越好。短消息更容易区分是配置问题，还是模型排队和上下文过长问题。

响应（非流式）

重点看 choices[0].message.content。

常见结构：

{
  "choices": [
    {
      "message": {
        "role": "assistant",
        "content": "你好"
      }
    }
  ],
  "usage": {
    "prompt_tokens": 12,
    "completion_tokens": 8,
    "total_tokens": 20
  }
}

usage 是计费和排查成本时最常看的字段。

第一次接通后，顺手多看一眼 usage 通常很有价值。
这样你很快就能知道：这次请求到底只是普通短对话，还是上下文已经大到会明显影响成本。

只要你已经拿到 choices[0].message.content，通常就说明这几件事已经同时成立：

• Key 可用
• 模型名正确
• 当前模型权限允许访问
• Base URL 填写正确
• 当前网络可以访问 小蓝中转站 网关

流式响应（stream=true）

需要流式输出时，把 stream 设为 true。终端工具和部分客户端会自动处理。

命令行测试时建议加 -N，避免 curl 缓冲输出：

MODEL="替换成模型广场里的实际模型名"

curl -N https://xiaolan.ainb.plus/v1/chat/completions \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer sk-你的专属Key" \
  -d "{\"model\":\"$MODEL\",\"stream\":true,\"messages\":[{\"role\":\"user\",\"content\":\"用三句话介绍 小蓝中转站\"}]}"

看到终端逐段返回内容，说明流式链路也已经打通。
如果非流式正常、流式异常，优先看客户端或当前网络对长连接的处理，而不是先怀疑 Key。

Node.js 示例

const response = await fetch('https://xiaolan.ainb.plus/v1/chat/completions', {
  method: 'POST',
  headers: {
    'Content-Type': 'application/json',
    Authorization: `Bearer ${process.env.小蓝中转站_API_KEY}`,
  },
  body: JSON.stringify({
    model: process.env.小蓝中转站_MODEL,
    messages: [{ role: 'user', content: '你好' }],
  }),
})

const data = await response.json()
console.log(data.choices[0].message.content)

运行前：

export 小蓝中转站_API_KEY="sk-你的专属Key"
export 小蓝中转站_MODEL="替换成模型广场里的实际模型名"
node demo.js

第一次写脚本时，建议把 Key 和模型名放进环境变量，而不是直接写死在源码里。后面切模型或更换 Key 时，也不用反复改代码。

Python 示例

import os
import requests

resp = requests.post(
    "https://xiaolan.ainb.plus/v1/chat/completions",
    headers={
        "Content-Type": "application/json",
        "Authorization": f"Bearer {os.environ['小蓝中转站_API_KEY']}",
    },
    json={
        "model": os.environ["小蓝中转站_MODEL"],
        "messages": [{"role": "user", "content": "你好"}],
    },
    timeout=60,
)

data = resp.json()
print(data["choices"][0]["message"]["content"])

运行前先设置：

export 小蓝中转站_API_KEY="sk-你的专属Key"
export 小蓝中转站_MODEL="替换成模型广场里的实际模型名"

Responses API

部分新工具会使用 Responses API。按照 OpenAI 近年的接口方向，新项目和新工具经常会优先接这个入口。小蓝中转站 同样提供兼容地址：

POST https://xiaolan.ainb.plus/v1/responses

大多数用户优先使用聊天接口。只有客户端明确要求 Responses API 时，再配置该入口。

也就是说：

• 你自己写最小脚本、日常联调：先用聊天接口最省时间
• 某个工具文档明确写死 Responses API：再切到 /v1/responses

常见问题

返回 401 / 鉴权失败

先检查：

• Key 是否复制完整
• Header 是否写成 Authorization: Bearer <Key>
• 这把 Key 是否已被禁用

返回模型不存在

说明模型名写错，或者这把 Key 没有该模型权限。直接回模型广场复制模型名。

返回 429

请求太密集，或当前 Key / 模型触发限速。降低并发，换轻量模型，或稍后重试。

响应很慢

先换轻量模型测试。轻量模型正常时，多半是当前模型排队或上下文太长。

明明能打开控制台，接口还是失败

控制台能打开，只能说明网页可访问；并不代表你的 Key、模型名和接口地址已经正确。最稳的判断方法仍然是回到这页的最小 curl 请求做一次验证。

下一步

• 模型列表
• 排障手册