1. 为什么我把提示词工程当成一门手艺来练刚接触大模型那会儿我跟大多数人一样觉得提示词这东西没什么门槛——不就是把需求用中文说清楚吗直到有次我让模型帮我写一个批量处理表格的脚本来回改了十几版每次它都能精准地绕开我的真实意图要么给我一个跑不通的伪代码要么在关键逻辑上自作主张。那天下午我盯着屏幕想了很久意识到问题不在模型能力而在我根本没搞清楚怎么跟它“对话”。后来我开始系统性地拆解这件事。提示词工程不是玄学也不是简单的“话术”它更像是一门需要刻意练习的手艺。你得理解模型的脾气知道它在什么情况下会犯什么类型的错误然后用结构化的方式去规避。这跟带团队很像——你不能指望新人一次就听懂你的意思但你可以通过明确约束、给出示例、分步引导让他产出接近你预期的结果。这篇文章我想把自己这两年踩过的坑、试过的招、沉淀下来的方法论完整地聊一遍。从最基础的参数调优到思维链、ReAct、APE这些进阶技巧再到怎么把这些东西组合成一套可复用的工作流。不管你是刚入门的新手还是已经写过几百条提示词的老手应该都能从中找到一些能直接拿去用的东西。2. 参数调优那些文档里不会告诉你的细节2.1 温度、Top-p、Top-k到底该怎么配很多人调参就是凭感觉温度高了怕它胡说温度低了怕它死板。我一开始也是这样后来逼着自己做了一组对照实验才慢慢摸清楚这几个参数的实际影响。先说温度。这个参数控制的是输出的随机性。温度越低模型越倾向于选择概率最高的那个词输出就越确定、越保守。温度越高低概率的词也有机会被选中输出就更多样、更有创意。但这里有个坑温度调到0并不意味着完全确定因为底层还有浮点计算的误差同一个提示词跑两次结果可能还是有细微差别。我的经验是不同任务类型应该用不同的温度区间任务类型建议温度原因代码生成0.1-0.3需要确定性避免模型自由发挥引入bug数据提取0-0.2要求严格忠实原文不能有创造性文案创作0.7-0.9需要多样性太保守反而没意思头脑风暴0.9-1.2要的就是发散越意外越好翻译0.2-0.4在准确和流畅之间取平衡Top-p和Top-k是另一种控制随机性的方式。Top-k是只从概率最高的k个词里选Top-p是从累积概率达到p的最小词集合里选。这两个参数一般不需要同时调选一个用就行。我个人的习惯是优先用Top-p因为它能自适应不同位置的候选词数量——在模型很确定的地方候选集自然就小在模型犹豫的地方候选集就大。有个细节值得注意当你把温度调得很低的时候Top-p和Top-k的影响会变得很小因为高概率词已经占据了绝对优势。反过来温度很高的时候这两个参数的作用就明显了。所以调参要有主次先定温度再用Top-p微调。2.2 最大长度与停止序列的隐藏陷阱最大长度这个参数看起来简单设个数字就行但实际用起来有不少门道。设得太短模型话说到一半被截断输出不完整设得太长模型可能会在结尾处开始胡言乱语或者反复重复同一句话。我的一般做法是先估算任务需要的输出长度然后在此基础上加20%到30%的余量。比如让模型写一段200字的产品描述最大长度设到300左右就够了。如果任务复杂需要模型先推理再给答案那就要把推理过程的长度也算进去。停止序列是个容易被忽略但很有用的功能。你可以指定一个字符串当模型输出到这个字符串时就自动停止。这在结构化输出场景下特别好用。比如你让模型输出JSON可以设置停止序列为“”这样它生成完代码块就会自动停下不会在后面加一堆解释性文字。注意停止序列本身不会出现在最终输出里所以如果你需要那个标记得在提示词里让模型在停止序列之前再输出一遍。2.3 频率惩罚与存在惩罚的实战取舍频率惩罚和存在惩罚都是用来抑制模型重复输出的。频率惩罚根据词出现的次数来惩罚出现越多惩罚越重存在惩罚只要词出现过就惩罚不管出现几次。这两个参数在长文本生成时特别有用。我遇到过模型在写长文时反复用同一个句式读起来非常机械。加了频率惩罚之后它会主动换表达方式。但惩罚也不能设太高否则模型会为了避开重复而选择一些不自然的表达。我的经验值是频率惩罚在0.3到0.8之间比较安全存在惩罚在0.1到0.5之间。超过1.0之后输出质量会明显下降模型会变得畏手畏脚甚至出现语法错误。还有一个细节这两个参数对中文的影响和对英文不太一样。中文的词汇重复率天然就比英文高所以中文任务可以适当降低惩罚值否则模型会为了不重复而用一些生僻词反而影响可读性。3. 思维链与进阶推理技巧3.1 思维链提示的正确打开方式思维链这个概念刚火的时候很多人以为只要在提示词里加一句“让我们一步步思考”就行了。我试过效果确实有提升但远没有传说中那么神奇。后来我仔细研究了相关论文和实际案例发现关键在于“示范”而不是“指令”。真正有效的思维链提示是给模型展示几个完整的推理示例每个示例都包含问题、推理步骤和最终答案。模型看到这些示例后会模仿这种“先推理再回答”的模式。单纯说“一步步思考”只是给了个方向但没有告诉模型具体该怎么一步步思考。举个例子如果你想让模型做数学应用题可以这样构造提示词问题小明有5个苹果吃了2个又买了3个现在有几个 推理初始5个吃掉2个后剩5-23个又买3个后336个。 答案6个 问题小红有8支笔送给同学3支又丢了1支现在有几支 推理模型看到前面的示例后会自然地按照“初始数量→变化→最终数量”的格式来推理。这比单纯说“一步步思考”要有效得多。3.2 零样本思维链的适用边界零样本思维链就是在没有示例的情况下直接让模型分步推理。常用的触发语有“让我们一步步思考”、“请展示你的推理过程”等。这种方法在数学、逻辑推理、多步计算等任务上效果不错但在创意写作、开放式问答等任务上反而可能拖后腿。我做过一个对比测试让模型写一段产品文案一组用零样本思维链一组直接写。结果直接写的那组文案更流畅、更有感染力而思维链那组因为把注意力放在了“推理”上文案变得像在写分析报告。所以我的建议是需要严谨推理的任务用思维链需要创意表达的任务别用。判断标准很简单——如果你自己完成这个任务时需要打草稿、列步骤那就适合用思维链如果你自己都是凭感觉一气呵成那就别让模型绕弯子。3.3 自洽性采样用多次推理投票出最优解自洽性采样是我觉得最被低估的技巧之一。它的思路很简单同一个问题让模型用较高的温度跑多次每次得到不同的推理路径和答案然后取出现次数最多的那个答案。这个方法在数学题上效果特别明显。我试过一道稍微绕一点的逻辑题单次推理的正确率大概在60%左右但跑5次取多数投票后正确率能到85%以上。代价就是计算成本翻了5倍所以适合那些对准确性要求高、但可以接受一定延迟的场景。实际操作时有个小技巧不要只取最终答案投票也可以对推理过程中的关键中间步骤投票。比如一道多步计算题如果多数推理路径在第二步就得出了相同的中间结果那这个中间结果的可信度就很高。3.4 思维树当线性推理不够用的时候思维链是线性的一条路走到黑。但有些问题需要探索不同的分支这时候思维树就更合适。它的做法是让模型在每个关键节点生成多个可能的下一步然后评估每个分支的前景选择最有希望的方向继续深入。我一般用思维树来处理那些需要“试错”的任务比如设计一个复杂的算法方案。让模型先提出三种不同的思路然后分别评估每种思路的优缺点再选择其中一种展开细节。这样比让模型直接给一个方案要全面得多。不过思维树也有代价提示词会变得很长而且需要多轮交互。如果任务本身不复杂用思维链就够了没必要上思维树。4. ReAct框架让模型学会边想边做4.1 ReAct的核心机制拆解ReAct是Reasoning和Acting的组合核心思想是让模型在推理和行动之间交替进行。传统的提示词要么只让模型推理思维链要么只让模型行动直接输出结果而ReAct让模型先推理当前情况然后决定采取什么行动观察行动结果后再继续推理。这个框架特别适合需要外部工具的场景。比如你让模型查一个实时数据它不能凭空编造得先推理“我需要查什么”然后调用搜索工具看到结果后再推理“这个结果说明什么”最后给出答案。ReAct的提示词结构一般是这样的你可以使用以下工具 - 搜索[关键词]搜索相关信息 - 计算[表达式]计算数学表达式 - 查询[数据库]查询数据库 请按照以下格式回答 思考你需要思考当前情况 行动你决定采取的行动 观察行动的结果 ...重复思考和行动 最终答案你的最终回答 问题...关键点在于“观察”这一步。模型需要根据工具返回的结果来调整后续的推理方向。如果搜索结果不相关它应该重新搜索而不是硬着头皮往下编。4.2 手写一个ReAct Agent的完整流程我拿一个实际例子来演示。假设我要让模型帮我分析某只股票最近的表现但不能直接给它数据得让它自己决定查什么。第一步定义工具集。我给它三个工具查股价、查新闻、查财报。每个工具都有明确的输入输出格式。第二步构造提示词。我会在系统提示里写清楚可用工具和输出格式然后在用户消息里给出任务。第三步解析模型输出。模型每次输出“行动”后我需要解析出它想调用哪个工具、参数是什么然后实际执行这个工具把结果作为“观察”返回给模型。第四步循环直到模型输出“最终答案”。这个流程听起来简单但实际写起来有几个坑。一个是模型可能会输出格式不规范的“行动”比如参数缺了引号或者用了中文标点。我的做法是在提示词里给一个严格的格式示例并且在解析时做容错处理。另一个是模型可能会陷入死循环反复调用同一个工具。我一般会设置最大轮数比如10轮超过就强制让它给答案。4.3 ReAct与函数调用的配合策略现在很多模型平台都支持原生的函数调用功能这比让模型自己输出“行动”文本要可靠得多。函数调用模式下模型会直接输出结构化的调用请求平台自动执行并把结果返回给模型。但函数调用也不是万能的。它更适合那些工具定义清晰、参数简单的场景。如果工具的逻辑很复杂或者需要模型在调用前做大量推理ReAct的显式推理过程反而更有优势。我的做法是混合使用对于简单的数据查询直接用函数调用对于需要多步推理的复杂任务用ReAct框架让模型显式地展示思考过程。这样既保证了效率又保留了可解释性。5. APE自动提示词工程的实践与局限5.1 APE的基本原理与操作步骤APE是Automatic Prompt Engineering的缩写思路是让模型自己生成和优化提示词。具体做法是给定一个任务和少量示例让模型生成多个候选提示词然后在这些候选上评估效果选择最好的那个再基于它生成下一轮候选反复迭代。我试过用APE来优化一个文本分类任务的提示词。初始提示词是我手写的准确率大概在78%左右。让模型生成20个候选提示词每个都在验证集上跑一遍最好的那个到了83%。然后再基于最好的那个生成第二轮候选最终稳定在86%左右。操作步骤大致如下准备任务描述和少量标注示例让模型生成N个候选提示词N一般取10-20在每个候选提示词上运行验证集记录准确率选择Top-K个候选让模型基于它们生成新的候选重复步骤3-4直到准确率不再提升或达到最大轮数5.2 什么时候该用APE什么时候不该用APE最大的优势是省人力。你不需要自己反复琢磨措辞模型会帮你探索你没想到的表达方式。但它的局限也很明显需要标注数据来评估候选提示词的好坏。如果没有验证集APE就无从谈起。另外APE生成的提示词有时候会“过拟合”到验证集上。我遇到过一种情况APE找到的提示词在验证集上表现很好但换一批数据后效果就掉下来了。这是因为模型找到了一些针对特定样本的“捷径”而不是真正理解了任务。所以我的建议是如果你有足够的标注数据而且任务比较标准化分类、抽取、匹配等可以试试APE。但如果你做的是创意类任务或者没有数据来评估那还是手动调提示词更靠谱。5.3 人工经验与自动优化的结合点完全自动化的APE我不太推荐但“半自动”的方式很好用。具体来说就是让模型生成候选提示词但由我来判断哪个更好而不是完全依赖自动评估。这样做的好处是我能看到模型提出的各种表达方式有些是我自己想不到的。比如有次模型把一个很啰嗦的提示词压缩成了一句话效果反而更好。这种“灵感”是自动评估给不了的。我的工作流是先用APE生成一批候选然后人工筛选出3-5个有潜力的再手动微调。这样既利用了模型的发散能力又保留了人的判断力。6. 系统提示词与Skill Agent的边界6.1 系统提示词该写什么、不该写什么系统提示词是模型的“出厂设置”它定义了模型的基本行为准则。很多人把系统提示词当成万能工具箱什么都往里塞结果模型反而变得畏手畏脚。我的原则是系统提示词只写那些贯穿整个对话的、不变的内容。比如模型的角色定位、输出格式的基本要求、必须遵守的安全准则。具体的任务指令应该放在用户消息里而不是系统提示词里。举个例子如果你在做一个客服机器人系统提示词可以写“你是一个专业的客服助手回答要简洁、友好、准确”但不应该写“当用户问退货时按照以下三步回答”。后者应该放在具体的对话流程里根据用户的实际问题动态构造。系统提示词写得太细的另一个问题是它会占用宝贵的上下文空间。现在的模型虽然上下文窗口很大但系统提示词太长会导致模型对用户消息的注意力下降。我一般把系统提示词控制在200字以内只保留最核心的约束。6.2 Skill Agent的适用场景与设计要点Skill Agent是最近比较火的概念本质上是把特定能力封装成独立的模块模型在需要时调用。比如一个“翻译Skill”、一个“总结Skill”、一个“代码审查Skill”。这种设计的好处是职责清晰。每个Skill只做一件事提示词可以针对这个任务深度优化。而且Skill可以独立迭代不会互相影响。但Skill Agent也有代价。模型需要判断什么时候该调用哪个Skill这个判断本身就可能出错。我见过模型在应该调用翻译Skill的时候直接自己翻译了结果质量参差不齐。我的做法是给每个Skill写清楚触发条件并且在系统提示词里强调“当遇到X情况时必须调用Y Skill”。同时Skill的输入输出格式要严格定义避免模型在调用时传错参数。6.3 两者如何协同工作系统提示词和Skill Agent不是二选一的关系而是可以配合使用的。系统提示词负责定义“你是谁”、“你有哪些能力”Skill Agent负责具体执行。我一般这样设计系统提示词里列出所有可用的Skill和它们的用途然后用户消息里给出具体任务。模型先判断这个任务需要哪些Skill然后依次调用最后整合结果。这种架构的挑战在于错误处理。如果某个Skill调用失败模型需要知道该怎么降级处理。我会在系统提示词里写清楚“如果某个Skill不可用尝试用其他方式完成或者告知用户当前无法处理。”7. 我的完整工作流与避坑清单7.1 从零开始构建提示词的步骤我现在写提示词的流程已经比较固定了分享出来供参考第一步明确任务边界。先想清楚这个提示词要解决什么问题输入是什么期望的输出是什么。这一步看起来简单但很多人跳过它直接开始写结果写到一半发现方向不对。第二步写一个最简版本。不要一上来就追求完美先写一个能跑通的最简提示词看看模型的基本表现。第三步分析失败案例。把模型输出不对的案例收集起来归类分析。是理解错了任务还是格式不对还是推理跳步了第四步针对性优化。根据失败类型选择优化策略理解问题就加示例格式问题就加约束推理问题就加思维链。第五步回归测试。每次修改后都要在之前的测试集上跑一遍确保没有引入新的问题。第六步固化模板。当提示词稳定后把它整理成模板把可变部分用占位符标出来方便复用。7.2 常见问题速查表问题现象可能原因解决方案输出格式不稳定约束不够明确给出严格的格式示例使用停止序列模型忽略部分指令指令太多或太靠后精简指令把最重要的放在前面推理跳步没有引导分步思考加入思维链示例或触发语重复输出频率惩罚不够提高频率惩罚值或加入“不要重复”的约束编造信息温度太高或缺乏约束降低温度加入“如果不确定就说不知道”输出被截断最大长度不够增加最大长度或让模型分多次输出对示例过拟合示例太少或太相似增加示例多样性覆盖边界情况7.3 那些年我踩过的坑第一个坑是“提示词越长越好”。刚开始我觉得写得越详细模型越明白结果发现太长的提示词会让模型抓不住重点。后来我学会了分层核心指令放最前面细节补充放后面用分隔符隔开。第二个坑是“示例越多越好”。有次我给了10个示例结果模型把示例里的具体内容当成了任务的一部分输出里混进了示例的措辞。后来我控制在3-5个示例并且确保示例之间有足够的差异性。第三个坑是“一次改太多”。有次我同时改了温度、提示词结构和示例结果效果变差了但我不知道是哪个改动导致的。后来我养成了习惯每次只改一个变量改完测试确认有效再改下一个。第四个坑是“忽略模型版本差异”。同一个提示词在不同版本的模型上表现可能完全不同。我现在会在提示词里标注适用的模型版本换模型时重新测试。7.4 持续迭代的心得提示词工程没有一劳永逸的解决方案。模型在更新任务在变化用户的需求也在变。我的做法是建立一个“提示词库”把每个任务的提示词版本都记录下来标注每次修改的原因和效果。这样当效果下降时可以快速回溯到之前的版本。另外我会定期用新的测试案例来检验现有提示词。有时候模型升级后之前的一些约束变得不必要了去掉反而效果更好。保持开放的心态不要固守某一种写法。最后分享一个我觉得最有用的习惯每次写提示词的时候把自己想象成在和一个非常聪明但完全不了解你背景的人对话。你需要把所有的隐含假设都显式地表达出来把所有的期望都明确地写下来。这个心态转变之后我的提示词质量有了质的提升。