聊一个我天天在用的东西提示词工程。同样一个模型有人一句话就能拿到能直接用的结果有人来回磨了十几轮拿到的还是一堆正确的废话。这个差距99%出在提示词上而不是模型本身。这篇文章我想把这两年自己在项目里反复验证过的10个提示词技巧连同那些我随手存下来的模板一起整理出来。这些不是理论推演全是实际用过、改过、排过雷的东西。不管你是刚接触提示词工程的新手还是已经被各种花式提问绕晕的普通用户只要你需要和大模型打交道这篇文章就能让你少走不少弯路。1. 提示词工程的核心认知与设计逻辑1.1 提示词工程真正解决的问题是什么很多人以为提示词工程就是把问题问得详细一点这个理解太表面了。大模型本身是一个基于海量文本训练出来的概率模型它给出的每一个词都是在预测在这个上下文里下一个词最该出现什么。也就是说它不是在理解你的需求它是在猜你的需求。你给的文字内容越清晰、边界越明确它猜对的概率就越高。所以提示词工程解决的核心问题其实是三个输出质量的稳定性、输出格式的可控性、以及一次对话的可用性。我自己的体感是如果拿一份表意模糊的提示词去问模型可能十次里只有两三次能碰运气出好结果但一份结构完整的提示词几乎每次都能得到70分以上的输出剩下不够好的部分再微调两句就行。这里我拿做饭打比方。同一个锅、同样的食材有人做出来就是家常味有人做出来就是米其林摆盘。差别不在锅而在对火候、顺序、调料的控制。提示词就是你对大模型的火候控制和放盐顺序。你放多放少、先放后放直接决定成品。1.2 好提示词的三层结构角色、任务、约束我自己写提示词有个习惯不管你是什么场景凡是高质量的输出提示词里一定包含这三层信息第一层角色。让模型以一个什么身份来思考和表达。比如你是一名从业十年的数据分析师和你是一个刚入行的实习生同样的问题输出的措辞、深度、结构完全不同。大模型在海量语料里见过无数种身份的表达方式你给了身份它就会自动对齐这个身份的语言体系。第二层任务。你希望它做什么这一步要写得像给外包需求文档一样明确。明确不是帮我分析一下数据而是请你基于我提供的数据找出转化率下降的主要原因并按影响程度从高到低排列。这个任务描述中动作、对象、目标、输出顺序必须全部说清。第三层约束。限定它不能做什么、输出成什么样。比如字数限制、必须用Markdown表格、禁止使用专业术语的解释、不要分点直接给结论等。约束不只是限制它更大的作用是帮模型缩小搜索空间把可能跑偏的范围圈起来让答案更集中。这三层不是需要你每一次都写全但当你发现输出不理想时回看提示词八成是某一层缺失了。我排查提示词问题第一件事就是检查这三个部件有没有少。1.3 为什么同样一个模型你能拿到的结果天差地别有一个现象特别有意思同一个模型同一个问题不同人问出来的结果完全不一样。这不是玄学是提示词在起作用。你给模型的上下文越完整它越能准确匹配到你想要的那个答案空间。相反如果你的提示词只有问题模型就只能靠猜测来补全所有缺失的信息那结果自然千奇百怪。我常跟朋友说和大模型对话你要把它想象成一位能力很强但没有读心术的新同事。你安排任务时讲得越具体它的执行力越强你只说一句这个东西你看着办它就只能给你一个平均水平的答案。所以那些用得好的人不是运气好而是他们在心里自动把这一套上下文补全了。2. 提示词工程实战10个立刻能上手的技巧2.1 角色设定法给模型装一个专业大脑这是我最先推荐掌握的技巧简单、见效快几乎所有场景都适用。用法就一句话在对话开头给模型一个明确的角色定义而不是让它无身份泛泛回答。来看对比。你直接问帮我写一封催客户付款的邮件模型可能给你一封礼貌但毫无力度的模板。但如果你说你是一位经验丰富的销售总监擅长用温和但坚定的语气催收账款请帮我给一个拖延了30天、合作关系良好但资金周转出现困难的客户写一封催款邮件目标是既不伤和气又能让对方给出明确的付款时间。这封邮件的质量会完全不一样。为什么有效因为当角色定义越具体模型调用的语料范围就越聚焦。它会自动模拟这个角色应有的语言风格、知识结构和表达习惯。我做项目管理时会把角色设定写得很细比如你是一位有十年全栈开发经验、参与过大型系统重构的技术负责人而不是简单一句你是程序员。角色的背景越详细输出的专业深度就越接近这个段位。进阶用发是角色背景目标三段式。把当前所处的情境也交代给模型比如客户是谁、双方什么关系、事件的前因后果它就能在角色的基础上围绕背景和目标组织语言回答的贴合度会再上一个台阶。2.2 示例引导法给模型一个模仿的样板大模型最擅长的事情之一就是模仿。你给它一两个优质样例它会顺着你给的样例格式、词汇密度、句式结构往同样的方向输出。这个方法在业内叫Few-shot提示也就是少样本学习。实操中的做法是在提示词里放1到3个输入—输出的示例。比如我要模型帮我提取简历里的关键字段我不会写请提取姓名、年龄、工作经验而是给他一个真实的示例输入张三男2015年毕业于XX大学计算机专业毕业后在A公司做了两年Java开发负责订单系统的维护随后跳槽到B公司担任技术主管。 输出 姓名张三 学历本科 专业计算机 工作年限9年 最近职位技术主管 核心技能Java、系统维护、团队管理给了这个示例后模型在处理其他简历时输出的字段和格式都会对齐示例。这里有个很重要的经验示例的质量决定了输出的质量。你给的示例本身是粗糙的那模型学到的就是粗糙的风格你把示例打磨得精炼它后续产出的内容也会精炼很多。我建议示例数量控制在2到3个太多反而会让模型只机械模仿而忽略你真正想处理的新问题。2.3 步骤拆解法让模型一步一步思考这个技巧在处理复杂问题时非常管用。大模型有个特点你让它一步到位给出最终答案它往往会在中途省略关键推理环节直接跳到结论结论的质量就不稳定。但如果你要求它把推理过程一步一步展开它的准确率和逻辑完整性会明显提升。最经典的用法是在提示词末尾加上一句请一步一步思考并把关键推理步骤列出来。不要小看这一句它本质上是在告诉模型我需要完整的过程而不是跳跃的结论。模型在按步骤输出时每走一步都会重新校正一下当前的状态等于给自己加了多道检查锁。举个例子我让模型帮我做一份季度复盘分析报告。我不说帮我写个复盘而是说请按以下步骤处理第一步把本季度的核心数据和目标进行对比第二步找出差距最大的三个指标分析可能的原因第三步针对每个原因提出一条可执行的改进措施第四步用结论先行的结构输出最终报告。这样把大任务切成四段每段模型都有明确的着力点输出的报告逻辑性和深度都会好很多。这里要提醒一点步骤不要碎片化4到6步是体验最好的区间。步骤过多模型容易在中间某一步开始跑偏而且输出会变得冗长步骤过少又起不到拆解的作用。2.4 格式约束法输出前先画好格子模型默认的输出风格是自然段落但很多时候我们需要的是表格、列表、JSON或特定结构的文本。如果你不明确告诉它格式它就会按自己的习惯随手写。解决的办法就是主动指定输出格式把格子画好让它往里填。我最常用的格式约束是这几类表格格式适合对比分析、数据整理、排期规划。提示词里写明用Markdown表格输出并指定列名。模型就会自动把信息分门别类填进格子。列表格式适合步骤说明、要点总结。写明用有序列表每项不超过20字。结构化代码格式适合需要程序解析的场景写明输出为JSON格式包含name、age、items三个字段。段落格式适合文章、邮件等连贯性内容。写明每段不超过5行段落之间用空行分隔。在实际项目中我经常把格式约束和模板一起使用让模型在指定框架内填充内容。这样做最直接的好处是多轮的输出之间格式高度一致后处理成本大幅降低。你要是做过批量内容生成就会明白这件事有多香。2.5 反面约束法明确告诉模型不做什么大多数人在写提示词时只关注要什么却忘了说不要什么。反面约束的价值在于它能够剔除那些看着没错、但不符合要求的输出。模型其实很像一个非常配合但有时过于灵活的助理你不说不要什么它就会按最常规的方式给你输出的东西。举个例子我写小红书文案的时候禁止项是这样的不要用首先其次最后这类过渡词不要用亲宝子等过度亲昵的称呼不要出现绝绝子yyds等网络流行语不要写超过3行的开头铺垫。这几个负面约束一加文案的风格立刻从AI味模板变成了真人分享。反面约束的写法有一些窍门。第一要具体不要写空泛的请写得自然一点而是直接列出你不想要的措辞和表达方式。第二数量要适度3到5个负面约束比较合适写太多模型容易混乱。第三把重要约束放在后半部分模型对提示词后半段内容的记忆会更清晰。2.6 分步交互法像带新人一样分阶段推进很多人拿到一个复杂任务恨不得一口气把整个需求都倒给模型让它一把输出所有东西。结果模型消化不了那么多信息输出又乱又浅。我现在的习惯是把复杂任务拆成多轮对话每一轮只处理一个阶段性目标确认好前面一步的结果再继续下一步。举个我常做的案例。我让模型帮我策划一场线下活动的方案。我不会让它直接输出完整方案而是分三步第一次只让它输出活动主题和核心创意提供三个选项我从中选一个第二次让它在选定主题的基础上列出活动流程框架第三次把流程细化成包含时间、环节、负责人、物料的执行清单。这种做法的好处有很多层。最重要的一点是每一轮的输出都能作为下一轮的输入模型对需求的理解会更深入不会出现开头说了A需求、写到最后变成B风格的情况。而且我可以在中途纠偏不会等模型把所有内容都生成完才发现方向不对那时候返工成本就高了。分步交互法唯一的代价是多花几轮对话但换来的是结果可控这笔账怎么算都划算。2.7 关键词强化法用指令词锁定重点所谓关键词强化就是在提示词中主动使用一些有强约束力的指令词把模型的注意力引向特定内容。常用的指令词包括重点强调必须包含禁止遗漏优先考虑忽略。这些词本质上是在给模型划重点让它知道哪些信息权重更高。我在做产品需求文档的时候会这样用请输出一份PRD必须包含以下部分用户场景、功能清单、优先级划分、验收标准。优先考虑上线成本最低的方案。忽略品牌声量因素只关注功能落地效率。这里必须包含定义了文档的骨架优先考虑定下了主次忽略排除掉干扰项。模型在组织输出时就会围绕这几个关键词分配内容重心。再分享一个细节关键词不要淹没在长段文字中间最好单独成行或者用一句清晰的指令收尾。比如在提示词最后另起一行写重点强调这个方案的关键成功标准是转化率提升20%所有建议都必须围绕这个目标展开。模型对提示词末尾的内容留意度很高这个位置放核心要求效果立竿见影。2.8 多轮迭代法把提示词当成需要调试的代码没有哪条提示词是第一次写就完美的。我在实际使用中反复提醒自己提示词不应该是我提问它回答的静态过程而是一个需要不断调试和迭代的动态过程。第一版输出不满意就回到提示词里改而不是无限追问同一个问题。改的时候有个重要原则一次只改一个变量。假如你同时改了角色设定、格式约束、背景补充模型输出变化了但你根本不知道是哪个改动在起作用。正确的做法是列出一份初始提示词跑一遍输出不满意就只调整一处——比如把角色写得更细再跑一遍如果还没到预期再换另一个变量比如增加一个负面约束。每次只动一个点才能建立提示词改动—输出变化之间的对应关系。我自己的习惯是给常用提示词建一份迭代记录表记录下每个版本的提示词、遇到的问题、输出质量等级。这样调着调着就能找到针对某个场景最稳定有效的那版提示词。这个习惯前期看起来有点麻烦但长期积累下来的模板库就是你最宝贵的提示词资产比任何网上抄来的模板都好用。2.9 上下文打包法一次把背景信息给齐模型在回答你的问题之前能掌握的信息完全来自对话上下文。你在提示词里给的背景信息越齐全它就越能给出贴合你实际情况的方案。很多人抱怨AI给的答案太通用没有针对性80%的原因就是提示词里缺少足够的具体背景。我总结了一套上下文打包五要素目标是什么、当前状况是什么、目标受众是谁、有什么资源和限制、期望输出是什么。每次写重要提示词时我都会在开头把五要素列一遍。比如我在做季度营销规划时会这样写我们是一个面向中小企业提供SaaS工具的产品团队当前季度新增用户3000人、付费转化率2.5%预算20万目标是Q3结束前付费转化率提升到4%。请基于这些信息制定一份营销规划包含渠道组合、预算分配、阶段目标。这段提示词里几乎没有废话每一句都在给模型喂有效信息。模型拿到的背景越细给出的方案就越贴合真实情况。五要素哪怕缺一个输出的针对性都会打折扣这个我在无数次实践中反复验证过。2.10 指令权重法用编号和顺序控制重点排序最后一个技巧我把它叫做指令权重法。它利用的是模型对提示词中内容顺序和编号的敏感度。放在靠前位置的内容模型会理解为高优先级单独成行、用编号列出来的要求模型会认为每一条都必须遵守。这个方法特别适合处理多重要求并存的场景。比如我自己写会议纪要总结的提示词是这样的请按以下要求整理会议纪要 1. 输出格式使用Markdown包含结论决议待办事项三个部分。 2. 优先级待办事项部分必须明确负责人和截止日期。 3. 风格每条决议不超过40字。 4. 终极目标让没参会的人读完纪要也能完全掌握会议全部关键信息。四个编号从格式到细节再到核心目标模型会把每一行都当成独立的子任务去完成而不是混在一起变成一团。特别是最后一条终极目标它起到了托底的作用即使前面几条模型执行得有点偏差最后它也会围绕没参会的人也能看懂这个方向去做整体调整。3. 提示词模板库拿来即用的场景配方3.1 通用写作模板这个模板适合公众号文章、博客、工作汇报等一切需要成稿的写作场景。核心逻辑是先定风格再给素材最后约束结构。角色你是一位擅长把复杂内容写得通俗易懂的内容创作者。 任务请基于我提供的素材写一篇面向[目标读者]的文章。 素材[粘贴你的素材内容] 要求 1. 标题要包含核心卖点控制在20字以内至少给3个备选。 2. 开头3句话内勾住读者兴趣不使用随着近年来这类套话。 3. 正文用小标题分成至少4个部分每部分逻辑独立。 4. 语言自然避免形容词堆砌不用赋能抓手等空词。 5. 结尾给出一个明确的行动建议。这个模板我每次用都会针对不同平台微调约束条。比如发小红书时我会加一条每段不超过3行多用换行写工作汇报时我会把第3条改成先结论后论据每部分不超过300字。3.2 编程辅助模板写代码、debug、技术方案设计这三个场景我都沉淀了对应的提示词模板。最常用的是代码生成这一版角色你是一位有多年[语言]开发经验的资深工程师熟悉工程化最佳实践重视代码可读性和稳定性。 任务请实现[功能描述]。 附加信息 - 运行环境[操作系统、语言版本、相关框架版本] - 输入数据格式[字段说明/示例] - 期望输出格式[返回值结构/接口定义] 代码要求 1. 先说明实现思路再贴代码。 2. 关键逻辑必须写清楚注释。 3. 错误处理要完整不能只顾正常路径。 4. 不允许使用已废弃的API。 5. 代码命名遵循[命名规范]。我把这个模板里的角色设定得越接近当前项目背景代码质量越高。比如加上熟练使用Python3.10和FastAPI这一句模型在选型时就会直接按这个技术栈来写而不是给你一堆需要二次修改的通用代码。技术方案设计类任务同理只需要把任务从实现改成输出技术方案文档再把附加信息换成现有系统架构、性能瓶颈、期望达到的效果一套模板可以复用出很多变体。3.3 数据分析与决策模板平时做数据分析需要模型帮忙解读数据的时候我习惯用下面这个结构。它的核心是把怎么看数据前面的业务背景全给足让模型先理解了业务的来龙去脉再来分析数据否则数字只能变成空洞的罗列。角色你是一位业务数据分析师熟悉[行业]常见的业务指标体系和归因分析方法。 任务请对以下数据进行深度解读并给出可落地的业务动作建议。 数据背景[说明数据来自哪个业务环节统计口径如何] 当前数据 [粘贴数据或表格] 分析要求 1. 先总结关键发现按重要程度排序。 2. 对异常指标做根因分析区分外部因素和内部因素。 3. 给出至少3条可执行的增长建议每条建议必须说明预期影响和所需资源。 4. 涉及同比环比时必须标明基数不许只写增减幅度。 5. 用数据表现—原因分析—行动建议三段式组织输出。用这个模板时最要紧的是把数据背景写准确。比如这组数据是日活还是周活、统计口径是去重还是按设备计算这些不写清楚模型可能默认按它理解的逻辑来分析最后结论满天飞落不了地。3.4 总结提炼模板总结类任务比如读文章提炼要点、长材料整理摘要、会议纪要归纳我用下面这个模板。它的特点是强制了输出结构让总结出来的内容可以直接复用。角色你是一位高效的文字秘书善于提炼长文的核心信息过滤冗余细节。 任务请总结以下内容的核心要点。 原文 [粘贴原文内容] 总结要求 1. 输出格式核心结论 / 关键论据 / 数据事实 / 行动项。 2. 核心结论不超过50字必须直接回答问题。 3. 关键论据不超过5条每条30字以内。 4. 出现数字和日期时必须保留。 5. 如果原文中有相互矛盾的信息单独列出并说明。这个模板最适合两类用途一是给团队共享的大材料做快速摘要二是给自己留档的参考资料库做定期精简。覆盖不同业务的资料整理需求只要把原文这一段换成不同的内容输出的结构始终统一后续检索非常方便。3.5 头脑风暴创意模板做方案策划、选题规划时我最怕模型给出一堆平庸的常见答案。后来我总结出一套能逼着模型跳出常规的模板核心技巧是注入限制条件减少常见路径。角色你是一位极具创意的策划人擅长在严苛条件下提出出人意料但又可落地的方案。 任务围绕[主题]进行头脑风暴输出10个创意方案。 硬性限制 1. 禁止使用[已用烂的套路比如性价比、官方补贴等] 2. 方案涉及执行成本必须分成高/中/低三档说明 3. 每个方案必须包含一句话的核心创意点、目标人群、预期效果 4. 至少有3个方案是不依赖预算投入、纯粹靠创意驱动的 思维路径要求先分别从产品角度用户角度传播角度思考再交叉融合。实践下来这个模板能把模型从标准答案模式里拽出来一些。尤其是硬性限制那一栏你框得越死它越会被逼到意想不到的角度去找方案。头脑风暴的关键不是立刻拿到完美答案而是用提示词制造更多可能性再从中挑苗子。3.6 翻译润色模板模型做翻译和润色其实远强于多数在线翻译但它默认输出的译文往往很平。要让译文有味道给它的风格指令很重要。角色你是一位精通中文和[目标语言]、对两种语言文化背景都有深入理解的资深译者。 任务翻译以下文本。 原文[待翻译内容] 翻译要求 1. 先给出直译版本再给一个意译版本。 2. 直译版严格忠于原文语义意译版要符合目标语言的表达习惯可以调整语序和句式。 3. 如果原文中有专有名词或文化隐喻用括号注释说明。 4. 对翻译的难点用一句话解释你的处理原因。 5. 最终给出一个在商业场景下可直接使用的推荐版本。这个模板用下来有个明显的好处你不会只拿到一份译文还能看到译者的思考过程。对于需要反复打磨品牌文案、产品介绍的人来说这个直译意译推荐的结构比普通翻译好用太多。4. 常见问题排查与实战避坑4.1 输出太泛泛感觉像正确的废话这个问题在提示词工程里最常见原因几乎都是信息给得太少约束给得太松。模型不知道你的真实场景只能给你一套最通用的逻辑框架。每次遇到这类问题我会系统性地检查三处身份清不清晰、背景全不全、约束够不够。身份不清就补角色设定比如资深产品经理永远比产品经理好用。背景不全就按我前面讲的上下文打包五要素挨个补。约束不够就加负面约束明确告诉模型不要写什么。这三步补完泛泛而谈的概率会大幅下降。4.2 格式输出不稳定同样的提示词格式总变这可能是最让人郁闷的问题。明明上一条提示词模型给出了漂亮的表格第二天再来一次它却用段落输出。原因在于模型给出的输出有随机性格式类要求如果没有在提示词里反复强调就可能被它忽略。我在格式稳定性上总结了两个技巧。第一格式要求重复两遍在提示词开头说一遍输出用Markdown表格在末尾再强调一遍严格按照题目指定的Markdown表格输出。第二在输出格式前加上必须或严格这类强约束词。做了这两步之后格式稳定性有了明显提升。如果还是不稳定就把示例格式直接贴进提示词让模型照葫芦画瓢。4.3 模型一本正经地编造事实幻觉问题目前任何模型都避免不了提示词的改进能降低概率但不能彻底根除。在事实性要求高的场景中我会在提示词里加一条当你不确定具体数据、历史事件或引用时明确回答我不确定不要推测。这一条很关键它给了模型一个诚实的出口否则模型为了满足用户的提问会倾向于生成看起来合理的内容。涉及到具体数字、权威来源的信息我会提示对于无法确认的内容标注为待核实并说明哪些部分需要人工查证。这样输出的内容即使有误差也能在流程中快速被发现而不是被当成事实直接采纳。把这个风险意识写进提示词工程的习惯里能少踩很多坑。4.4 一句话提示词能解决的事别写得又长又复杂和提示词太简单导致输出泛泛相比另一个极端是提示词冗长、嵌套把模型绕晕。我自己早期就犯过这个错一口气写了20行要求结果模型抓不住重点输出反而比简单提示时更难用。现在我的原则是先搭骨架再补肉。第一版提示词先只写角色任务核心输出要求三行跑一轮看基础方向对不对。方向对了再根据不足的地方逐条增加细节和约束。这里我只会针对模型说明书式地逐层加码避免一次投喂过多无关信息。提示词不是越长越好而是相关信息密度越高越好。4.5 常用问题排查速查表症状可能原因排查与解决方案输出太泛泛身份、背景、约束缺失按角色任务约束三层检查提示词缺哪层补哪层格式不稳定格式要求在提示词中权重不够开头和结尾重复强调用必须等强约束词提供格式示例内容编造模型幻觉明确要求不确定就说不确定对数据和引用标注待核实答案太长或太短缺少字数/段落外部约束提示词末尾指定输出长度、段落数、每段行数风格不对用户未指定语气或表达偏好使用角色设定法或反面约束列清想要的与不想要的风格多次追问后跑偏上下文过长、新指令覆盖旧指令分步交互法每轮只聚焦一个目标或直接开新对话重新给提示词一改就到不了预期一次改动多个参数无法定位原因一次只改一个变量建立版本记录对比我自己在实际项目里遇到问题第一步就是拿这个速查表对照很少落空。很多问题表面上看起来是模型不行实际上都是提示词里的某一个环节没照顾到。结尾最后再分享一点我做提示词工程的个人心得别把提示词工程当成一个可以速成的秘技也别指望找到一条万能提示词然后一劳永逸。模型在更新你的任务场景在变化提示词也需要跟着迭代优化。我现在每次在项目中使用新提示词时都会顺手把它保存到一个统一的本子里并标注好使用场景、适用模型、踩过哪些坑。时间长了这个本子就成了我个人最值钱的提示词模板库很多新项目甚至都不用从零开始想提示词直接在这个库里改改就能用。希望这10个技巧和模板能帮你在自己的使用场景里省下一点时间和头发这才是写这篇内容最想达到的目的。