1. 提示词工程到底在解决什么问题1.1 它不是玄学话术而是显式的上下文设计如果你最近在玩大模型大概率有过这种体验同一件事换一个说法结果天差地别换个时间再问同样的说法答案又不一样。于是很多人开始把提示词当成某种“咒语”去研究觉得一定存在某种神奇口令能让模型发挥全部潜力。我做了几年大模型应用开发可以负责任地说提示词工程的核心不在“咒语”而在“上下文设计”。模型本身的能力是固定的它能利用的信息就是当前上下文窗口里的所有内容。你的提示词本质上是一套“上下文布局”告诉模型当前任务是什么、背景是什么、约束是什么、期望输出长什么样。把这些信息布局得越清楚模型回答的质量就越稳定。这也是为什么优秀提示词和普通提示词之间的差距不在于用了多少生僻词汇或神奇句式而在于信息密度、结构层次和边界定义是否到位。一个“帮我把这段文章改通顺”的提示词看起来没问题但模型不知道你要改成什么风格、是否允许大幅删改、要不要保持原长度。它只能在泛泛的指令里挑一个平均值。反过来说当你想明白这些问题并把它们写进提示词输出自然就不一样了。1.2 为什么说上下文工程是提示词工程的下一站最近行业里讨论“上下文工程”的人越来越多有人把它说成提示词工程的下一代形态。这个说法有点道理也不全对。我的理解是提示词工程是上下文工程的一个子集而且是最靠近用户的那部分。什么意思呢上下文工程关注的不只是系统提示词怎么写而是整个上下文中所有元素的组织方式。包括用户输入、系统指令、检索到的知识片段、工具调用结果、多轮对话历史甚至模型自己的中间推理过程。这些元素以什么顺序进入上下文、每条占多大比例、哪些信息必须放在靠近开头或结尾的位置都会影响模型最终输出。举一个最典型的例子给大模型接一个企业知识库。你单靠一段写得再漂亮的提示词也无法让它回答出私有文档里的内容因为模型根本没有这些信息。你得先通过检索把相关文档片段找出来塞进上下文再给模型下达“只基于以上资料回答”的指令。这时候检索质量、片段长度、排序方式、上下文拼装顺序这些看似不属于提示词的部分反而决定了最终效果。所以我在这篇文章里列的10个技巧既有传统提示词玩法也有偏上下文工程的实践。核心思路是一致的让模型在更明确、更有限、更完整的上下文里工作。2. 10个立刻能上手的技巧上先把手头的提示词改规范2.1 技巧1角色锚定但别只说“你是一个专家”角色提示是大多数人最开始接触的技巧。给它一个角色比如“你是一名资深律师”“你是十年经验的前端架构师”模型输出确实会更贴合角色设定。原因是这个角色名在训练数据里关联了大量特定语料相当于帮模型锁定了一个输出分布空间。但这只是第一步如果你想让它真正稳定输出只有“角色名”远远不够。一个完整的角色锚定至少包含三个维度角色背景、任务场景、行为约束。要说明它是谁、服务于谁、专业边界在哪要说明它要做什么、输出给谁看还要说明哪些行为是被禁止的。我给一个对比弱写法你是一名数据分析师。帮我分析这份销售数据。强写法你是一名有8年零售行业经验的数据分析师现在需要为一家电商公司的管理层制作月度销售分析报告。请基于我提供的数据指出销售额变化的3个主要原因并给出1条可执行的建议。不要堆砌统计术语用管理层能听懂的语言表达。后一种写法里模型能判断的维度更多。它知道用户是管理层、不需要术语、要有决策建议这些约束会直接影响它对信息粒度的取舍。角色设定不是让你编故事而是在给模型划出“谁在什么立场上以什么标准回答”的边界。2.2 技巧2少样本示例让规则长在例子里面如果你发现无论怎么描述规则模型总是“听懂了但做不对”那就别再讲规则了。给它看例子。少样本提示的理论基础是上下文学习模型在训练时就具备根据示例推断任务规律的能力。你不需要告诉它“人名要抽出来、公司名要抽出来、地名要抽出来”直接给它三组“输入文本-期望输出”的对照它就能学会这个模式。但示例不是随便丢几个就行。用多了以后我总结出几个关键点第一示例质量比数量重要两三个能覆盖边界情况的例子远胜于十个模糊雷同的例子。第二最好既有正例也有负例。拿信息抽取来说我会在示例里专门放一条“没有目标实体”的输入并让模型返回“无结果”。加了这一步误报率明显下降因为模型知道了“空就是空不要硬填”。第三示例的输出格式要和你期望的最终输出格式完全一致。如果示例用JSON它就会学着用JSON如果示例是口语段落它也会学着口语化。模型在示例里找规律你得确保你给的规律就是你想让它学会的规律。2.3 技巧3思维链让模型把计算过程摊开写思维链是2022年前后火起来的方法入门用法简单在提示词末尾加一句“请一步一步思考”模型就会在给出答案前输出推理过程。但真实生产环境里有两个问题必须想清楚一是什么任务该用二是什么时候别用。先说该用的。数学题、逻辑推理、代码调试这些多步骤场景模型直接输出最终答案时中间一步算错很难被发现如果把推理过程显式写出来错误更容易暴露模型也更可能中途自我修正。但如果是简单任务比如情感分类、格式转换、摘要总结思维链只会拖慢响应、多烧token甚至把一眼能看出的结论越想越偏。我见过不少开发者在简单任务上强行加“深思熟虑”结果输出变得冗长又绕。再说怎么防跑偏。在提示词里可以这样约束“在给出结论前请用不超过200字说明推理步骤每一步都要引用题干中的数据或原文。”加了“引用原文”这个要求模型就被迫回到原始输入而不是凭空推断。这一步对很多幻觉问题都有抑制作用。2.4 技巧4结构化输出让结果可以被程序直接消费如果把大模型接入业务系统最基础的门槛是输出格式。模型天生擅长自然语言但你的系统需要的是JSON、XML、Markdown表格这类结构化数据。解决方法不复杂在提示词里明确格式要求并附上一个结构示例。我日常的写法是请以JSON格式输出不要包含JSON之外的任何文字。输出结构{result: [{name: 实体名称, type: 实体类型可选值为PERSON、ORG、LOCATION}]}。如果未识别到任何实体返回{result: []}。这里有个容易忽略的坑模型可能会在JSON前后加上“好的结果如下”这类话导致解析失败。除了在提示词里强调“不要包含其他任何文字”更稳的办法是在程序解析端做兼容把输出中第一对花括号之间的内容截取出来再解析。提示词能降低问题概率但工程上永远要留一道兜底。另一个经验是越复杂的JSON结构模型越容易在字符串里混入未转义的引号或换行。能扁平的JSON就尽量扁平不要用太深的嵌套。如果必须嵌套给一个完整的示例比写一堆字段说明更有用。2.5 技巧5反问澄清信息不足时让模型先提问很多人抱怨“模型总是在编”其实有时候是任务本身给的信息不完整模型只能靠猜。与其让它猜不如在提示词里明确授权它反问。模板写法我的需求是为我的新产品做一份市场推广方案。如果你认为我提供的信息不足以给出高质量方案请先向我提出不超过3个关键问题我会逐个答复。如果信息充足则直接生成方案。这里的关键是把“质量优先”放在“速度优先”前面。模型不是客服你授权它提问它就会在关键信息缺位时主动拦截而不是生成一份看似完整、实际全是空话的方案。我遇到过好几次内部需求想用大模型做竞品分析但连竞品对象、目标用户都没说清。不加反问机制时模型把所有知名品牌都评论一遍看着好像全面其实完全没有可用性。加了反问环节用户被迫先想清楚边界后续生成的方案质量立刻不一样。3. 10个立刻能上手的技巧下进阶玩法与组合技3.1 技巧6自我检查让模型再挑一遍自己的毛病一个容易被忽视的进阶玩法是自我修正。模型第一遍生成的内容只要约束不够严格多多少少会有瑕疵。与其额外调用一次模型专门做“审查”不如在同一个提示词里设置两阶段任务。写法示例第一步根据我的要求生成一篇关于远程办公效率的文章800字左右。第二步逐条检查你生成的这篇文章重点检查事实准确性、逻辑连贯性、是否包含没有依据的具体数字或案例。如果发现问题重写一遍并说明修改了哪里。加了第二步之后输出质量提升是肉眼可见的。原因在于模型第一遍生成时倾向于选择最流畅的词汇和句式而进入检查阶段后会切换成一种更挑剔的视角一些第一遍时容易出现的“幻觉细节”会被它自己揪出来。需要注意自我检查不适合所有场景。同一段内容要生成两遍token消耗和响应时间都会增加。如果目标是几百字的短回复丢在同一个提示词里没问题如果是上千字的长文我更建议拆成两次独立调用第一次生成第二次只审查和修改这样每一步的上下文更干净。3.2 技巧7拆解任务让模型先出大纲再写全文大模型在长文本生成上有个通病开头高能、结尾烂尾或者开头持A观点结尾悄悄偏向B观点。最典型的是让它一次性输出1500字以上中后段经常出现重复表达、逻辑跳跃。解决思路是为任务设置“中间产物”把一个大任务切成若干个小步骤。拿写长文举例可以让模型先输出文章大纲你确认后再逐段扩展。提示词可以这样写请先为“智能家居安全设计”这个话题写一份文章大纲包含5个章节每章给出3个关键点。大纲确认后再逐章撰写正文每章约400字。全部完成后按章节顺序拼接为完整文章。这个做法本质上是任务分解。一段上下文里只聚焦一个章节时模型需要同时管理的信息量大幅减少前后一致性自然更好。虽然交互成本高了一点但换来的是结构稳定的长文。做API接入时你还要自己处理多轮调用的上下文拼接建议把已经确认的大纲一直保留在后续每轮的上下文中防止模型写后半部分时忘记框架。3.3 技巧8多候选生成与自洽性选择大模型的输出带有随机性同一个提示词跑两次结果会有差异。很多人把随机性当成麻烦换个思路它也能变成工具让模型一次生成多个候选然后从中选最优。学术上管这个叫自洽性说白了就是“多准备几个答案再挑好的”。在网页对话界面里可以这样让模型在同一回复中给出多个版本请给出3个不同方向的方案每个方向要有明显差异不要只是换几个同义词。随后从这3个方案中选出最符合以下标准的一个信息准确、结构简洁、可落地执行并说明你的选择理由。在API环境下更常见的做法是多次调用同一提示词把temperature调到0.7以上让每次生成有更多变化再用程序对这些结果做汇总评分。评分可以用规则比如是否包含关键字段、长度是否符合要求也可以再用模型当裁判。这个技巧适合创意方案、文案标题、产品命名这类多样性优先的任务。事实型问答和代码生成不建议这么做——代码多跑几次再让模型选反而可能把本来正确的那份改成错的因为它在“评分”时也会引入新的臆测。3.4 技巧9上下文工程的核心——把背景知识放进提示词这里要谈的其实是整体视野上的做法不要把模型默认成什么都知道主动把背景资料、业务约束、示例文档放进提示词。模型内部的知识是静态的存在信息截止日期而且不包含你业务中的私有内容。但它的上下文窗口足够大可以临时接纳你给的新材料。简单落地方式包括让它总结一段日志就把日志原文贴进去你们公司有内部命名规范就把规范写成一个简短的段落放在任务描述前面做知识库问答就先用检索把相关片段捞出来再拼进提示词里。顺序方面有一条经验把背景信息放在提示词最前面任务指令放中间输出格式要求放最后。原因是模型对上下文不同位置的注意力权重有差异开头和结尾的信息更容易被强化。重要背景放开头能在生成后续内容时持续形成约束输出格式放最后等于在收尾阶段给它一个明确的“着陆点”。这一条看起来不起眼实际改完效果经常有明显变化。3.5 技巧10把提示词当代码来维护做版本和评测最后一个技巧更像工程习惯。提示词早期可以靠灵感但一旦进入生产环境就必须当代码管起来。需要有版本号、变更记录和回归测试。具体操作分三步。第一给每一类提示词建独立文档记录初始版本、修改时间、修改原因、实测效果。第二准备一个小规模评估集比如20条真实业务输入每次修改提示词后都用同一批输入去测试观察输出是变好还是变差而不是凭感觉说“好像好点”。第三如果一个提示词的某个片段被多个场景复用就把易变部分和固定部分拆成变量比如用占位符表示任务描述、背景资料固定部分单独维护。我实践下来的体会是没有评估集的提示词优化基本等于裸奔。你调整了几版风格如果不跑同一批测试输入做对比根本分不清效果提升来自新写法还是来自模型这次随机生成的运气。一份20条的测试集不用很重但能帮你少走很多弯路。4. 可直接抄作业的模板库建议复制后按需修改4.1 通用任务模板角色背景任务约束输出格式这个模板适合大部分文本处理任务要点是把五类信息全部写清楚缺一类都可能影响最终效果。【角色】 你是一名具有5年经验的{领域}专家服务于{目标受众/使用方}。 【背景】 {说明当前情况、为什么需要这个任务、这个任务的使用场景} 【任务】 请完成以下任务{明确描述要做的事} 【约束】 - 不要{列出禁止事项} - 必须{列出强制要求} 【输出格式】 {描述期望的输出结构最好给出示例}这个模板看着简单但每个字段都在回答模型一个问题角色解决“以什么身份说话”背景解决“为什么做这件事”任务解决“到底要做什么”约束解决“哪些不能做”输出格式解决“结果长什么样”。五个问题都回答了模型的输出空间就被压缩到一个很小的范围内。4.2 RAG/资料问答模板让模型只基于给定资料回答做知识库问答时最怕一件事模型脱离你给的资料自由发挥。想让模型“只基于资料回答”不能只靠一句“请根据以下资料回答”还需要明确告诉它遇到未知内容怎么处理。你是一名企业知识库助手。以下是用户问题和相关资料片段。 【资料片段】 {检索到的文档内容用分页符或其他标记分隔} 【用户问题】 {用户的问题} 【回答要求】 1. 只基于以上资料片段回答不要引用资料以外的信息。 2. 如果资料中未包含答案请明确回答“资料中未找到相关信息”不要自行推断。 3. 回答末尾用[1][2]标注引用来源对应资料片段的编号。 4. 用简洁的要点形式输出控制在200字以内。这里第2条和第3条是最关键的。第2条给了模型一个“承认不知道”的出口明显减少编造第3条把回答和证据绑定便于用户复核。在实际业务里如果发现答案经常出现资料里没有的细节优先检查检索环节是否把最相关内容漏掉了而不是一味改提示词。4.3 信息抽取模板实体识别与结构化输出信息抽取类任务对输出格式要求最严格建议把格式示例直接写进提示词同时准备好负例。你是一名信息抽取引擎。从用户提供的文本中抽取指定类型的信息并以JSON返回。 【抽取目标】 - 人名PERSON - 公司名ORG - 产品名PRODUCT 【输出格式】 {result: [{name: 实体文本, type: 实体类型}]} 【规则】 1. 只抽取文本中明确出现的实体不要根据常识推断。 2. 如果一个实体被多次提到只保留一次。 3. 如果没有识别到任何目标实体返回 {result: []}。 【示例】 文本华为在昨天发布了Mate 70系列手机。 输出{result: [{name: 华为, type: ORG}, {name: Mate 70系列, type: PRODUCT}]} 【待抽取文本】 {在此处输入文本}如果你一次性需要抽取的实体类型很多建议分多次抽取每次只抽一两类。类型越多模型串场的概率越大。另外如果文本里大量出现“公司名和人名相同”的情况可以把“结合上下文上下文判断”写进规则同时期待它在较长的上下文信息中自行作出更准确的判断。4.4 代码相关模板生成、审查、改错三类常用场景代码类任务和文本类任务差别很大代码对正确性要求高容错率低。我用得最多的是三个模板生成、审查、改错。先看代码审查模板你是一名资深的{语言}开发工程师请审查以下代码找出潜在问题。 【代码】 {此处粘贴代码} 【审查重点】 1. 是否存在边界条件处理缺失 2. 是否存在内存泄漏或资源未释放问题 3. 错误处理是否合理 4. 代码风格是否清晰可维护 【输出格式】 按以下格式输出 - 问题描述... - 风险等级高/中/低 - 修改建议...代码生成模板更强调约束条件。写代码前一定要让模型先给出实现思路再写代码避免它直接甩出一段看着对但逻辑有误的实现。提示词里加一句“先简要说明你的实现思路再输出代码”能显著提高代码与需求的匹配度。改错场景则一定要附上报错信息原文、运行环境版本、出错的输入样例这三个信息缺哪个都容易让模型陷入猜测。4.5 内容创作模板文章、营销文案与多版本生成内容创作类模板是最不需要“死板”的但它需要一个清晰的创作简报。很多内容看起来空洞是因为模型没拿到具体的选题角度、目标读者、字数范围和风格偏好。你是一名{平台}内容作者。请创作一篇关于{主题}的文章。 【读者画像】 {目标读者的身份、认知水平、阅读场景} 【文章目标】 {读者读完后应该知道什么、能做什么} 【风格要求】 {口语化/专业/幽默/严谨...} 【结构建议】 {如果有明确结构要求就写没有就让模型自己定} 【其他要求】 - 字数{范围} - 开头需要{具体钩子} - 避免{哪些表达或内容}营销文案则适合用多版本生成。一次生成5个标题或3个slogan再让模型说明每个版本对应的场景和理由。这个方法比一次只给一个结果要高效得多因为文案好坏本身有很强的主观性多版本能给决策留出比较空间。5. 高频问题与排查思路5.1 模型不遵守格式约束怎么办这是接入业务系统时最常遇到的问题。你明确说了“以JSON输出”它还是给你带解释文字。我通常按以下顺序排查第一检查提示词里有没有给格式示例。只描述格式结构模型理解起来还是抽象给一段具体示例它才能照着样子走。第二检查提示词里是否出现自相矛盾的表述比如前面允许它“详细说明”后面又要求“只输出JSON”。第三检查解析端是否过于脆弱能不能支持剥离前后缀的兼容逻辑。格式问题很多时候不全是模型的锅。模型在生成时会被上下文中重复出现的模式影响如果你的示例写得足够密集、结构足够一致它照着做的概率会高很多。如果试了很多次还是不定还可以考虑用更小的输出约束工具。至于是什么这里不多扩展你只需要知道纯提示词不是唯一解法。5.2 加了思维链效果反而变差之前提过思维链不是万能的。如果发现加了“请一步步思考”效果反而变差先检查任务类型。简单分类任务、格式转换任务本来就不需要复杂推理模型被“要求思考”后反而会增加额外步骤在这些步骤里它的错误率会上升。另一个常见原因是思维链的推理过程太长导致模型在长步骤中逐渐偏离原始问题。解决办法是限制推理长度并要求每一步引用原始输入信息。比如写成“请用不超过3步得出结论每一步都要说明依据”就能把推理控制在较短链路里。另外如果模型在推理过程中输出了错误的前提后续再怎么推也是错的。这时候与其让它一口气推到底不如把推理过程拆成几步每步单独和原始输入比对。部分场景下也可以先让模型复述一遍题目中的关键信息再让它推理瞎推断的情况会少很多。5.3 上下文太长导致关键信息被忽略很多人以为给的信息越多越好实际上模型对上下文的注意力是有限的。当上下文超过一定长度后中间部分的信息容易被忽略或者被错误理解俗称“迷失在中间”。如果你的提示词很长但需要的核心指令或关键数据放在长文中间模型很可能看不到。解决办法有几个把最关键的信息放在提示词开头或结尾把不重要的大段资料挪到提示词末尾附近用分隔符明确标注“以下是参考资料”或者精简上下文只保留与当前回答最相关的部分而不是一股脑全塞进去。在RAG场景里缩短检索片段、提炼摘要比把大原文端给模型更有效。5.4 模板不生效最容易被忽略的变量用了模板还是没效果先不要怀疑模板本身。我遇到过几次“同一套模板在A场景表现很好在B场景完全失效”的情况最后排查下来都是变量没改对。最常见的问题是模板里用方括号占位符但填写时把原方括号也一起删了或者背景资料切换后任务指令还沿用上一场景的描述导致逻辑冲突。还有个容易被忽略的点同一个模板在不同模型上表现差异会很大。有些模型对指令的理解能力强有些模型对格式的遵从能力弱。换模型后如果发现输出风格明显变化优先检查是不是模型本身的指令遵循能力差异导致的而不是反复调模板。6. 一点个人实操心得做了这么多轮提示词优化之后我最大的体会是提示词工程表面上是写文字本质上是在设计信息结构。你写的每一句话都在参与塑造模型的“上下文工作区”与其纠结某个词用得好不好不如先想清楚这个任务里哪些信息是不可或缺的、哪些约束不能放松、哪些反馈能帮助模型自我修正。提到上下文工程我的态度是它不是一个需要单独学习的知识体系而是提示词工程的延伸。当你开始关心信息放哪里、上下文怎么组装、历史记录要不要压缩、检索结果如何排序其实已经在做上下文工程了。行业下一个阶段的竞争点也会从“谁提示词写得好”转向“谁能把整个上下文链路设计得更高效”。最后分享一个小技巧每次改提示词之前把当前版本和上一版本的输出放在一起对比。如果拿不准哪个好可以开一个全新的会话语境把两版提示词各跑一遍再分别针对结果追问一轮。比起反复在同一个对话里修改这种方法更能避免上下文污染带来的误判。