一句话定义
LLM API 是模型能力的程序化接口。你发送一段消息数组，得到一个回复。它没有状态、没有记忆、没有会话——所有「上下文」每次都要你重新发送。
这个事实看似简单，却是 AI 应用工程里最重要的一个前提。
为什么重要
它划清了「用 AI」和「做 AI 产品」的界限。
在聊天窗口里，上下文由产品帮你管理。在 API 里，上下文完全由你负责：保存什么、发送什么、截断什么、花多少钱——都是你的设计决策。这也意味着你把控制权拿回来了。
请求的基本结构
{
"model": "…",
"messages": [
{ "role": "system", "content": "你是…" },
{ "role": "user", "content": "…" },
{ "role": "assistant", "content": "…" }
],
"temperature": 0.2,
"max_tokens": 1024,
"stream": true
}关键点：
- messages 是完整历史。每次请求都要把之前所有轮次重新发一遍，费用按总 token 计。
- system 消息不是「设定一次」，它只是数组的第一项，同样每次都要发。
- 多轮对话的成本是二次增长的：第 N 轮的输入包含前面 N-1 轮的内容。
几个必须理解的参数
| 参数 | 作用 | 实用建议 |
|---|---|---|
| temperature | 采样随机性 | 抽取/分类用 0–0.3，创意写作用 0.7+ |
| max_tokens | 输出上限 | 设小可以防止跑飞，设太小会截断 |
| stream | 流式返回 | 交互场景必开，用户感知延迟大幅下降 |
| stop | 停止序列 | 结构化输出时有用 |
| top_p | 另一套采样控制 | 通常只调 temperature 即可 |
工程上真正难的部分
- 重试与限流：模型服务会超时、会 429。必须有退避重试。
- 成本控制：输入 token 通常比输出便宜，但输入量大得多。缓存与摘要很关键。
- 可观测性：记录每次请求的输入、输出、耗时、token 数，否则无法优化。
- 模型切换：不要把某个模型的特性写死在业务逻辑里，用一层薄适配。
常见误解
- 「API 会记住对话」：不会。忘记发送历史是最常见的 bug。
- 「prompt 写一次就能一直用」：模型版本更新会改变行为，需要回归测试。
- 「直接拼接用户输入即可」：必须区分「指令」与「数据」，否则会有提示注入风险。
延伸阅读
- Tool Calling：让模型突破纯文本的下一步
- Evals：如何知道换模型之后有没有变差