核心要点
能说清核心参数：model 选型、messages（system 定角色 + user 给任务）、temperature 控随机性、max_tokens 控输出长度
能讲一条完整调用流程：构造请求 → 发送 → 处理超时/重试/限流 → 解析返回 → 统计 token 计费
知道工程兜底：设超时、指数退避重试、捕获 4xx/5xx 报错、对 429 限流退避
知道流式（stream）与结构化输出（JSON）的用法，避免一次性等待长响应
标准回答
关键参数
model 决定能力与价格；messages 是核心，system 设定角色和规则、user 放具体任务（多轮就把历史依次放进去）；temperature 01，问答/抽取用 00.3 求稳定，创意用 0.7+；max_tokens 限制输出长度（防止超长烧钱）；top_p 是另一种采样控制，一般与 temperature 二选一调；stop 指定停止符；seed 固定可复现；stream=true 边生成边返回，改善体验。
一条调用流程
1）把任务写成 system + user 的 messages；2）设 temperature、max_tokens；3）发请求并设超时（如 30s）；4）失败按指数退避重试 2~3 次，对 429 限流单独退避；5）解析返回里的 content，校验格式（要 JSON 就让模型只输出 JSON 再 parse）；6）从返回的 usage 读 prompt/completion token 数，按单价算成本并记日志。
示例
调天气助手：system=「你是天气助手，只用中文简短回答」，user=「北京明天穿什么」，temperature=0.3，max_tokens=200。
常见误区
⚠️ 常见踩坑
把所有逻辑塞进一个超长 prompt 又不设 max_tokens，结果输出失控、token 暴涨；以及不做超时和重试，线上偶发限流/网络抖动就直接报错给用户。
追问
追问 1：要模型稳定输出 JSON 给下游解析，怎么做？
优先用 API 的结构化输出 / JSON mode（强制返回合法 JSON）；没有该功能时在 system 里给出字段定义和示例、要求「只输出 JSON 不要解释」，并在代码里 try/catch 解析，失败就重试一次或做正则提取兜底。
追问 2：线上调用偶尔超时或返回 429，如何处理？
超时设合理上限并配指数退避重试（如 1s、2s、4s）；429 是限流，按返回的 Retry-After 退避，必要时做客户端限速、请求排队或多 key 轮询；同时降级（如返回缓存结果或友好提示），并监控失败率告警。
延伸学习
与本题相关的知识库文章、术语、工具与行业资讯。