这个标题看着简单，但"提示词工程的几个参数"恰恰是很多人在实际落地时最容易糊弄过去、最后又被逼回来反复调的一块。我见过不少团队，提示词写得花团锦簇，思维链用得飞起，结果一换模型、一调温度，输出质量直接崩盘，排查半天才发现是参数和提示词压根就不配套。今天我就把提示词工程里绕不开的那些参数一次性讲透——它们各自控制什么、互相之间怎么影响、在不同任务里到底怎么配——全是实际项目里能直接拿去用的经验。

无论你是刚入门提示词工程的新手，还是已经写了几个月提示词但总觉得输出不稳定、想系统梳理一遍的人，这篇文章都适合你。我会从最基础的采样参数讲起，再深入到进阶的调用策略，最后给出一份可以直接抄作业的参数配置参考。

1. 先把思路摆正：参数不是提示词的附属品，而是提示词的上层建筑

很多教程喜欢把提示词工程等同于"写提示词"，好像只要措辞够精准、指令够清晰，模型就会稳定输出正确结果。这个认知在我的实操经验里是站不住脚的。

1.1 参数和提示词其实是同一个系统的两个旋钮

一个完整的模型调用请求，实际上由两大部分组成：系统级指令（System Prompt）、用户级指令（User Prompt），以及在两者之外的一组采样参数。提示词决定了模型"看什么"，而采样参数决定了模型"怎么从候选词里挑答案"。两者是串在一起的：提示词把模型引导到某个概率分布的峰值附近，参数则决定模型在这个分布上采样时有多"贪心"、多"发散"。

举个直观的例子。你让模型写一句产品宣传语，提示词已经把风格锁死为"简洁有力"，但如果temperature拉到1.5，模型仍然可能给你蹦出华丽的书面语。因为高温度意味着即便某个词在概率上不是最高，也有更大机会被选中，风格约束就被采样随机性冲淡了。反过来，如果temperature=0，哪怕提示词写得很开放，模型也会反复挑最高概率的同一个答案，创造性和多样性全被压死。

所以我的建议是：参数必须放在提示词设计同一优先级来考虑，而不是写完提示词后随手填一个默认值了事。你写提示词时精神高度集中，选参数时却用默认值，这是项目实践中最大的隐性坑。

1.2 参数调优的"成本-收益"逻辑

还要想清楚一件事：调参数不是越复杂越好。每多引入一个参数，就多一个需要上下联动检查的变量。四个任务分别用四套参数组合，日常维护成本会慢慢累积。

我的一般原则是：先确定任务对确定性的容忍度，再选择参数组合。对代码生成、数据提取、数学推理这类必须100%可靠的场景，直接固定temperature=0或接近0，top_p=1，尽量关闭随机性。对文案创作、头脑风暴、游戏剧情这类需要多样性的场景，才逐步拉高温度和采样范围，同时配合惩罚系数避免重复。

这个"设计在先、调参在后"的顺序，能让你少走很多弯路。

2. 核心采样参数逐个拆解：Temperature、Top-p 与 Max Tokens

这一节是重点中的重点，我按实际调用中影响最大的三个参数来讲。理解了它们，你已经解决了八成的参数问题。

2.1 Temperature：控制"冒险程度"的终极旋钮

Temperature（通常记作temperature，取值范围0~2，部分平台更高）是所有采样参数里最直观也最常被误解的一个。

原理层面，模型在生成每个token时，会先计算出一个概率分布，而temperature通过缩放logits来实现概率分布的"锐化"或"平缓化"。具体公式是：

[ P_i = \frac{e^{z_i / T}}{\sum_j e^{z_j / T}} ]

其中 (z_i) 是模型输出的原始分数（logits），(T) 就是温度。当 (T=1) 时，概率分布保持不变；当 (T<1) 时，概率差异被放大，高概率词会更突出，模型更倾向于确定性输出；当 (T>1) 时，概率分布变得平坦，低概率词也有机会被选中，输出更多样、更有创造力，但也更容易胡言乱语。

