Prompt工程实战：6招提升大模型输出精准度

去年有一段时间我特别迷信各种提示词模板备忘录里存了满满一屏。直到有个项目要批量生成产品文案我用同一段Prompt跑了三家模型三份回答各写各的一份像广告软文一份像说明书一份直接跑题。那一刻我才意识到Prompt工程不是背模板而是搞清楚大模型到底在什么条件下才愿意稳定输出。这篇不是科普长文把我踩过坑之后真正沉淀下来的6个提升输出精准度的技巧都列出来每个技巧都带原理、对比和可以直接改改就用的写法适合那些正在调Prompt但总觉得结果忽好忽坏的人。1. 为什么同样的提示词输出忽好忽坏1.1 大模型不是逻辑引擎而是概率填空器很多人第一次翻车是因为把大模型当成了数据库或逻辑引擎以为我输入清楚它就应该输出正确。但大模型的底层工作方式是一个概率填空器它根据你已经给它的一段上下文逐字预测最可能出现的下一个token。这个最可能是一个概率分布不是唯一答案。所以输出不稳定至少有三个来源。第一个是采样随机性即便temperature拉低只要没到0每个采样步仍有随机性就算调到0不同模型在不同硬件环境下也可能有微小差异。第二个是上下文编码的敏感度Prompt里多一个顿号、少一个换行都可能让注意力权重重新分配。第三个是模型对模糊指令的默认假设你说请专业一点它理解的专业和你理解的专业未必是同一种专业。这个理解直接决定了后面所有技巧的走向既然模型是根据上下文来调节行为那我们的工作就不是把话说清楚这么简单而是把上下文结构搭到让它的概率分布集中在你想要的那一类答案上。这一句可以说是我对Prompt工程的全部理解。另外想多说一句很多人第一反应是把temperature调到0是不是就稳了。实测下来调0能减少发散但解决不了理解偏了的问题。判断一个输出问题是随机性还是理解性有个土办法同一个Prompt重复跑三次。如果三次内容五花八门说明随机性占主导可以调低temperature如果三次内容都稳定地答非所问那就是理解问题需要改Prompt本身。1.2 精准度问题的三种典型症状跑题、跑形、跑偏我把平时遇到的不精准归纳成三种症状排查起来非常方便。第一是跑题问的是A回答里拐到B。比如让它分析销售数据下跌原因它却开始写促销方案。这通常是角色和任务边界没划清楚模型不知道你到底要我干嘛。第二是跑形内容方向对但格式乱。让它列出5个要点它给出一整段话让它输出JSON它多了一段解释。这是缺少结构约束它不知道输出形式本身也是需求的一部分。第三是跑偏内容沾边但颗粒度不对。写总结写得像全文复述写标题写得像论文摘要。这是缺少评分标准模型没有标尺去判断什么算好。我把三种症状和对应的解法做成了一张表后面的章节就是按这个顺序展开的症状典型表现优先使用的解法跑题答非所问、方向偏移技巧一角色任务约束跑偏颗粒度不对、详略失控技巧二可检查的评分标准跑形字段混乱、格式不符技巧四、技巧六示例与结构化输出综合症任务复杂什么都想要技巧三单步指令链、技巧五CoT2. 技巧一角色、任务、约束三段式让模型先定性再作答2.1 角色设定如何改变输出分布第一个技巧看起来最简单但很多人只用了半截。完整的做法是角色、任务、约束三段式少一段输出就会开始漂。先说原理。预训练模型见过海量的角色—对话语料律师说话是什么风格、客服说话是什么风格、小学老师又是什么风格。当你给模型一个明确的角色等于在几十亿参数里激活了一个高概率的行为分区。角色设定越具体激活的分区就越窄输出也就越容易被框住。直接看一个对比。烂写法请帮我写一段产品介绍。这个Prompt跑十次十次风格都不一样。好的写法角色你是一名擅长电商文案的资深文案编辑。 任务为一款适合上班族使用的便携榨汁杯写一段商品详情页介绍。 约束字数控制在150字以内突出3个核心卖点语言风格偏日常、有生活感结尾加一句购买引导语。区别在哪儿角色给了它文案编辑的措辞偏好任务给了它一个具体动词写一段商品详情页介绍约束给了它字数、卖点数、风格和结构。三样加在一起模型的可选择空间被压缩到了一个很小的范围内答案自然稳定。2.2 三段式的落地模板与常见反例如果不想每次从零开始写可以套用这个通用模板角色你是【某个领域的专家/具备某种身份的人】擅长【几项具体能力】。 任务请为【具体对象】完成【一个动词性动作】目标受众是【谁】。 约束字数不超过【N】必须包含【关键点1/2/3】不要出现【禁忌内容】输出用【格式】。我个人的经验是角色设定宁可用一句话交代擅长什么也不要堆一长串头衔。我踩过一个坑某次让模型同时扮演资深律师、理财顾问、心理学专家、写作达人去写一封沟通邮件结果它的措辞一会儿法律条款、一会儿心理分析整体像四人在抢话筒。角色越复杂行为分区越互相干扰输出越分裂。还有一个反例是只给角色不给任务。你让它作为资深数据分析师然后直接问这个表格怎么办它可能给你一堆空话套话因为你没有告诉它该怎么办的具体动作。正确做法是让角色和任务之间明确衔接比如你作为资深数据分析师请根据以下销售数据找出三个最可能的原因每个原因附一条数据证据。角色和任务之间用请根据……完成……连接输出就踏实了。3. 技巧二把你看着办改成可检查的评分标准3.1 为什么模型也需要打分表第二个技巧是解决跑偏问题的核心。很多时候模型的输出不是差而是不对味——你说写总结它给你写概述你说写得精炼它给你压缩到几个短句。问题的根源在于用户脑子里的好是没有表达的。大模型生成回答的过程其实很像一个人在做开放式论述题如果考试只写了请作答没有评分标准学生只能凭感觉写。而如果你把评分标准也写进Prompt模型在生成过程中就相当于拿到了一份自查表每一步都会朝这些维度靠拢。但评分标准不能是空话。像逻辑清晰语言流畅这类词模型基本无法操作。要改成可以被检验的动作。比如每个结论后面必须给出一个数据或事实支撑每条建议必须对应一个具体的实施动作不允许出现总之此外等没有任何信息量的过渡语这些标准有一个共同点模型在生成时能够自我检查是否做到。能检查才有约束力不能检查写了等于没写。3.2 用满分定义 关键维度 否决项约束输出我的实操写法是把评分标准拆成三块满分定义、关键维度、否决项。满分定义用来告诉模型一份合格的答案长什么样。关键维度告诉它好有哪几个方面按什么优先级。否决项告诉它出现什么情况就算不及格。三块的Prompt示例请为以下产品写一段客服道歉回复。 评分标准 1. 满分定义一份让用户感到被重视、同时把解决方案讲清楚的回复。 2. 关键维度按优先级排列 - 共情先承认用户的不便再解释原因 - 明确补偿方式/时间节点必须具体不能写尽快 - 简洁不超过120字。 3. 否决项出现推卸责任的字眼或没有给出可执行的补偿方案直接视为不合格。实际操作中把模糊要求和评分标准放在一起对比效果更明显模糊要求评分标准写法输出变化写得好一点每个论点后必须跟一个数据支撑句子密度明显提升语气温和一点开头必须先道歉禁止使用你误会了开头稳定不再防御性概括全面一点必须覆盖价格、规格、售后三个主题缺项明显减少最后提醒一句评分标准不要超过5条。模型在上下文里的注意力是有限的我给某项目写了8条评分标准结果模型只记得前4条后4条完全被忽略。收敛到最关键的3-5条比列一堆更有用。4. 技巧三拆成单步指令链一次只让模型干一件事4.1 多任务指令为什么容易顾此失彼第三个技巧是我在真实项目里觉得性价比最高的一个把大任务拆成多个小任务一次只让模型干一件事。很多人在写Prompt时喜欢大而全让模型总结全文、提炼观点、提出建议、生成标题、顺便改成社交媒体风格。我理解这种偷懒心理一次调用多省事。但实测下来任务一旦超过两三个输出质量会明显下滑。原因是多任务会稀释模型的注意力分配。它在生成每一个token时都要同时惦记着你扔给它的所有要求很难保证每个环节都照顾到。更麻烦的是错误会传导前面总结部分如果写得偏了后面提炼观点就会基于错误的摘要继续延伸最后整条链都歪掉。打个比方你让一个实习生一次处理五件事他会怎么做大概率每件事都做得马马虎虎还有可能把咖啡洒在文件上。你让他一次只处理一件事处理完再安排下一件效率和质量反而上来。大模型也一样。4.2 指令链的落地方式把中间结果当成下一步的输入我自己常用的拆法是先把任务拆成可以单独交付中间结果的链条。以客服工单生成为例原来一个Prompt想搞定全流程后来拆成三步第一步让模型判断工单类别请判断这条用户留言属于以下哪一类售后、物流、使用咨询、其他。 只输出类别名称不要解释。 用户留言……第二步根据类别提取关键字段上一步判断的类别是【售后】。请从用户留言中提取订单号、问题描述、用户期望的处理方式这三个字段。 如果某个字段不存在输出未提及。第三步根据前面结果生成回复基于以上提取结果请生成一段客服回复。 回复需要用第一人称、语气诚恳并给出明确的处理时限。这个做法的关键在于每一步的Prompt都显式引用了上一步的输出模型不用去同时处理所有约束只需专注当前这一步。如果中间某一步出了问题你也能很快定位到是哪一步而不是对着整段输出做无头苍蝇式排查。在工程实现上有两种方式一种是分多次调用API每次把上一步的结果拼进下一步的Prompt另一种是在一次会话里多轮对话交替扮演执行者和传递者。前者更容易做程序化控制后者更适合调试阶段人工观察。需要注意别把指令链写得过长。链条太长中间错误累积和token浪费会抵消它带来的精度收益。我的经验是超过4步的任务先想想是不是任务本身定义得太复杂了。有些任务看起来复杂其实是Prompt设计者自己没想清楚。5. 技巧四少样本示例选准参照系正反例比数量更重要5.1 示例不是越多越好关键是分布对齐第四个技巧是关于少样本Few-shot的。很多人以为给模型的示例越多模型学得越好于是一股脑塞进去七八个例子。但我用下来的感受是示例质量远比数量重要更重要的是示例要跟真实输入对齐。模型在上下文中看示例本质是在做类比推理它从示例里归纳出用户想要的输入输出映射长什么样。如果示例和真实任务存在分布偏差比如示例全是长文本真实输入却是短句模型就会机械模仿长文本的格式如果示例的输出全部是俏皮话模型的正式任务输出也会变俏皮。我吃过一次亏某次做意图分类给模型喂了三个示例全是用户问价格的意图结果真实输入里用户问怎么退款模型按着示例的格式输出了一大段售前话术而不是分类结果。不是模型傻是示例让它以为所有输入都要按这个风格回答。所以选示例有三个原则格式一致、难度相近、目标输出风格统一。你希望模型最终输出什么形态示例就尽量长成什么形态。5.2 正例反例的组合比堆数量更管用在实际项目里我更推荐正例反例的组合方式。正例告诉模型应该怎么做反例告诉模型不要怎么做两者的对比能帮模型更快划清边界。以意图分类为例请判断用户的意图属于价格咨询、功能咨询、售后问题、其他。 示例1正例 用户这个榨汁杯能打冰吗 意图功能咨询 示例2正例 用户现在买有优惠吗 意图价格咨询 示例3反例 用户不买了东西有质量问题要退货。 输出如果判断为「价格咨询」是错误的正确意图是「售后问题」。 请对下面这句话进行分类只输出意图名称。 用户昨天收到的线控耳机右耳没声音。只给正例的时候模型可能只学到从问题里抓关键词加了反例之后它更清楚边界在哪里、哪些情况不能混为一谈。我在另一个项目上做过对比同一批测试集只放正例的准确率约78%加了明显错误反例后提升到89%。当然不是每个任务都能提升这么明显但少给几个、给得准几乎总是优于多给几个、给得杂。还有一个小建议反例的选择要针对高发错误。如果你发现模型总把物流咨询误判成售后问题那就专门造一个这样的反例放进去比新增10个正例都管用。少样本是一场定向纠偏不是题海战术。6. 技巧五先推理后作答把思考过程写进输出6.1 思维链CoT激活的机制与适用场景第五个技巧是在复杂推理任务里效果最明显的让模型先想再答。这种现象在行业里通常叫思维链Chain of ThoughtCoT我换一个更容易理解的说法强制模型把中间计算步骤写出来给推理过程一个草稿区。原理其实不神秘。模型是逐token生成的每生成一个token就消耗一份概率。如果它直接给结论就跳过了大量中间步骤很容易在关键计算上跳步得出貌似合理但实际不对的结果。而如果你让它先列出推理步骤再给结论它等于在输出里给自己搭了一张草稿纸每一步都会重新审视前一步错误率自然下降。适用场景非常明确数学题、逻辑判断、多条件规则匹配、需要比较再决策的任务。我用过一个典型案例判断订单是否符合发货条件用户订单信息 - 商品状态已付款 - 收货地址偏远地区不在普通配送范围内 - 库存有货 请判断该订单能否按普通流程发货。 要求先列出判断步骤每一步对照订单条件最后给出结论。输出里会出现步骤1已付款满足付款条件步骤2偏远地区不满足普通配送范围结论不能按普通流程发货。这样就算结论错了你也能顺着推理步骤找到是哪一步跳了。6.2 思维链Prompt的写法与边界控制但CoT不是万灵药。最典型的反例是简单任务你让模型翻译一句hello它也非要先写这句话的意思是……然后给翻译纯属浪费token和延迟。另一个问题是过度推理某些任务本来可以直接凭直觉判断比如情感分类强行加推理反而可能引入不必要的纠结和幻觉。我的写法经验是给出明确的推理边界请先进行推理再把结论放在最后一行。 要求 - 推理步骤不超过3步每步不超过20个字 - 结论必须单独一行以结论开头 - 如果题目很简单可以直接给结论不需要推理。第三句如果题目很简单可以直接给结论很关键它给了模型一个出口避免简单任务也背上一层推理脚手架。还有一个常见的坑是推理诱导偏见。如果你在Prompt里写了倾向性的话比如你觉得用户肯定不满意吧模型可能会顺着你的话往前推理最后得出一个迎合性的结论。所以在需要客观判断的场景不要在推理引导句里夹带自己的预判。我在项目里遇到过一次某个自动化审核流程加了CoT后结论一直偏向通过后来发现是Prompt里写了如果没有严重问题就通过模型把没有严重问题当成了合理默认值再一路推理自证。后来改成请独立检查以下风险项再给出结论偏见才消除。7. 技巧六结构化输出 自校验兜住最后一公里7.1 从请用JSON到显式schema约束最后一个技巧是偏工程向的如果你要让模型输出结构化数据指望请用JSON格式返回已经不够了得把schema写进Prompt里。我见过太多人写请用JSON返回结果然后模型输出了JSON夹杂一句以下是结果甚至把某个字段值写成undefined。原因很简单你告诉它用JSON但没告诉它JSON长什么样。它只能靠概率猜猜着猜着就跑形了。更稳的写法是把字段名、类型、允许值、是否必填直接展示给它看请分析下面这段用户反馈输出JSON对象。 JSON字段定义 - sentiment: 字符串只能是positive、negative或neutral - key_issues: 字符串数组最多5项 - summary: 字符串不超过50个字 - urgent: 布尔值是否属于紧急投诉。 要求只输出JSON对象本身不要输出任何解释或代码块标记。这样做有两个好处一是把输出空间压缩到了很小的范围模型采样时想跑偏都难二是程序解析方便后续接流程几乎零成本。注意最后那句只输出JSON对象本身这句话能干掉80%的多余前缀后缀问题。7.2 自校验循环让模型检查自己的输出但即便做了schema约束模型偶尔还是会犯低级错误字段缺失、数值越界、枚举值拼错。针对这种情况我的做法是加一道自校验循环让模型生成完之后用另一轮Prompt检查自己的输出。典型的写法是两步走。第一步正常生成第二步追加请检查你上一步生成的JSON对象 1. 是否包含所有必填字段 2. sentiment字段的值是否在允许枚举内注意拼写 3. summary是否超过50字 4. 是否混入了JSON之外的文字。 如果发现问题请输出修正后的完整JSON如果没有问题直接输出通过。实操里需要注意自校验会显著增加token消耗和延迟所以不是所有任务都值得做。我的取舍标准是看输出出错的代价代码生成、合同摘要、医疗建议、自动工单这类高风险场景多花一次校验很值得而像文案改写、头脑风暴这类低风险场景来回校验纯属浪费。从工程角度看自校验其实是最后一道护栏不要把全部希望压在它上面。我在生产项目里的组合是提示词用前面的技巧把底座打好再用程序做JSON.parse、字段枚举校验最后在解析失败时才触发模型自校验。能靠代码约束的就不要靠模型自觉模型自校验只是兜底不是万能。这个思想我认为才是整个提示词工程进阶的核心把它当工程来搭而不是当咒语来念。我自己现在调试一个Prompt的固定顺序基本上就是围绕这6个技巧来的先定角色和任务边界不贪多拆成小步骤然后给它评分标准和正反例复杂任务再让模型先推理最后统一用结构化输出接程序实在不行才上自校验。整套走下来项目里的输出精准度基本是可控的后续维护也只是小修小补。提示词工程最大的价值不是让你变魔法而是让你把一个不稳定系统逐步驯化成可以依赖的工具。