常用调用参数

max_tokens、top_p、stream、system，每个参数在产品上意味着什么。

参数不多，但每一个都直接对应一种用户能感受到的问题。你不用会调，得知道调错了会怎样——因为很多「模型不行」的投诉，根子在参数上。

你会遇到的现象：

• 回答老是在半句话处戛然而止，像是被人掐断了
• 要它输出固定格式，十次里有两次多带一段客套话
• 用户抱怨「太慢了」，但后台看响应时间其实不长

管「说什么」

**system —— 系统提示。**放在对话最前面、每一轮都带上的那段设定：产品的角色、语气、边界、禁区。它和普通消息的区别在于优先级更高，也更稳定。产品的「性格」写在这里。

顺带一个成本提示：它每轮都要重发，所以是最该做缓存的一段。把固定内容放前面、变化内容放后面，缓存命中率会高很多。

**temperature —— 随机性。**这个参数值得单独一节，温度与随机性那篇讲透了。这里只记一条：要稳定输出就调低，默认值往往偏高。

**top_p —— 另一种控制随机性的方式。**它和温度的路子不同：温度是调整每个候选词的概率分布，top_p 是只从概率累计到某个比例的那批候选里挑。

实际使用上你只需要知道：**两个一般只调其中一个，通常调温度。**两个一起调，效果会互相干扰，很难说清是哪个在起作用。

管「说多少」

**max_tokens —— 输出长度上限。**这是最常见的翻车点。各家的 API 参考里都有它，但它同时也是账单的主要旋钮，因为输出比输入贵好几倍。所以这个值不是越大越好：设太小会截断，设太大则失去了成本保护。openai-api-ref

它是硬截断：模型写到这个长度就被强行停住，不会自己收尾。所以症状很典型——回答在半句话处戛然而止。用户会以为是网络问题或者产品有 bug。

实践建议：按功能分别设置，而不是全局一个值。摘要功能给的额度和长文生成显然不该一样。另外，在提示词里也说明期望长度（「用三句话回答」），让模型自己收着写——这比靠 max_tokens 硬砍体面得多。最后，要能识别「因为长度上限而结束」这种情况，接口会告诉你，别把截断的半截内容直接展示给用户。

**stop —— 停止序列。**遇到指定的字符串就停下。用在结构化输出、或者防止模型自问自答继续往下编的场景。用得不多，但知道有这个东西。

管「怎么给」

stream —— 流式输出。这是所有参数里对产品体验影响最大的一个，但它影响的不是真实速度，是感知速度。

不开流式，用户盯着转圈等好几秒，然后整段出现；开了流式，第一个字几百毫秒就到，然后一个字一个字往外冒。总耗时可能一模一样，但体感差得非常远。——前者像卡住了，后者像在思考。技术上它通常走服务端事件流之类的传输方式。sse-wiki

所以只要是用户直接等着看的场景，基本都该开。代价是工程上要处理流式传输，以及「生成到一半失败了」这种中间状态。

**response_format —— 强制输出格式。**要模型返回 JSON 之类的结构化数据时用。比在提示词里写「请只返回 JSON」可靠得多——后者十次里总有一两次给你多带一段「好的，这是您要的结果：」。

如果你们的功能要把模型输出接进程序里，这个参数几乎是必开的。

**seed —— 可复现。**固定它，理论上同样输入能得到同样输出。但要注意：**厂商通常只承诺「尽最大努力」，不保证完全复现。**模型服务端的版本、批处理方式都会影响结果。所以别把它当成严格的确定性保证，做测试基线时可以用，做合规审计不行。

四个场景的配法

拿不准就先照这个来，再按实测微调。

这是起点不是标准答案。真正的配法要拿你自己的样例跑出来——同一组样例、不同参数各跑一遍，比较结果。

最后一条通用提醒：**默认值几乎从来不是你要的那一档。**厂商的默认值是为「通用聊天」调的，而你做的多半是个具体功能。每上线一个功能，这三类参数都该过一遍。