1. 模型不是人它读提示词的方式决定了你的写法1.1 自回归机制下上下文就是概率分布的方向盘先抛一个可能让很多人意外的结论大语言模型并不真的理解你的需求它做的最核心的一件事是根据已有的文本预测下一个词。你在对话框里写的每个字都会进入它的上下文窗口成为下一轮预测的依据。这个机制听起来简单但它能解释大量日常使用中的怪现象。比如同一个问题你直接问15和27的最小公倍数是多少模型常常能给出正确结果但如果你把这个问题塞在一大段背景介绍的最后一行它反而容易算错。原因不是模型分心了而是它的注意力在长上下文里被分散关键信息被其他内容稀释了。我用一个类比来记这件事模型像一个非常擅长模仿的临时助理。你交给他一份资料只说整理一下他只能按自己印象里最普遍的整理方式发挥结果当然不可控。而提示词工程做的事本质上就是给这个临时助理一份足够具体的上下文让他不用猜、也不许猜。所以提示词写得好不好首先不是修辞问题而是信息结构问题。你在什么位置强调什么、哪些内容靠近问题核心、哪些示例放在哪里都在实质性地改变模型产出的概率分布。理解了这一层后面所有的技巧才有落脚点。1.2 温度、长度和信息密度三个被忽略的隐藏变量提示词之外还有几个参数经常被忽略但它们对输出质量的影响一点不比文字内容小。第一个是温度。温度控制模型从概率分布中取词时的冒险程度温度接近0时模型总是选概率最高的词输出稳定但略显呆板温度升高后它开始接受概率更低的选择输出变得多样甚至飘。对格式提取、数据整理这类任务我几乎永远把温度设在0到0.3之间只有写文案、起标题这类创意任务才会把温度往上调。第二个是最大输出长度。很多人习惯给一个很大的上限觉得多给空间总没错。但模型生成时会有一种顺着惯性写下去的倾向长度上限给得太大它反而不急着收尾容易在结尾处添加与任务无关的补充说明。更稳的做法是把合理的长度直接写进提示词比如不超过150字让模型在生成时就自我约束。第三个是信息密度也就是提示词里有效信息占全部文本的比例。一些模板把背景、示例、注意事项全部堆在一起真正决定任务的句子只有一两句模型的注意力自然容易被带偏。我习惯把提示词控制在一个内行同事不用追问就能完成的长度多一句交代背景少一句无关废话。另外提醒一句调提示词时参数一定要固定否则你就是在两个变量同时变化的情况下做判断永远分不清输出变好是因为改对了提示词还是因为改了温度。这个习惯能帮你省掉大量无效返工。2. 一条靠谱提示词的三层骨架指令、上下文、输出2.1 指令层用做什么代替别做什么我见过最多的坏写法是把要求写成堆否定句不要啰嗦、不要编造、不要用列表。模型对否定句的处理能力并不好你越强调不要编造它反而越容易生成出带编造嫌疑的内容。原因不难理解否定句把编造这个动作放进了上下文中心模型更容易顺着这个动作的空间去采样。更好的写法是正面描述动作。拿内容整理类任务举例模糊版帮我分析一下这个市场情况写个简单报告。清晰版请基于以下三组数据分析某目标人群的市场情况。要求1200字以内2包含现状、趋势、风险三个小节3每条结论必须标注对应的数据编号4若数据不足输出数据不足不要猜测。清晰版把任务类型、篇幅、结构、约束全部钉死模型几乎没有发挥空间结果自然稳定。写指令层的几个原则我一直贴在工位上一是用动词开头避免分析一下大概看看这类模糊说法二是每个句子只放一个要求多个要求拆成编号列表三是有冲突时明确优先级比如以近三个月数据为准历史数据仅作参考。这层是整个提示词的地基地基不稳后面的上下文和输出格式做得再好也是白搭。2.2 上下文层背景资料、示例与限制条件的摆放顺序上下文层的任务是为模型补充完成任务所需的领域信息。但补多少、怎么摆很多人没有仔细想过。我的排序习惯是任务定义放最前面背景资料放中间示例紧随其后附加限制条件放最后。这个顺序不是随便定的。任务定义放最前面相当于先告诉模型你接下来要干什么让它在后续阅读资料时带着明确的目的示例放在资料后面、限制条件前面是因为示例承担着展示期望输出长什么样的功能要紧挨着输出要求限制条件放最后则可以起到收尾兜底的作用把模型刚要开始发挥的边缘拉回来。上下文层最常见的误区是给得太少或太多。给太少模型只能凭训练数据里的平均印象作答给太多又会造成指令稀释。一个相对可靠的判断标准是把提示词拿给不了解这个任务的同事看一遍如果他能不追问就完成任务说明上下文给得刚好够。还有一个小技巧当背景资料比较长时不要原封不动贴进去先在指令里做一次剪裁。比如请从下面的对话中提取与退换货相关的信息就比请根据以下对话进行总结精确得多因为前者帮模型划定了注意力范围。2.3 输出层把格式钉死模型就不敢乱来输出层是投入产出比最高的一层。很多时候提示词已经写得不错了输出内容也正确就是格式乱成一团下游程序没法解析。这时候只要在输出层加约束问题立刻解决大半。比如做客服对话信息提取我会直接写请从下面的对话中提取信息输出JSON对象字段包括customer_name、issue_type、urgency、suggested_action。字段缺失时置为null不要自行补全。模型看到这种结构化的输出约束会自动进入字段匹配模式很少再自由发挥。输出层的另一种常见用法是叠加自检指令答案生成后请逐条核对每个结论是否能在原文中找到依据如果找不到删除该结论。这种自检对精确度要求高的任务特别管用虽然会让响应时间增加一点但换来的质量提升通常很值。还有一个经验值得单独说输出格式的约束不要只在指令里写一次最好在结尾再强调一遍。这是利用了模型对上下文结尾内容更敏感的特性省得它在长篇生成中途把格式要求忘了。3. 高频技巧背后的原理角色、少样本示例与思维链3.1 角色设定何时有效、何时失效你是一名资深律师你是一位经验丰富的编辑这类角色设定几乎出现在所有提示词分享里。它的原理不难理解模型在训练时见过大量以特定身份写作的文本当你赋予它一个角色等于把生成方向往这个身份常见的表达方式上引导。对文案、翻译、客服回复这类风格很重要的任务角色设定的效果立竿见影。不过角色设定有明确失效条件。一个常见的失效场景是角色与指令冲突你让它扮演严谨的审计师又说随便写写就行模型通常会受靠后的指令影响演一半就出戏。另一个更危险的问题是角色幻觉当模型对某个专业领域的知识储备不足时为了维持专业形象它会更倾向于自信地编造答案。医疗建议、法律解释、财务判断这类场景我基本不靠角色设定来保证正确性而是把注意力放在要求模型标注信息来源、区分事实与推测上。所以我的结论是角色设定是风格工具不是事实工具。它能让语气更贴合场景但不会让模型突然变聪明。需要精确推理和事实核查时应该用下面的思维链技巧而不是换一个更权威的角色。3.2 少样本示例数量与选择比多放几个重要少样本示例是让模型对齐你想要的输出长什么样最直接的手段。但网上很多教程有个误区以为示例越多越好。我的实测结论是三到五个精心挑选的示例通常胜过十几个重复性很高的示例。数量太多会让提示词变长反而稀释模型的注意力。选择示例比增加数量更重要。我挑示例一般看三点一是覆盖任务的主要变体比如做文本分类至少要有正常类、边界类、缺失信息类各一个二是格式必须与目标输出严格一致包括标点和字段顺序因为模型会模仿示例里的所有细节三是刻意放一两个容易犯错的输入比如字段缺失的样例明确告诉模型这种情况该输出什么。示例的放置位置也影响效果。我习惯放在任务指令之后、输出要求之前相当于先讲规则、再看示范、最后说清验收标准。如果示例放在很靠后的位置模型容易把示例当成最近发生的指令去执行反而压过你前面的规则。一个踩过的坑示例本身要反复核对。有次我做字段抽取手工写示例时漏了一个字段模型的输出从第三轮开始就跟着漏排查了半天才发现是示例带坏了节奏。从那以后凡是用在提示词里的示例我都要求先在测试集上跑一遍确认它不会把坏习惯传染给模型。3.3 思维链提示把隐形推理变成显式步骤思维链被讨论得很多但很多人只记得那句让我们一步一步思考然后发现效果时好时坏。问题的关键在于那句话只是一个引子真正有效的是把推理过程的结构显式定义出来。我常用的写法是把步骤写死例如请按以下步骤完成任务1列出题目中给出的所有已知条件2判断每个条件与问题的关联3逐步推导结论4用一句话给出最终答案。当模型拿到这样一份可执行清单它的推理稳定性会明显提升。这种写法对计算、逻辑判断、方案比较类任务尤其管用。思维链也有取舍显式推理会让输出变长增加时间和费用。如果业务场景只需要最终答案我一般会在步骤后面加一句最终回答控制在50字以内。还有一类更高级的用法是隐藏式推理——让模型在内部思考只输出结论不过这是否有效很大程度上取决于具体模型的能力和指令遵循水平建议自己实测后再决定要不要用。4. 一次完整迭代实录投诉转工单提示词的五版进化4.1 V1到V5每次改动改了什么、为什么这么改光讲理论容易虚我拿一个真实场景走一遍完整的提示词迭代过程。任务是把一段客户投诉文本转换成熟练工单概要需要提取问题类型、紧急程度、用户诉求、涉及商品并生成一段摘要。第一版提示词非常简单把下面的投诉转成工单概要。结果输出是散文式的一段话字段不固定紧急程度忽高忽低完全没法直接入库。这一版给我的教训是自由度越大模型越会按训练数据里最常见的表达方式来写而不是按你的业务标准来写。第二版我加了输出结构限制请提取以下字段问题类型、紧急程度、用户诉求、涉及商品输出为JSON对象。这一版之后字段名总算统一了但问题类型仍然五花八门商品损坏质量问题物流太慢混在一起写没有对齐系统预设的分类枚举下游照样没法聚合统计。第三版加入分类体系定义和两个示例一个正常案例、一个信息不足案例。字段值终于落在预设集合里但新问题出现了——模型开始模仿示例里的措辞风格示例写得稍微口语化它的输出也跟着口语化。这让我意识到示例的风格信息和格式信息同样会被模型学习。4.2 同一段输入两版提示词的输出对比V4和V5的改动思路是继续做收口V4把输出要求调整为语气中性仅陈述事实短语不超过20字并把示例换成两种不同风格避免模型误以为示例风格是固定模板V5增加自检步骤要求模型在输出前区分原文可直接确认的信息和基于推断的信息。不用把每一次改动都背下来关键是看效果差异。下面用同一段输入对比V2和V5的输出。输入大意是用户反馈某商品到货延迟三天且外包装破损申请换货希望补偿运费。V2的输出只有格式约束{ 问题类型: 物流问题, 紧急程度: 高, 用户诉求: 换货、补偿运费, 涉及商品: 某商品, 摘要: 用户投诉商品到货延迟外包装破损申请换货和运费补偿。 }V5的输出带自检与信息边界规则{ 问题类型: 到货延迟、外包装破损, 紧急程度: 中, 用户诉求: [申请换货, 希望补偿运费], 涉及商品: 某商品原文未提供具体名称, 摘要: 用户反馈到货延迟三天外包装破损希望换货并补偿运费。其中补偿运费为用户主观诉求非平台承诺。, 信息边界说明: [到货延迟三天原文可直接确认, 外包装破损原文可直接确认, 紧急程度根据延迟加破损推断] }看到差别了吗V2把紧急程度直接判定为高其实是模型在猜V5会主动说明这是推断还会在摘要里区分事实与用户诉求。对只做人工查看的场景V2勉强能用但要入库、要自动化流转V5的信息边界说明就是决定性的——下游系统可以放心使用可回溯字段风险因此大幅下降。代价是V5生成的token数量大概多一倍对需要入生产环境的数据来说这点成本非常划算。4.3 可复用的提示词迭代工作流这一段是我想重点留给你的部分。提示词优化不是凭感觉改一句看看效果而是一套可以重复执行的工程流程我把它总结成四步。第一步建立小测试集。选5到10条真实输入必须覆盖正常情况、边界情况、信息缺失情况缺一类都会让后续评估失真。第二步定义评分标准。我给常用的任务定了四个维度格式合规率、字段完整率、内容可回溯率、无幻觉信息率。每个维度单独打分避免整体感觉还行这种无法量化的判断。第三步单变量修改。一次只改一层要么改指令、要么换示例、要么加自检改完跑一遍同样的测试集对比结果。如果同时改了三处效果变好或变坏你都无法定位到具体原因。第四步记录版本。把每版提示词、改动点、测试结果放进一张表写明预期变化和实际变化。没有记录三天后你就说不清今天的效果是哪个改动带来的。版本主要改动观察结果V1首次尝试无约束格式混乱字段不固定无法入库V2增加JSON输出约束字段名统一分类值仍不收敛V3加入分类体系与两个示例分类值收敛示例风格被连带模仿V4输出要求收口、替换示例风格风格稳定仍有推测性填充V5增加自检与信息边界规则输出稳定可回溯字段可入下游流程提示单变量修改是提示词迭代里最难坚持但最有效的一条纪律。一次只改一处才能准确归因。这套流程最大的价值在于它把这次运气不错变成这次规则有效。哪怕某次改动失败了记录也能告诉你失败在哪个环节下一次就不会重复踩坑。5. 容易翻车的细节与补救膨胀、污染、位置与评估5.1 提示词越长不一定越好警惕指令膨胀很多团队有个直觉提示词写得越详细模型越听话。这个直觉在小范围内成立但一旦过了某个度反而会出问题。我见过一条写了快三千字的提示词把各种边界条件、业务知识、特殊规则全部塞进去结果模型开始挑着执行——开头的要求遵守了中间的规则被忽略结尾的要求倒是每条都执行整体呈现出一种典型的顾头不顾尾。我把这个现象叫指令膨胀关键约束被大量次要信息淹没模型注意力跟不上执行的确定性反而下降。应对办法其实很简单就是做减法删掉与任务无关的修饰语合并重复要求把真正的关键约束控制在十条以内背景资料如果很多压缩成结构化要点而不是大段文字。自检的方法是信息密度测试把提示词里除了关键指令之外的句子全删掉看任务是否还成立。如果删完发现关键信息没丢说明原来的版本里确实有不少废话。5.2 示例里的坏习惯会被模型学走示例的双刃剑效应比大多数人预期的更严重。模型不会自动区分你给的示例是正面教材还是反面教材它只会把它当成可模仿的样本。示例里的口语化表达、省略字段、甚至一个小到不仔细看就发现不了的错别字都会成为模型复制的对象。我自己就栽过一次做一个数据清洗的提示词示例里的标准输出是我手工敲的结果漏填了一个字段模型从第一轮开始就跟着漏。我花了几小时以为是输出解析的问题最后才发现是示例本身带坏了节奏。这件事之后我养成了两个习惯第一提示词里的示例一律用程序生成加人工核对绝不用随手打的临时文本第二每次改动示例必须重新跑一遍测试集——示例和指令是一个互相影响的整体不能只测其中一部分。5.3 关键指令的位置开头和结尾最容易被记住模型对上下文不同位置的敏感度不一样这个特性在实际使用中会带来明显的效果差异。简单说开头的内容负责建立任务框架结尾的内容在生成时更容易被激活中间段落经常沦为被快速扫过的信息带。这个特性能解释很多怪现象。比如你把输出JSON格式放在提示词中间模型经常写一半就忘了加反括号同样的要求挪到开头和结尾各出现一次问题立刻消失。我遇到过好几次模型老忘掉某个要求的情况起初以为是指令不够强反复加注意两个字也没用直到调整了位置才真正解决。所以定位这类问题时先别急着加权重先检查这个要求出现在提示词的哪个位置。凡是关键约束尽量在开头定义、结尾重申中间专心放资料和示例。5.4 用测试集和评分标准把碰运气变成做工程最后聊一个最容易被忽视、却最能拉开水平差距的话题评估。模型生成有随机性同一个提示词跑几次结果都可能不一样。如果你只凭这次输出看起来像样来判断提示词好坏本质上就是在碰运气运气不好时还容易得出错误结论。最基本的做法是准备一个几十条样本的测试集每次修改后批量跑几轮统计一个简单的通过率比如字段完整率、格式合规率。更进一步可以写个几行的自动化脚本批量调用模型接口把输出和预期字段做比对定期回归——这会让提示词维护进入真正的工程化状态。注意测试集必须与业务输入同步更新否则它只会给你虚假的安全感。我想提醒这一点是因为自己项目里就吃过亏有段时间上游数据格式变了但测试集没有同步更新提示词在本地跑分一直很好看实际业务效果却在悄悄下滑。保持测试集与真实输入同步和保持代码与需求同步一样重要。这大概就是我在提示词工程这件事上最想说的部分它不是一个可以速成的技巧清单而是一套需要持续维护的小型系统。你越是把它当作工程来对待它就越是会给你稳定的回报。