实操层面的经验值：

很多平台默认temperature=0.7，这个数值其实是"通用适中"。但注意，0.7不代表稳定，如果你的任务要求结果可控，一定要主动调低，不要信任默认值。

我踩过的坑：有一次做SQL生成任务，我把temperature设为0.9，结果同一个自然语言问题生成的SQL五次五个样，有的把LEFT JOIN写成子查询，有的字段名拼错。后来统一改成temperature=0，问题直接消失。切记：凡是需要机器解析的输出，温度一律压到0.2以下。

2.2 Top-p（核采样）：动态截断候选词表

Top-p（也常写作top_p，取值范围0~1，默认通常为1）是另一个高频出现的采样参数。它的作用不是缩放概率，而是动态决定保留多少个候选词。

原理层面，top_p会将所有候选词按概率从高到低排序，然后从最高概率的词开始逐个累加概率，直到累计概率达到top_p设定的阈值（比如0.9），就从这个累加集合里采样，其余的词直接丢弃。所以top_p=0.9并不是"取前90%的词"，而是"取累积概率达到90%的最少的那批词"。

为什么需要它：温度只改变了概率分布的形态，却没有解决"长尾噪声词"的问题。哪怕概率分布被温度压缩得很尖锐，尾部那些概率极低的垃圾词仍然存在；而top_p直接把尾巴砍掉，从根源上保证采样范围是一个高质量候选集。

和temperature的关系：OpenAI官方的API文档里明确建议，最好只调整其中一个，不要同时大幅调整两个。因为它们都在改变采样范围，同时动两个旋钮容易互相干扰，调参时也难以定位是谁导致了输出变化。我的做法是：默认固定top_p=0.9，然后把精力集中在temperature上。只有在temperature已经压得很低、但输出仍然不够多样时，我才会考虑同时调低top_p到0.85左右来收紧采样域。

2.3 Max Tokens：既控制长度，也控制质量

Max Tokens（也可能是max_tokens、max_new_tokens，不同平台命名不一）是控制生成token上限的参数。它最容易被新手当成"输出长度设置"，但它在实际使用中有更隐蔽的作用——防止模型陷入循环或离题万里。

如果max_tokens设置得过高，模型在长文本生成时有更大概率出现重复、逻辑漂移甚至复读机现象。因为每个新增token都会带入新的上下文状态，生成的序列越长，累积误差越大。相反，如果max_tokens设置得过低，长回答会被生硬截断，也可能出现回答到一半突然结束的情况。

所以实际调参时我给两条原则：

• 先估算后设置：根据任务预期的输出字数，反推token数。中文环境下，1个汉字约等于1~1.5个token，英文1个单词约等于1~1.5个token。如果让模型写200字的商品描述，设置max_tokens=500通常有足够余量，但没必要给到2000。
• 按输出结构的峰值需求设置：如果任务是生成JSON或带固定格式的内容，峰值长度可能远超平均长度。这时候宁可给长一些，也要避免结构被截断导致解析失败。截断回来的报错纠正成本，远高于多花的一点token费用。

一句心得：max_tokens不是越大越好，它和你的提示词长度一起决定了模型能"回头看"多少内容。上下文窗口是固定预算，留给输出的空间越大，留给输入的就越小，这会直接影响模型对上下文的把握能力。

3. 进阶参数与惩罚机制：Presence Penalty、Frequency Penalty、Top-k 与 Stop

核心三参数能解决大部分问题，但当你开始处理长文本生成、客服对话、多轮Agent等复杂场景时，就会撞上另外几个参数——它们处理的是"重复""发散""中断"这些更隐蔽的问题。

3.1 Presence Penalty 与 Frequency Penalty：两把"反重复"的梳子

