1. 为什么参数调优是提示词工程里最被低估的基本功很多人聊提示词工程第一反应就是“写一段神奇的话让模型变聪明”。但我在实际项目里踩过最大的坑恰恰不是措辞不够花哨而是参数没配对。同一个提示词温度值差0.3输出质量可能天差地别。这一章我想先把参数调优这件事讲透因为它是所有高级技巧的地基。1.1 温度、Top-p、Top-k到底在控制什么先把这三个参数用生活化的方式说清楚。你可以把大模型生成文本想象成一个“选词游戏”每一步它都会给词表里所有候选词打分然后按某种规则挑一个出来。温度Temperature控制的是“随机性的整体缩放”。温度趋近0时模型几乎总是选概率最高的那个词输出稳定但可能死板温度调高低概率词也有机会被选中输出更发散但容易跑偏。我一般把温度理解成“冒险程度”。Top-p核采样控制的是“候选池的大小”。它先把词按概率从高到低累加累加到p为止只在这个池子里采样。比如Top-p0.9就是只从累计概率占90%的那批词里选。它的好处是动态调整——模型越确定池子越小模型越犹豫池子越大。Top-k更直接就是“只保留概率最高的k个词”。它的问题是k固定遇到模型很确定的场景会引入不必要的噪声遇到模型很犹豫的场景又可能砍掉合理选项。所以现在很多场景我更倾向用Top-p而不是Top-k。参数控制维度典型取值适用场景Temperature随机性缩放0~0.3 严谨任务0.7~1.0 创意任务代码生成用低温文案创意用高温Top-p候选池动态大小0.8~0.95通用对话、开放式生成Top-k候选池固定大小20~50需要限制发散范围时重复惩罚抑制重复1.0~1.2长文本生成防复读这里有个经验温度、Top-p、Top-k不要同时大幅调整。它们的作用是叠加的一起动很容易把输出搞成四不像。我的习惯是固定Top-p0.9、Top-k不动只调温度这样变量单一出了问题好定位。1.2 不同任务类型的参数配方参数没有万能值得按任务类型配。我整理了一套自己常用的配方实测下来比较稳结构化抽取类任务比如从一段文本里抽JSON温度设0Top-p设1.0。这类任务要的是确定性任何随机性都是敌人。温度0能让模型每次都走最高概率路径输出格式最稳定。代码生成类任务温度0.2~0.4。完全为0有时候会陷入“最保守但最笨”的写法稍微给一点随机性反而能写出更灵活的代码。但别超过0.5否则容易生成语法对但逻辑飘的代码。创意文案类任务温度0.8~1.0Top-p 0.9。这类任务要的就是多样性温度低了出来的东西千篇一律。我做过一个测试同一个产品卖点温度0.3生成的文案和温度0.9生成的文案后者被选中的概率高出近一倍。多轮对话类任务温度0.6~0.8。太低会显得机械太高会前后矛盾。这个区间是我试了很多次找到的平衡点。提示参数调优一定要做A/B对比。我的做法是固定提示词只改一个参数跑20次看输出分布。凭感觉调参是最容易翻车的。1.3 一个被忽视的参数最大生成长度很多人只盯着温度和Top-p却忽略了max_tokens。这个参数设小了模型话说到一半被截断设大了模型可能开始“凑字数”说废话。我的经验是先估算任务需要的合理长度再留20%余量。比如摘要任务一般200字够那就设300 tokens左右。另外要注意有些接口的计费是按max_tokens算的设太大纯属浪费。还有一个细节当输出被截断时模型不会告诉你“我还没说完”它只是戛然而止。所以如果你发现输出结尾很突兀第一件事就是检查max_tokens是不是设小了。2. 思维链不是万能药什么时候该用什么时候是浪费思维链Chain of ThoughtCoT这两年几乎被吹成了提示词工程的银弹。但我实际用下来它的适用边界比想象中窄得多。这一章我想聊聊CoT的真实适用场景以及一个更进阶的替代方案。2.1 思维链的底层逻辑与适用边界CoT的核心思想很简单让模型在给出最终答案前先输出推理步骤。为什么这有用因为大模型本质是“逐词生成”它没有内部的草稿纸。当你要求它直接给答案时它必须在一步之内完成所有推理而当你要求它“先想再答”它就把推理过程外化成了token相当于给自己搭了个草稿纸。但这里有个关键前提任务必须真的需要多步推理。我见过太多人给简单任务硬加CoT结果模型绕了一大圈答案反而更容易出错。比如“把这句话翻译成英文”你让它“一步步思考”它可能开始分析语法结构最后翻译得还不如直接翻。我的判断标准是如果这个任务人类需要打草稿才能做对那就用CoT如果人类能脱口而出那就别用。数学应用题、逻辑推理、多条件约束规划这些适合CoT。分类、翻译、简单抽取这些不适合。2.2 零样本CoT与少样本CoT的取舍CoT分两种玩法。零样本CoT就是加一句“Lets think step by step”或者中文的“请一步步思考”。少样本CoT是给几个带推理过程的示例让模型模仿。零样本CoT的优点是省token、通用性强缺点是推理路径不可控。少样本CoT的优点是路径可控、准确率高缺点是费token、示例写起来麻烦。我的取舍原则是先试零样本效果不够再上少样本。因为写少样本示例本身成本很高而且示例质量直接决定输出质量。如果零样本CoT能达到80分我一般不会为了那10分去写一堆示例。但有个例外当推理格式有严格要求时必须用少样本。比如你要求模型输出“条件→公式→计算→结论”这种固定结构零样本CoT给不出稳定格式这时候示例就是必要的。2.3 CoT的常见翻车场景CoT翻车我遇到过几种典型情况值得单独说说。第一种是“假推理”。模型输出了一堆看起来像推理的话但其实是事后编的跟最终答案对不上。这种情况在温度偏高时特别常见。解决办法是把温度降到0.3以下让推理更“老实”。第二种是“推理链断裂”。模型前面推得好好的中间突然跳步结论就错了。这通常是因为推理步骤太长模型“忘了”前面的内容。解决办法是把大问题拆成多个小问题分步提问。第三种是“过度推理”。简单问题被模型想复杂了本来对的答案被它“想”错了。这就是我前面说的不该用CoT的场景硬用。注意CoT会显著增加token消耗。一个原本100 token能搞定的任务加了CoT可能变成500 token。如果任务量大这个成本要提前算清楚。3. ReAct框架让模型学会“边想边做”如果说CoT是让模型“想清楚再答”那ReAct就是让模型“边想边做边看”。这是我认为目前最实用的高级提示词技巧之一尤其适合需要调用外部工具的场景。3.1 ReAct的核心循环思考-行动-观察ReAct这个名字来自“Reasoning Acting”。它的核心是一个循环Thought思考→ Action行动→ Observation观察→ 再Thought。举个具体例子。你让模型查“今天北京天气适合穿什么”。纯CoT模型只能基于训练数据瞎猜。而ReAct模型会这样跑Thought我需要知道北京今天的天气。Action调用天气查询工具参数是“北京”。Observation返回“晴15-25度微风”。Thought15-25度比较舒适微风适合穿薄外套。最终答案建议穿长袖T恤加薄外套。这个循环的关键在于Observation是真实的外部反馈不是模型编的。这就把模型的“幻觉”问题从根上缓解了——它不需要记住所有事实只需要知道去哪里查。3.2 手写一个ReAct提示词模板ReAct的提示词结构其实很固定我给你一个我常用的模板你可以使用以下工具 - search(query): 搜索信息 - calculator(expression): 计算数学表达式 - lookup(term): 查询术语定义 请严格按照以下格式回应 Question: 用户的问题 Thought: 我需要思考下一步做什么 Action: 工具名(参数) Observation: 工具返回的结果 ... (Thought/Action/Observation可以重复多次) Thought: 我现在知道最终答案了 Final Answer: 最终答案 开始 Question: {用户输入}这个模板有几个细节要注意。第一工具描述要写清楚输入输出否则模型不知道怎么调。第二格式必须严格因为后续代码要解析Action和Observation。第三要给出终止条件也就是什么时候输出Final Answer否则模型可能无限循环。3.3 ReAct在真实项目中的落地要点ReAct落地最大的坑不是提示词而是解析和容错。模型不一定每次都按格式输出可能少个冒号、多个空格、工具名拼错。我的做法是写一个宽松的解析器用正则匹配关键字段匹配不上就重试或者降级处理。另一个要点是限制循环次数。我一般设最多5轮Thought-Action-Observation超过就强制输出当前最优答案。不设上限的话模型可能在一个查不到结果的问题上死磕烧光token。还有个经验工具返回结果要精简。如果search返回一整页HTML模型会被噪声淹没。我一般会在工具层做预处理只返回最相关的几条摘要。这跟给人做信息检索是一个道理喂给模型的信息质量直接决定它的推理质量。4. APE自动提示词工程到底靠不靠谱APEAutomatic Prompt Engineering是这两年比较火的概念简单说就是“让模型自己写提示词”。听起来很美好但实际用下来我的结论是它能帮你找灵感但不能替你做决策。4.1 APE的工作流程拆解APE的典型流程是这样的给定一个任务和一批输入输出示例让模型生成若干个候选提示词然后在这些示例上评估每个候选提示词的表现选最好的那个再基于它迭代优化。这个流程听起来很合理但有几个隐藏问题。第一评估集太小容易过拟合。如果只有10个示例选出来的提示词可能只是恰好在这10个上表现好。第二模型生成的提示词往往“正确但平庸”缺乏人类那种对业务场景的深刻理解。第三迭代次数多了成本很高每次迭代都要跑一遍评估。4.2 我实际使用APE的方式我不会让APE全自动跑而是把它当成“头脑风暴工具”。具体做法是让模型生成20个候选提示词我自己扫一遍挑出3-5个有启发的然后手动改写融合。这样既利用了模型的发散能力又保留了人的判断。另外一个用法是用APE做提示词的“体检”。把我写好的提示词丢给模型让它指出可能的歧义、遗漏的约束、可以优化的表述。模型在这方面还挺敏锐的经常能发现我自己没注意到的盲点。4.3 APE与人工提示词的边界我的判断是APE适合处理“通用任务”人工适合处理“业务任务”。比如“把一段话改写成正式语气”这种通用任务APE能生成不错的提示词。但“根据我们公司的客服话术规范回复用户投诉”这种业务任务APE生成的东西往往隔靴搔痒因为它不懂你的业务细节。所以我的工作流是通用部分用APE打底业务部分人工精修。两者结合效率和质量都能兼顾。5. 系统提示词与Skill Agent两个容易混淆的概念最近“系统提示词工程”和“Skill Agent”这两个词经常被放在一起讨论很多人搞不清区别。我用自己的理解给大家捋一捋。5.1 系统提示词的角色定位系统提示词System Prompt是给模型设定的“底层人设和规则”。它决定了模型是谁、能做什么、不能做什么、用什么风格说话。比如“你是一个专业的法律助手回答必须严谨不确定的要说明”就是典型的系统提示词。系统提示词的特点是全局生效、相对稳定。它不针对某一次具体对话而是贯穿整个会话。写系统提示词的核心是“约束”和“边界”把模型的行为框在一个可控范围内。5.2 Skill Agent的职责边界Skill Agent更像是一个“技能包”。它把某个具体能力比如查数据库、调API、做计算封装成一个可调用的模块模型在需要时调用它。Skill Agent的特点是按需触发、职责单一。打个比方系统提示词是“这个员工的岗位说明书”Skill Agent是“这个员工会用的各种工具”。岗位说明书告诉他该怎么做事工具帮他把事做成。5.3 两者如何配合实际项目里这两者是配合使用的。系统提示词负责“定调”Skill Agent负责“干活”。比如一个客服系统系统提示词规定“你是XX公司的客服态度要友好不能承诺退款”Skill Agent则提供“查询订单”“修改地址”“转人工”这些具体能力。配合的关键是系统提示词里要说明什么时候用哪个Skill。否则模型可能该查订单的时候在那闲聊该转人工的时候自己硬答。我一般会在系统提示词里写一段“工具使用指南”明确每个Skill的触发条件。6. 我的提示词工程完整工作流前面聊了这么多点最后我想把它们串成一个完整的工作流。这是我这些年摸索出来的一套流程不一定最优但实测下来比较稳。6.1 从需求到提示词的拆解步骤第一步明确任务类型。是抽取、生成、推理还是对话任务类型决定了后面所有选择。第二步确定输出格式。先想清楚你要什么格式的输出JSON、Markdown还是纯文本。格式定死了提示词才好写。第三步写初版提示词。我的初版一般包含四块角色设定、任务描述、输出格式、约束条件。先跑通再说不追求完美。第四步构造测试集。至少准备10个有代表性的输入包括边界情况。没有测试集就没法评估提示词好坏。第五步迭代优化。每次只改一个变量跑测试集看指标变化。改什么、为什么改都要有记录。6.2 迭代优化的记录方法我强烈建议做提示词版本管理。我的做法是用一个简单的表格记录每次改动版本改动内容测试通过率备注v1.0初版60%输出格式不稳定v1.1加了格式示例75%格式问题解决v1.2温度从0.7降到0.385%稳定性提升v1.3加了边界情况说明90%边界case处理改善这个表格看起来简单但作用巨大。它让你清楚知道每个改动带来了什么避免“改了半天不知道有没有变好”的困境。6.3 几个让我少走弯路的经验经验一提示词不是越长越好。我见过有人写了两千字的提示词结果模型抓不住重点。提示词的核心是“信息密度”每句话都要有用。废话多了反而稀释关键指令。经验二示例比描述更有效。与其花大段文字描述“输出要简洁”不如直接给一个简洁输出的示例。模型对示例的模仿能力远强于对抽象描述的理解能力。经验三负面指令要慎用。“不要输出XX”这种指令模型有时候会“越不让越想”。更好的做法是正面引导告诉它“应该输出什么”而不是“不要输出什么”。经验四定期回归测试。模型会更新你的提示词可能在新版本上表现不一样。我一般每个月跑一次回归测试确保老提示词没退化。经验五把提示词当代码管理。用Git管理提示词版本写清楚每次commit的原因。这听起来有点重但当你维护几十个提示词时这套流程能救命。6.4 一个完整的实战案例最后用一个案例把整个流程串起来。假设我要做一个“从用户评论中抽取产品问题”的功能。任务类型结构化抽取。输出格式JSON数组每个元素包含problem和severity两个字段。初版提示词你是一个产品评论分析助手。请从用户评论中抽取产品问题输出JSON格式。跑测试集通过率50%。问题主要是有时候输出不是合法JSON有时候漏抽问题。v1.1加了格式示例和字段说明你是一个产品评论分析助手。请从用户评论中抽取产品问题输出JSON数组。 每个元素格式{problem: 问题描述, severity: high/medium/low} 示例输入电池用两小时就没电了而且充电很慢。 示例输出[{problem: 电池续航短, severity: high}, {problem: 充电速度慢, severity: medium}] 现在处理{用户评论}通过率升到80%。剩下的问题是severity判断不稳定。v1.2加了severity的判断标准severity判断标准 - high影响核心功能使用 - medium影响体验但不影响使用 - low轻微瑕疵通过率升到92%。温度从0.7降到0.2后稳定在95%。这个案例里每一步改动都有明确目的都能在测试集上看到效果。这就是我说的“有据可循”的迭代而不是凭感觉瞎调。提示词工程这件事说到底是个“手艺活”。工具和方法论能帮你少走弯路但真正的功力还是来自大量实践和踩坑。我上面分享的这些都是真金白银试出来的希望能帮你省下一些摸索的时间。