做提示词工程这两年我接过不少类型的项目从内容生成、代码助手到结构化数据抽取都碰过。说实话大部分人把精力全花在“怎么写提示词”上却忽略了提示词背后那几个真正决定输出质量的旋钮——生成参数。提示词写得再漂亮如果 temperature、top_p、惩罚系数这些参数没配对输出照样翻车甚至提示词越复杂翻车越厉害。这篇文章我打算把提示词工程里最常用的几个参数一次性讲透包括它们各自管什么、为什么这么设计、不同场景下该怎么配以及我实际踩过的一些坑。不管你是刚入门的新手还是已经被调参折磨过的老手这应该都是一份可以反复翻看的实用参考。1. 参数全景先搞清楚手上有哪些旋钮1.1 生成类参数temperature、top_p、top_k先聊最核心的三个采样参数。在上手调参之前我建议你先理解一个基础事实大模型生成文本并不是“选唯一正确答案”而是每生成一个 token都会计算出一个概率分布然后从这个分布里抽一个词。temperature、top_p、top_k 这三个参数本质上都是控制“抽词”策略的。temperature 是最常被提到的参数一般范围在 0 到 2 之间不同平台略有差异它直接把概率分布压扁或拉尖。温度越低高概率的词被抽中的机会越大输出越稳定、保守、可预测温度越高低概率词也有机会冒头输出越发散、有创造力但也不可控。到极端情况 temperature0 时模型基本每次都会挑概率最高的那个 token所以同样的输入会得到几乎一样的输出。top_p 是另一种策略也叫核采样nucleus sampling。它只从累计概率达到 p 的最小候选词集合里采样。举个例子top_p0.9 就意味着模型生成下一个词时先把所有候选词按概率从高到低排列然后从前往后累加直到累计概率超过 0.9只在这个词表子集里做采样。这样能直接把那些概率极低、基本不相关的长尾词过滤掉让输出至少在“合理范围”内波动。top_k 更直接它限定候选词数量只从概率最高的 k 个词里采样。比如 top_k50就表示每一步只从概率排名前 50 的词里选。OpenAI 的 API 里现在不太强调这个参数了但在很多开源模型和推理框架里比如 transformers 库的 generate 方法它依然非常重要尤其是在中文文本生成任务里top_k 能有效防止一些生僻字突然蹦出来。我记得有段时间做政务类文案生成客户反复反馈“内容太放飞”随口用词不够严谨。后来排查了一圈问题就出在我把 temperature 拉到了 0.95top_p 也设成了 0.95配合本来就富于修辞的提示词模型每步都在“创造性发挥”。政务文案哪里撑得住这种随机性。后面把 temperature 压到 0.3top_p 保持 0.9输出立刻稳了很多。这里也顺带说一句参数不是越大越好得看场景。1.2 长度与行为类参数max_tokens、惩罚系数、停止序列与随机种子除开采样参数还有几个参数决定生成过程的“边界”。max_tokens 限制的是输出 token 的上限。很多人以为它是“字数上限”其实 token 和字数并不是一回事中文一个字大约对应 1 到 2 个 token英文一个词也差不多。更需要留意的是max_tokens 只管生成部分不包含输入的 prompt 长度但整轮请求的 prompt 加 completion 不能超过模型的上下文窗口。还有就是如果你调的是 o1 这类带 reasoning 能力的模型内部还会消耗一部分 token 做推理max_tokens 设太小可能导致模型“想太多、说不完”最终只输出了推理过程而没有给出正式回答。frequency_penalty 和 presence_penalty 是我特别爱用的两个参数。它们分别解决两类问题前者根据词在已生成文本中出现的频率进行惩罚词出现得越多后续再被抽中的概率就被压得越低这样可以明显减少内容重复后者只要词出现过一次就会受到一定惩罚不管它出现多少次作用是鼓励模型去谈一些之前没出现过的话题。两者取值范围通常是 -2 到 2正值是惩罚、负值是鼓励0 是不干预。我实测下来frequency_penalty 设 0.3 到 0.6 就能消除一大半“车轱辘话”而 presence_penalty 设 0.3 到 0.5 会让回答在保持主题的同时更愿意换角度展开不会一直绕着同一个表达打转。stop 是停止序列参数你传入一个或一组字符串模型一旦生成到这些字符串就立即中止。这个参数在控制输出格式时非常救急比如你要求模型只输出 JSON那可以把 stop 设为 [“}”] 之后的某个分隔符避免它继续啰嗦。seed 是随机种子理想情况下同样的 prompt、同样的 seed、同样的参数会得到可复现的结果。不过需要说明的是目前多数 API 的 seed 只承诺“尽力复现”尤其在使用浮动版本模型时结果仍可能受到服务端内部随机性和部署变动的影响不能把它当成 100% 可靠的回归工具。1.3 提示词里的“隐藏参数”示例数量、输出格式和角色约束很多人容易忽略一个问题提示词本身的某些设计其实也扮演着“参数”的角色。比如 few-shot 示例的数量你给模型提供 1 个示例和 5 个示例输出的稳定性和风格一致性完全不一样。示例越多模型对“你期望的输出长什么样”的理解就越准确相当于把输出分布往你的目标方向硬掰。但这个“数量”不是越多越好示例太多会占用上下文窗口还可能引入示例之间的冲突反而让模型无所适从。输出格式约束也是同样的道理。你让模型“自由发挥写一段产品介绍”和“必须按照‘产品名称—核心功能—适用场景—注意事项’四段结构输出”后者即使 temperature 设到 0.8结构也不会乱到哪里去。格式本质上是一种强先验它比采样参数更能约束模型行为。角色设定也算一种“隐藏参数”。当你给模型设定“你是资深工程师”和“你是热情活泼的小助理”即使其他参数完全一致输出也会显著不同。所以我在实际调参时有个习惯如果参数怎么调都不对劲先回头审视提示词本身看看是不是角色设定和约束条件把模型卡死了。参数只能微调概率分布提示词才是圈定答案范围的那堵墙。2. 参数为什么这样设计原理与调优逻辑2.1 temperature 与 top_p 的互补关系先说一个很多人忽略的细节OpenAI 官方文档明确建议temperature 和 top_p 最好只改其中一个不要同时大幅度调整。原因在于这两者解决的其实是同一类问题——控制采样的随机程度——只是实现方式不同。temperature 是直接改变概率分布的形状top_p 是截取概率分布的子集。如果两个都动效果会叠加你根本分不清输出变化到底是哪个参数引起的。不过我在实践中发现它们也不是完全不能搭配。最理想的做法是以 temperature 为主调参数top_p 保持一个比较稳的基线值比如 0.9 或 0.95。只有当 temperature 调到接近上限仍觉得发散过头、但又不舍得放弃多样性时才稍微把 top_p 往下压一压比如从 0.95 降到 0.85利用“候选集合变小”来拉回输出的合理性。举个我实际的例子。有一次做营销文案批量生成甲方要求“20 条不同风格但不离题”的版本。我开始把 temperature 拉到 1.1top_p 保持 0.95结果输出倒是千变万化但其中不少已经偏得离谱比如卖护肤品的文案跑偏到了“深夜加班”的鸡汤上。后来我把 temperature 降到 0.85top_p 从 0.95 降到 0.85随机性降了不少但多样性依然足够跑偏率大幅下降。这背后的逻辑就是top_p 把概率分布里那些不靠谱的长尾先切掉temperature 再在剩下的合理范围内制造变化。2.2 max_tokens 并非单纯的“字数限制”很多人把 max_tokens 当成“字数限制”来用这是我对参数误解吐槽最多的一点。首先token 和字符的换算关系不是 1:1而且中英文差异很大。我自己在项目里粗略统计过中文场景下一个汉字大约占 1 到 1.5 个 token但遇到专业术语、生僻词会更高英文里一个常见单词通常是一个 token长词和复合词会被拆成两三个。所以如果你需要固定输出 500 字max_tokens 建议直接给到 1000 以上留足余量否则经常出现“答到一半被拦腰截断”的问题。更要命的是上下文窗口的联动。你输入的 prompt 本身就占 token 额度比如你丢进去一大段参考文档再塞了几十个 few-shot 示例如果模型窗口是 8k你已经用掉了 6k那 max_tokens 最多只能设 2k设大了接口直接报错。所以我做长文本项目时第一步永远是先估算 prompt 的长度再反推可用的 max_tokens 上限而不是凭感觉填一个“很大”的数字。另外提醒一句如果你用的是 OpenAI 新的 reasoning 模型o1 系列max_tokens 的行为会和普通模型不一样。它内部有个隐藏的 reasoning buffer模型会在正式回答前先“思考”一段这部分 token 是计算在 max_tokens 之外的。我记得有次测试我把 max_tokens 设成 500心想输出 500 个 token 足够处理一个简单逻辑题了结果模型输出了 600 多个 token 的“内心推理过程”最终答案却被截掉了。这种烧钱又伤神的情况建议你直接给 reasoning 模型留出更大的输出空间。2.3 惩罚系数是控制重复与发散的关键我先解释一下 frequency_penalty 和 presence_penalty 的内部机制这有助于理解为什么它们对“重复问题”这么有效。模型在每一步生成时除了根据 prompt 和已生成内容计算下一个 token 的概率分布外还会把惩罚系数加进去做一次 logit 调整。frequency_penalty 按“词已出现的次数”正比例扣分出现次数越多扣得越狠presence_penalty 则只按“词是否出现过”做一次性的扣分不关心出现多少次。你可以把这两个参数理解成两种“纠偏手段”。frequency_penalty 适合对付那种一句话来回说、一段话反复表达同一个意思的情况它相当于给高频词加了个递减阈值逼着模型换词。presence_penalty 更适合用于长文本生成因为随着生成内容变长模型很容易钻进一个话题里出不来presence_penalty 会不断对已经用过的主题词施加压力促使模型转向新信息。我实际测试过一个典型案例让模型写一篇 1000 字的产品介绍初始参数全为 0。生成结果出现了“优质”“专业”“高效”这类词的复数次重复读起来非常廉价。把 frequency_penalty 调到 0.5 后重复率明显下降调到 0.8 以上又出现了一个新问题——模型开始改用一些生僻的同义词比如把“好用”换成“宜用”读起来反而别扭。这说明惩罚系数不是越高越好它是在“重复”和“用词自然度”之间找平衡。我目前的经验值范围是 frequency_penalty 0.3~0.6、presence_penalty 0.2~0.5超过这个区间就需要谨慎验证。2.4 参数之间会互相打架参数调优最难受的地方在于没有哪个参数是独立生效的它们之间打成一团。temperature 调高会增加输出随机性而 frequency_penalty 也在改变概率分布两者叠加可能导致一个本意是“更有创意”的配置实际却变得又乱又重复。同样top_p 截断了候选集合会让惩罚系数的“纠正空间”变小因为候选词本来就少你再惩罚某些词剩下的合理词可能更少反而抬高了低质量词被抽中的概率。我习惯把参数调优看成是一个“系统调试”而不是“单独拧旋钮”。每动一个参数都要观察整体输出的变化而不是只看单点指标。我在团队内部搭过一套简单的调参实验记录表输入同样的 prompt分别跑不同参数组合然后把每次输出的质量打分、重复率、跑题率、截断情况都记下来。你很快就会发现真正好的参数组合往往是一组“相互制衡”的值而不是单个参数拉到最满。比如“创意文案”这个场景我最终选定的组合是 temperature0.85、top_p0.85、frequency_penalty0.4、presence_penalty0.3这几个值单独看都不激进但组合在一起既保住了多样性又控制住了跑偏和重复。3. 不同场景的参数配置参考3.1 代码生成与逻辑推理低温度优先代码生成是我做过的对确定性要求最高的场景。一个函数命名稍有变化可能问题不大但逻辑结构、分支条件、API 调用方式是不允许乱来的。所以代码类任务我基本把 temperature 控制在 0 到 0.3 之间top_p 设 0.9 到 1不额外收紧max_tokens 根据函数或文件长度预估。特别要强调的是改写、补全、Debug 这三类子任务参数倾向也不一样。补全任务比如写一个函数体我倾向于 temperature0让模型严格按照上下文和已有风格续写改写任务可以给到 0.2~0.3保留一点表达余地因为翻写代码时经常需要调整变量命名和注释风格如果你是让模型从报错信息中回溯原因不要调任何随机性参数就用默认值或者直接 temperature0 跑。我在一个内部工具项目里用这种配置代码审查的一次通过率从原来的 70% 左右提升到了 85% 以上效果非常明显。3.2 文案创作与头脑风暴高温度搭配宽松采样文案创作这类任务追求多样性和惊喜感参数可以大胆一些。我的常用配置是 temperature0.8~1.0、top_p0.9~0.95frequency_penalty 和 presence_penalty 都设为 0.3 左右。这样既能让模型跳出常规表达又不会因为随机性过大而彻底跑题。这里有个额外的技巧如果你一次要生成多条候选我会调低 max_tokens 而不是降低温度。比如要求生成 5 条广告语每条不超过 30 字那我通常把 max_tokens 设在 300 左右强制模型在有限空间内输出短句避免它越写越多、越写越散。同理如果你希望模型输出多种角度的思路可以在 prompt 里明确“列出 5 个不同的角度”然后让 temperature 保持在 0.9 以上即使每个角度之间偶有交叉整体依然会保持多样性。3.3 数据提取与结构化输出确定性优先数据抽取类任务的毛病在于模型只要稍微“灵活”一点输出的字段就忽多忽少、格式忽好忽坏。这种场景不需要创造力需要的是把文本里的实体、属性、关系老老实实抽出来。所以我的建议非常极端temperature0top_p 不低于 0.95惩罚系数都为 0同时用 stop 和输出格式约束来锁死结构。我之前做过一个合同关键条款抽取的项目目标是从 PDF 文本里抽签署方、金额、日期、违约条款。早期用 temperature0.3 试跑结果同一个合同抽两次金额格式一次是“人民币壹佰万元整”一次是“1,000,000 元”直接没法用。后来把 temperature 压到 0同时在 prompt 里加上“统一使用阿拉伯数字日期格式为 YYYY-MM-DD”的约束再用 stop 参数卡住 JSON 输出结束位置最终抽取结果的字段一致性做到了接近 100%。这种任务里宁可让模型“死板”也不能让它“发挥”。3.4 多轮对话与客服机器人稳定中有弹性多轮对话是让我觉得调参最“吃经验”的场景。你既要模型每次都给出稳定、不矛盾的答案又希望它在不同用户表达下能灵活理解和换措辞所以参数往往要在“稳”和“活”之间取中间值。我常用的配置是 temperature0.5~0.7、top_p0.9frequency_penalty0.5presence_penalty0.3。frequency_penalty 调高一点的原因是多轮对话特别容易出现复读机现象——模型会重复上一轮已经说过的内容或固定的开场白加大频率惩罚可以有效缓解。presence_penalty 则能保证模型在回答不同问题时愿意引入新信息而不是每个回答都回到那几句“标准话术”上。我还想特别提一个很多人忽略的点stop 在多轮对话里非常好用。很多客服机器人接单轮接口时经常出现模型“抢答”下一轮内容的问题。你可以把系统设定里约定的对话结束标记比如“|end|”或“用户:”放进 stop 列表这样模型生成到标记位置就会停下来不会越俎代庖替用户把问题也问了。我们团队实际测试过加了 stop 之后多轮会话的连贯性和完整性评分提升了不止一个档次。下面是我平时比较常用的参数配置速查表你可以直接抄作业先跑起来场景temperaturetop_pfrequency_penaltypresence_penaltymax_tokens 建议代码生成/补全0~0.20.9~100按文件长度×2代码改写0.2~0.30.900按输出代码量×1.5文案创意/头脑风暴0.8~1.00.9~0.950.30.3按字数×2数据抽取/结构化输出00.95~100按目标格式估算多轮对话/客服0.5~0.70.90.50.3300~500/轮4. 常见问题与排查技巧实录4.1 输出千篇一律调了 temperature 也没用我遇到过一种很典型的情况已经做了一个内容生成的 prompt觉得输出太死板于是很自然地把 temperature 从 0.7 拉到 1.2结果连续跑了十几条内容还是惊人的相似顶多就是个别形容词换了换。排查下来原因通常有三个。第一top_p 设得太低导致候选集合被砍得只剩下高概率的“安全词”再高的 temperature 也只是在这个狭窄集合里打转。第二提示词里给了太多限定条件等于把模型的发挥空间都堵死了比如你既要求“简短”又要求“必须提到 A、B、C 三个点”那模型只能在那几个点附近换说法本质上没什么自由度。第三temperature 在高值下确实会增加随机性但如果模型本身对任务的理解已经形成固定套路多跑几次之后采样的均值还是会收敛到套路化的表达上。我的解决思路是先看 top_p 是不是低于 0.85如果是重新提到 0.9 到 0.95然后检查提示词里的限定条件是不是过多有没有“既要又要”的情况适当放开一些非必要的约束如果还是没变化再考虑把 max_tokens 适当调大给模型更多篇幅去展开细节而不是单单靠温度参数硬撑。记住一个原则温度解决的是“表达变化”问题如果连表达空间都没有温度再高也只是在螺蛳壳里做道场。4.2 回答重复绕圈停不下来长文本生成里最常见的翻车现场就是“绕圈子”。模型先围绕一个观点说了一大段然后开始重复前面已经说过的内容或者永远在那个观点附近打转就是推不进去。这种情况我的排查顺序是先看 frequency_penalty 是不是 0。如果是直接提到 0.3 到 0.6 重试大概率能解决。如果 frequency_penalty 已经比较高还是绕圈就要考虑是不是 top_p 太低了。top_p 低候选集合小模型可换的词语有限即使有惩罚机制它也找不到足够多的替代词来描述同一个意思只能被迫重复。这种时候把 top_p 提高到 0.95 以上给模型更大的词表空间通常能缓解。还有一种情况是 prompt 本身给出了过于狭窄的结论。比如你要求“论证 A 方案更好”模型如果只掌握三个论据它翻来覆去也只能用这三个论据出现重复几乎是必然的。这时你更应该在 prompt 里要求“从成本、效率、风险、扩展性等多个角度展开”而不是单纯靠惩罚系数硬掰。参数能缓解症状提示词才能解决病根。4.3 生成结果被截断怎么判断是谁的锅输出被截断是特别常见的问题。我自己每次遇到截断都会先做一个判断是 max_tokens 不够还是 stop 设得太激进还是模型因为上下文太长“被迫收尾”。最简单的方法是直接数一下输出文本末尾是不是一个完整的句子或完整的 JSON 结构。如果结尾明显断在半句话或者 JSON 缺了个右括号那基本就是 max_tokens 不够把参数调大即可。但这里有个陷阱如果你已经输出了一大堆废话或重复内容那 max_tokens 调到多大都会继续截断因为模型优先把 token 浪费在了废话上。所以遇到截断我的排查顺序是先看有没有重复和大段无关内容有就先清掉调惩罚系数或改提示词再判断是否要加大 max_tokens。stop 设得太激进的情况一般是输出提前结束但文本看起来是“消失”而不是“截断”比如你要求输出 JSON把 stop 设为 “}”结果模型刚输出一个步骤里的 “}” 就停了根本没有输出完整的对象。这种问题很难靠肉眼判断我建议你自己用同样的 prompt 去掉 stop 跑一次对比一下输出长度差异就能快速定位。4.4 参数导致的“翻车”案例实测我这里想分享一个印象比较深的实测。某次做金融领域的摘要生成要求从一段投研报告中提炼三个要点。最初配置是 temperature0.7、top_p0.95、max_tokens1024本意是希望摘要“有点行文变化”不要每次一字不差。结果跑出来的摘要里多次出现“从长期来看”“总体而言”这类风险行业套话而且不同次之间差异非常大有一次甚至把“看到行业回暖”写成“看到行业全面复苏”一个是谨慎判断一个已经近乎定论性质完全变了。当时排查下来问题出在两处一是 temperature 对金融摘要这类需要高度精确的任务来说太高了0.7 的随机性足以让模型在措辞的“分寸感”上失控二是提示词只写了“总结要点”没有强调“保持原文的审慎语气”。我把 temperature 降到 0.2并在 prompt 里加入对风险表述的敏感性约束要求保留原文的限定词比如“有望”“或”“存在不确定性”连续跑 10 次输出语气的一致性终于稳定了。这个案例给我的启发是在专业领域里参数调的不只是温度更是“表达的分寸”。4.5 常见问题速查表为了方便你快速定位问题我把下面这个速查表放在这里平时排查可以直接对号入座问题现象可能原因优先排查项输出千篇一律top_p 过低、提示词约束过多、temperature 无效top_p 提到 0.9精简提示词内容重复绕圈frequency_penalty 为 0、top_p 过低、主题过窄frequency_penalty 提到 0.3~0.6生成到一半截断max_tokens 不够、stop 误杀、废话占位太长先清重复再加大 max_tokens输出跑题temperature 过高、prompt 缺少边界降低 temperature补充任务边界格式不稳定缺少格式约束、temperature 过高强制输出格式temperature 降到 0~0.2语气拿捏不准缺少语气约束、temperature 过高在 prompt 中明确语气降低温度5. 我的调参习惯与实操心得5.1 一次只改一个参数先跑基线我见过太多人拿到参数面板就是一通乱拧temperature、top_p、penalty 同时调最后输出变了也不知道是谁起的作用。这种调参方式既浪费时间也没法积累经验。我自己的习惯是拿到一个任务先用平台默认参数跑 5 到 10 次把这批输出当作基线。然后一次只改一个参数观察变化再回到基线换另一个参数试。等每个参数单独的效果都清楚了再去做组合调整。这个方法听起来慢实际上是最快的。因为你积累的是每个参数在这个提示词下的“性格画像”下次再遇到类似任务基本可以直接“按方抓药”。而且这个习惯还有一个额外好处当你向团队其他成员说明为什么最后选定这套参数时每一处调整都有据可查而不是“我觉得这样比较好”。5.2 把参数写进配置而不是散落在代码里这是我后期才形成的习惯但强烈建议大家尽早养成。当项目里有用到大模型的地方不要直接在内联代码里写死参数而是把参数集中放在配置文件或环境变量里比如使用 JSON 或 YAML 统一管理{ model: gpt-4o, temperature: 0.2, top_p: 0.9, max_tokens: 1024, frequency_penalty: 0, presence_penalty: 0, stop: [\n\n] }这样做的价值在于参数和业务代码解耦之后调参的时候不需要改动程序逻辑改完配置直接重跑即可。而且不同场景可以共用一套代码只要切换不同的配置文件就能应对代码生成、文案创作、数据抽取等不同任务类型。我们团队现在每个接入大模型的项目都会维护一份 params 配置测试和上线用同一套配置源极大地减少了环境不一致导致的调参混乱。5.3 用 seed 做回归测试但别迷信完全复现当你的项目开始迭代提示词或参数时一定要有一个“回归测试”的概念。我会给每轮实验记录下来使用的 seed跑同一批测试用例然后对比前一轮结果判断改动是变好了还是变坏了。特别是做对话机器人这类高频迭代的项目没有回归测试的话你根本分不清某次线上输出异常是新改的提示词引起的还是模型服务端本身就存在随机波动。不过对 seed 的期望值要合理。我实测 OpenAI 的接口时即使设置相同的 seed也无法保证每次输出绝对一致服务端模型版本更新、负载变化都可能影响结果。所以我的做法是同一组参数和 seed 跑 3 次用 3 次中的“多数表现”来评价效果而不是拿单次结果下结论。seed 的价值更多是缩小随机方差、辅助定位问题不能当成“保证完全复现”的开关来用。这里再分享一个更偏后端的细节如果你在生产环境对输出的一致性要求极高那么除了 seed还要固定模型版本不要用 floating 的动态别名这样才能进一步减少变量。参数只解决“同一模型下如何采样”的问题版本漂移导致的差异参数是救不回来的。做了这么久的提示词工程我越来越觉得大部分人问“用什么参数”之前应该先问“我的任务需要什么样的确定性”。代码生成和数据抽取需要低温度、严格格式创意文案需要高温度、宽松采样多轮对话需要在稳定中保留弹性。没有一套参数是万能的就像没有一把螺丝刀能拧所有型号的螺丝。把每个参数的脾气摸清楚再根据任务性质组合使用你才能真正从“碰运气调参”变成“按需配置”。