Presence Penalty（存在惩罚，通常范围-2.0~2.0）和Frequency Penalty（频率惩罚，范围同上）都是用来降低文本重复度的，但机制完全不同。

• Presence Penalty：对"所有已经出现过的token"统一施加惩罚，无论出现了多少次。它鼓励模型探索新话题、新表达，而不是反复提及某个主题。
• Frequency Penalty：根据token出现的频率施加惩罚，出现得越多惩罚越重。它直接抑制词级别的重复（比如"然后然后然后""非常好非常好"）。

原理层面，这两个参数都是在每次token生成时，向对应token的logits中减去一个惩罚值。Presence Penalty相当于只要某个词出现过就减一次固定分，Frequency Penalty则是这个词出现一次减一次、出现N次减N次分。因此：

• 长文本生成、故事续写、文案改写，推荐presence_penalty=0.5~0.8、frequency_penalty=0.3~0.5，能明显改善"车轱辘话来回说"的问题。
• 代码生成、格式转换、抽取任务，不推荐开惩罚，因为高频出现的代码关键词（return、function、if）恰恰应该被正常使用，过重的惩罚会扭曲代码结构。
• 如果模型输出已经开始"胡言乱语"，先检查是不是惩罚系数拉太高了。惩罚过强会让模型为了回避重复而硬造生僻表达，反而降低可读性。

我的默认配置：普通创作任务我通常直接设presence_penalty=0.6, frequency_penalty=0.3，不纠结，稳定有效。如果发现输出过于保守、缺乏新意，再单独把presence_penalty往上加0.1~0.2。

3.2 Top-k：更简单粗暴的候选集裁剪

Top-k（top_k）是比top_p更硬核的采样方式：它直接按概率从高到低取前k个token，然后只从这k个token里采样。top_k=50就是只从得分最高的50个候选词中抽取。

和top_p的区别在于：top_k是固定数量截断，不管这50个词的总概率是90%还是40%；top_p是固定概率截断，候选词数量会动态变化。实际工程中，两者可以配合使用：先top_k砍掉绝对的长尾（比如保留前50个词），再top_p=0.9进一步收紧到高质量候选集。但注意，不要在同一次请求里同时把top_k和top_p都调得特别激进，那会过度限制输出空间，让模型变得僵化。

目前在主流API中，GPT系列并不开放top_k，但HuggingFace的开源模型、部分国产大模型API和本地部署框架中都支持。如果你在用本地模型，top_k=40~50是一个经典的安全区间。

3.3 Stop Sequences（停止序列）：手动掐断模型的"废话连篇"

Stop Sequences（停止词/停止序列）是一组字符串，模型只要生成了其中任意一个，就会立刻终止生成。

这个参数在提示词工程里经常被遗忘，但它的价值被严重低估了。很多输出问题根本不需要调整法和温度，只需要一个精准的停止序列：

• 你要模型只输出JSON，那就在停止序列里放上\n和}之后的边界符，防止模型继续追加解释文字。
• 你要模型做多选题，只要输出A/B/C/D，那停止序列可以设置成换行符，模型答完就停，不会继续啰嗦。
• 在Agent或多轮对话中，停止序列常设为Observation:、Human:之类的边界标记，保证模型不会越过角色边界乱说话。

很多平台的API叫stop或stop_sequences，传入一个字符串数组即可。实战里我强烈建议每个任务都设计至少一个停止序列，即使你不是100%确定会命中，它也能作为安全兜底，防止输出无限膨胀。

3.4 Seed 与 Logit Bias：复现与硬约束

Seed（随机种子）是可以让多次生成结果尽量一致的参数。如果你把temperature设为0，本身输出就接近确定性；但如果temperature较高还希望可复现，设置固定的seed就能让采样路径尽量稳定。不过要认清现实：seed并不能100%保证完全复现。在分布式推理环境或API服务端有并发请求时，浮点运算的微小差异仍可能导致结果漂移。所以把seed当成"尽力而为的一致"比较好，别依赖它做严格回归。

