1. 为什么提示词工程值得单独拎出来做一套方法论我接触大模型应用开发差不多两年多从最早拿API瞎试到后来带团队做智能客服、文档问答、数据分析助手踩过的坑比写过的提示词还多。一开始我也觉得提示词这东西没什么技术含量不就是把话说清楚吗但真正到了生产环境你会发现同一个模型、同一个任务提示词差一句话输出质量能差出两个档次。提示词工程不是玄学它是一套可以拆解、可以复现、可以量化的工程方法。这篇文章我想聊的是我自己的完整方法论从最底层的参数调优到中层的结构化提示词设计再到上层的思维链、ReAct、思维树这些高级技巧。适合谁看如果你已经在调用大模型API做应用或者准备把大模型能力集成到自己的产品里那这套东西你大概率用得上。如果你只是偶尔用用聊天窗口那可能感受没那么深但了解一下参数背后的逻辑也没坏处。先说一个我自己的判断提示词工程的核心不是“写提示词”而是“控制模型的输出空间”。你写的每一句话、设的每一个参数本质上都是在缩小模型可能的输出范围让它更大概率落在你想要的那个区域里。理解了这个底层逻辑后面所有的技巧都是围绕这个目标展开的。我见过太多人把提示词当成一次性消耗品写完就扔出了问题就换模型。但实际上一套好的提示词是需要迭代的需要你有意识地去记录、对比、优化。我现在的习惯是任何一个上生产的提示词至少经过五轮以上的迭代每一轮都有明确的改动点和评估标准。下面我从参数开始一层一层往上拆。2. 参数调优三件套temperature、top_p、presence_penalty到底怎么设很多人调API的时候参数那一栏直接默认或者随便填个0.7就完事了。但参数调优是提示词工程里最容易被忽视、又最立竿见影的部分。我把它总结成“三件套”temperature、top_p、presence_penalty。这三个参数控制的是模型输出的随机性、多样性和重复度理解它们之间的配合关系比单独调某一个重要得多。2.1 temperature控制输出的“冒险程度”temperature的本质是softmax函数里的温度系数。说人话就是温度越低模型越倾向于选概率最高的那个词温度越高概率分布越平坦低概率的词也有机会被选中。我一般这么设0到0.3适合事实性问答、代码生成、数据提取。这个区间输出非常稳定几乎每次跑结果都差不多。0.4到0.7适合文案写作、对话生成。有一点变化但不会太离谱。0.8到1.2适合创意写作、头脑风暴。输出多样性明显增加但事实准确性会下降。超过1.2我基本不用输出容易胡言乱语除非你在做对抗测试。注意temperature设成0并不代表完全确定性。由于浮点运算和并行计算的差异同一输入两次调用仍可能有微小差别。如果你需要严格可复现得配合固定随机种子。我踩过的一个坑是做数据提取任务时temperature设了0.7结果模型偶尔会把数字“3”写成“三”或者把日期格式变来变去。后来降到0.1问题直接消失。所以任务越需要精确温度越要低这个原则基本不会错。2.2 top_p另一种控制多样性的方式top_p叫核采样思路是把所有词按概率从高到低排列累加到top_p为止只从这个“核”里采样。比如top_p0.9就是只考虑累计概率前90%的词。和temperature的区别在于temperature是全局调整概率分布top_p是动态截断。我的经验是temperature和top_p不要同时调。一般固定一个调另一个。我通常固定top_p1只调temperature因为这样更直观。如果你发现temperature调了之后输出还是太发散可以把top_p降到0.8或0.9效果相当于给输出加了个上限。2.3 presence_penalty和frequency_penalty控制重复这两个参数经常被混淆。presence_penalty是“只要这个词出现过就惩罚它”不管出现几次。frequency_penalty是“出现次数越多惩罚越重”。我一般用presence_penalty来避免模型反复说同一句话设0.1到0.5就够了。frequency_penalty用得少除非在做长文本生成需要防止某个词被过度使用。下面这张表是我在不同任务下的参数配置参考可以直接抄任务类型temperaturetop_ppresence_penalty说明数据提取/分类0.11.00追求稳定和准确代码生成0.21.00代码需要确定性客服对话0.50.90.3需要一定灵活性文案创作0.81.00.2需要多样性头脑风暴1.01.00.5追求发散提示不同模型厂商对参数的定义和范围可能不同。比如有些模型的temperature范围是0到2有些是0到1。调之前先看文档别照搬。还有一个我经常用的技巧动态调参。比如在对话系统里用户第一轮提问时用temperature0.7让回复自然一些但如果检测到用户情绪激动或者问题涉及事实查询自动降到0.3。这个逻辑可以在代码里根据意图识别结果来切换效果比固定参数好很多。3. 结构化提示词设计从“说人话”到“说模型能听懂的话”参数调好了接下来就是提示词本身。我见过很多人写提示词就像在跟人聊天想到哪写到哪。但模型不是人它没有常识推理的默认背景你需要把上下文、角色、约束、输出格式全部显式地写出来。我现在的提示词基本都遵循一个结构角色定义 任务描述 上下文 约束条件 输出格式 示例。3.1 角色定义给模型一个“身份锚点”角色定义不是随便写一句“你是一个助手”就完事了。好的角色定义应该包含三个要素专业领域、经验水平、行为风格。比如你是一位有十年经验的Python后端工程师擅长编写高并发、可维护的代码。 你回答问题时先给出结论再解释原因代码示例必须包含类型注解和异常处理。这样写的好处是模型在生成时会自动对齐这个角色的知识范围和表达习惯。我实测下来加了详细角色定义的提示词在代码生成任务上的可用率能提升30%以上。3.2 任务描述动词要具体不要模糊“帮我写个方案”和“写一份包含背景分析、技术选型对比、实施步骤、风险预案的项目方案每个部分不少于200字”这两个提示词的效果天差地别。任务描述里的动词越具体模型的输出越可控。我常用的具体动词包括列出、对比、分类、总结、改写、翻译、生成、提取、验证。还有一个技巧是分步骤描述任务。比如不要写“分析这段文本的情感”而是写“第一步识别文本中的情绪词第二步判断每个情绪词的极性第三步综合所有情绪词给出整体情感倾向”。这样模型会按照你的步骤走中间结果也更可解释。3.3 输出格式用Schema约束模型如果你需要模型输出结构化数据最可靠的方式是直接给出JSON Schema或者示例。比如请以JSON格式输出包含以下字段 - sentiment: 字符串取值为positive/negative/neutral - confidence: 浮点数0到1之间 - keywords: 字符串数组最多5个我试过只写“请输出JSON”模型有时候会加注释有时候会用单引号有时候字段名对不上。给了Schema之后格式错误率从15%降到了2%以下。如果模型支持function calling或者JSON mode那就更稳了直接开。3.4 少样本示例给模型“抄作业”的机会少样本提示是我认为性价比最高的技巧之一。你不需要写很长的规则只需要给两三个输入输出示例模型就能学会你的意图。比如做文本分类输入这个产品太差了用了一次就坏了 输出{label: 负面, reason: 产品质量问题} 输入物流很快包装也很用心 输出{label: 正面, reason: 物流和包装体验好} 输入东西还行就是价格有点贵 输出模型会自动补全第三个输出。示例的选择很关键要覆盖不同类别要包含边界情况示例的格式要和你期望的输出完全一致。我一般放3到5个示例太多了会占用上下文窗口太少了模型学不会。注意示例的顺序也会影响效果。有研究表明把更接近目标任务的示例放在最后模型的表现会更好。我自己的做法是把最典型的示例放最后。4. 高级思维技巧思维链、ReAct、思维树怎么用才不翻车前面说的都是基础真正让模型解决复杂问题的是思维链、ReAct、思维树这些高级技巧。但我要先泼一盆冷水不是所有任务都需要这些技巧。简单任务用了反而浪费token甚至让输出变差。我一般只在多步推理、需要外部工具、或者需要探索多种可能性的场景下才用。4.1 思维链让模型“把思考过程写出来”思维链的核心就一句话让模型在给出最终答案之前先输出推理步骤。最简单的实现方式是在提示词里加一句“让我们一步一步思考”。但这句话现在已经有点被用烂了效果不如早期那么明显。我现在的做法是显式定义推理步骤请按以下步骤分析 1. 提取问题中的关键信息 2. 判断需要用到哪些知识或公式 3. 逐步计算或推理 4. 给出最终答案并验证这样做的好处是模型的推理过程更可控而且如果中间步骤出错你能快速定位是哪一步的问题。我做过对比在数学应用题上显式步骤的思维链比简单加“一步一步思考”准确率高12%左右。但思维链有个坑模型可能会编造推理过程。它先得出一个答案然后倒推一个看起来合理的推理链。这种情况在事实性任务上特别危险。我的应对方法是在提示词里加一句“如果某一步你不确定请明确说明不确定不要编造”。另外对于关键任务我会用另一个模型或者另一轮调用来验证推理链的每一步。4.2 ReAct推理和行动交替进行ReAct是Reasoning Acting的缩写核心思想是让模型在推理和调用工具之间交替。比如你问“今天北京天气怎么样”模型先推理“我需要查天气”然后调用天气API拿到结果后再推理“温度是25度适合穿短袖”最后给出回答。我实现ReAct的提示词模板大概长这样你可以使用以下工具 - search(query): 搜索信息 - calculator(expression): 计算数学表达式 - weather(city): 查询城市天气 请按以下格式回答 思考你需要做什么 行动工具名(参数) 观察工具返回的结果 ...重复思考和行动 最终答案你的回答ReAct的关键在于工具描述要清晰参数格式要明确。我踩过的坑是工具描述写得太模糊模型不知道该什么时候调用或者传错参数。后来我把每个工具的功能、输入格式、输出格式、适用场景都写清楚调用准确率大幅提升。还有一个经验限制最大迭代次数。ReAct有时候会陷入循环反复调用同一个工具。我一般设最多5轮超过就强制输出当前结果。另外每次工具调用后要把结果简洁地总结成“观察”不要把原始JSON全塞回去否则上下文很快就爆了。4.3 思维树当一条路走不通时试试分叉思维树是思维链的升级版核心是在每一步生成多个候选思路然后评估哪个最好再继续往下走。适合那种需要探索、没有唯一正确答案的任务比如创意策划、复杂问题拆解。我实现思维树的方式是多轮调用第一轮让模型生成3个不同的解题思路第二轮对每个思路进行评估打分第三轮选择最高分的思路继续深入。这样做成本会高一些但在关键决策场景下值得。不过我要说实话思维树在日常任务里用得不多因为token消耗大、延迟高。我一般只在方案设计、策略分析这类需要多角度思考的场景下用。而且思维树对模型的指令遵循能力要求很高如果模型本身能力不够生成的分支质量会很差反而浪费时间。下面这张表是我对不同技巧的适用场景总结技巧适用场景token消耗实现复杂度效果提升基础提示词简单分类、提取低低基准少样本提示格式固定、类别明确中低明显思维链多步推理、数学中低明显ReAct需要外部工具高中显著思维树开放探索、方案设计很高高视任务而定5. 实操全流程从零搭建一个可复用的提示词工程管线说了这么多理论接下来我拿一个实际项目来串一遍。这个项目是一个合同关键信息提取系统输入是一段合同文本输出是结构化的甲方、乙方、金额、期限、违约责任等字段。我按步骤拆解。5.1 第一步任务拆解和基线测试先不要急着写复杂提示词。我做的第一件事是用最简单的提示词跑一个基线请从以下合同中提取甲方、乙方、金额、期限、违约责任以JSON输出。 合同内容{contract_text}跑100条测试数据记录准确率。结果大概是甲方乙方准确率85%金额70%期限60%违约责任40%。这个基线很重要它告诉你哪些字段是难点后面优化才有方向。5.2 第二步逐字段优化提示词针对准确率低的字段我逐个优化。比如“期限”字段模型经常把签订日期和生效日期搞混。我的优化是提取合同的“有效期限”注意 - 有效期限是指合同开始生效到结束的日期范围 - 不要提取签订日期 - 如果合同写的是“长期有效”输出“长期” - 如果只写了开始日期没写结束日期输出“开始日期至今”加了这些约束后期限字段准确率从60%提到了88%。每个字段单独优化比整体优化效率高得多。5.3 第三步加入少样本示例对于格式要求高的字段我加入示例。比如“违约责任”需要输出具体的条款摘要我给了两个示例示例1 合同原文任何一方违约需向对方支付合同总额20%的违约金。 输出{违约责任: 违约方支付合同总额20%的违约金} 示例2 合同原文乙方逾期交付的每逾期一日按合同总额的0.5%支付违约金。 输出{违约责任: 乙方逾期交付按日支付0.5%违约金}示例加入后违约责任字段的格式一致性从55%提升到了92%。5.4 第四步参数调优和验证这个任务需要高准确性所以我把temperature设为0.1top_p设为1.0presence_penalty设为0。然后用200条测试数据做验证整体字段准确率从基线的64%提升到了89%。但还没完。我发现有些合同扫描件OCR质量差模型会提取出乱码。于是我加了一个前置校验步骤先用一个轻量模型判断文本是否可读如果乱码比例超过10%直接返回“文本质量不足请人工处理”。这个逻辑用代码实现不消耗大模型token。5.5 第五步建立评估和迭代机制上线不是终点。我建了一个评估集包含200条标注好的合同每次修改提示词后都跑一遍对比准确率变化。同时记录每次修改的内容和效果形成迭代日志。这个习惯让我在后续优化中少走了很多弯路。下面是我这个项目的提示词最终结构供参考# 角色 你是一位专业的合同信息提取助手擅长从法律文本中准确提取结构化信息。 # 任务 从以下合同文本中提取指定字段以JSON格式输出。 # 提取字段及要求 - 甲方合同中的甲方全称 - 乙方合同中的乙方全称 - 金额合同总金额包含币种 - 期限合同有效期限 - 违约责任违约条款摘要不超过50字 # 约束 - 如果某字段在文本中找不到输出null - 不要编造信息 - 金额保留原始格式 # 示例 此处放2-3个示例 # 合同文本 {contract_text}6. 常见问题与排查技巧实录在实际操作中我遇到过各种各样的问题。这里整理成速查表方便你遇到类似情况时快速定位。问题现象可能原因排查方法解决方案输出格式不稳定提示词格式约束不明确检查是否有Schema或示例加入JSON Schema或固定示例模型编造信息temperature过高或缺少约束降低temperature加“不要编造”设temperature0.1加验证步骤长文本截断超出上下文窗口检查token数分段处理或使用摘要工具调用错误工具描述模糊检查工具定义明确参数格式和适用场景推理链错误模型能力不足检查中间步骤拆解任务或换更强模型输出重复presence_penalty过低检查参数设presence_penalty0.3响应太慢思维树或ReAct迭代过多检查迭代次数限制最大轮次我再分享几个独家避坑技巧。第一个是“反向验证”对于关键输出我会用另一个提示词让模型自己检查一遍比如“请验证以下JSON中的金额是否与原文一致”。这个步骤能 catch 掉不少错误。第二个是“温度分层”同一个任务先用高temperature生成多个候选再用低temperature做筛选和整合。第三个是“提示词版本管理”我用Git管理提示词文件每次修改都commit方便回滚和对比。还有一个我经常被问到的问题提示词工程和微调怎么选我的判断是如果任务固定、数据量少、快速上线优先提示词工程如果任务复杂、数据量大、对延迟敏感考虑微调。但大多数场景下提示词工程能做到80分微调可能做到90分但成本差很多。我一般先用提示词工程跑通确认有价值后再考虑微调。最后说一个我自己的体会提示词工程不是一劳永逸的。模型在更新你的业务在变化提示词也需要持续迭代。我现在的做法是每个月review一次核心提示词看看有没有优化空间。这个习惯让我在模型升级时能快速适配而不是被动等待。这个领域变化很快新的技巧和工具层出不穷。但底层逻辑是不变的理解模型的行为控制输出的空间持续评估和迭代。把这三点做好大部分问题都能解决。