★ FEATURED ARTICLE 1. 为什么Prompt工程值得当作一门独立手艺来练很多人第一次接触大模型应用开发都会有一种错觉不就是把需求写成一句话丢给模型吗这有什么技术含量。我刚开始也是这么想的直到在一个文本分类的小项目里同一批数据、同一个模型我写的提示词准确率卡在七成上不去换了一位同事的写法直接冲到九成以上。那一刻我才意识到Prompt工程不是会说话就行它更像是一门需要刻意练习的手艺里面有结构、有套路、有边界也有大量只能靠踩坑积累出来的经验。这篇笔记围绕Prompt工程实践这个主题展开把实验手册里那些零散的练习点串成一条完整的学习路径。它适合三类人一是刚入门大模型应用、想系统补齐提示词基本功的开发者二是已经在用大模型做业务、但效果时好时坏想找方法论的工程师三是把大模型当作日常生产力工具、希望输出更稳定可控的普通用户。读完之后你应该能独立设计出一套结构清晰、可复用、可调试的提示词方案而不是每次靠运气去抽卡。需要先明确一个前提Prompt工程的核心目标不是让模型变聪明而是把模型已有的能力稳定地引导出来。模型本身的能力是固定的你能改变的只有输入的组织方式。理解这一点后面所有的技巧才有落脚点。我见过太多人把精力花在反复换模型上却忽略了提示词本身的结构问题结果就是不断在同一个坑里打转。在展开具体方法之前我想先纠正一个特别常见的认知偏差。很多人把提示词当成咒语觉得只要找到那句神奇的话模型就会乖乖听话。实际上提示词更像是一份工作说明书——你给一个刚入职、能力很强但完全不熟悉你业务的同事派活你会怎么写这份说明你会说清楚背景、目标、约束、输出格式、参考样例。提示词也是同样的逻辑。把它当成沟通问题而不是玄学问题心态就对了。2. 提示词的基本骨架四个必须交代清楚的要素2.1 角色、任务、约束、格式这四件套一份能稳定工作的提示词通常包含四个基本要素。我把它们称为四件套角色设定、任务描述、约束条件、输出格式。缺了任何一个模型都可能在某个维度上跑偏。角色设定解决的是以什么身份回答的问题。比如你是一名资深数据分析师和你是一名刚入门的实习生同样的任务输出的专业度和措辞会明显不同。角色不是装饰它会实际影响模型调用哪些知识和表达习惯。任务描述解决的是要做什么。这里最容易犯的错是任务太模糊。像帮我优化一下这段文字就是典型的模糊任务模型不知道你是要改语法、改风格、还是改长度。正确的做法是把任务拆到可执行的程度比如把下面这段文字改写成面向非技术读者的科普风格控制在200字以内保留所有关键数据。约束条件解决的是不能做什么、必须满足什么。比如字数限制、不能编造事实、必须引用给定材料、语气要求等。约束是保证输出可控的关键尤其是涉及事实性内容时必须明确告诉模型只使用我提供的信息不要自行补充。输出格式解决的是结果长什么样。是纯文本、Markdown表格、JSON、还是分点列表格式约定得越清楚后续程序化处理的成本就越低。做应用开发时格式约定几乎是刚需因为你要拿模型的输出去对接下游代码。2.2 一个可以直接抄的基础模板把四件套组合起来就是一个可复用的基础模板。我平时最常用的结构是这样的# 角色 你是一名[具体身份]擅长[具体能力]。 # 任务 请根据以下输入完成[具体任务]。 # 输入 [待处理的内容] # 约束 1. [约束一] 2. [约束二] 3. 如果信息不足请明确说明不要编造。 # 输出格式 请按以下格式输出 [格式说明或示例]这个模板看起来朴素但覆盖了绝大多数场景。我建议新手先把这套骨架用熟再考虑花哨的技巧。很多人一上来就研究各种高级提示技巧结果连最基本的任务描述都写不清楚效果自然不稳定。提示模板里的分节标题如# 角色不是必须的但加上之后模型对结构的识别会更清晰尤其在长提示词里效果明显。你可以把它理解成给模型划重点。2.3 为什么结构化比堆字数更有效有一种常见的误区是提示词写得越长越详细越好。我实测下来长度和效果并不是正相关。真正起作用的是结构也就是信息之间的组织关系。一段500字但结构混乱的提示词效果往往不如一段200字但层次分明的提示词。原因在于模型处理输入时也在做注意力分配。结构清晰的提示词相当于帮模型提前做好了信息分层它更容易抓住重点。而一大段没有分节的文字模型需要自己去猜哪句是任务、哪句是约束猜错的概率就上去了。我做过一个对比实验同一个信息抽取任务A版本是把所有要求写成一段话B版本是用分节标题拆成角色、任务、约束、格式四块。在几十条测试样本上B版本的字段抽取准确率明显高于A版本而且输出格式的合规率提升更明显。这个实验说明结构化本身就是一种有效的提示技巧而且成本极低。2.4 约束条件的写法把不要换成要写约束时有个小技巧特别管用尽量用正向表述代替负向表述。比如不要编造数据这种负向约束模型有时候反而会被编造这个词带偏。更好的写法是所有数据必须来自我提供的材料材料中没有的信息请标注为未知。正向表述给了模型明确的行动指令而不是让它去规避某个行为。再比如不要写得太长可以改成控制在150字以内只保留最核心的三个要点。后者既给了长度上限又给了内容取舍的标准模型执行起来更到位。这个技巧我在实际项目里反复验证过尤其在需要严格控制输出的场景下正向约束的稳定性明显更好。3. 从零样本到少样本什么时候该给例子3.1 零样本提示的适用边界零样本提示就是不给任何例子直接描述任务让模型完成。它的优点是提示词短、编写快适合任务本身足够常见、模型已经见过大量类似情况的场景。比如把下面这句话翻译成英文给这段文字起三个标题这类任务模型训练时见过太多零样本就能做得不错。但零样本有个明显的边界当任务涉及你特定的业务规则、特定的输出风格、或者比较冷门的领域时光靠描述往往不够。模型会按它理解的通用做法来输出而这个通用做法可能和你的预期差很远。这时候就需要引入例子。判断要不要给例子我有个简单的标准如果这个任务换一个新人来做光看我的文字描述能不能做对如果连人都需要看几个样例才能理解那模型大概率也需要。3.2 少样本提示里例子怎么挑少样本提示就是给几个输入输出示例让模型照着模仿。这里的关键不是例子数量而是例子的质量。我总结了几条挑例子的经验第一例子要覆盖典型情况而不是全挑简单的。很多人喜欢挑最好处理的例子结果模型遇到稍微复杂一点的情况就懵了。正确的做法是让例子覆盖你实际会遇到的主要类型包括那些容易出错的边界情况。第二例子之间要有区分度。如果三个例子几乎一模一样那给一个就够了多给反而浪费上下文。例子的价值在于展示不同情况该怎么处理。第三例子的格式必须和你要的输出格式完全一致。模型是极强的模仿者你例子里怎么写的它就怎么输出。如果例子里字段顺序是A、B、C你期望的输出也是A、B、C那就别在例子里写成B、A、C。3.3 例子顺序会影响结果这一点很多人不知道少样本提示里例子的排列顺序会实际影响模型的输出倾向。模型对靠后的例子往往更敏感也就是所谓的近因效应。如果你把最重要的、最希望模型模仿的例子放在最后效果通常会更好。我在一个情感分类任务里验证过这个现象。同样的三个例子把最典型的正面案例放最后模型对正面样本的识别就更准把负面案例放最后负面识别就更准。所以当你的任务有明确的倾向性时可以把最希望模型学会的那类例子放在末尾。注意这个技巧不是万能的它更像是一种微调手段。如果例子本身质量不行调顺序也救不回来。先把例子选对再考虑顺序优化。3.4 例子太多反而会拖后腿少样本不是越多越好。我见过有人一口气塞十几个例子结果模型开始过拟合这些例子遇到稍微不同的输入就硬往例子的模式上套。而且例子太多会占用大量上下文留给实际任务的空间就少了。我的经验是大多数任务三到五个例子就够了。如果发现效果还不理想优先检查例子的质量和覆盖度而不是继续加数量。真正复杂的任务与其堆例子不如考虑把任务拆成多个步骤每一步用简单的提示词处理。4. 让模型想清楚再回答推理引导的实操4.1 直接要答案为什么容易错对于需要推理的任务比如数学题、逻辑判断、多步计算直接让模型给答案错误率往往偏高。原因不难理解模型是逐词生成输出的如果它一上来就写答案等于没有给自己留思考的空间只能靠直觉蒙。这就好比让一个人做复杂计算要求他张口就报答案他大概率会错但如果允许他先打草稿再报答案正确率就上去了。模型也一样你需要给它打草稿的机会。4.2 引导模型分步思考的写法最直接的做法是在提示词里明确要求模型分步推理。比如请先分析题目中的已知条件然后列出解题步骤最后给出答案。 在给出最终答案之前请逐步说明你的推理过程。这种写法能显著提升推理类任务的准确率。但要注意分步推理会让输出变长如果你的场景对响应速度或输出长度有要求需要权衡。还有一种更结构化的写法是要求模型把推理过程和最终答案分开请按以下格式输出 【推理过程】你的逐步分析 【最终答案】简洁的结论这样既保留了推理的收益又方便你后续只提取最终答案部分做程序化处理。做应用开发时这种分离式输出特别实用。4.3 推理引导的常见翻车点分步推理不是没有代价的。我踩过的一个坑是模型在推理过程里编造了看似合理但实际错误的中间步骤最后得出了一个错误答案但因为过程写得很像那么回事反而更难发现错误。所以分步推理提升了准确率但不等于结果一定对关键结论还是要人工复核或交叉验证。另一个坑是有些任务其实不需要复杂推理强行要求分步反而会让模型把简单问题复杂化。比如一个简单的信息抽取任务你让它逐步分析它可能会过度解读文本抽出一些本来不存在的信息。所以推理引导要用在刀刃上判断标准是这个任务是否真的需要多步思考。4.4 自洽性检查让模型自己验算一个进阶技巧是让模型在给出答案后自己检查一遍。写法大概是给出答案后请重新审视你的推理过程检查是否存在计算错误或逻辑漏洞。 如果发现问题请修正并给出最终答案。这个技巧在数学和逻辑任务上效果不错相当于让模型做了一次自我复核。但它也有局限如果模型第一次就理解错了题意自我检查往往也发现不了因为它是在错误的前提下检查的。所以自洽性检查是锦上添花不是万能药。5. 输出格式控制让结果能被程序直接消费5.1 为什么格式控制是应用开发的生命线做Demo的时候模型输出一段自然语言人看着舒服就行。但一旦进入真实应用模型的输出往往要对接下游代码这时候格式的稳定性就成了刚需。我见过太多项目卡在模型输出格式时对时错上最后不得不加一堆正则去兜底维护成本极高。格式控制的目标是让模型的输出可预测、可解析。理想情况下你拿到输出后不需要任何清洗就能直接解析成结构化数据。5.2 用JSON约束输出的实操JSON是最常用的结构化格式。让模型输出JSON关键是把schema写清楚。比如请以JSON格式输出包含以下字段 - name: 字符串人名 - age: 整数年龄 - skills: 字符串数组技能列表 只输出JSON不要添加任何解释性文字。这里有两个细节很重要。一是明确字段类型模型对整数数组这类类型描述是有感知的。二是强调只输出JSON否则模型很可能在JSON前后加一句好的以下是结果导致解析失败。即便如此模型偶尔还是会输出不合法的JSON比如多一个逗号、少一个引号。所以生产环境里解析失败的重试机制几乎是标配。我的做法是解析失败时把错误信息和原始输出一起回传给模型让它修正。这个纠错重试的循环能解决绝大多数格式问题。5.3 表格和列表格式的取舍不是所有场景都需要JSON。如果输出是给人看的Markdown表格或分点列表往往更合适。表格适合展示多字段的对比信息列表适合展示并列的要点。选择格式时先问自己这个输出接下来给谁用给人看优先可读性给程序用优先可解析性。两者兼顾的场景可以考虑先输出JSON再由前端渲染或者输出Markdown表格再由程序解析。我个人的偏好是能用JSON就用JSON因为它的解析最稳定可读性问题交给展示层解决。5.4 格式约束失效时的排查思路当模型不遵守格式时别急着换模型先按这个顺序排查第一检查格式说明是否足够明确。很多时候不是模型不听话而是你的说明有歧义。比如你说输出一个列表模型不知道你要有序还是无序、要不要编号。第二检查例子的格式是否和你要的一致。如果你给了例子但例子的格式和文字说明有出入模型会优先模仿例子。第三检查提示词里有没有相互冲突的要求。比如你一边要求详细解释一边要求只输出JSON模型就会纠结最后可能两边都不满足。第四考虑用更强的格式约束手段比如在提示词末尾再强调一次格式要求或者用系统提示词单独约定格式。6. 提示词调试把玄学变成可复现的工程6.1 建立自己的测试集提示词调试最大的敌人是凭感觉。改了一版提示词试了一两个例子觉得不错就以为优化成功了结果上线后各种翻车。要避免这个问题必须建立一个小型测试集。测试集不需要很大十几到几十条就够但必须覆盖你实际会遇到的主要情况尤其是那些容易出错的边界情况。每次修改提示词都在这套测试集上跑一遍对比修改前后的表现。这样你的优化才有依据而不是靠运气。我自己的习惯是给测试集里的每条样本标注期望输出这样对比起来更直观。对于开放式任务期望输出可能不唯一那就标注关键要点只要模型覆盖了这些要点就算通过。6.2 一次只改一个变量调试提示词时最忌讳一次改好几个地方。比如你同时改了角色设定、加了例子、又调整了格式要求结果效果变好了你根本不知道是哪个改动起了作用。正确的做法是一次只改一个变量观察效果变化。这样虽然慢一点但每一步的因果关系是清楚的积累下来的经验才可靠。这个原则和做实验是一样的控制变量才能得出有效结论。6.3 记录每次修改和结果我强烈建议养成记录的习惯。每次修改提示词都记下改了什么、为什么改、测试结果如何。这些记录积累起来就是你自己的提示词经验库。下次遇到类似问题翻一翻记录就能找到方向不用从头试错。记录不用很复杂一个表格就够了版本修改内容测试通过率备注v1基础四件套70%格式偶尔出错v2增加JSON格式说明85%格式问题基本解决v3补充两个边界例子92%边界情况改善明显这张表看起来简单但坚持记录几个月你对提示词的理解会有质的飞跃。6.4 常见失效模式与对应策略调试久了会发现提示词失效其实就那么几种模式。我把最常见的几种和对应策略整理如下失效模式典型表现应对策略任务理解偏差输出方向完全不对把任务描述拆得更细补充背景格式不合规输出结构时对时错强化格式说明增加纠错重试内容编造出现材料中没有的信息明确约束只用给定材料要求标注未知过度发挥输出远超预期长度给出明确长度上限和取舍标准忽略约束某些要求没执行把关键约束放在靠后位置或单独强调这张表是我踩了无数坑之后总结出来的基本上覆盖了日常调试中八成以上的问题。遇到失效时先对照这张表定位类型再针对性处理比盲目改提示词高效得多。7. 把提示词用进真实项目几个实战心得7.1 系统提示词和用户提示词的分工在真实应用里提示词通常分两层系统提示词和用户提示词。系统提示词设定全局的角色、规则和格式要求用户提示词承载具体的任务输入。这种分层的好处是系统提示词可以固定下来复用用户提示词只关注变化的部分。我的经验是把稳定的、全局性的要求都放进系统提示词比如你是一个严谨的助手不确定的信息要明确说明。把具体的、每次变化的任务放进用户提示词。这样既保证了行为的一致性又保持了灵活性。7.2 长上下文场景下的信息组织当输入材料很长时怎么组织信息就成了关键。一个常见的坑是把长材料直接塞进提示词然后任务描述放在最后结果模型看了后面忘了前面。更好的做法是把任务描述和关键约束放在材料的前后两端形成首尾呼应中间放材料。这样模型在开始和结束处理时都能看到任务要求不容易跑偏。另外长材料里如果有多个部分最好用清晰的分隔符隔开比如用### 材料一### 材料二这样的标记。模型对分隔符是敏感的清晰的分隔能帮它准确定位信息。7.3 提示词版本管理提示词是会不断迭代的所以版本管理很重要。我见过团队把提示词硬编码在代码里改一次就要发一次版非常痛苦。更好的做法是把提示词抽出来单独管理用配置文件或专门的提示词管理工具改提示词不用动代码。如果条件允许还可以给提示词加上版本号和变更记录方便回溯。当线上效果出现波动时能快速定位是不是某次提示词改动引起的。7.4 别忽视成本和延迟提示词越长消耗的token越多成本和延迟都会上升。做实验时可能不在意但上线后这就是真金白银。所以优化提示词时除了看效果也要看成本。有时候一个更短的提示词能达到差不多的效果那就没必要用长的。我的做法是先追求效果把提示词写充分效果达标后再逐步精简去掉那些对结果影响不大的部分。精简的过程中持续用测试集验证确保效果没有明显下降。8. 一些容易被忽略的细节和我的个人习惯写到这里主体方法基本讲完了。最后分享几个我在实践中总结的细节都是那种文档里不会写但实际很管用的经验。第一个细节是关于标点符号的。中文提示词里全角和半角标点混用有时会影响模型的理解尤其是涉及代码或结构化内容时。我的习惯是自然语言部分用中文标点代码、字段名、格式说明部分用英文标点保持内部一致。第二个细节是关于否定词的。前面提过尽量用正向表述这里再补充一点如果实在要用否定把否定词放在句首强调比如禁止编造任何未提供的信息比信息不要编造更有效。模型对句首的指令更敏感。第三个细节是关于温度的。虽然温度是模型参数不是提示词但它和提示词效果密切相关。需要稳定输出的任务温度调低需要创意发散的温度调高。很多人调提示词调半天其实调一下温度就解决了。第四个细节是关于测试的心态。提示词调试是个反复的过程不要指望一次就写出完美的提示词。我现在的习惯是任何提示词都先写个粗糙版本跑起来然后根据实际输出不断迭代。先跑通再优化比憋大招高效得多。第五个细节是关于积累的。我有个习惯看到好的提示词写法就随手记下来不管是别人的分享还是自己偶然试出来的。时间长了这些碎片就拼成了一套自己的方法库。Prompt工程这东西理论看再多不如自己动手改几十版来得实在。这套笔记里的方法都是我在实际项目里反复用过、验证过的。它们不是什么高深的理论但每一条背后都有具体的踩坑经历。如果你刚开始学Prompt工程建议从第二章的四件套模板入手先把基础打牢再逐步尝试后面的技巧。如果你已经有一定经验可以重点看看调试和实战那两章那里面的排查思路和记录方法可能比具体技巧更有长期价值。
阅读完成 · 觉得有帮助？
