同一句提示词，有时得到简洁答案，有时突然变成一大段解释。很多人把这种变化都归结为“温度太高”，于是把 temperature 改成零，希望 AI 从此稳定、准确。温度主要影响生成时的取样方式，不是事实准确率开关，也不是输出格式校验器。

本文解释 temperature 与 top_p 的区别，并设计一个不涉及敏感信息的小练习：给一段活动通知生成三个短标题。你将学会先查参数是否生效，再比较变化，最后把设置写进可复查的记录。所有输出示例都是教学说明，未调用付费接口，不提供虚构测试结果。

一、先理解模型是在一段段选择文字

生成模型通常不是从固定答案库中抽取一整篇成稿，而是根据已有内容，逐步生成后续 token。面对多个可能的后续选择，取样策略影响最终走哪条路径。

可以把它想成写“请于周五”之后，模型可能接“报名”“提交资料”“前往现场”。这些候选与上下文有关，概率也不相同。实际模型处理的是 token，未必对应完整汉字或词语；这个比喻只是帮助理解选择过程。

temperature 会调整候选概率分布的尖锐程度。较低温度通常让较高概率候选更占优势；较高温度通常让更多候选有机会被取到。它不向模型新增资料，也不会判断原始资料中的活动日期是否写错。

所以，一个模型可能用很低的温度，反复给出同一个错误日期。你观察到的是稳定，不是正确。一致性、正确性、完整性是三个不同的验收维度。

二、top_p 与温度为什么不宜同时乱调

top_p 常称为核取样：根据累计概率保留一组候选，再从其中取样。它关注候选集合的概率覆盖范围；temperature 更偏向调整概率分布。两者都可能改变输出多样性，但不是同一个参数的两种叫法。

如果同时改动两者，结果变了，你很难判断原因。入门练习最好固定 top_p，只比较温度；要研究 top_p 时，再固定温度。DeepSeek 当前 API 参考也一般建议调整其中一个，而不是一起改。

不同提供商、模型与模式对参数的允许范围和实际效果可能不同。某个网页对话产品里的“创意”滑块，也不一定直接对应某个 API 的 temperature。不要照搬网上一个数字，就认为所有工具获得了相同设置。

三、先看当前 API 参考，确认参数没有被忽略

这里以当前 DeepSeek 文档作为“如何查证”的具体例子，不把它泛化为所有模型规则。其聊天补全 API 参考给 temperature 标出的范围为零到二，同时明确：在思考模式中，temperature 不起作用。

top_p 的处理更依赖模型和模式。当前参考说明，deepseek-flash 在非思考模式固定为一，传入值被忽略；思考模式下还有最小有效值的处理。deepseek-v4-pro 的思考模式又与是否启用工具调用有关。因此，不看具体模型和模式，只写“top_p 越低越稳定”，无法指导实际配置。

文档的温度入门页还给出了任务类型建议。这些建议可以作为理解用途的线索，却不能覆盖 API 参考里更具体的模式限制。通用建议页、具体接口说明和实际返回行为要一起看；遇到不一致先暂停下结论。

动手前记录四项信息：提供商、模型标识、思考模式是否启用、相关参数支持情况。如果产品没有暴露这些信息，就把实验结论限定为“该产品当前界面的表现”，不要冒充可复现的 API 调参实验。

调参前先检查模型与模式支持，再固定输入、单变量对比和事实验收的流程示意

四、准备一个结果可检查的练习任务

选用以下虚构通知，不上传内部文件：

社区图书整理活动，周六上午九点开始，地点为社区阅览室。
面向成年志愿者，最多十人，需要提前报名。
现场不提供培训证书，不收取报名费。

固定提示词：

根据通知写三个中文活动标题，每条不超过十八个汉字。
不要新增时间、福利、证书或报名条件。
三个标题分别突出地点、活动内容和志愿者参与。
仅输出编号标题，不写宣传口号或解释。

这不是测谁写得最华丽，而是测多样性增加时，有没有破坏限制。先规定四个核验点：有没有新增事实、是否突出不同角度、长度是否合格、格式是否符合要求。中文长度统计在这个小例子里按人工数汉字即可；若用于生产系统，应明确标点与数字算不算字符。

五、按单变量方法比较三组设置

仅在确认 temperature 对所选模式生效后，设置低、中、高三组，例如零点二、零点八、一点二。这是实验取值，不是官方保证最佳值，也不是适用于所有接口的通用处方。

  1. 固定模型、消息内容、系统要求和输出长度上限。
  2. 固定其他会影响结果的选项，不临时加搜索或切换工具。
  3. 每组独立请求三次，不把上一次答案附到下一次上下文。
  4. 保存每次完整原文、参数、时间和检查结论。
  5. 每完成一组，按相同规则核验，不因为标题好听就放宽限制。

已有接口账号的读者，应先确认余额、计费方式和组织允许的调用方法，再做少量请求。没有账号也可以先完成设计和人工验收表，不必为了理解概念先购买服务。

记录可以按以下字段分行保存：

  • 请求编号与温度值。
  • 模型、模式及其他固定条件。
  • 原始输出。
  • 新增事实条数、超长条数、角度重复条数。
  • 是否满足用途、需要人工修改什么。

假如某次出现“报名免费领证书”，即使文案流畅也应判为事实失败。把“没有新增事实”作为硬条件，“更有吸引力”作为满足硬条件后的选择，避免把营销效果建立在虚构承诺上。

六、怎样解释观察结果，才不会过度推断

如果高温组的用词更多样，但也更容易偏离格式，只能说明在这批样例和设置下观察到这种取舍。九次调用的规模很小，不能证明整个模型的总体错误率，也不能用来宣称某个参数能提升固定百分比的准确率。

如果三组输出几乎一样，先检查参数是否生效、请求是否真的不同，以及任务是否本来就只有很少合理答案。一个简短的日期提取任务，与一个开放故事创作任务，天然不适合用同一套多样性预期。

即使 temperature 设为零，也不应承诺永远逐字一致。实际服务可能还有模型更新、实现和运行环境等因素；更重要的是，文档未给出某项确定性保证时，就不能替提供商作出保证。要保存正式产物，应保存当次输出，不依赖以后重新生成完全相同内容。

区分输出变化、事实准确、格式合规和可复查记录四个验收目标的示意

七、任务失败时，先改什么

日期经常写错，先提供明确来源，要求保留原文并核验；缺少信息时允许回答未提供。字段格式不符合要求，先定义字段、类型和校验逻辑，必要时使用接口支持的结构化输出能力。回答冗长，先把目标长度、受众和示例写清楚。只有在任务已经定义清楚后，再把取样参数作为微调项。

写作探索类任务可以先保留更多候选，再由人挑选；订单提取、金额处理等任务，则应优先约束来源和业务规则。不能因为较低温度让回答看起来肯定，就把它直接接入付款或客户通知流程。

当你找到一组可用设置，把提示词版本、模型与模式、参数、验收样例和人工审核要求一起保存。下次模型或模式变化，重新检查支持规则，再跑同样的小练习。调参真正有用的成果，是一套知道何时有效、如何复查的方法，而不是一串脱离场景的“万能参数”。

官方资料