Logit Bias（logit偏置）则是一个更硬核的干预手段：它允许你直接给某些token的logits增加或减少数值，从而让模型更倾向或更回避使用这些token。比如你想让模型坚决不说脏话，就给对应token加上较高的负偏置。但由于tokenizer会把词切成子词，实际操作需要先确认目标词对应的token ID，较为繁琐，一般作为进阶玩家的利器使用。

4. 参数组合的实战思路：从"任务类型"倒推参数配置

前面拆了单个参数的原理，但真实的项目不会只调一个参数。这一节我给出几个实战场景的完整参数组合，并解释每个组合背后的逻辑。

4.1 场景一：结构化数据提取，要求高可靠

任务：从用户留言中提取姓名、电话、需求描述，输出JSON。

temperature: 0 top_p: 1 max_tokens: 800 presence_penalty: 0 frequency_penalty: 0 stop: ["```"]

这个配置遵循"零随机"原则。temperature=0保证面对同样输入时输出几乎确定；top_p拉满等于放弃二次采样；惩罚系数全部归零，避免常用词被惩罚后扭曲JSON键名；停止序列设为Markdown代码块结束符，防止模型在输出完JSON后补一句"以上是提取结果"之类的废话。

为什么不用frequency_penalty：JSON里"和}是高频率出现的字符，一旦引入频率惩罚，模型可能为了规避惩罚而改变标点格式，直接破坏JSON合法性。这类场景要的是"格式正确"，不是"词汇丰富"。

4.2 场景二：创意文案写作，要多样性又要不跑偏

任务：给某产品生成5条不同风格的社交媒体文案。

temperature: 1.0 top_p: 0.95 max_tokens: 300 presence_penalty: 0.8 frequency_penalty: 0.3 stop: ["###"]

为了多样性，温度拉到1.0，top_p略高于默认值给模型更多候选词空间；presence_penalty=0.8鼓励模型每次采用不同的切入角度，避免五条文案都是"xx产品真好"的同一个模板；frequency_penalty=0.3防止单条文案内部某几个词高频复读；停止序列用###，和提示词里用###分隔每条文案的格式呼应，保证模型生成的恰好是5条，不会多写。

4.3 场景二点五：长文档摘要，要稳定也要凝练

任务：把一篇3000字文章压缩成200字摘要。

temperature: 0.3 top_p: 0.9 max_tokens: 400 presence_penalty: 0.3 frequency_penalty: 0.3

摘要任务对事实准确性的要求高，所以温度压到0.3，而不是0，给模型保留一点语言组织自然度；惩罚系数稍微开启，防止原文某个高频短语被摘要机械复读；max_tokens给到400，是考虑到200字摘要加上标点、换行等token消耗，留有缓冲余量，避免被截断成残句。

4.4 场景三：多轮Agent对话，要在"跟随指令"和"不呆板"之间取平衡

任务：让Agent扮演客服，在对话中完成多步工具调用。

temperature: 0.2 top_p: 0.9 max_tokens: 1024 presence_penalty: 0.2 frequency_penalty: 0.2 stop: ["<|end|>", "Human:", "Observation:"]

在Agent场景中，模型需要同时做好两件事：严格按系统提示词里的规划步骤走，以及在每句话里显得自然不机械。因此温度必须低（但不必为0），否则Agent可能跳过工具调用直接瞎编答案。停止序列尤其重要：多轮对话里模型一旦生成Observation:或Human:的标记，就应该把控制权交还给外层调度逻辑，让模型接着写就是灾难。

4.5 参数组合速查表

这张表不是拿来死记硬背的，而是作为调参的起点。多数时候我都是从表里的推荐值出发，运行一小批测试样本，观察错误模式后再做微调。

5. 实操过程与调参工作流：从"盲调"到"系统调"

