补全

兼容需要传统 prompt 形式的场景时，可以使用这个接口。

如果你是第一次写新脚本，不建议从这页开始。多数新项目优先使用 聊天。这一页更适合已经存在的旧脚本、旧工具或只认 prompt 的历史集成。

创建补全 POST

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

常用请求参数

• model：模型名称
• prompt：输入文本
• max_tokens：最大输出长度
• temperature：输出随机性

这里和聊天接口最大的区别，是它直接接收一段 prompt 字符串，而不是 messages 数组。

这也是为什么它更适合旧脚本：
旧程序往往只知道“把一整段文本丢进去，拿回一整段文本”，并不知道多轮消息结构是什么。

第一次建议怎么测

第一次验证补全接口时，重点不是让模型立刻写出一篇长文，而是先把三层问题拆开：

1. 这把 Key 能不能访问 /v1/completions
2. 这个模型是不是支持补全接口
3. 这段 prompt 本身是不是已经把输出压得太长

所以第一次最好只发一条很短的 prompt。
短 prompt 的意义，不是节省那几十个 token，而是让你更容易判断问题停在接口层、模型层，还是只是参数给得太激进。

示例请求

先把 MODEL 替换成你在模型广场复制、且确认支持补全接口的模型名：

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

curl https://xiaolan.ainb.plus/v1/completions \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer <你的 API Key>" \
  -d "{\"model\":\"$MODEL\",\"prompt\":\"写一个 Python 读取 JSON 文件的例子\",\"max_tokens\":300}"

第一次验证时，先用一段短 prompt。这样更容易区分是接口不支持、模型不支持，还是只是输出被截断。

响应

重点看 choices[0].text。

如果你已经能拿到 choices[0].text，说明这把 Key、当前模型和补全接口链路已经正常工作。

如果响应里还能看到 usage，也建议顺手看一下。
它能帮助你确认这次请求到底吃了多少输入和输出 token，后面你再调 prompt 长度和 max_tokens 时，会更有感觉。

常见参数怎么理解

• prompt：真正交给模型补全的原始文本
• max_tokens：这次最多允许它再往后写多少
• temperature：越高越发散，越低越稳定

第一次接入时，temperature 不需要一开始就调。
把地址、Key 和模型跑通以后，再根据业务看要不要继续追求更稳定或更开放的输出。

什么时候用它

• 老脚本只支持 prompt
• 某些第三方工具还没切到聊天接口
• 你明确知道当前模型支持传统补全格式

新项目优先用 聊天。

迁移建议

如果你的脚本还能改，建议逐步迁到 /v1/chat/completions：

{
  "model": "从模型广场复制、且支持补全接口的模型名",
  "messages": [
    {"role": "user", "content": "原来的 prompt 内容"}
  ]
}

聊天接口更适合多轮上下文，也更贴近现在主流客户端。

如果你正在维护旧脚本，可以先用下面这个思路迁移：

• 原来的 prompt 内容，先原样塞进一条 user 消息
• 原来靠字符串拼接实现的上下文，逐步拆成多轮 messages
• 先验证输出结果，再逐步加入 system 规则

这样比一次性重写整套提示词更稳。

常见问题

choices 为空

先检查模型是否支持补全接口。部分新模型只支持聊天或 Responses API。

如果你已经确认模型本身没问题，再回头看 prompt 是否为空、是否被 shell 转义破坏了原文。

输出被截断

提高 max_tokens，或者把输入拆小。

如果你的 prompt 本身已经很长，再继续拉高 max_tokens，结果通常不是“更稳”，而是更贵也更难判断真正问题在哪。
第一次排障时，优先缩短输入，通常比一味拉大参数更有效。

明明模型能聊天，为什么补全接口不能用

聊天接口可用，不代表同一个模型一定支持传统补全格式。遇到这种情况，优先回模型广场确认模型能力，或者直接改走聊天接口。