第 9 章:对话结构——顺便推开 API 的门

9.1 还记得第 5 章吗

第 5 章讲过:和模型对话有三层结构——System 设底色,User 发请求,Assistant 回回答。

当时你看到的是概念。现在我们看看它在 API 里真正长什么样。

一个真实的 API 请求,核心部分长这样:

{
  "model": "deepseek-v4-pro",
  "messages": [
    {"role": "system", "content": "你是一个翻译助手。只翻译,不解释,不加评语。"},
    {"role": "user", "content": "Hello, how are you?"}
  ]
}

三个字段,对应三个角色:

字段	对应角色	类比
"role": "system"	System Prompt	厨师守则——贴在厨房墙上的规矩
"role": "user"	User Message	客人点菜
"role": "assistant"	Assistant Message	厨房端出来的菜

这就是 API 请求的门缝里透出来的第一道光。格式不复杂——你认识这三个 role,就认识了对话结构的骨架。

---

9.2 API 不帮你记聊天记录

API 服务端不会主动记录你的对话上下文。就像你每次去传菜口,厨房不会记得你上一轮点了什么—— 你得把整段对话重新说一遍。

所以实际代码里,每次请求都要自己拼完整的 messages 数组:

第一轮传:
messages = [
  {system: "你是翻译助手"},
  {user: "珠穆朗玛峰有多高?"}
]
模型回:"8848 米"

第二轮你得传:
messages = [
  {system: "你是翻译助手"},
  {user: "珠穆朗玛峰有多高?"},
  {assistant: "8848 米"},        ← 上一轮的回答也要带上
  {user: "那第二高呢?"}         ← 这才是新问题
]

整段历史每次都要带着——这就是为什么第 6 章说"聊得越久越贵"。你传的 messages 越来越长,输入 token 越来越多,钱就这样花出去的。

厨房只负责做菜,不负责记你说了什么。记性是你在代码里管的。

但传归传,钱不一定全收。 虽然每次都要把完整历史塞进请求,但服务端不傻——前面重复的部分可以通过 KV Cache 跳过计算,输入 token 费用会打折。还记得第 4 章讲的 DeepSeek 缓存命中 0.025 元/百万 token 吗?就是这个机制在省钱。具体原理见第 13 章。

---

9.3 速率限制——厨房忙不过来了

API 不是无限供应的。当请求太多,服务端会限制你。

情况	返回	翻译成人话
并发太多	HTTP 429	"别再点了!厨房炸了!"
排队等待中	服务端发来的"心跳信号"	"还没轮到你,但我在听……"
排队超时(~10 分钟)	连接断开	"太久了,下次再来吧"

429 是最常见的限速错误。遇到它别慌——不是你的请求有问题,是厨房灶台不够用。等几秒重试就好。

---

9.4 常见错误码——厨房给的回复

每次调用 API,服务端会返回一个三位数状态码。和浏览网页一样。

状态码	含义	翻译成人话	你该做什么
200	成功	菜端出来了	吃
400	请求格式错误	"你这点的什么乱七八糟的"	检查参数拼写
401	没权限	"你谁啊?门禁卡呢?"	检查 API Key
429	超并发/超频率	"锅不够用了!"	等几秒重试
500	服务器内部错误	"厨房着火了"	重试,不行就找服务商
503	服务不可用	"今天歇业"	过会儿再来

小白记住三个就够了:401 查 Key,429 等一等,500 甩给服务商。

---

本章要点

概念	一句话
对话三要素	system(守则)+ user(点菜)+ assistant(端菜),在 API 里是 messages 数组里的三种 role
API 不记聊天	每次请求带完整历史——这就是为什么聊得越久越贵
KV Cache	传归传,重复的部分可以打折,第 4 章的 DeepSeek 缓存价格就是这个
429	最常见限速错误,等几秒重试就行
401/429/500	查 Key / 等一等 / 甩给服务商