很多人在调参时是"东一榔头西一棒子"：先调温度，不行再调top_p，还不行又回来调温度。这样不仅效率低，而且永远不知道是哪次修改真正生效了。下面分享一套我在项目里反复使用、被验证有效的调参流程。

5.1 第一步：固定一个测试集，量化任务目标

调参前先准备一个固定的测试集，样例数量不用太多，20~30个有代表性的输入就够。每个样例都标注好"标准答案"或"关键质量指标"。

比如一个文案生成任务，我可以定义三个指标：

• 格式通过率：是否严格输出5条，且每条之间有分隔符。
• 关键词覆盖率：模型是否提到了产品名和核心卖点。
• 人工评分：随机抽5条让人打分，1~5分。

有了这些量化指标，"效果好/不好"就不再是主观感受，而是可以对比的数字。

5.2 第二步：先固定边界，再调核心

我的调参顺序是固定的：

1. 先定temperature。根据任务你要的是"确定性"还是"多样性"来决定温度区间。这是影响最大的旋钮。
2. 再定top_p。默认先放0.9或1，只有当你发现候选词范围太大导致输出"飘"时，才去收紧它。
3. 然后设置max_tokens。根据任务需求估算上限，这个参数没有太多玄学，给够别浪费即可。
4. 最后调惩罚系数。只有发现重复、模板化问题时才引入，而且每次只动一个。
5. 补上停止序列。这一步放在最后，但绝不可跳过。

这套顺序的核心逻辑是：先确定"采样随机性"的上限，再处理"输出范围"，最后处理"语言质量"。跳步调参是新手最容易犯的错——比如开了高惩罚系数，结果以为是温度太高导致发散，把温度一路降到0，最后输出变成了干巴巴的复读。

5.3 第三步：单变量验证，一次只改一个参数

改参数的时候，一次只改一个。如果你同时把temperature从0.5调到1.0、把top_p从0.9调到0.95，模型输出变化了，你根本无法确定是谁的功劳。

正确做法是：固定其他参数，只动一个，跑一轮测试集，记录指标。然后恢复原状，再动下一个。虽然慢，但每一步的因果都非常清楚。

实操中的一个小技巧：给每个场景建立一个调参记录表，记录日期、模型版本、各个参数的值、测试集规模、关键指标的变化。你可能觉得多此一举，但当我同时维护5个Agent项目、每个项目有3个不同任务场景时，这套记录帮了大忙。

5.4 第四步：写成可配置的参数模板

调参完成后，把参数组合固化到代码或Prompt模板里，而不是散落在各个调用点。我在实际项目中通常用类似这样的结构（以Python为例）：

from dataclasses import dataclass @dataclass class GenConfig: temperature: float = 0.7 top_p: float = 0.9 max_tokens: int = 1024 presence_penalty: float = 0.0 frequency_penalty: float = 0.0 stop: list[str] | None = None # 不同场景的预设 CODE_GEN = GenConfig( temperature=0.0, top_p=1.0, max_tokens=2048, stop=["```"] ) CREATIVE_COPY = GenConfig( temperature=1.0, top_p=0.95, max_tokens=500, presence_penalty=0.8, frequency_penalty=0.3, stop=["###"] )

这样做的好处是：业务代码里只负责传场景名，参数集中管理，后续要调整某一个场景的配置不用去翻业务逻辑，改配置对象就行。尤其当团队里有多个同学都在调同一个项目时，这种方式能避免有人在某次调用里随手写了个temperature=1.5导致线上输出飘了。

6. 常见问题与排查技巧实录

最后这部分，我整理了过去项目里真实遇到过的、可以和参数直接挂钩的典型案例。每一个都是被反复验证过的"参数背锅"名场面。

6.1 提示词明明写了"简短回答"，模型还是长篇大论

这种情况十有八九不是提示词没写明白，而是max_tokens设置过大，给了模型太多的"输出预算"。模型在训练时学到的习惯是尽量把回答补充完整，在预算充足的情况下它会倾向于继续解释而不是戛然而止。

