“同一个模型同一个问题我把提示词改了三段输出质量差出一个量级。”上个月帮朋友调一个合同摘要的小工具他原来的提示只有一句“帮我总结一下这份合同的重点”模型返回的东西排版漂亮但基本没用——该说的条款没说不该下的结论乱下。我补了一段职责描述、两个少样本、一个固定的输出骨架再加一条“原文没有的信息一律写‘未提及’”的兜底规则同样的模型、同样的输入摘要立刻能进业务流程。这种反差我经历过太多次所以越来越确信高质量提示词工程不是玄学它是一门有明确输入、明确输出、明确评价标准也有一张明确踩坑清单的手艺活。这篇内容写给三类人刚接手大语言模型应用、还在靠“多试几次”碰运气的开发者要把提示词交给团队协作、需要它稳定可复现的工程负责人以及业务侧想自己动手调效果、不想每次都排期等研发的产品同学。全文不谈虚的只讲结构怎么拆、参数怎么定、效果怎么验、坑怎么绕。1. 先想清楚提示词工程到底在解决什么问题很多人对提示词工程的想象停留在“找一句咒语”仿佛存在某个神秘句式敲进去模型就变聪明。真做过几个落地项目就会明白模型的能力边界是固定的你能改变的只有三件事给它什么信息、以什么结构给、用什么标准判断它答得好不好。这三件事合起来就是提示词工程的全部战场。1.1 从“会聊天”到“会指挥”的认知转变聊天框里的交互是开放式的你说一句它接一句错了重来就行成本几乎为零。但一旦把模型接进业务流性质就变了它变成流水线上的一个工位上游给它原料下游等它的半成品这时候“大概齐”是不能接受的。我见过一个很典型的场景某团队做发票信息提取前两周在聊天框里测得好好的一上量就崩——同样的发票版式今天抽出金额明天抽出的是税额后天干脆把整段文字塞进一个字段里。问题不在模型在于他们从来没写过“输出契约”也就是没告诉模型结果必须以什么形状交付。从聊天到指挥核心转变是把隐含期待显式化。你脑子里知道“我要的是简洁的三行摘要”模型不知道你知道“金额必须是数字不带币种符号”模型不知道你知道“这份文档里没写生效日期就不要编”模型更不知道。提示词工程做的就是把这些只存在于你脑子里的约束一条一条翻译成模型能读懂的指令。1.2 四个真实痛点决定了你必须认真写提示词我把实际项目里遇到的麻烦归了归类基本逃不出下面四类每一类都直接对应一项提示词技巧不是凭感觉对号入座痛点表现根因对应手段输出格式天天变下游解析老失败没有输出契约固定骨架 结构化约束 兜底值同样的输入两次结果差很多指令有歧义、缺少判定标准明确判定规则 少样本锚定关键信息漏掉或凭空捏造上下文组织混乱、无“未知”出口分段标注 显式拒答规则换个人写就废没法交接提示词没有版本和结构模板化 变量占位 版本记录这四类问题有个共同点它们都不是靠“换个更强的模型”能根治的。模型升级确实能抬高下限但格式漂移、指令歧义、幻觉出口缺失这些属于“你没说清楚”模型再强也只能猜。我在项目里反复验证过一件事把一个中等能力模型上的提示词打磨到位效果提升幅度往往大于直接换更强的模型而且成本低得多。1.3 一个必须提前接受的现实提示词是有寿命的这点很少有人提但特别重要。你精心调好的提示词在模型版本更新之后可能效果波动甚至明显变差。原因不复杂——不同版本对指令的敏感度、对格式的偏好、对长上下文的处理方式都会有差异。所以从第一天起我就建议把提示词当成代码资产来管有版本号、有变更记录、有配套的评测集。改一版跑一遍评测数字掉了就回滚别靠记忆判断“好像变好了”。后面第 5 节会讲具体怎么搭这套东西。2. 一条提示词的解剖六个部件与它们的排列逻辑写提示词最忌讳的是“想到哪写到哪”。我习惯用固定骨架六个部件按顺序摆写完自查一遍有没有漏。这套骨架不复杂但能覆盖九成以上的常规任务。2.1 六个必备部件清单角色与职责不是“你是一位资深律师”而是“你负责从合同中提取与付款相关的条款不做法律意见判断”。任务定义一句话说清输入是什么、要产出什么动词要具体“提取”“归类”“改写”比“分析”“处理”明确得多。上下文材料待处理的原文、参考资料、历史对话用清晰的分隔标记包起来。约束条件字数、语气、禁止项、边界情况怎么处理。示例一到三条高质量输入输出对用于锚定风格和粒度。输出契约字段名、类型、顺序、缺失值怎么写、允不允许额外解释。我的经验是第六项被忽略得最狠但收益最高。哪怕你只是加一句“只输出 JSON不要任何前后说明文字”下游解析失败率都能降一大截。2.2 顺序为什么这么排而不是随便放部件顺序不是审美问题它直接影响模型的注意力分配。我的排法遵循三条经验规则第一任务定义要靠近材料。模型在读到大段原文时容易“沉浸”进去而忘了要干什么所以任务说明放在材料前一句、材料后再复述一遍关键要求效果比只在开头说一次好。第二输出契约放在最后。多数模型的注意力对结尾位置更敏感把格式要求压在末尾比埋在中间更不容易被冲淡。这一点在长提示里尤其明显。第三示例放在约束之后、契约之前。示例的作用是“示范粒度”它要能同时参照前面的约束和后面的格式位置夹在中间最合适。如果你的示例很长考虑压缩到最关键的一两条长示例会挤占真正指令的注意力。提示不要试图用空行和符号把提示词排得花里胡哨。清晰的分隔比如用 XML 风格标签或三级标题有用但一堆星号、波浪线、箭头只会让结构更难读对模型也没帮助。2.3 系统提示与用户提示别混着写如果你用的是带系统提示system和用户提示user分离的接口一定要利用好这个分层。我的划分原则很简单系统提示放“不变的东西”角色、职责边界、全局禁止项、输出契约的骨架。用户提示放“每次都变的东西”这一次的原文、这一次的具体任务、这一次的额外要求。这么分的好处很实际。系统提示稳定可以配合缓存机制降低成本、提高响应速度用户提示短小调试时只改一小段不会牵一发动全身。我见过不少项目把所有内容堆在用户提示里结果每次调用都要重传几百字规则调试时改一个标点都得整体回归非常低效。顺带说一个容易踩的坑系统提示里的规则和用户提示里的规则冲突时模型不一定按你期望的优先级执行。所以两条原则一不要写互相矛盾的规则二如果业务上确实需要“用户可覆盖”的默认值就在系统提示里明确写出覆盖规则比如“若用户另行指定长度以用户指定为准”。3. 六个高频技巧正确用法、常见误用与替代方案技巧本身不难找难的是知道什么时候该用、什么时候用了反而添乱。下面这六条是我用得最多、也见过最多误用的。3.1 角色设定写职责不写头衔“你是一位拥有二十年经验的资深专家”这类写法坦白说收益很有限。它唯一的作用是给模型一个大概的语域方向但“资深专家”到底怎么说话、关注什么、不关注什么全是空的。真正有效的角色设定写的是职责边界包含三样东西负责什么、不负责什么、遇到越界情况怎么办。举个例子对比一下弱你是一位专业的财务分析师。 强你负责从财报原文中提取营收、毛利率、经营现金流三项数据。 你不做投资建议不评价公司好坏。 原文没有明确披露的项填“未披露”不要用推算值填充。第二种写法带来的差别是可观测的越界回答明显减少“未披露”这类兜底值让下游能准确判断数据完整性。角色设定本质上是给模型划定行为空间而不是给它戴一顶帽子。3.2 少样本示例数量、排序和“坏例子”示例few-shot是最有效的技巧之一但也是最容易被用坏的。三个实操要点数量上两到三条通常足够。一条太少模型抓不到规律四五条以上边际收益迅速递减还会挤占上下文预算。如果任务确实复杂宁可拆成两个子任务分两次调用也别硬塞十条示例。排序上把最接近真实分布的放最后。模型对靠近结尾的示例更敏感最后一条示例的“示范权重”最高。所以别把最极端的边界案例放最后除非你就是要它重点学会处理边界。最关键的一点示例的格式必须和输出契约完全一致。我见过太多反例——契约里写“输出 JSON”示例却是一段自然语言描述模型当然会优先模仿示例。示例就是模型的模板格式不一致等于自己拆自己的台。关于“坏例子”我的看法是谨慎使用。有些场景确实需要示范“什么是不该输出的”比如“不要输出这种笼统的表述本文主要介绍了……”。但负面示例有副作用模型可能被带偏去做类似风格的输出。如果一定要用把它放在明确的“反例”标签下并在后面紧跟一条正例形成对照。3.3 输出契约从“请用表格”到可执行的格式约束“请用表格输出”这种要求在聊天框里够用在工程里不够。因为“表格”有无数种形态几列、列名叫什么、空值怎么表示、单元格里能不能换行。工程上需要的是一份契约我通常包含这几项字段名与顺序固定不允许增删字段类型字符串、数字、布尔、数组缺失值约定统一写null或未提及二选一全篇一致长度上限比如摘要不超过 120 字附加说明的处理方式统一放在某个指定字段里或干脆禁止如果接口支持结构化输出或 JSON 模式优先用它能从机制层面减少格式漂移。如果不支持那就把契约写得足够死并配一条“只输出内容本身不要任何解释、不要代码块标记”的硬性要求——这条看似多余实际能省掉大量清洗工作。3.4 让模型“先想后答”的正确姿势让模型先推理再给结论对多步计算、逻辑判断题确实有帮助。但很多人的用法有个问题把推理过程也当成了交付物结果输出里一半是思考、一半是答案下游还得自己切。正确做法是分离推理和结果。要么在契约里明确要求“先输出分析过程用分析标签包裹再输出结果标签包裹的最终答案”要么更干脆——分两次调用第一次让它列要点第二次基于要点出结果。后一种方式在工程上更容易控制因为每一步的输出都能单独校验。还有个反直觉的经验简单任务不要强行让它推理。抽取字段、改写句子这类任务加了推理步骤反而容易引入噪音甚至让模型把推理里的中间猜测写进结果。判断标准很简单——如果你的任务不需要多步推导就别加。3.5 负面指令为什么老是失效“不要编造”“不要说废话”“不要用专业术语”——这类否定句实际效果往往很差。原因在于模型处理否定信息的方式和人类不同它对“编造”“废话”这些词的激活强度可能高于对“不要”的抑制。你越强调不要什么越容易把注意力引到那上面。替代方案是把否定转成肯定并给出可执行的替代动作失效写法改写后不要编造信息每个结论后标注来源句编号无来源句支撑则输出“无依据”不要写得太啰嗦每个要点不超过 30 字全篇不超过 5 个要点不要用口语使用书面语避免“啊”“呢”“其实”等词不要漏掉关键条款按“付款、违约、期限、争议”四类逐项检查缺项写“无”改写后的共同点是给了模型一个可执行的动作而不只是一个禁令。这是我这些年最有价值的一条经验几乎适用于所有“模型不听话”的场景。3.6 分步拆解把一个大任务切成能验收的小任务一个提示词干三件事几乎注定失败。信息抽取 逻辑判断 文风改写这三件事对上下文的要求、对温度的要求都不一样混在一起必然互相拖累。我的做法是拆成流水线每步一个提示词每步的输出都能单独验收。举个文档处理的实际拆法第一步清洗和分段第二步逐段抽取结构化字段第三步汇总去重第四步生成成稿。每一步的提示词都很短出问题能立刻定位到是哪一环。代价是调用次数变多、成本上升所以拆到什么粒度要看业务容忍度——高价值场景值得多花几次调用批量低价值场景就合并成两步。4. 实操从零搭一个可复用的提示词模板光讲原则不够我把一次完整的搭建过程摊开写你可以直接照着改。4.1 第一步把需求拆成信息清单假设任务是从用户反馈里提取问题类型和紧急程度输出成结构化记录给客服系统。先别急着写提示词先列清单输入是什么一条用户反馈原文长度几十到几百字可能带错别字和情绪表达。输出要什么问题类型限定枚举值、紧急程度三档、关键信息摘要不超过 40 字、是否能自动回复布尔。边界情况有哪些反馈内容为空、反馈是纯情绪无实质内容、一条反馈包含多个问题、语言混杂。判定标准是什么紧急程度靠什么区分这是最容易含糊的地方必须写死。这一步花的时间最值。清单列完提示词基本就成型了一半剩下的只是措辞。4.2 第二步搭骨架与变量占位我习惯用一个固定的模板文件变量用双花括号占位方便程序替换和人工审阅# 角色 你负责把用户反馈整理成工单记录。你不回复用户不评价产品只做信息归类。 # 任务 读取下方【反馈原文】按输出契约产出记录。若原文包含多个独立问题只提取最主要的一个其余在备注中列出数量。 # 判定规则 问题类型只能取功能异常 / 使用咨询 / 体验建议 / 费用疑问 / 其他。 紧急程度判定 - 高涉及无法使用、资金损失、数据错误 - 中影响部分功能但可绕过 - 低咨询、建议、表达不满但无具体故障 # 约束 - 摘要在 40 字以内只陈述事实不带情绪词 - 原文未提及的信息一律填“未提及”禁止推测 - 只输出 JSON不要任何解释文字不要代码块标记 # 示例 输入付了两次钱第一次显示失败我又点了一次现在扣了两笔 输出{type:费用疑问,urgency:高,summary:用户重复支付两笔首次显示失败,autoReply:false,note:未提及} # 输出契约 {type: string, urgency: string, summary: string, autoReply: boolean, note: string} # 反馈原文 {{feedback_text}}这份模板有几个值得注意的设计。示例放在契约前、原文后让模型在读完材料后再看一遍“标准答案长什么样”。原文放在最末尾紧贴生成位置减少中间内容对注意力的稀释。兜底值“未提及”和“禁止推测”成对出现一个给出口一个堵入口比单说“不要编造”有效得多。4.3 第三步参数怎么定别凭感觉提示词之外的调用参数对稳定性影响同样大。下面是我常用的起步配置不是绝对标准但作为初始值很少需要大改参数抽取/归类类任务创作/改写类任务说明温度temperature0 ~ 0.20.6 ~ 0.8越低越确定抽取任务几乎不需要随机性top_p0.1 ~ 0.30.9与温度配合一般不两头都调最大输出长度按契约上限 20%按需留余量但别无限长输出容易跑偏停止词可按需设置一般不用结构化输出时可用于截断多余内容一个实操心得调试阶段先把温度压到 0。这样同一个输入跑十次结果基本一致你才能判断“改动提示词带来的差异”和“随机性带来的差异”哪个在起作用。等提示词稳定了再根据业务需要把温度往上调。4.4 第四步跑通并记录第一版结果拿二十条真实反馈跑一遍我记录的内容包括通过条数、失败类型分布、典型失败样本。第一版通常能过十五到十七条剩下的是宝贵的调试素材。这里有个必须提醒的点——别用你调试时反复看的那几条样本当评测集。人一旦对某条样本熟悉就会不自觉地围绕它优化最后提示词只在那几条上好使。评测集要从一开始就留出一部分“不看”的样本。5. 怎么判断提示词真的变好了没有评测的提示词迭代本质上是盲改。这套东西搭起来不复杂一个下午够了但收益是长期的。5.1 二三十条样本就够起步不需要几百条二十到三十条覆盖主要场景和边界情况即可。关键是分层抽样正常情况占大头边界情况空输入、超长输入、多问题混合、语言混杂各留几条。每条样本要有人工标注的“正确答案”或“合格标准”哪怕是粗略的也行。样本集要冻结。改提示词的时候不动它否则你永远不知道是提示词变好了还是题目变简单了。需要扩充就新增一份旧的那份留着做回归对比。5.2 打分维度拆开看别只打总分我一般拆成四个维度各打通过/不通过比打总分更有诊断价值维度看什么常见不通过原因格式合规能否被程序直接解析多了说明文字、字段拼写错、类型不对内容准确关键信息与原文一致数值抄错、漏掉核心问题、把备注当成主问题边界处理异常输入是否按约定兜底空输入时自己编内容、多问题时强行合并表达质量摘要是否简洁无赘述带情绪词、超字数、把原话整段复制四列分开看问题定位会快很多。比如格式维度全过但内容维度掉了一半说明是抽取逻辑的问题不用去动格式部分。5.3 迭代记录写下来别靠记忆我用一张很朴素的表管版本字段就这几个版本改动点通过率失败主因是否采纳v1初版75%摘要超字数-v2摘要限制改为例示写法85%边界输入仍会编造采纳v3加“未提及”兜底92%无采纳这张表的价值在模型升级时体现得最明显。新版本一上线先跑一遍评测集通过率掉到 80% 就知道要复查了对照记录能快速定位是哪类改动失效了。没有这张表你只会感觉“好像变差了”然后陷入无休止的试错。6. 常见问题排查实录下面这些是我被问得最多、自己也踩过最多次的坑按现象归类附排查顺序。6.1 输出忽好忽坏同样输入两次结果不同先查参数再查提示词。温度高于 0.5 的抽取类任务天然不稳定压到 0 复测一轮如果压到 0 还波动那就是指令有歧义。最常见的歧义源是判定标准写得含糊比如“重要的问题标为高优先级”——什么叫重要模型只能猜。把判定标准改成分条可判定的条件波动基本会消失。还有一种情况容易被忽略输入里含有相互矛盾的信息。比如反馈里用户先说“能用”后说“打不开”模型在两次采样中可能各偏向一边。这时候别指望模型自己权衡直接在提示词里规定冲突时的取舍规则。6.2 长文档里指令被“淹没”处理长文档时把指令全放开头模型读到后面就忘了要干什么这是很普遍的现象。我的处理顺序是把关键指令在文档前和文档后各放一次后一次紧贴输出位置措辞可以更短。用清晰的分隔标签把文档包起来比如document.../document让模型知道哪里是材料、哪里是指令。如果文档超长先做分段预处理每段单独抽取再合并结果而不是指望一次读完。材料内部如果有小标题或编号保留它们结构信息对模型理解内容帮助很大。6.3 结构化输出解析失败按这个顺序排查基本能覆盖九成情况有没有多输出内容最常见的是模型在 JSON 前后加了解释或代码块标记。加一条硬性禁止必要时用停止词截断。字段名是否拼错契约里写autoReply模型可能输出auto_reply。契约里把字段名用引号原样列出能显著降低出错率。类型是否漂移布尔值被写成字符串false数字被写成带单位的文本。在契约里明确类型并给一个正确示例。特殊字符是否破坏结构摘要里带引号或换行会把 JSON 弄坏。要求摘要内不带引号、不换行或让程序侧做转义兜底。6.4 排查速查表现象优先怀疑快速验证方法格式漂移输出契约不完整 / 示例格式不一致对照契约与示例看是否完全同构内容编造缺少“未知”出口加“原文未提及则填 X”后复测指令被忽略位置太靠前 / 上下文过长把关键指令复制到末尾再测一次输出过长无长度约束加字数上限与“超出即视为失败”的说明语气不对角色描述空泛改成职责描述 一条风格示例多问题混淆未规定冲突处理明确“只取主要问题其余记入备注”最后分享两个我自己常用的小技巧。一是反向测试故意喂一条完全无关的输入看模型会不会硬编一个答案出来能兜底住才算合格。二是朗读测试把提示词当成写给一个新同事的交接文档读一遍如果读起来你会反问“这里到底啥意思”那模型八成也会反问——只不过它不会问它会猜。这套方法我用了两年多最大的感受是提示词的收益不在某一次灵感爆发而在每次改动都能被验证。我早期也靠感觉调改十版有八版是原地打转后来把评测集和版本记录补上迭代速度反而快了一倍因为知道哪条路走不通就不会反复去走。至于模型本身的能力交给厂商去卷就好我们把手头这几百字写到没有歧义已经能吃掉大部分红利了。