“提示词工程”这个话题被讨论得很多但真正能把提示词写出稳定效果的并不多。我自己在项目里和大模型打交道有一段时间了从最早“请帮我写一篇文章”这种对话式提问到后来把提示词当成一套工程体系来设计最大的感受是好用的提示词不是靠灵感而是靠结构。下面我整理出10类实测过、并且在项目里反复使用的提示词模板每个都附上可直接套用的模板、适用场景和改参方式。无论你是想提升日常写作效率还是正在做模型API的接入和效果调优都可以直接拿去用先稳定跑通再逐步调出你自己的风格。1. 内容整体设计与思路拆解1.1 为什么提示词工程值得被当作“工程”来做大模型本质上是一个概率系统不是搜索引擎也不是传统规则引擎。同一个问题换几个字的措辞输出质量可以天差地别。你可能遇到过这种情况随口问一句“帮我分析一下这个数据”得到一个泛泛而谈的框架但如果你换一种写法明确告诉它“你是一名数据分析师请先给出结论再说明推断依据最后列出数据局限性”输出立刻就不一样了。提示词工程要解决的就是这种“不确定性”。从实际项目角度看提示词工程的核心价值体现在三个层面。第一是稳定性同一个模板换不同的输入内容输出质量能保持在一个可接受的区间而不是时好时坏。第二是可复用性沉淀下来的模板可以跨场景复制不用每次从零开始试。第三是可优化性效果不好时能结构化地定位问题而不是靠“换个说法再碰运气”。这三条只要做到两条产出效率就能拉开明显差距。所以我通常会把提示词按照角色、任务、格式、上下文、约束、综合六类建档管理。分类方法不唯一关键是让自己的模板库有索引。你不会希望三个月后翻回来看发现全是一堆没有标注、没有版本记录的碎片文本那和没做没有任何区别。1.2 模板库的定位不是万能钥匙而是脚手架模板库最容易踩的坑就是把它当成文案生成器复制粘贴一遍就指望得到完美结果。我见过太多人拿别人的模板去套效果不满意立刻得出结论“这模板没用”。实际上模板的作用不是替你做业务判断而是把模型的表达能力稳定地释放出来。它保证的是下限上限还得看你填进去的业务上下文和迭代方式。我个人的使用方法是这样的先拆需求明确要让模型做什么、输入是什么、输出给谁看然后从模板库里匹配最接近的结构替换掉角色和任务字段接着把背景资料、示例、约束条件填进去再观察输出记录哪些位置稳定、哪些位置飘最后把改动过的版本再存回模板库形成版本迭代。这个过程看起来简单但真正坚持做的人不多。模板库是需要“养”的。网上那些通用模板只能保证正确只有你自己在业务场景里反复调出来的版本才能称得上好用。比如同一个写作任务你所在行业的黑话、语气、禁忌这些通通要沉淀进模板里才能让模板真正长在你的业务上。2. 10个可以立刻上手的提示词写法2.1 角色设定一句话框定回答视角你现在是一名[角色]你的特长是[领域]。请以这个身份回答我的问题。你的回答风格要[风格描述比如简洁、专业、口语化]。如果问题超出你的专业范围请直接说明不要编造答案。这是最基础也最常用的技巧。给模型设定角色本质上是告诉它从哪个“知识分布”里取词。让它当老师它会用解释性的语言让它当销售它会更主动地引导。角色描述不是装饰而是一种先验信息会在生成时影响模型的措辞、语气甚至影响它对信息的取舍。我建议角色描述至少包含三个要素身份、领域、风格。身份决定口吻领域决定知识面风格决定表达节奏。比如“你是一名熟悉下沉市场的增长运营”和“你是一名互联网运营专家”前者输出的用户洞察明显更接地气。注意角色和任务要配套只设角色不提任务模型容易“进入角色”却不知道要交付什么。2.2 任务指令把模糊需求拆成可执行步骤我要完成以下任务[一句话描述目标]。请按以下步骤处理 1. 先[提取/收集/整理]相关信息 2. 再[分析/比较/归纳] 3. 最后[输出/总结/建议]。 每一步都要给出明确结果不要跳过。模型对“做这件事”和“按这几步做这件事”的理解差异很大。任务指令模板的核心是把目标拆成过程。对一个复杂请求如果模型直接从输入跳到输出中间很容易漏掉关键环节这也是很多回答看起来“很全但没干货”的原因。举个例子“帮我写一份产品调研报告”这种模糊需求直接问很容易得到大而空的框架。套用这个模板后模型会先锁定竞品范围再对比功能再分析用户评价输出结构自然扎实许多。步骤数量建议控制在3到5步太多模型会开始啰嗦太少约束力又不够。关键是每一步都要有明确的产出物这样你才能在中途检查质量而不是最后拿到一个无法拆解的完整答案。2.3 少样本示例用3个案例校准输出风格请参考下面的示例完成同样的任务。 示例1 输入[内容] 输出[内容] 示例2 输入[内容] 输出[内容] 示例3 输入[内容] 输出[内容] 现在请处理 输入[内容] 输出少样本提示是我自己用得最稳定的技巧之一。它最直接的作用是给模型看到“什么叫做得好”。模型在生成时会对齐你给出的示例结构、措辞和叙事节奏尤其当你在示例里写清输入输出对应关系时它的模仿能力会超出预期。我常拿它来改造模型默认的输出腔调。比如我不希望输出里出现“首先、其次、综上所述”这类连接词那示例里就坚决不出现一个这样的词全部用短句、口语、分段来示范。两个高质量示例就能让模型抓住规律三个更稳。注意示例质量永远比数量重要与其给8个随意写的示例不如精挑3个能覆盖不同情况的示例效果完全不一样。2.4 输出格式控制让模型返回结构化的JSON请分析以下文本并用严格的JSON格式返回结果不要输出任何其他内容。 { 观点: 用一句话概括核心观点, 论据: [支持观点的三个理由], 风险: [可能存在的问题], 建议: 一句话行动建议 } 文本内容如下[内容]如果你在接模型API这类模板几乎每天都会用到。它把模型的输出空间限制在一个固定的数据结构里调用方直接解析JSON就能用省去了处理自由文本的麻烦。更重要的是结构化的输出让自动化的错误检查和重试机制成为可能。实际调试中有一个关键坑模型偶尔会在JSON前后多输出一句“好的以下是结果”之类的废话。解决办法是在模板末尾强调“不要输出任何其他内容”然后把采样温度调到0或接近0稳定度会显著提升。如果偶尔仍然不稳定就在模板里再加一个few-shot示例把期望的JSON结构原样演示一遍让模型照着填字段。这个方法我在生产环境里用了很久基本零事故。2.5 分步思考让复杂问题一步步被拆解请一步步分析这个问题不要直接给结论。先把问题拆成子问题再逐个回答最后基于子问题的答案给出最终结论。 问题[内容]这个方法就是常说的“思维链提示”Chain-of-Thought本质上是把推理过程显式化。模型在给出结论之前先完成一系列中间推理而这些中间步骤能显著提升复杂问题的准确率。原理在于每一步推理都在为下一步提供上下文模型的注意力不会因为问题过于庞大而散掉。我最常使用它的是数学计算和逻辑判断场景。比如“公司要在A方案和B方案里选一个更省钱的方案”直接问模型它经常搞混让它先分别列A方案的总成本、B方案的总成本再比较准确率提升非常明显。需要提醒的是分步思考只适用于存在中间推理的任务翻译一句话、改写一段文案这类任务没必要硬套强行套用只会让模型变得啰嗦输出质量反而下降。2.6 负向约束明确告诉模型不要做什么请完成[任务]。要求 - 不要使用“首先、其次、综上”等连接词 - 不要输出超过[字数]字 - 不要包含[敏感词/特定内容] - 不要编造任何未提供的数据。写提示词时很多人只顾着写“你要什么”忘了写“你不要什么”。模型对指令的理解是概率性的负向约束能直接砍掉一批高概率的错误输出。这就像是给生成过程画了一条边界线在线内它自由度可以很高但碰线的内容一律不允许出现。这个技巧在内容合规场景里尤其重要。比如给教育产品生成内容时加上“不要出现任何商业品牌、不要使用夸大广告词”输出把关压力会小很多。在写作场景里“不要用成语”“不要使用排比句式”这类约束也能明显减少AI味。我会把负向约束放在模板后部的“注意事项”区块里与正向指令分开结构清晰也方便后续维护。如果模型连续多次违规说明光靠“不要”不行还要补充正确的正向示例引导它。2.7 背景注入把上下文“喂”给模型再提问以下是我们公司的背景资料[资料内容]。 请基于以上资料回答用户的问题。如果资料中没有相关信息请直接说“资料中未找到相关信息”不要自行推测。 用户问题[问题]背景注入就是给模型一个“事实锚点”。大模型会产生幻觉很多时候不是它不想说真话而是它不知道在你的语境里什么是“真”。当你把背景资料直接放进上下文模型会优先从这段资料里找答案编造的概率会明显下降。这就是RAG检索增强生成的极简实现。做企业内部知识库问答时这个技巧是刚需。你直接问“我们公司的报销标准是多少”模型只能凭预训练记忆去猜但如果你先把公司制度文档里相关段落贴进去再提问答案才能真正落地。执行时控制好资料长度上下文有窗口上限太长会被截断。我的经验是优先放与问题直接相关的那几段而不是把整份文档全部塞进去既省token又防止无关信息干扰。2.8 迭代追问把不满意结果变成下一轮输入你刚才的回答里[指出具体问题]。 请重新回答。这次请特别注意 1. [优化点1] 2. [优化点2]。 你可以先说明修改思路再给出新版本。很多人把提示词当成一次性的事情写不好就推翻重来这其实是对对话机制的浪费。模型有上下文记忆能力前一轮的输出会成为这一轮的输入你完全可以利用这一点逐步逼近目标。好文案或者好方案很多时候不是一次生成的而是“逼”出来的。我实际干活时常用的链路是这样的第一轮让模型自由发挥看整体方向对不对第二轮要求压缩篇幅、删掉空话第三轮补充具体数据和案例第四轮统一语言风格。每一轮只改一个点别想着一步到位。这个技巧的额外好处是节省成本你不需要每次都写一版全新的长提示词只需要在上一轮基础上做增量修改对话历史本身就是你的提示词资产。2.9 结构化标签用Markdown组织长文本输出请用以下Markdown结构输出[任务内容] ## 问题概述 [内容] ## 核心原因分析 [内容] ## 操作步骤 1. [步骤] 2. [步骤] ## 注意事项 [内容]输出长篇内容时如果不限定结构模型自由发挥的章节顺序经常会突破你的预期。明明你要的是“先把结论放前面”它偏偏给你从背景开始讲起。结构化标签的作用就是把你要的章节骨架先定下来让模型往指定的框架里填内容而不是自由生长。这个模板特别适合写技术方案、周报、复盘文档这类有固定套路的文体。我写技术方案时一定会用这个方式让模型按“背景—目标—方案—风险—计划”输出生成结果基本能直接拿去排版。不过章节数量不要超过6个太多会把内容切成碎片章节之间也容易重复反而降低可读性。2.10 综合万能模板从0到1兜底方案你是一名[角色]擅长[领域]。 任务请完成[任务目标]。 背景资料[相关上下文或数据] 要求 - 输出格式[格式要求如总分总结构、JSON、Markdown] - 风格[风格描述] - 字数[字数范围] - 特别注意[负向约束] 参考示例 输入[示例输入] 输出[示例输出] 请开始处理[用户输入]当你面对一个全新、不熟悉的任务时把角色、任务、背景、格式、风格、约束、示例七个区块全部写清是最稳妥的兜底方案。这个模板解决的是“不知道该用哪个技巧”的问题把所有要素组合在一处让模型在一个相对完整的指令空间内工作。我建议所有模板的核心区块都固定成这个骨架遇到新需求就复制一份然后替换对应内容。第一次使用综合模板时不要追求完美先让输出跑起来再根据实际偏差去调整对应区块。这里有一个小经验模板里的描述尽量用短语而非长难句模型对“简短明确的指令”响应更稳定。长句子包含的约束过多时模型容易顾此失彼丢三落四。3. 实操过程用模板库跑通一个公众号改写案例3.1 场景设定与模板选型挑一个最常见的场景做全流程演示把一段产品功能描述改写成适合公众号推送的文案。原始素材大约100字目标输出600到800字的公众号段落。先做需求拆解角色公众号内容编辑面向品牌年轻用户任务改写并扩写产品文案输入原始产品描述输出风格轻快、有卖点、有说服力的推广文案约束不夸张、不AI腔、不超过指定字数。对应模板库核心选型是2.10的综合万能模板。我把它替换成这个任务的字段同时追加两个负向约束一个是“不要使用‘首先/其次/总之’这种连接词”另一个是“不要出现电商平台专用的夸张用语”另外补了一条少样本示例用来展示期望的改写风格。3.2 完整调用与参数调整过程我实际提交的完整模板是这样的你是一名公众号内容编辑擅长把枯燥的产品描述改写成生动、有吸引力的推广文案。 任务请根据以下原始描述改写为一篇适合公众号推送的短文案。 原始描述 [产品描述文字] 要求 - 全文控制在680到800字之间 - 风格轻快、口语化读起来像朋友推荐而不是官方播报 - 开头要有场景感先讲用户痛点再引出产品 - 突出产品的三个核心卖点每个卖点配一个使用场景 - 结尾给一句自然的行为引导 - 不要使用“首先、其次、综上所述”等连接词 - 不要出现夸大宣传的词语。 参考示例 原始描述这是一款保温性能很好的不锈钢水杯。 改写示例早上倒进去的热水到下午三点还烫嘴。这杯子像个迷你暖水瓶通勤路上喝一口整个人都缓过来了。 请开始改写。实际调用时温度参数要调整。做创意型改写我会把温度调到0.7到0.9让表达更多样但如果同一轮生成中还有事实性内容需要保持准确温度最好控制在0.5左右取一个平衡点。通过API提交时max tokens要给足800字的中文输出至少需要配1200个token否则会在句子中间被硬生生截断。我跑这个案例时第一轮输出只有400多字比要求的680到800字明显偏短。原因是模板里的“参考示例”本身很短模型倾向于对齐示例篇幅。发现问题后我在参考示例后面追加了一句“示例只是风格示范篇幅需要达到任务要求”第二轮输出就稳定在750字左右。这个调整过程看起来很小但正是模板迭代最典型的场景不是模板没用而是某个细节没对齐。3.3 结果评估与迭代方法评估模型输出时我不会只看“字数对不对”而是按四个维度打分信息完整性原始素材里的关键卖点有没有全部覆盖风格一致度有没有出现“AI腔”的连接词或空洞表达场景匹配度是不是真的按公众号推文的方式开篇、展开、收尾可用性拿掉小标题和格式后直接发到读者群里是否自然。如果某一项不达标就回到模板里改对应区块。风格不对补负向约束或示例字数不对改篇幅说明卖点不全就把“突出三个核心卖点”改成“先提取卖点清单再依次展开”。每一次改动都记录下改了哪个区块、为什么改下一次遇到同类任务直接复用优化后的版本。长期积累下来这个模板会越来越贴合你的业务场景而不是停留在“通用但不出彩”的水平。4. 常见问题与排查技巧实录4.1 提示词“失效”的5个典型原因现象典型原因排查方法模型答非所问任务描述模糊角色与任务不匹配把任务前置用“请完成[具体动作]”开头输出格式混乱没有明确“不要输出其他内容”在模板末尾加一句“只输出上述格式的内容”生成内容过短参考示例篇幅太短模型对齐示例长度增加篇幅说明补一条符合目标长度的示例风格AI味重没有负向约束也没有风格示例追加“不要使用”清单再给一个期望风格的示例事实经常编造没有提供背景资料把相关资料放进上下文并注明“没有资料就直说”这5个原因覆盖了我遇到过的绝大多数“模板没用”的情况。排查思路其实很固定先看任务目标是不是一句话能说清再看格式和风格是否已经约束最后检查上下文和示例有没有给到位。按这个顺序逐项检查基本都能定位到问题。4.2 我踩过的坑三条独家经验笔记第一条温度参数和提示词是配合使用的不是调大就一定“更有创意”。同一个提示词温度从0调高到0.9输出会从“稳定但保守”变成“多样但容易跑偏”。如果你既想要稳定又想要多样性正确做法不是盲目调高温度而是把提示词里的风格描述写得更细让模型在约束范围里发挥。第二条你每次在聊天界面里手动优化的过程都应该回填到自己的模板库里。很多人的模板库实际上是“收藏夹”收藏了从别处抄来的模板从来不做迭代。真正好用的模板库应该是“版本库”每个模板都带着几轮调整记录比如“v1偏短追加篇幅要求后正常”“v3加入负向约束后风格明显改善”。长期积累下来这份库就是你最大的私房资产。第三条如果模型连续几次出现同样的错误不要继续在对话里周旋回到提示词本身去改。有人习惯在对话里反复说“不对再改改”这种方式成本很高对长任务来说还会占用大量上下文空间。更高效的做法是终止当前对话在模板里把问题对应的约束补上再开一个新对话重新生成。你修改的是“工程”而不只是和模型“聊天”。我自己整理模板库时坚持一条很简单的原则任何模板如果三个月后我打开来看还需要费力回忆它为什么这么写那它就不合格。所以每个模板里顺手记一句“当初是为了解决什么问题而建”这句话在项目交接和新场景选型时尤其有用。提示词工程说到底不是咒语而是一套可以不断沉淀的方法论你投入的每一轮调试最终都会变成可复用的资产。