解决思路有两个：

• 把max_tokens压到"刚好能容纳预期回答"的大小，逼模型精简。
• 加停止序列，比如在回答应该结束时设置\n\n或END作为停止标记。

千万不要一边把max_tokens设成2048，一边抱怨模型话多——你给了它两页作文纸，它当然给你写满。

6.2 微调样本的多样性不足，是参数调节无法解决的

如果你用了低温度、低top_p，模型还是输出奇怪内容，先别急着调参，检查一下你的示例样本是否过于单一。参数只能影响"怎么选"，无法凭空补充模型没学到的知识。如果你的任务本身有大量需要模型"理解后才能输出正确结果"的场景，参数再怎么调也不可能稳定，这时候该考虑的是增加示例、优化提示词结构，甚至是引入检索或微调，问题不在参数层。

6.3 同样的参数，两次运行结果不一样

这是很多人第一次接触大模型时最困惑的问题。原因有几层：

• 服务端推理本身有随机性，除非temperature=0；
• 浮动精度误差在分布式推理中几乎无法避免；
• 某些API即使你传了seed，在多副本部署下也不保证严格一致。

如果业务要求必须完全复现，唯一稳妥的方式是把输出缓存下来，用业务层的KV/Pinecone/MySQL做去重，而不是寄希望于参数层面彻底解决。

6.4 常见问题速查表

6.5 多模型对比测试的隐藏坑

如果你在做模型选型，千万不要只用默认参数去对比两个模型。不同模型对同一个temperature=0.7的实际表现差异非常大，A模型在这个温度下可能已经足够稳定，B模型的同温度输出却散得没法看。对比测试时，应该分别对每个模型做一轮参数粗调，找到各自的"稳定工作区间"再对比，否则你淘汰的可能不是一个差模型，而是一个"参数没调好"的好模型。

这个坑我在做技术方案选型时就踩过。当时对比两个模型在代码生成任务上的效果，一开始直接用默认参数跑，其中一个模型输出乱得没法看，差点被否决。后来我把温度都调到0，另一个模型的表现立刻拉平了很多。自此之后，所有模型对比评测我都强制要求先把参数基线校准一遍。

7. 参数调优的最后一层心得：先盯住"任务边界"，再谈"调参魔法"

写到这里，我特别想强调一个容易被技术细节淹没的认知：参数调优的作用边界，永远在"任务定义"之下。

如果你的提示词本身没有明确的任务边界，没有给出足够的约束条件，没有提供必要的示例，那么再精确的参数组合也无法拯救它。temperature=0只能让模型在错误的道路上走得更坚定，frequency_penalty只能让废话换着花样说。参数解决的是"如何从概率分布中采样"的问题，而提示词解决的是"模型应该关注哪些信息、按照什么逻辑组织输出"的问题。

我个人的推荐顺序永远是：先打磨提示词的结构和示例，再确定temperature的定位，最后调整惩罚系数和停止序列这类细节。提示词是地基，参数是房子内部的装修。地基歪了，装修再豪华也住不了人。

最后再分享一个实用小技巧：调参时可以把temperature当成"任务性质探测器"。如果某个任务在temperature=0下表现良好，但一提高就崩盘，说明这个任务对随机性极其敏感，后续所有迭代都应以低温度为前提；如果某个任务在temperature=0下效果很差、需要提升温度才正常，说明任务本质上更偏向创造性表达，那你就应该把精力放在如何通过提示词引导模型发散，而不是纠结它为什么不稳定。每接到一个新的提示词工程需求，我先做这个温度敏感性实验，往往能在两三轮测试内就找到正确的调参方向，比闷头一个个参数试高效得多。

这套方法我已经在多个项目里反复验证过，希望它能让你少走一些弯路。如果之后你在实际调参中遇到什么奇怪的输出问题，不妨从温度敏感性和惩罚系数这两个角度先做一轮排查，大概率会有收获。