开发者LLM API入门：聊天补全实践指南

AI2026-09-22TryQuickToolBox

你对某个AI驱动的功能有了很棒的想法，但当你开始阅读API文档时，却被一堆术语挡住了去路：token、temperature、流式传输、系统提示。感觉像是需要再读一个学位才能发送一条消息。好消息是，核心概念其实很简单：你发送一个消息列表，模型返回一条回复。其余的都只是调优。本文将带你逐步实践，把LLM聊天补全API集成到你的应用中，代码可以直接拿来用。

什么是聊天补全API？

本质上，聊天补全API接收一段对话历史作为输入，并返回对话中的下一条消息。历史记录是一个消息对象数组，每个对象包含role和content。角色通常有system、user和assistant。系统消息设定助手的行为，用户消息是人输入的内容，助手消息是模型之前回复的内容。通过发送完整的历史记录，你为模型提供了生成连贯回复所需的上下文。

大多数提供商（OpenAI、Anthropic、Google以及开源替代方案）都遵循类似的模式，尽管具体的端点和请求负载可能不同。一旦你理解了一种，就能很快适应其他的。

分步实践：你的第一次API调用

让我们用一个使用Python和OpenAI SDK的最小示例来走一遍。你可以通过pip install openai安装它。将API密钥设置为环境变量，避免把它写进代码里。

import os
from openai import OpenAI

client = OpenAI(api_key=os.environ["OPENAI_API_KEY"])

response = client.chat.completions.create(
    model="gpt-4o-mini",
    messages=[
        {"role": "system", "content": "You are a helpful assistant."},
        {"role": "user", "content": "Explain what an API is in one sentence."}
    ]
)

print(response.choices[0].message.content)

就是这样。响应对象包含一个choices列表；通常你取第一个。消息内容就是模型的回复。你还可以访问usage统计信息来追踪token消耗。

你应该调优的关键参数

除了messages之外，还有几个参数控制模型的输出：

model：使用哪个模型。较小的模型更便宜、更快；较大的模型能力更强。
temperature：控制随机性。0是确定性的，1是创造性的。对于事实性任务，使用较低的值；对于头脑风暴，使用较高的值。
max_tokens：限制回复的长度。设置此项以避免意外过长（且昂贵）的响应。
top_p：控制多样性的另一种方式，可替代temperature。通常只调整其中一个，而不是两个都调。
stream：当为true时，API会在生成过程中发送部分响应，改善感知延迟。

流式响应带来更好的用户体验

等待完整响应可能会感觉很慢，尤其是对于较长的答案。流式传输让你可以在文本到达时立即显示。以下是在Python中处理流的方式：

stream = client.chat.completions.create(
    model="gpt-4o-mini",
    messages=[{"role": "user", "content": "Tell me a story."}],
    stream=True
)

for chunk in stream:
    delta = chunk.choices[0].delta.content
    if delta:
        print(delta, end="", flush=True)

每个chunk包含一个delta，其中是响应的一部分。你将这些片段累积起来以构建完整消息。在Web应用中，你可以使用Server-Sent Events（SSE）或WebSockets将这些chunk转发到浏览器。

处理错误和速率限制

API会失败。网络会抖动。速率限制会触发。你的集成应该优雅地处理这些情况。常见错误包括：

401 Unauthorized：API密钥无效。检查你的环境变量。
429 Too Many Requests：你触发了速率限制。实现指数退避并重试。
500 Internal Server Error：提供商侧的问题。延迟后重试。

始终将API调用包裹在try/except块中并记录失败。对于生产环境，可以考虑使用像tenacity这样的库来实现重试。

管理成本和Token

Token是LLM API的货币。输入和输出token都会计入你的账单。为了让成本可预测：

对简单任务使用较小的模型。
当不需要完整上下文时，将对话历史裁剪到最近几条消息。
设置max_tokens来限制输出长度。
如果你的用例允许，缓存频繁出现的响应。

通过提供商的仪表板或记录每次响应的token数量来监控使用情况。

安全与隐私考量

当把用户数据发送到LLM API时，你是在信任第三方来处理这些数据。查看提供商的数据保留政策。避免发送密码或个人标识符等敏感信息。如果必须发送，可以考虑自托管模型或具有强隐私保障的提供商。另外，永远不要在客户端代码中暴露你的API密钥；始终通过你的后端代理请求。

常见问题

聊天补全和普通补全有什么区别？

聊天补全是为对话式界面设计的。它们接受带有角色的消息列表，允许模型维持上下文。普通补全接受单个提示字符串，不太适合多轮对话。

如何选择合适的模型？

从较小、较便宜的模型开始做原型。如果你需要更好的推理能力或更长的上下文，再转向更大的模型。在你的具体任务上测试两者，找到最佳的成本性能权衡。

我可以在一个应用中使用多个LLM提供商吗？

可以。许多开发者将API调用抽象在一个接口后面，并根据成本、延迟或功能切换提供商。像LiteLLM或LangChain这样的库可以帮助统一不同的API。

后续步骤

现在你已经能进行基本调用了，可以尝试用系统提示来引导模型的行为。试试流式传输来改善用户体验。并且始终关注token使用情况。在构建过程中，你可能需要格式化模型返回的JSON响应以便进一步处理。为此，一个JSON格式化工具可以帮助你快速验证和美化输出。