很多人用大语言模型觉得它“时灵时不灵”同一个问题换个说法结果就天差地别。这背后的差别往往不是模型本身的问题而是提示词写得好不好。提示词工程Prompt Engineering说白了就是一套跟大模型高效沟通的方法论。它不是玄学也不是靠运气而是有明确套路、可拆解、可复现的技术活。这篇文章我就围绕“提示词工程怎么写才有效”这件事把背后最核心的 5 大要素逐个拆开揉碎再配上可以直接拿去用的实战代码示例帮你把提示词这件事彻底整明白。1. 内容整体设计与思路拆解先聊一个很多人没想透的问题提示词到底在“工程化”什么我见过不少开发者写提示词跟发朋友圈一样想到哪儿写到哪儿。比如“帮我写个方案”“给我一段营销文案”然后抱怨模型输出太水。这不是模型不行而是信息输入太少了。大模型的本质是一个概率模型你给它的信息越多、越精准它生成的输出就越贴近你的预期。提示词工程的核心就是设计一套“信息投喂”策略让模型在有限的上下文里尽可能理解你到底想要什么。我梳理了一下一套有效的提示词几乎总是包含这 5 大核心要素角色设定告诉模型“你是谁”。任务指令告诉模型“你要干什么”。上下文信息告诉模型“你还需要知道什么背景”。输出约束告诉模型“你该以什么形式回答”。示例引导告诉模型“你参考我的标准来”。这五个要素放在一起就像你给一位新来的同事交代工作。你光说“把这份数据整理一下”他大概率不知道你要的是表格、PPT还是分析报告也不知道你的数据处在什么业务背景下。但你如果告诉他“你是数据分析师请把这份季度销售数据整理成一张按月汇总的表格毛利和净利单独列一列风格参照我上个月那份报表”——他立刻就知道该怎么做了。这套逻辑本身并不依赖某一家模型厂商也不依赖具体代码框架。它可以应用在纯文本对话里也可以应用在调用 API 的工程代码中。这也是为什么说提示词工程是一种“通用能力”掌握了它你换哪个模型都能快速上手。在写这篇文章之前我其实做过一次小范围的对比测试。同样一个任务分别用“一句话指令”和“五要素完整指令”去调用同一个模型输出质量的差距可以说判若云泥。后面我会把完整的测试对比过程、代码都放出来你可以自己跑一遍感受下。2. 核心要素逐项拆解这 5 个维度到底怎么玩2.1 角色设定给模型一个“人设锚点”角色设定是提示词里最容易被忽略但效果立竿见影的一个要素。你让模型“写一段关于咖啡的介绍”和你说“你是资深咖啡师正在为一本美食杂志写一篇面向咖啡爱好者的深度介绍”产出的内容专业度和风格都会完全不同。为什么一个简单的人设变化会带来这么大差别原因在于大模型在生成文本时会依赖于它在训练阶段学到的“语境相关性”。当你设定了角色模型就会倾向于从这个角色的知识分布里抽取内容。这个机制有点像“表演”你给演员一个角色他自然会进入状态调动的表情、语气、词汇都会往那个方向靠。实操的时候角色设定不能太宽泛。比如“你是专家”这种设定就太虚了模型不知道自己是什么领域的专家。正确的写法是带上具体领域、具体身份、甚至具体立场弱你是畅销书作家。强你是一位擅长写非虚构类作品、尤其擅长把复杂技术概念讲给普通读者听的科普作家。角色设定还可以配合“任务场景”一起使用。比如让模型扮演“恶意用户”来测试你自己写的提示词检验提示词的鲁棒性这就是一种很经典的对抗性用法。我在做自动化内容审核系统的时候经常让模型同时扮演“审核员”和“违规发布者”两个角色互相博弈来找提示词的漏洞效果非常好。2.2 任务指令把需求说清楚是基本素养任务指令是整个提示词的主干它直接告诉模型要做什么。很多人的问题是任务描述得太模糊或者一次塞了太多任务。先说模糊的问题。“分析这段数据”就是一个典型的模糊指令。数据是什么格式从哪些维度分析有没有重点指标输出形式是什么这些没讲清楚模型就只能靠猜。而猜的结果就是输出内容五花八门每次都不稳定。再说任务太多的问题。有人喜欢一口气让模型“先总结文章再提取关键词再翻译成英文再写一段推荐语”看起来很高效但模型在一段提示词里同时处理多个任务时注意力和输出质量都会被稀释最后往往两头不讨好。更稳妥的方案是拆分成多个步骤、多次调用每次只让模型做一件事。在写任务指令时我总结了一个“三句话公式”第一句话动作词 核心对象比如“提取这份文件的要点”。第二句话限定条件比如“只提取与成本相关的信息不要其他内容”。第三句话输出要求比如“用列表形式每条不超过50字”。这套公式看着简单但你实际去用的时候会发现它几乎能应对90%以上的基础任务。它的本质是通过“减法”削减模型的自由发挥空间让输出更可控。2.3 上下文信息少让模型当“盲人摸象”上下文信息是决定提示词质量的“天花板”。模型本身不具备读取你脑子的能力它只知道你给它看了什么。你给的背景信息越充分它的输出就越贴合实际情况。我举个真实的例子。之前我帮一个做电商的朋友优化商品文案生成流程他最初的提示词是“帮我把这个商品写一个吸引人的标题”。输入的商品信息只有名称和一个价格数字。产出的标题基本是通用模板什么“超高性价比”“不容错过”完全没有商品的核心卖点。后面我帮他把提示词改成带上完整的“商品信息卡片”材质、工艺、使用场景、目标人群、差异化优势、历史竞品分析。结果生成的标题和文案质量直接上了一个台阶。差别在哪里就在于模型拿到了一张“信息全景图”它知道自己在什么样的前提下写文案。上下文信息需要注意一个度的问题。信息太少模型会泛泛而谈信息太多又会冲淡主线任务。我的经验是所有上下文信息都要和最终任务直接相关和任务无关的细节果断删掉。比如你要模型做多轮对话那对话历史就是上下文的关键你要模型做知识库问答那检索到的相关文档片段就是上下文的核心。不分青红皂白把一堆资料丢给模型不仅浪费 token还可能干扰它的判断。2.4 输出约束给模型的回答装上“骨架”输出约束的作用是把模型的输出框在既定的边界里。用术语说就是让生成结果具备“高可解析性”和“高可控性”。最常用的输出约束包括几种格式约束比如用 JSON、Markdown、表格、长度约束比如限制在 X 字以内、结构约束比如“分三段输出每段一个小标题”、以及内容约束比如“不要包含价格信息”“不要用评价性语言”。在实际项目里格式约束的价值会被放大。因为当你用代码调用大模型时往往还要做后续的程序处理。如果模型返回的是一段自由文本你去解析它的成本会很高。但如果你在提示词里要求它“严格按 JSON 格式输出包含 name、price、reason 三个字段”那后续的数据处理就顺畅多了。举一个典型例子请分析下面这段用户评论的情感倾向输出 JSON 格式包含 sentiment 字段取值为 positive/negative/neutral和 confidence 字段取值为 0 到 1 之间的小数。像这样明确的约束即便模型有时理解力有限也会因为格式骨架的存在而“收敛”得很规矩。有些模型甚至能稳定输出你要求的字段只是偶尔会有字段缺失或类型错误这时候你可以在代码里加一个 JSON 解析的容错机制兜底。长度约束是另一个容易翻车的地方。很多人说“一句话总结”结果模型输出了一大段。因为“一句话”在模型的理解里很模糊。更精确的写法是“用一段话总结字数不超过 30 个字”。注意“不超过30个字”和“最多30字”其实也有细微差别但总体上数字化的约束永远比形容词靠谱。2.5 示例引导一句话胜过千言万语如果说前面四个要素都是“说教”那示例引导就是“示范”。你给模型一个输入和输出的对应示例它就能从示例里反推你的偏好和标准。示例引导在业界有个更专业的名字叫 Few-shot Learning少样本学习核心原理是让模型通过类比来完成任务。它尤其适用于那些不太好用规则描述的任务比如风格转换、语气模仿、内容改写等。举个例子。你想让模型把产品文案从“正式商务风”改成“活泼口语风”光说“改写一下”是不够的。但你给它一个对照示例输入原文本公司致力于为用户提供一站式数字化转型解决方案。 输出示例我们是干什么的帮你搞定数字化转型一站式那种再给它另一个产品的原文让它照着示例的风格去写效果就会好很多。它会自动学习示例里那种短句、设问、口语化的表达特征而不是用一堆“亲和”“高效”之类的空词来搪塞你。示例也不是越多越好。一般情况下两三个高质量示例就足够太多了反而会让模型“学偏”。另外示例要尽量贴近你的真实任务场景领域差异过大的示例会起反效果。比如你让它模仿某短视频平台的文案风格示例就一定要选该平台上的真实爆款文案而不是拿微博评论来凑数。3. 实战代码示例一套可复用的提示词封装方案理论说完直接上代码。我这里提供一个基于 Python 的提示词封装示例它把前面讲的 5 大要素做成了可配置的结构方便你在真实项目里直接使用。3.1 先看一个效果对比一句话指令 vs 五要素指令我觉得这个对比特别有冲击力先展示给你看。我用同一个模型分别给两种提示词任务都是“写一个咖啡品牌的新品推广语”。第一组提示词帮我写一个咖啡品牌的新品推广语。模型输出这款咖啡口感醇厚香气扑鼻是您日常生活中不可错过的选择。限时优惠快来抢购第二组提示词完整五要素角色你是资深品牌营销专家擅长捕捉年轻消费者的心理。 任务为一款主打冷萃冻干的精品黑咖啡写一句推广语突出便捷和口感。 背景信息目标人群是 25-35 岁的一线城市上班族工作忙但追求品质经常早上来不及去咖啡店。 输出约束字数控制在 20 字以内语气要有活力不能出现醇厚精选等烂大街的词不用感叹号只输出推广语本身不要解释。 示例 传统写法精选优质咖啡豆醇厚口感无可挑剔。 优秀写法冷水一冲3秒解锁咖啡馆级黑咖。模型输出不用出门冷水即溶你的随行咖啡馆。看到差距了吗第一个结果更像“通用广告词生成器”的产物第二个则是完全贴合产品卖点、人群场景和品牌调性的定制文案。这种输出质量的差距就是提示词工程的价值所在。3.2 结构化提示词封装类实际写代码的时候不要每次手动拼字符串而是用一个可配置的结构来管理提示词。我习惯这样写# prompt_engine.py import json from typing import Optional, List, Dict class PromptTemplate: def __init__(self, role: str , task: str , context: str , constraints: Optional[List[str]] None, examples: Optional[List[Dict[str, str]]] None): self.role role self.task task self.context context self.constraints constraints or [] self.examples examples or [] def build(self) - str: parts [] if self.role: parts.append(f角色{self.role}) if self.context: parts.append(f背景信息{self.context}) parts.append(f任务{self.task}) if self.constraints: parts.append(输出约束) for c in self.constraints: parts.append(f- {c}) if self.examples: parts.append(示例) for e in self.examples: parts.append(f输入{e[input]}) parts.append(f输出{e[output]}) return \n.join(parts) def call_model(prompt: str, model: str your_model_name, temperature: float 0.5, max_tokens: int 500) - str: # 这里替换成你实际使用的大模型 API 调用 # 我用的是一个兼容的接口你换成自己的即可 import openai client openai.OpenAI(base_urlyour_api_endpoint, api_keyyour_api_key) resp client.chat.completions.create( modelmodel, messages[{role: user, content: prompt}], temperaturetemperature, max_tokensmax_tokens ) return resp.choices[0].message.content if __name__ __main__: tpl PromptTemplate( role资深品牌营销专家擅长捕捉年轻消费者的心理, task为一款主打冷萃冻干的精品黑咖啡写一句推广语突出便捷和口感, context目标人群是25-35岁一线城市上班族工作忙但追求品质, constraints[ 字数控制在20字以内, 语气要有活力, 不能出现『醇厚』『精选』等烂大街的词, 不用感叹号, 只输出推广语本身不要解释 ], examples[ {input: 传统写法, output: 精选优质咖啡豆醇厚口感无可挑剔。}, {input: 优秀写法, output: 不用出门冷水即溶你的随行咖啡馆。} ] ) prompt tpl.build() print(生成的提示词\n, prompt) result call_model(prompt) print(\n模型输出\n, result)这段代码你把 API 地址和密钥换成自己的就能跑。数据流非常清晰先组装提示词再调模型最后拿到输出。这里还要提一个小细节temperature参数。它是控制模型随机性的重要旋钮。你对输出要求稳定、格式严谨时把 temperature 调低0~0.3你需要模型发挥创意、生成多样化内容时把 temperature 调高0.7~1.0。我在做结构化数据提取任务时通常直接设成 0让模型输出结果尽量收敛做营销文案生成时会调到 0.8 左右避免每次结果都一模一样。3.3 输出结果的结构化解析如果你让模型输出 JSON那就涉及解析问题。我习惯写一个容错解析函数因为你直接json.loads很容易被模型的多余文本搞崩。import json import re def parse_json_response(text: str) - dict: # 尝试直接解析 try: return json.loads(text) except json.JSONDecodeError: pass # 如果模型返回的内容里包含 JSON 代码块先提取 code_block re.search(r(?:json)?\s*(\{.*?\})\s*, text, re.DOTALL) if code_block: try: return json.loads(code_block.group(1)) except json.JSONDecodeError: pass # 如果模型返回的是纯文本开头和结尾尝试找到第一个 { 和最后一个 } start text.find({) end text.rfind(}) if start ! -1 and end ! -1: try: return json.loads(text[start:end1]) except json.JSONDecodeError: pass raise ValueError(f无法解析模型输出为 JSON{text})这套容错逻辑我一直在用覆盖了绝大多数模型返回格式不稳定的情况。尤其在对接开源模型或者本地微调模型时这类看似简单的兜底函数能帮你省下一大把调试时间。4. 常见问题与排查技巧实录提示词工程虽然讲究方法但实战中永远会遇到新问题。这里整理几个我频繁踩过的坑以及对应的排查思路。4.1 模型不从你的“示例”里学习怎么办这是初始化使用示例引导时最常见的问题。你给了模型一个很好的示例但它输出的时候完全无视了还是按自己的习惯来。这种情况很多时候不是示例没用而是示例太少了只给一个示例模型很难形成稳定的模式。解决方案是我前面提过的至少给出 2~3 个示例并且示例之间要有明确的差异对比比如一个“错误写法”加一个“正确写法”。模型会从这种对比里学到“边界在哪里”比只给一个孤立的正面示例有效得多。也可以尝试在示例前后加上解释性文字比如“注意下面的示例中优选用例的特点是……”。4.2 输出结果总是“太啰嗦”或者“太简短”这个问题的根源多数在约束不够量化。你让模型“简洁一点”它不会知道什么叫简洁。把它改成“用 5 条列表输出每条不超过 20 字”它立刻就能执行到位。同样地有时候你希望答案足够详细结果它三句话讲完了。你需要在提示词里加一条“请从背景、现状、问题、建议四个维度展开每个维度不少于 100 字”。数字是模型最容易理解的约束方式没有之一。还有一个容易被忽略的原因模型的max_tokens参数你可能设置得太小了。如果模型生成到一半被截断那输出肯定看起来“不够长”。排查的时候先检查这个参数再优化提示词。4.3 角色设定有时候会“失效”有些模型对角色设定的响应不明显特别是在模型能力偏弱或者角色描述和任务脱节的时候。比如你设定“你是资深医生”但让它去写相声段子模型就很难把这两个信息自然融合。解决方法是把角色设定和任务场景缝合在一起而不是各说各话。比如“你是一位擅长把专业医学知识融入日常幽默段子的写手请为一场医院开放日活动写 3 个 30 秒的暖场相声梗”。这样角色的“知识背景”和任务的“表达形式”就统一到一个语境里了。如果模型还是不听可以在角色定义后加一句“以上角色设定必须严格遵守”或者把角色设定重复到任务描述里。这算是一种“笨办法”但实测在某些场景下效果立竿见影。4.4 上下文太长模型“记不住前面说的话”大模型有上下文窗口限制超过窗口长度时早期的内容会被截断或者被模型“忽略”。这在很多问答系统里特别常见你把一大段知识库资料全塞进提示词结果模型只重点看了后半段。解决思路有三条一是优先把与任务最相关的内容放在提示词的后半部分因为有些模型对越靠后的内容关注度越好二是做内容检索不要全塞进去只挑和问题匹配度最高的片段三是把长文本做摘要压缩后再输入。我在做知识库问答系统的时候通常会用向量检索把候选文档压缩到 5~10 个片段再交给模型效果远比全量塞入好得多。4.5 输出的 JSON 字段时有时无这种情况非常折磨人。模型明明答应你输出 JSON结果第二个字段它有时候给、有时候不给还有的时候给你串成一个字符串。排查的时候我会先做一件事把temperature调到 0 再跑一遍。如果输出稳定了就说明是随机性带来的字段缺失。如果还是不稳定那大概率是提示词对字段的定义不够清楚或者字段命名和模型的预训练知识冲突了。一个更稳妥的做法是在提示词里直接给一个“字段模板”请严格按以下 JSON 结构输出不要额外加字段 {公司名称: , 成立年份: 0, 主营业务: }这种“填空式”约束比单纯说“输出 JSON 格式”要清晰得多模型照着填就行基本不会跑偏。4.6 常见问题速查表问题现象可能原因优先排查项输出内容太泛泛上下文不足缺少约束补充背景信息增加量化约束风格不像预期缺少示例或示例数量不足补 2~3 个高质量示例格式不稳定约束过于模糊随机性过高提供字段模板temperature 调低输出被截断max_tokens 设置太小调大 max_tokens模型忽略角色角色与任务脱节把角色和场景融合描述内容越改越差迭代方向不对叠加了太多混乱要求从零重写提示词精简约束这张表是我自己日常排查问题时的首选清单。每次遇到提示词效果不达标我都会先对照这张表按顺序检查而不是凭感觉乱调。值得提醒的是一次只改一个变量。很多人喜欢一次性把提示词改了七八处然后发现效果变好了却根本不知道是哪一步起的作用。提示词工程的本质是“实验科学”保持变量可控才能持续积累经验。5. 进阶玩法从“写提示词”到“设计提示词系统”一旦你熟练掌握了单个提示词的设计方法就可以把它从“单次调用”升级到“系统化设计”。这里分享三个我正在用的进阶技巧。5.1 链式提示词把一个复杂任务拆成多步流水线前面我提到不要在一个提示词里塞多个任务更合理的做法是设计一条“提示词流水线”。以写一份行业分析报告为例第一步让模型提取资料中的核心数据和观点。第二步让模型基于这些数据生成分析大纲。第三步让模型按大纲逐段撰写。第四步让模型做整篇校对和风格统一。每一步都用独立的提示词模板输入是上一步的输出。这样做的好处是每一步的目标都很聚焦模型输出质量更可控而且你可以在任意一步插入人工修改或审核。不要小看这个“插一脚”的能力在真实业务流程里让中间结果经过人审再进入下一步往往能避免很多连锁错误。5.2 思维链引导模型先推理再回答在处理逻辑推理、数学计算、条件判断类任务时直接让模型给答案很容易出错。一个通用技巧是引导模型“先展示推理过程再给出最终答案”。请解决下面的问题先写出你的推理步骤然后给出最终答案。严格来说这个叫思维链提示Chain-of-Thought。它并不神秘本质上就是强制模型把思路外显从而减少盲猜的概率。我在处理一些需要多条件判断的文本分类任务时经常用这个技巧发现模型在小样本场景下的准确率提升很明显。唯一的代价是输出变长了token 消耗会稍微增加。但多数情况下这个成本换来的是更高的结果置信度是划算的。5.3 自动评估让模型自己评判自己的输出质量评估是提示词工程里最容易被低估的一环。你怎么知道这次生成的提示词到底好不好凭感觉不行靠运气更不行。一个稳妥的做法是再写一个“评估提示词”让模型对自己的输出按几个维度打分。比如让模型生成营销文案后再调用一次模型提示词大致长这样你是一位严格的文案评审。以下是一条营销文案请从吸引力、信息准确度、和用户痛点的契合度三个维度打分每个维度满分10分给出总分和修改建议。文案内容{生成结果}这样做还有一个额外的好处模型给的修改建议可以作为下一轮生成提示词的优化方向形成“生成—评估—再生成”的闭环。我在做内容工厂项目时就是靠这套自动评估机制来筛选候选文案的效率比人工审核高出数倍。写在最后的实操体会我自己做提示词工程也踩了不少坑从最初完全靠“多试几次碰运气”到现在能结构清晰地把问题拆解成五个要素逐个调整这个转变让我实实在在感受到了“工程化”的力量。每次被模型输出气到的时候我都会提醒自己不是模型糊涂而是我的提示词没说到位。如果你刚接触提示词工程我的建议是别一上来就追求什么高级技巧先老老实实把这 5 个核心要素用起来在你最常用的场景里把每个要素都试着写一遍再对照本文的排查表做优化。等你对这些基础操作形成了肌肉记忆再去玩链式提示、思维链那些进阶玩法一定要记着最容易忽略的往往就是角色设定和输出约束这两条但往往补上它们效果就会立刻不一样。