开头直接进入从一次真实业务场景写起。手头有一个每周都要跑的分类任务大模型输出时好时坏指令写了一大段结果还是漏字段、格式乱、分类跑偏。后来把提示词彻底重构了一遍效果稳定了很多。这篇把这些年的Prompt工程经验浓缩成6个技巧专门解决“模型听得懂但答不准”的问题。1. 结构化指令模板先把Prompt当模板写1.1 为什么“一段话”式的Prompt不靠谱很多人写Prompt的习惯是想到哪写到哪比如“帮我分析一下这段用户反馈看看用户对价格有什么意见语气专业一点最好能总结一下标点符号注意”。这种写法不是不能用而是你把所有要求混在一块儿模型得自己做“信息拆解”它拆解的路径不一定是你要的。这里有一个容易被忽略的底层事实大模型的解码过程是基于上下文的注意力分配它不是把你的话逐字当作“待办事项”去执行而是对整段文本进行语义权重计算。混在一起的指令语义权重会被稀释。比如你把“输出JSON格式”和一大段背景描述混在一起模型记住背景描述的概率远高于记住格式要求因为背景描述的token占比大、语义空间广。结果就是模型回答得“很在理”但格式完全不是你要的。我试过的做法是把Prompt拆成独立字段角色、任务、输入数据、输出要求、约束条件、示例。每个字段一行或一个区块互不串扰。这就好比给开发提需求你写“做一个注册功能要好看点快点做”和写一份“功能清单验收标准界面要求”的需求文档开发做出来的东西完全是两个水平。提示词结构化之后模型对每个字段的目标感会清楚很多实测下来输出符合率提升非常明显。1.2 结构化指令模板怎么搭一个稳定的指令模板我一般固定用这么几块角色你是[具体角色描述] 任务目标完成[具体动作]解决[具体问题] 输入数据以下是需要处理的原始内容 输出要求 - 必含字段字段名字段含义说明 - 格式约束JSON / Markdown / 纯文本 - 风格约束书面语 / 口语、简洁 / 详尽 约束条件 - 不要输出与任务无关的额外说明 - 遇到无法判断的内容输出[兜底值] 示例参考输入与输出的对应关系这块模板里的每一行都是有意图的。角色字段用来锚定回答的语气和专业方向任务目标字段要给模型一个明确终点避免发散输出要求字段把“要什么”变成清单约束条件字段专门用来堵后路把容易翻车的场景提前拦住示例字段则提供模仿对象。实际操作中有个细节字段之间的分隔符号要统一。要么全用###要么全用---别一半用###一半用**混用会让模型的段落切分出现不稳定。另一个细节是任务目标放在第二行不要放到最后。模型对靠前内容的指令遵循度更高把最核心的目标放前面后面那些约束条件它才不会“先入为主”地跑偏。这套模板适合绝大多数文本生成、总结、分类、提取场景。它不是银弹但能把“模型输出完全不可控”压缩到“偶尔有瑕疵”。2. 少样本示例给模型一个模仿的锚点2.1 示例为什么比规则更有效只写指令而不给示例等于给一个实习生讲了一堆流程规范然后说“你去干吧”。大模型的训练语料千差万别你要它输出的风格、深度、颗粒度它只能从你的描述里去猜。而少样本示例本质上是把“抽象描述”变成“具体映射”。比如你要求“在100字以内总结这段客服对话并提取出用户的核心诉求”只靠文字描述模型输出的总结风格每次都不一样有的一次写三句话有的写一大段。而当你给一个示例“用户说商品两周没到货人工客服先是道歉再给了物流单号最后让用户48小时后再查”——输出为“用户核心诉求查询物流进度。关键信息订单已发货但未按时到达客服承诺进一步跟进。”模型就会按这个示例的句式、字数、信息层级来生成。这背后是模型在训练阶段形成的一种能力它对“遵循例子格式”这件事比“遵循抽象文字规则”要擅长得多。这个现象在生成式模型里很稳定。你给的示例就像是给它划定了一个“输出风格的坐标”它会在离这个坐标最近的区域里生成内容。所以示例的质量几乎决定了输出质量的上限比指令写得漂不漂亮重要得多。2.2 Few-shot实操里的数量、配比与顺序先说数量。2到5个示例是最甜区。给1个的情况下模型容易机械模仿具体措辞给超过5个效果不再线性提升反而可能因为示例之间互相干扰、上下文被占满而出现输出冗余。我的习惯是先给2个跑一轮看效果不够再加到4个但很少超过5个。再说配比这是踩过坑之后才重视的。做分类任务时如果给的示例全是“正向案例”模型很容易把所有输入都判成正向。比如情感分类你只给了三个正面示例遇到一句“这个商品质量还行”这种中性偏正向的话它也给你判成正面。解决方法很简单每个类别都要有代表正向、负向、中性各给一个如果能给一条“边界案例”效果会更好。边界案例指的是那种介于两个类别之间的输入比如“价格不便宜但是质量真的可以”这种示例能让模型的判断边界更贴近真实需求。顺序也有讲究。模型对上下文里离当前位置近的内容记忆更牢因此把最复杂、最贴近真实业务场景的示例放在最后一个。这样模型在生成时最近参考到的那个例子就是你最希望它模仿的那个。再补一点示例的输入输出要和真实场景保持一致。如果真实业务里的输入是连续的对话流示例里却给了一句干巴巴的评论模型就会在两种风格之间来回摇摆。宁可示例少一点也要保证它与真实输入的形态贴合。3. 思维链让模型先把推理过程写出来3.1 思维链到底改变了什么大模型本质上是一个“接下来哪个字最合理”的预测器。碰到需要多步推理的任务比如数学计算、逻辑判断、方案选型如果让模型直接输出最终结论它相当于在一个很宽的预测空间里一次跳到终点。中间任何一步算偏了结论就错了而且它自己完全意识不到。思维链Chain of Thought的做法是把“直接给结论”改成“分步推理后给结论”。为什么这能提升准确率因为分步推理把原来一次性的宽范围预测切成了多个小范围的连续预测。每一步只往前推进一点点每一步都有前一步的事实和推理结果作为锚点。模型每一步需要预测的可能范围变窄了出错概率自然下降。我在实际里最常用的触发方式就是在指令末尾加一句“请逐步思考并在回答中展示推理过程”。很多人以为这只是一句口头语实际上它会让模型切换到一种“先内部推导再输出”的模式生成质量明显不同。还有一个变体是把推理过程作为可选项“如果任务简单可以直接输出结论如果任务复杂请先分步分析。”这样能避免简单任务被CoT拖成冗长回答。3.2 三种CoT写法和使用边界按复杂度排列我常用的CoT有三种写法。第一种是零样本CoT。不加任何特殊示例只在Prompt末尾追加一句“让我们一步一步思考”。这种方法适合所有任务快速提效成本几乎为零。注意要用“让我们”这种第一人称复数实测比“请逐步推理”这类表达效果更稳定原因是模型在训练语料中对“让我们一起...”这种协作式指令的跟随性更强。第二种是显式步骤模板。在输出要求里直接列出步骤1提取问题中的关键信息和已知条件 步骤2判断需要运用哪些判断规则或计算逻辑 步骤3逐步计算并给出中间结果 步骤4汇总中间结果得到最终结论这种写法适合流程固定的业务场景比如审核任务、方案评审、量化分析。它不只是让模型“想一想”而是强制它按固定节奏输出后续你再单独校验每一步也不需要模型重新组织语言。第三种是少样本CoT。在示例的答案里也包含推理过程。比如分类任务示例答案先写“这句话里有‘质量不行’这种直接负面描述因此判断为负面”再输出“负面”。这种示例能同时教模型“怎么推理”和“按什么格式输出”对复杂任务的提升最明显。使用边界我得特意说一下。CoT不是万能的它最适合推理类任务比如算术、逻辑判断、方案比较。但如果是事实检索类任务比如“这句话里提到的产品型号是什么”CoT反而有害因为模型会在没有事实依据的情况下凭空编造推理过程。还有一个坏处是token消耗变高成本敏感的高频调用场景要权衡。实践里我会给所有需要“给结论”的任务默认先试零样本CoT如果输出质量不稳定再升级到显式模板或少样本CoT。4. 角色设定让模型切换到专业模式4.1 角色设定的本质是激活专业分布给模型设定角色很多人觉得就是“cosplay”。其实它起作用的原因更重要大模型在训练时见过海量文本不同领域、不同身份的语料在语义空间里是有聚类的。当你输入“你是一名有十年经验的医生”模型会检索到医学问答语料的条件分布它后续生成的内容在术语选择、表达方式、逻辑结构上都会向那个分布靠拢。这就是为什么同一句描述“你是一个助手”和“你是一名资深全科医生”得到的回答完全是两个量级。理解这点之后你就知道角色设定不是越夸张越好而是越具体越好。与其说“你是医疗专家”不如说“你是一名三甲医院的呼吸内科主治医生擅长解读肺功能报告习惯于用通俗语言向患者解释检查结果”。角色描述里带上“工作场景擅长领域表达风格”模型能定位到的语料分布会精确得多。这里我说个实操细节角色描述和任务要求要分开写不要混成一句话。角色放在最前面做铺垫任务放在角色之后做启动模型会先“进入角色”再去“执行任务”输出的稳定性会好很多。4.2 把角色写“实”的四个要素一个管用的角色设定我一般至少包含四个要素身份头衔、经验年限、工作场景、对谁说话。比如角色你是一名在某大型电商平台工作8年的资深营销文案审核员。 任务对你收到的每条商品推广文案进行审核判断它是否存在过度承诺、用语夸大、误导消费者的风险。 受众你的审核意见会提交给一线运营同事他们需要快速知道问题在哪、怎么改所以每条意见都要给出具体修改建议。这个设定里“工作8年”不是废话它让模型调用更资深的审核语料“面向一线运营同事”也不是废话它决定了输出语气必须是“直接给修改建议”而不是“写一篇分析报告”。我常用的一个进阶技巧是双角色设定。比如先让模型作为出题人设计一个营销文案再让它作为审核人去挑毛病。两个角色分别激活不同的语料分布相当于一个人同时兼具“创作视角”和“批判视角”生成质量比单角色高很多。代价是token消耗增加如果你对成本敏感这个技巧只用在最核心的生成环节。反面的例子我也踩过。给角色设定加了一堆动作描述比如“你是一个喜欢骂人的老板回答问题时先发火再给建议”结果模型确实“演得很像”但回答的内容偏离任务核心全是情绪表达。角色描述要聚焦在“身份能力语境”上不要试图用性格描写来替代任务要求。5. 输出格式约束让结果可以被程序直接消费5.1 三种格式约束手段从弱到强平时最让人头疼的不是内容不对而是“内容对了但对不上字段”。做自动化流程的人应该都有这种体验模型输出了一段JSON却在JSON前面加了“好的这是您需要的JSON”这种废话或者把字段名写成近义词。解决这个问题的路径有三层按约束强度从弱到强排列。第一层是自然语言描述格式。只要在Prompt里写清“用JSON格式输出字段为title和content”模型通常能大致遵守。但够不够稳定全看模型的听话程度和Prompt里有没有其他干扰文本。这一层适合自己手工看结果、不做自动解析的场景。第二层是给格式模板。直接把一个JSON对象写进Prompt里要求模型“严格按这个结构输出”字段名和类型都锁定。比如请将以下内容输出为JSON必须包含4个字段 { summary: 一句话总结, category: 分类名, priority: 1, reason: 判断理由 } 数值类型的priority字段不要用引号包裹。给模板比给文字描述有效得多因为模型把JSON模板当成“字面任务”来执行不会理解出偏差。第三层是格式后置校验。Prompt即使写得再严谨模型也有万分之一概率输出不合法内容。只要这个流程是自动化的就必须在后端做解析校验不合法就重试或者报错。这个不算是Prompt技巧但它和Prompt是配套的。你要做的就是在生成代码里写好try-catch把模型输出直接喂给解析器解析失败就再调用一次模型最多两次。5.2 结构化输出的工程级写法工程级写法有几个关键细节是踩坑后才总结出来的。第一明确告诉模型“不要输出多余内容”。我经常在Prompt末尾加一句“直接输出JSON对象不要包含markdown代码块标记、不要包含解释性文字。”这句放在所有指令的最后离输出位置最近模型的遵循度最高。第二枚举值要提前锁定。如果某个字段只允许三个取值明确写出来“category只能取[a,b,c]之一不得出现其他值。”如果不锁枚举值模型会给你造出“a类”“b型”“c级”这种变体后置校验直接崩溃。第三格式约束要和内容指令分开描述。我发现把“你要做内容分析”和“你要输出JSON”写在同一句话里时模型经常顾此失彼。我更习惯分成两个独立段落第一个段落讲“这个任务的内容判断标准是什么”第二个段落讲“输出的结构和字段定义是什么”。实测内容质量和格式符合率都有提升。第四如果业务需要可以把temperature参数调低。生成任务中temperature0.3以下时输出的随机性大幅降低对格式合规来说收益很大。但注意不要在日常生成中全局用0那会牺牲内容多样性只有格式敏感型任务才值得这样做。6. 迭代式自反思让模型自己挑自己的毛病6.1 自我反思循环的两轮三Prompt结构有一次做内容生成模型第一版稿子逻辑空洞我本来准备手动改后来灵机一动直接把稿子喂回给模型让它扮演评审人挑毛病再把评审意见连同原稿一起喂回去让它重写。结果重写后的版本质量提升非常明显。后来我就把这种做法沉淀成了固定的两轮三Prompt结构。第一轮Prompt让模型生成初稿。这轮不需要特殊技巧就是把任务本身描述清楚生成一份尽量发散、内容充足的稿子。第二轮Prompt让模型扮演评审人对初稿进行挑刺。Prompt大概是这样的你是一名严格的内容评审专家现在需要对以下稿件进行审核。 请从三个维度给出具体修改意见 1. 逻辑是否清晰有没有前后矛盾或无依据的论断 2. 细节是否充分有没有需要补充的具体数据和案例 3. 表达是否精炼有没有废话、重复或不够说服力的句子 稿件内容{初稿} 请直接列出问题清单不要客气。第三轮Prompt把初稿和评审意见一起塞回让模型基于这些进行重写以下是原始稿件和相关评审意见请逐条修正稿件。 原始稿件{初稿} 评审意见{评审意见} 要求保留原文的优点修正所有被指出的问题。在输出开头用一句话说明你主要做了哪些修改。这个流程的价值在于它完全不依赖任何外部工具只是利用模型自身的语言理解能力对同一段内容进行二次加工。相当于让模型用一个“批判性视角”来审视自己的产出。它在内容创作、方案起草、文案润色这类任务上效果显著。6.2 自反思的适用边界与参数配合自反思不是所有任务都该用。在内容创作类任务里它是神器因为创作本身就是反复修改的过程模型完全有能力扮演“自己的甲方”。但要注意它适合内容不硬性依赖外部事实的场景。一旦任务涉及事实、数据这类需要外部知识校验输出的场景自反思很可能在错误的事实基础上越改越自信改出来的稿子逻辑通顺但事实更离谱。另一种不建议用自反思的场景是高并发、低延迟的接口调用。两轮三次Prompt的耗时是单次的三倍成本也成倍增长。工程实践里我会把自反思做成可选参数只有处理低频率、高价值的生成任务时才开启。参数配合方面我自己的经验是第一轮生成用temperature0.7让初稿有发散空间第三轮重写时降到0.3让修改过程更稳定收敛。如果你对修改质量要求高也可以在第一轮之后手动挑一版看得顺眼的初稿再进第二轮效果会更好。还有一个小技巧第二轮评审的意见最好要求模型“每条意见对应一个具体的修改点”不要让它只写“内容不够丰富”这种空话。我在第二轮Prompt里加了约束“每条意见必须包含原句位置、问题类型、改进建议。”这样第三轮模型修改的时候定位更准输出质量明显更稳定。7. 综合案例六个技巧叠加在真实任务里7.1 任务背景与一稿Prompt假设这样一个业务场景某客服团队每周要把用户反馈沉淀成产品需求清单。原始输入是散落的用户留言期望输出是分类清晰、优先级明确的结构化数据。单靠人工整理耗时很长用Prompt配合程序处理能省下一整块人力。这个任务就是典型需要“六个技巧全上”的场景输出要进系统格式必须严格约束留言风格十分口语化需要示例校准输出风格分类时需要一定的推理判断边界情况需要拆分处理。一稿Prompt如下角色你是一名有多年产品经验的用户研究分析师擅长把用户反馈转化为可执行的产品改进建议。 任务目标分析用户留言提取关键诉求并按指定分类体系归类。 输入数据以下每条独立编号的文本是一条用户留言。 1. 发货太慢了等了一个星期才到体验很差 2. 新版后台总是报错每次都要重新登录烦死了 3. 希望价格能再优惠一点不然续费的时候我会考虑其他家 输出要求返回一个JSON数组每个数组元素包含4个字段 { text_id: 输入编号, summary: 不超过30个字的口语化概括, category: 分类枚举, action: 建议采取的产品动作 } category只允许取这四个值之一物流体验、功能缺陷、价格策略、其他。 action必须是对应的产品动作例如“优化物流通知机制”。 约束条件 - 只输出JSON数组不要输出解释性文字 - 如果一条留言同时涉及多个维度选择最核心的那一个维度 - summary必须保留用户原始表达里的关键情绪词 示例 输入包装很好但是这个尺码完全不对客服还说是我量错了 输出{text_id:0,summary:尺码不符且客服处理不当用户不满,category:功能缺陷,action:核查尺码标注与客服话术机制}这个Prompt完整使用了结构化模板、角色设定、格式约束、少样本示例这些技巧。末尾的示例里也隐含了一条简短的推理路径对模型理解分类逻辑很有帮助。7.2 后置校验与解析代码Prompt已经承担了80%的格式约束工作后端仍需把最后的20%补上解析与校验。这里我贴一段常用的解析代码语言的细节不重要关键是思路。import json import re def parse_model_output(raw): # 先剥离可能出现的markdown标签 cleaned raw.strip() cleaned re.sub(r^(?:json)?|$, , cleaned, flagsre.MULTILINE).strip() data json.loads(cleaned) if not isinstance(data, list): raise ValueError(输出不是数组) allowed {物流体验, 功能缺陷, 价格策略, 其他} for item in data: item[text_id] int(item[text_id]) item[category] item[category].strip() if item[category] not in allowed: raise ValueError(f非法分类: {item[category]}) if len(item[summary]) 40: raise ValueError(概要超长) return data这段代码的逻辑就是二次校验正则剥掉模型喜欢加的前后缀解析JSON再对枚举字段做白名单校验。校验失败的场景直接整批重试。我在实际流程里会在这里加一个重试计数器最多重试两次两次都失败就走人工兜底避免死循环。跑一遍这条Prompt配合校验代码输出会自动分类、提取要点、给产品动作建议直接进系统变成待办。把原本需要两天的人工整理压缩到了十几分钟。这个案例想表达的核心就是你不需要把六个技巧当成独立功能去背而是理解每个技巧在流程里承担什么角色组合起来用才是完整的Prompt工程思路。8. 常见问题与排查技巧实录8.1 高频翻车现场速查表下面这些是我在真实使用中反复遇到、且网上常见教程不怎么提的问题整理成速查表方便对照现象常见原因解决方向模型输出的格式偶尔不合法Prompt里格式要求被内容说明淹没把格式要求独立成段放在内容要求之后、示例之前输出的JSON字段名和期望不一致字段定义不够显眼或没有给模板实例把完整JSON模板原样写进Prompt用字面量锁定字段名分类总是偏某一种类型少样本示例里类别配比不均给每个类别至少一个示例边界案例放最后简单任务被输出成又长又绕的回答开启了CoT但任务不需要推理只在推理类任务中使用CoT或给一句“可直接输出结论”模型的推理过程写得很顺结论却是错的事实检索任务里错误使用CoT避免对纯事实提取任务用CoT如已开CoT要求“仅输出结论”角色设定后模型只顾演角色忘了任务角色描述里混入了大量性格和语气描写角色描述聚焦“身份领域受众”把任务目标独立写出一条留言同时涉及多个分类模型乱选没有预设处理多维度问题的优先级约束条件里写明“选择最核心维度”或改为可输出多个分类重写后内容变得过于保守、丧失原有亮点重写指令里只有“修正”没有“保留优点”第三轮Prompt要求保留原稿优点只针对意见修改8.2 排查优先级与习惯如果你现在有一个Prompt跑出来的结果不稳定我建议按下面的顺序排查而不是东一榔头西一棒。先看输出格式。只要格式还不干净后面的一切都谈不上。格式过了再看内容维度是否出现任务目标不清晰、示例配比失衡这类问题。内容没问题再往上查角色设定和CoT这些“风格层”的东西。这个顺序其实是把最影响自动化和业务结果的环节放在最前面。还有一个排查习惯我觉得非常重要。每次改Prompt不要同时改多个变量。比如又改了角色又加了示例又调了输出格式最后输出质量提高了你完全不知道是哪一步起的作用。我自己会存一个简短的版本变更记录v1初版 v2角色从“助手”改为“产品分析师” v3增加一个边界示例输出格式增加category白名单 v4启用0.3的temperature这样每一轮改动都能对照着输出质量时间一长你会形成一种直觉什么类型的任务要优先加示例、什么类型的任务要优先改格式。排查的时候还可以查一个细节指令里的敏感词和模型内置的安全机制是否有冲突。遇到内容分类、审核类任务时模型有时会出于安全克制给出格式化但空洞的输出这时候不是Prompt写得不好而是模型自身的防御机制挡了一下。我的做法是单独加大示例里正常输出的比重通常能让模型走出过度谨慎的状态。说实话Prompt工程做到后面拼的不是奇技淫巧而是排查的耐心和改版本的习惯。很多“精度不够”的问题拆开来看全都可以归因到上述某个环节。我最后再分享一个自己的习惯每次写完Prompt我会从头到尾朗读一遍站在一个完全没学过这个任务的陌生人的角度看它能不能准确执行每一步。确实有两次我在朗读时发现指令顺序上还有优化的空间调整之后效果提升很明显。把Prompt当成产品你的输出质量就会跟着稳定下来。