1. 为什么我把提示词工程当成一门手艺来练刚接触大模型那会儿我跟很多人一样觉得提示词这东西没什么技术含量——不就是把话说清楚吗直到我用同一套业务需求在不同写法下拿到了天差地别的输出结果才意识到这里面的水比想象中深得多。有一次做商品文案批量生成第一版提示词写出来模型给我的东西全是“品质卓越、匠心打造”这种放之四海而皆准的废话后来我花了整整一个下午调整结构、补充约束、加入示例同样的模型、同样的参数输出质量直接上了一个台阶。那一刻我明白了提示词工程不是玄学它是一门可以拆解、可以练习、可以复用的手艺。这篇文章想聊的是我自己在提示词工程这条路上踩过的坑、总结的方法以及从最基础的参数调优一路走到思维链、ReAct、APE这些进阶技巧的完整路径。不管你是刚上手大模型应用开发的新人还是已经写过一些提示词但总觉得效果不稳定的同行我都希望这里的内容能让你少走一些弯路。我不会只告诉你“这样写效果好”还会把“为什么这样写效果好”讲清楚因为只有理解了底层逻辑你才能举一反三而不是死记硬背几个模板。先说说我对提示词工程的整体理解。很多人把它等同于“会写Prompt”我觉得这个认知太窄了。提示词工程的本质是在模型能力边界内通过输入的结构化设计最大化地引导出你想要的输出。它涉及三个层面第一层是参数层面temperature、top_p、max_tokens这些旋钮怎么拧第二层是结构层面提示词怎么组织、信息怎么排列、示例怎么给第三层是思维层面怎么让模型“想清楚再回答”怎么让它调用外部工具怎么自动优化提示词本身。这三层是递进关系但又不是严格线性的——很多时候你需要同时考虑多个层面。我见过太多人一上来就追求“高级技巧”结果连temperature和top_p的区别都没搞明白调出来的结果忽好忽坏还以为是模型不稳定。所以我的建议是先把基础参数吃透再往上走。接下来的内容我会按照这个逻辑层层展开每一部分都配上我实际用过的例子和参数你可以直接拿去试。2. 参数调优那些看似简单却最容易踩坑的旋钮2.1 temperature和top_p到底该怎么配合temperature和top_p是影响输出随机性的两个核心参数但很多人对它们的理解停留在“temperature越高越随机”这个层面实际用起来还是一头雾水。我用一个生活化的类比来解释把模型生成下一个词的过程想象成你在餐厅点菜temperature控制的是你有多“冒险”——temperature低的时候你倾向于点自己常吃的那几道菜temperature高的时候你愿意尝试菜单上那些没吃过的。而top_p控制的是你从菜单的哪一部分选菜——top_p0.9意味着你只看累积概率排在前90%的菜品后面那些冷门选项直接不考虑。这两个参数的关系是temperature先调整概率分布的形状top_p再在这个调整后的分布上做截断。所以它们不是互斥的而是可以配合使用。我的经验是大部分场景下只需要调其中一个就行同时调两个反而容易让效果变得难以预测。具体怎么选我整理了一个实操参考表场景类型temperaturetop_p说明代码生成、数学推理0.1-0.31.0需要确定性强的输出不要模型“发挥创意”文案创作、头脑风暴0.7-1.00.9-0.95需要多样性但也不能完全放飞数据提取、格式转换0.0-0.11.0几乎要确定性输出不允许有任何偏差对话闲聊0.5-0.80.9平衡自然度和一致性这里有个很多人不知道的细节当temperature设为0时模型理论上每次都会选概率最高的那个词输出是确定性的。但实际中由于浮点运算和并行计算的差异不同批次的输出可能还是有微小差别。如果你需要完全可复现的结果除了设temperature0还要固定seed参数如果模型支持的话。还有一个坑我踩过有些人觉得“temperature设高一点模型会更聪明”。这是完全错误的。temperature高只是让输出更随机不是让模型能力变强。在需要严谨推理的场景下高temperature只会让模型更容易出错。我做过一个简单的测试同一道逻辑推理题temperature0.1时模型答对的概率明显高于temperature1.0。原因很简单推理需要的是步步为营而不是天马行空。2.2 max_tokens与停止序列的隐藏陷阱max_tokens控制的是模型单次输出的最大长度这个参数看起来简单但设置不当会带来两个典型问题。第一个问题是设得太小输出被硬生生截断。我见过有人做长文摘要max_tokens设了256结果模型摘要写到一半就停了后面全是省略号。第二个问题是设得太大浪费资源不说还可能让模型在回答完问题后继续“编”一些无关内容。我的建议是max_tokens要根据任务类型来定而不是拍脑袋设一个值。比如做分类任务输出可能就几个词max_tokens设64足够了做文章生成可能需要2048甚至4096做代码生成要看代码复杂度一般1024-2048比较稳妥。如果你不确定可以先设一个较大的值观察几次输出的实际长度再往下调。停止序列stop sequences是另一个容易被忽视的参数。它的作用是告诉模型“遇到这些字符串就停下来”。比如你在做批量数据处理每条输出用“---”分隔那就可以把“---”设为停止序列这样模型生成到分隔符就会自动停止不会继续往下写。这个技巧在需要连续调用模型处理多条数据时特别有用可以避免模型“串台”。注意停止序列是精确匹配的如果模型输出的内容和停止序列有细微差别比如多了个空格就不会触发停止。所以设置停止序列时最好选那些不太可能自然出现在正文中的字符串。2.3 频率惩罚与存在惩罚的实战取舍frequency_penalty和presence_penalty这两个参数很多人直接忽略但在某些场景下它们能解决大问题。frequency_penalty降低的是“已经出现过的词再次出现的概率”presence_penalty降低的是“已经出现过的词只要出现过就降低其概率”。听起来很绕我用一个例子说明。假设你在让模型写一篇产品介绍模型反复使用“创新”这个词。frequency_penalty会根据“创新”出现的次数来逐步降低它的概率——出现3次后第4次出现的概率就被压得很低。而presence_penalty只要“创新”出现过一次就会把它的概率降低一个固定值不管出现了几次。所以如果你要解决的是“某个词重复太多次”的问题用frequency_penalty如果你要解决的是“模型总是倾向于用某些词”的问题用presence_penalty。两个参数的取值范围一般是-2.0到2.0正值表示惩罚负值表示鼓励。我的经验是frequency_penalty设在0.3-0.8之间比较常用presence_penalty设在0.1-0.5之间。设太高会导致模型用词变得非常奇怪甚至影响语义连贯性。有个实际案例我做商品标题生成时模型总是喜欢用“优选”“甄选”这类词导致生成的标题千篇一律。后来我把presence_penalty设为0.4frequency_penalty设为0.6标题的用词多样性明显提升而且没有出现语义不通的情况。这个组合我后来在多个文案生成场景中都复用效果稳定。3. 提示词结构设计从“说清楚”到“说得巧”3.1 角色设定不是万能药但用对了很管用“你是一个资深的XX专家”——这句话几乎成了提示词的标准开头。但我发现很多人只是机械地加上这句话并没有真正理解角色设定的作用。角色设定的本质是给模型一个上下文锚点让它从海量的训练知识中激活与这个角色相关的部分。当你告诉模型“你是一个资深Python工程师”时它会更倾向于调用Python相关的知识、使用更专业的术语、遵循更规范的代码风格。但角色设定不是越详细越好。我见过有人写“你是一个有20年经验、毕业于名校、曾在多家大厂工作、擅长算法和架构设计的资深工程师”这种过度的角色描述反而会分散模型的注意力。我的做法是角色描述控制在1-2句话重点突出与当前任务最相关的特质。比如做代码审查我会写“你是一个注重代码可读性和边界条件处理的资深工程师”做文案生成我会写“你是一个擅长用具体场景打动读者的文案策划”。还有一个进阶技巧角色设定可以和输出格式绑定。比如“你是一个数据分析师你的回答总是先给出结论再用表格展示数据支撑”。这样模型不仅会以数据分析师的视角思考还会按照你期望的格式输出。这比单独在格式要求里写“请用表格输出”效果更好因为角色设定让格式要求变得“合理”了。3.2 少样本示例的选取与排列策略少样本学习few-shot learning是提示词工程里最实用的技巧之一但示例怎么选、怎么排里面有不少讲究。先说数量大部分任务3-5个示例就够了太少模型抓不住规律太多会占用大量token且边际收益递减。我做过对比测试从3个示例增加到5个准确率有明显提升从5个增加到10个提升就非常有限了。示例的选取比数量更重要。我的原则是示例要覆盖任务的主要模式同时包含边界情况。比如做情感分类你不能只给正面和负面的例子还要给中性、混合情感的例子。做信息提取你要包含字段缺失、格式不规范的例子。这样模型才能学会处理各种情况而不是只会在“标准情况”下工作。示例的排列顺序也有影响。我发现把最典型的示例放在最后效果比较好因为模型对靠近生成位置的上下文更敏感。另外示例的格式要高度一致——如果你第一个示例用“输入xxx 输出xxx”第二个示例用“问题xxx 答案xxx”模型就会困惑。格式一致性是少样本学习的基本功。实操心得示例中的标签分布要均衡。如果你做二分类5个示例里4个是正类1个是负类模型会倾向于预测正类。我一般保持正负样本比例接近1:1如果做不到至少不要差得太离谱。3.3 输出格式约束的硬手段与软手段让模型按照指定格式输出是很多应用场景的刚需。我总结了两类方法软手段和硬手段。软手段是在提示词里描述格式要求比如“请用JSON格式输出包含name和age两个字段”。硬手段是直接给出格式模板甚至给出一个完整的示例输出。软手段的优点是灵活缺点是模型有时候会“忘记”格式要求特别是在输出内容较长的时候。硬手段的优点是约束力强缺点是如果模板设计得不好模型可能会生搬硬套。我的做法是两者结合先用一句话描述格式要求再给一个具体的模板示例。比如请按以下JSON格式输出 {name: 姓名, age: 年龄, skills: [技能1, 技能2]}这样模型既有文字描述作为指导又有具体模板作为参照格式遵循率会高很多。另外如果你用的是支持JSON mode的API那就直接开启这个模式模型会保证输出合法的JSON。但要注意JSON mode只保证格式合法不保证字段内容正确所以提示词里的字段说明还是要写清楚。还有一个技巧在提示词末尾再次强调格式要求。因为模型对末尾内容的注意力权重更高把格式要求放在最后可以起到“提醒”的作用。我通常会在提示词的最后一行写“请严格按照上述格式输出不要添加任何额外说明”。4. 思维链与ReAct让模型学会“想清楚再做”4.1 思维链提示的适用边界与变体思维链Chain of ThoughtCoT是提示词工程里一个里程碑式的技巧。它的核心思想很简单让模型在给出最终答案之前先展示推理过程。这个技巧在数学题、逻辑推理、多步计算等场景下效果显著。我做过对比同一道需要三步推理的应用题直接问模型准确率大概在60%左右加上“请一步步思考”之后准确率能到85%以上。但思维链不是万能的。对于简单的事实性问题、分类任务、信息提取任务思维链反而可能带来负面影响——模型会“过度思考”把简单问题复杂化甚至推理出错误的结论。我试过在情感分类任务里加思维链结果模型开始分析“这句话为什么是正面的”分析着分析着把自己绕进去了最后给出了错误的分类。所以我的原则是只在需要多步推理的任务上用思维链简单任务直接问就行。思维链还有几个变体值得了解。Zero-shot CoT就是最简单的“请一步步思考”不需要给示例。Few-shot CoT是给几个带推理过程的示例让模型模仿。还有Self-Consistency就是让模型用较高的temperature生成多条推理路径然后取多数答案作为最终结果。这个方法在数学题上效果很好但成本也高——相当于一次请求要调用多次模型。我实际用得最多的是Zero-shot CoT因为它在大多数场景下已经够用了而且不需要精心准备示例。如果效果不够好再考虑Few-shot CoT。Self-Consistency我一般只在做高价值、高难度的推理任务时才会用毕竟成本摆在那里。4.2 ReAct框架的落地细节与常见误区ReActReasoning Acting是我认为最被低估的提示词工程技巧之一。它的核心思想是让模型交替进行推理和行动先想一步然后决定要不要调用工具根据工具返回的结果再想下一步如此循环直到得出最终答案。这个框架特别适合需要外部信息的任务比如查天气、算数学、搜资料。ReAct的提示词结构一般包含三个部分Thought思考、Action行动、Observation观察。模型先输出Thought说明它现在要做什么然后输出Action指定要调用的工具和参数系统执行工具后把结果作为Observation返回给模型模型再基于Observation进行下一轮Thought。这个循环直到模型认为可以给出最终答案为止。我踩过的一个坑是没有给模型足够的工具使用示例。第一次写ReAct提示词时我只描述了工具的功能没有给具体的调用示例结果模型要么不调用工具要么调用格式完全不对。后来我在提示词里加了2-3个完整的ReAct循环示例模型的工具调用准确率大幅提升。所以如果你要用ReAct一定要在提示词里给出完整的示例包括Thought、Action、Observation的格式。另一个常见误区是工具描述太模糊。比如你有一个搜索工具描述写成“搜索信息”模型就不知道什么时候该用、什么时候不该用。好的工具描述应该包含工具能做什么、输入格式是什么、什么场景下应该使用。比如“当需要查询实时信息如天气、新闻、股价时使用此工具输入为搜索关键词字符串”。注意ReAct对模型的指令遵循能力要求较高。如果模型本身能力不够ReAct的效果可能还不如直接问。我建议在能力较强的模型上使用ReAct小模型上还是用简单的提示词更稳妥。4.3 从CoT到ReAct的选型决策树CoT和ReAct不是互斥的而是适用于不同场景。我整理了一个简单的决策逻辑如果任务需要多步推理但不需要外部信息用CoT如果任务需要外部信息或工具调用用ReAct如果任务既需要推理又需要工具用ReAct因为ReAct本身就包含了推理环节。具体来说数学应用题、逻辑谜题、代码调试这类任务CoT就够了。查天气、订机票、搜索最新资讯这类任务必须用ReAct。而像“帮我分析一下这家公司的最新财报并给出投资建议”这种任务就需要ReAct——先搜索财报数据再基于数据进行推理分析。还有一个混合模式先CoT再ReAct。比如让模型先分析问题需要哪些信息再决定调用什么工具。这个模式在复杂任务上效果不错但提示词会复杂很多需要仔细设计。5. APE与自动提示词优化让模型自己写提示词5.1 APE的核心思路与实操流程APEAutomatic Prompt Engineering是这两年比较火的一个方向核心思路是让模型自己生成和优化提示词。具体做法是你先给模型一个任务描述让它生成多个候选提示词然后用这些候选提示词去执行任务根据执行结果给每个提示词打分最后选出得分最高的提示词或者让模型基于高分提示词进一步优化。这个方法的优势在于可以减少人工试错成本。特别是当你对某个任务不太熟悉、不知道怎么写提示词时让模型先给你几个候选方案往往能打开思路。我做过一个实验让模型为“从用户评论中提取产品特征和情感倾向”这个任务生成提示词它给出的方案里有一些我没想到的角度比如“先判断评论是否包含具体产品特征再提取情感词”。但APE也有明显的局限。它生成的提示词往往比较“通用”缺乏针对具体业务场景的精细约束。比如模型生成的提示词可能不会考虑到你的数据里有大量反讽表达或者你的输出格式有特殊要求。所以我的做法是用APE生成初版提示词然后在此基础上人工调整加入业务特定的约束和示例。实操流程上我一般这样做第一步写一个“元提示词”让模型生成5-10个候选提示词第二步用一批测试数据分别跑这些候选提示词记录每个提示词的表现第三步选出表现最好的2-3个让模型分析它们的共同点并生成改进版第四步人工审核改进版加入必要的业务约束。这个流程走下来通常能比纯手工写提示词节省一半以上的时间。5.2 自动优化中的评估难题APE最大的难点不在于生成提示词而在于如何自动评估提示词的好坏。对于分类任务你可以用准确率对于生成任务评估就复杂多了。我试过用BLEU、ROUGE这些指标但它们和人类判断的相关性并不高。后来我改用“模型评估模型”的方式用一个能力较强的模型来给输出打分从相关性、完整性、流畅度等维度评价。这个方法的效果比自动指标好但也有问题评估模型本身可能有偏见。比如它可能偏好更长的输出或者偏好某些特定的表达方式。我的应对策略是设计评估提示词时明确列出评分维度和每个维度的评分标准让评估模型按标准打分而不是凭感觉。另外我会定期人工抽查一批评估结果看看评估模型的判断和我的判断是否一致如果不一致就调整评估提示词。还有一个实用技巧用A/B测试的思路来评估提示词。不要试图给每个提示词打一个绝对分数而是两两比较让评估模型判断“哪个提示词的输出更好”。这种方法比绝对打分更稳定因为模型更擅长做相对判断。5.3 人工经验在自动优化中的不可替代性虽然APE听起来很美好但我想强调的是人工经验在提示词优化中仍然不可替代。模型生成的提示词往往缺乏“业务感”——它不知道你的用户是谁、你的产品调性是什么、你的业务红线在哪里。这些只有你自己清楚。举个例子我做金融领域的问答系统时APE生成的提示词里有一条“尽可能提供详细的信息”。这个提示词在通用场景下没问题但在金融领域就危险了——详细的信息可能包含投资建议而投资建议是需要合规审核的。后来我把它改成了“提供基于公开信息的事实性回答不包含任何投资建议”。这个修改是模型想不到的因为它不理解金融行业的合规要求。所以我的建议是把APE当成一个辅助工具而不是替代方案。用它来拓展思路、生成初稿但最终的提示词一定要经过人工审核和业务适配。另外APE生成的提示词往往比较冗长人工优化时可以把冗余部分删掉让提示词更精炼。6. 实战中的问题排查与经验沉淀6.1 输出不稳定的排查思路输出不稳定是提示词工程中最常见的问题。同样的提示词有时候输出很好有时候一塌糊涂。遇到这种情况我一般按以下顺序排查第一步检查temperature和top_p。如果temperature设得比较高输出不稳定是正常的。先把它降到0.1试试如果输出变稳定了说明问题出在随机性参数上。第二步检查提示词是否有歧义。有时候你自己觉得说清楚了但模型理解成了另一个意思。我常用的方法是把提示词给一个同事看问他“你觉得这个任务要做什么”如果他的理解和你的预期不一致那模型大概率也会理解错。第三步检查示例是否一致。如果少样本示例的格式、风格、标签分布有问题模型就会困惑。我一般会仔细检查每个示例确保它们在格式和逻辑上完全一致。第四步检查输入数据是否有异常。有时候问题不在提示词而在输入数据本身。比如输入文本里包含了特殊字符、超长文本、或者与示例风格差异很大的内容都可能导致输出异常。6.2 常见问题速查表问题现象可能原因排查方法解决方案输出被截断max_tokens太小检查输出长度增大max_tokens输出格式不对格式约束不够强检查提示词中的格式说明加入格式模板和示例模型不调用工具工具描述模糊或缺少示例检查工具描述和ReAct示例补充工具使用示例输出重复啰嗦frequency_penalty太低检查重复词出现频率提高frequency_penalty推理结果错误缺少思维链引导检查是否需要多步推理加入“一步步思考”分类结果偏向某一类示例标签分布不均统计示例标签比例调整示例使标签均衡输出内容跑题提示词约束不够检查提示词是否明确任务边界加入明确的约束条件6.3 我踩过的三个典型坑第一个坑是过度依赖角色设定。刚开始写提示词时我总觉得角色设定越详细越好结果写了一大段角色描述反而把任务本身的要求淹没了。后来我学会了角色设定要精简把重点放在任务描述和输出要求上。第二个坑是示例选取不当。有一次做意图分类我选了5个示例其中4个都是“查询类”意图只有1个是“办理类”。结果模型在测试时把所有“办理类”的输入都分类成了“查询类”。这个教训让我明白示例的标签分布必须均衡否则模型会学到错误的先验。第三个坑是忽视停止序列。做批量数据处理时我没有设置停止序列结果模型在输出完一条数据后自动开始“编”下一条数据导致输出混乱。后来我设置了“---”作为停止序列问题就解决了。这个坑让我意识到提示词工程不只是写提示词还包括对模型行为的全面控制。6.4 提示词版本管理与迭代策略提示词是需要迭代的而迭代的前提是可追溯、可对比。我现在的做法是每个提示词都存成一个独立文件文件名包含版本号和日期比如intent_classification_v3_20260315.txt。每次修改提示词都新建一个版本而不是直接改原文件。这样当新版本效果不好时可以快速回滚到旧版本。另外我会为每个提示词维护一个简单的测试集包含10-20条代表性输入和期望输出。每次修改提示词后跑一遍测试集对比新旧版本的表现。这个习惯让我避免了很多“改了一个地方结果另一个地方坏了”的问题。实操心得提示词里的注释很重要。我习惯在提示词文件的开头用注释写明这个提示词的用途、适用场景、已知限制和修改记录。这样过几个月再回来看也能快速回忆起当时的思路。7. 从提示词工程到上下文工程我的认知升级做了大半年的提示词工程之后我逐渐意识到一个事实提示词本身只是上下文的一部分。模型最终输出什么取决于它看到的整个上下文——包括系统提示词、对话历史、检索到的文档、工具返回的结果等等。所以单纯优化提示词天花板是有限的。这个认知让我开始关注“上下文工程”这个概念。它的核心思想是把模型需要的所有信息以最合适的方式组织在上下文窗口里。这包括哪些信息应该放在系统提示词里哪些应该放在用户消息里哪些应该通过检索动态注入哪些应该通过工具调用获取。提示词工程是上下文工程的一个子集但上下文工程的视野更广。举个例子做知识库问答时提示词工程关注的是“怎么问模型才能让它答得准”而上下文工程关注的是“检索哪些文档、怎么排序、怎么截断、怎么和问题拼接”。后者对最终效果的影响往往更大。我做过对比同样的提示词检索策略优化后回答准确率提升了30%以上。所以如果你已经掌握了提示词工程的基本技巧我建议你把视野再放宽一点开始关注上下文工程。这两个技能结合起来才能真正把大模型应用的效果做到位。最后分享一个我最近在用的技巧把提示词当成代码来管理。用Git做版本控制用测试集做回归测试用A/B测试做效果对比。这套工程化的方法比手工改来改去靠谱得多。我现在的提示词仓库里已经有几十个版本每次迭代都有记录出了问题也能快速定位。这个习惯看起来麻烦但长期来看节省的时间远超投入。