做提示词工程这两年我最大的感受是大多数人在写提示词的时候不是在工程而是在碰运气。同一个模型换一种问法输出质量可以天差地别。有人把这归结为模型随机性但我见过太多人把本来可控的方差归因于玄学这很可惜。提示词工程完全是可学习、可验证、可积累的关键是要把它当需求规格说明书来写而不是当聊天话术。这篇文章把我自己在真实项目里反复验证过的10个技巧全部摊开讲每条都会给出可复制的模板和必要的参数说明最后还会送你一套可以直接改用的模板库。1. 先纠正一个误读提示词工程不是话术是需求规格1.1 同一个模型为什么换一种问法结果完全不同先举个最典型的例子。你让模型帮我写一份周报它大概率会给你一份泛泛而谈的模板看起来什么都对但没什么用。如果你换一种方式你是项目A的负责人本周完成了登录模块开发、修复了3个线上bug、和设计组对完了新版首页原型请用业务负责人的口吻写一份周报包含已完成事项、风险与求助、下周计划三部分每部分不超过3条。输出质量会完全不一样。这不是玄学而是信息密度不同。模型在生成每一个token时依赖的都是上下文里可用的信息。上下文里对背景、角色、格式、约束的说明越充分它可选的高概率token就越集中在你想要的方向上。换句话说prompt写得越像一份需求规格说明书模型就越像一个按需交付的开发团队prompt写得越模糊模型就只能用通用的、安全的、正确但平庸的方式来回应。我在实际项目中见过太多人抱怨模型笨或者不听话但把对话记录翻出来往往发现需求本身就含糊不清没有背景、没有受众、没有格式要求、没有验收标准。这和团队里接需求是一样的需求写不清楚开发做出来的东西自然不是你要的。提示词工程不是要把话说得多华丽而是要把话说得多明确。1.2 三个底层机制上下文、注意力与概率生成要真正理解提示词工程不需要读论文但至少要建立三个朴素的直觉。第一模型是在预测概率分布。每个token的生成都基于前面所有内容所以前面所有内容的质量直接决定后续生成质量。这也是为什么把关键约束放在开头、反复强调重要信息是有用的因为它参与了每一次概率计算。第二注意力不是均匀分布的。模型在生成时会关注上下文里的关键片段。你把需求拆成编号列表、把核心限制单独提行本质上是在帮注意力机制快速定位关键信息。这就像面试时你把简历里的重点加粗面试官才能一眼看到你的亮点。第三输出是逐token累积的。如果模型在第三步就已经跑偏后面会沿着这个偏差点越走越远。所以任务拆解、分步执行这类技巧的底层逻辑就是尽早暴露偏差避免后期不可收拾。这三个直觉合在一起会改变你写prompt的习惯你会开始关心信息结构、关键信息的位置以及每一步的生成风险。你也会明白为什么有时候把同样的内容换一种排列顺序效果会差很多。1.3 什么场景才值得认真设计提示词不是所有使用场景都需要提示词工程。如果只是闲聊、头脑风暴那随意提问反而有助于生成多样性。但以下三类场景我建议一定要认真设计重复执行型同一类任务要反复做比如每周生成周报、每天生成内容摘要值得花时间打磨一份可复用模板。输出稳定性要求高自动化流程里要解析结果、要直接对外发布的内容必须把格式和语义边界卡死。复杂任务需要多步推理、多条件约束的方案设计、代码生成、数据分析一次说清楚能省下大量修正成本。判断标准很简单如果改进prompt节省的时间大于你设计prompt的时间就值得做。大多数人其实是反过来的宁可花40分钟在对话框里反复纠正也不肯花10分钟把需求写清楚。2. 技巧1-4先把结构立起来输出就不会跑偏第2章要聊的四个技巧有一个共同点它们都发生在模型生成之前解决的是边界在哪的问题。很多人在对话里反复纠正模型本质上是没有提前把边界说清楚。结构类技巧的作用就是让模型从一开始就知道自己该在什么范围内工作。下面四条按使用频率从高到低排序其中输出结构约束是我在自动化流程里用到最多的。2.1 角色设定不只是你是一个专家很多人知道要加角色但只写你是一个专家基本没用因为它太宽泛了。有效的方式是给角色补上两个信息擅长什么在什么背景下工作。你是拥有10年经验的DevOps工程师擅长CI/CD流水线设计、云原生架构和故障排查。 背景我们团队正在从传统虚拟机部署迁移到Kubernetes。 任务请给出迁移过程中的3个主要风险点及应对方案。 要求用你实际操盘迁移项目的经验来写避免教科书式回答。角色设定的本质是给模型一个先验框架。它一旦进入这个框架术语体系、判断标准和表达风格都会向特定方向偏移。比如上面这个prompt里避免教科书式回答就是在框架之上再追加一个风格约束。实测中要注意一个反向问题角色设定过强会牺牲灵活性。有一次我让模型扮演严格的技术审查员来做方案设计结果它对所有创意方案都持否定态度导致输出失去了开放性。所以角色设定要跟任务匹配需要严谨判断时用严格角色需要发散创新时用开放角色。2.2 任务拆解把大任务变成子步骤尽早暴露偏差模型处理大任务时最容易出现前半段还行后来越写越空的问题原因是上下文里细节被稀释了。任务拆解能有效对抗这个问题。请分四步完成以下任务 第一步列出该主题的核心受众与他们的主要困惑。 第二步基于困惑给出3个候选大纲。 第三步从3个候选中选1个最优的并说明理由。 第四步按最优大纲撰写完整文章。 每一步完成后先输出这一步的简短结论再进入下一步。这个模板里有几个容易被忽略的设计。一是每一步完成输出结论这是故意的为了让模型的中间结果外显让你能在早期发现方向错误而不是等全文生成完才后悔。二是说明理由这强制模型进行元认知通常会让选型更合理。任务拆解也不是越细越好。拆到模型可以一步完成的粒度即可一般3到5步比较合适。拆得太碎反而会让输出变得机械丢失整体性。我见过有人把一篇文章拆成20个步骤结果每段之间像拼凑出来的一样没有连贯的逻辑线。2.3 输出结构约束用格式把结果卡死在实际项目里输出结构约束是性价比最高的技巧之一尤其是在要接后处理流程的场景。比如你写了一段抓取新闻摘要的工作流最后需要把结果存成结构化数据那就不应该让模型自由发挥而是要告诉它输出JSON。请分析以下文章并输出JSON格式字段如下 { title: 文章标题, summary: 不超过50字的摘要, key_points: [要点1, 要点2, 要点3], tone: 整体语气可选值客观/积极/批评/中立, risk_level: 风险等级可选值高/中/低 } 文章{文章内容}这种提示词的核心是把输出schema说清楚包括字段名、类型、可选值范围甚至要不要换行、用不用引号。你定义得越具体解析代码就越简单出错概率就越低。我在一个自动化项目中就遇到过这种情况早期没要求纯JSON输出模型经常在JSON前后加一句这是您要的结果导致解析脚本频繁报错。后来在prompt里加了一句不要输出任何解释性文字解析成功率从不到80%提升到接近100%。对于普通写作也可以用结构约束要求分小节、每小节有标题、每部分限定条数。比如每部分不超过3条这种数量约束比要简洁这种抽象词有效得多。因为数量是可检查的模型在执行时有一个明确的边界。2.4 少样本示例两个标准答案比解释一百句管用有时候你很难用语言描述清楚我要什么样的输出但你手头有几个好例子。这时候就使用少样本示例策略把输入和输出成对放入prompt。请参照示例对输入文本进行意图分类。 示例1 输入明天下午三点把合同送到前台 输出安排任务 示例2 输入这个月报销什么时候到账 输出查询进度 请分类以下输入 输入麻烦帮我查一下最近一笔订单的物流 输出少样本示例的底层逻辑是让模型直接从输入输出对中归纳映射关系这往往比抽象规则更直接、更少歧义。示例也不需要多2到3个高质量示例通常就够了关键是要覆盖不同情况最好包含一个边缘情况帮模型理解边界。这里我踩过的一个坑是示例和实际输入差异太大。比如示例都是短句实际输入是长文本模型就容易不知所措。所以要尽量保证示例与目标任务在风格和复杂度上接近。在构建示例时我一般会把最常见的两个情况加一个边界情况放进去比如一个正常样本、一个拒绝回答样本、一个包含特殊字符的样本。3. 技巧5-7让模型多想几步质量立刻不一样第2章聊的是结构现在聊深度。这组技巧的共同点是让模型在生成最终结果前多花一点推理成本很多表面上看起来模型不会的问题其实是它跳步跳得太快。在处理复杂任务时这组技巧往往比单纯增加提示词长度更有效因为它们针对的是模型的推理深度而不是信息覆盖度。3.1 思维链提示把推理过程显式化很多人在让模型做推理题时直接问请回答模型容易跳步、结论可疑。但如果你要求模型先把推理过程写出来它的表现会明显提升。请一步步思考并展示推理过程 某商品原价800元先涨价20%再打八折最终价格是多少思维链有效的原因不复杂模型每一步的生成都基于当前所在的语境如果它先把中间运算写出来后面的每一步都在这些中间结果上继续累积误差就会变小。这就像做复杂计算时你在一张草稿纸上写清楚每一步而不是全靠心算出错概率自然低得多。这里有一个实用细节如果你担心输出太长可以用先简要列出关键推理步骤再给出结论的方式而不是要求输出满篇的内心独白。实际项目里思维链在数学题、逻辑判断、竞品分析这类需要多步推导的任务里效果尤其明显。但在简单分类任务里就没必要用反而浪费token还会把简单问题复杂化。3.2 背景锚定把关键约束放在上下文前面上下文窗口是有限的而且模型在长上下文中会遗忘中部信息这种现象有时被称为lost in the middle。所以重要信息的位置比你想象的重要。背景信息 - 项目名称智能家居控制平台 - 目标用户25-40岁、有一定技术接受度的家庭用户 - 核心约束必须支持离线语音控制、只兼容主流智能家居协议 - 禁止事项不支持云依赖方案 请基于上述背景设计一个用户引导功能的实施方案。把关键约束放在上下文最前面等于在模型生成的每一阶段都提供一个锚点。尤其是禁止事项很多模型生成到一半就忘记了把它放在开头并单独成行约束力会强很多。之前做一个自动化报告生成项目模型总是擅自加入一些不存在的假设。后来我就在prompt开头加了一条本报告只基于以下数据生成不得自行补充未提供的数据效果立竿见影。核心约束前置这个动作几乎成了我所有prompt的标配。我还习惯在关键约束下加粗或使用独立行因为排版层面的区分确实会影响模型对信息权重的判断。3.3 自检机制让模型在输出前先审一遍这是把工程里的代码评审概念移植到提示词里。具体做法是在原任务后追加一个自检清单要求模型在给出正式答案之前先按清单过一遍。请完成以下任务{任务内容} 完成后按如下清单自检 1. 是否完整回答了原始问题 2. 是否存在事实性错误或过度引申 3. 是否严格遵循了输出格式 4. 结论是否与正文一致 如果发现问题直接修正后重新输出最终版本。自检机制的本质是用一次额外的推理换质量稳定性。实测中很多模型在自检阶段真的能发现自己前面犯的错误尤其是格式错误和结论不一致这类问题。代价是会多一些输入输出token但对于重要产出物这点成本非常值得。有个使用技巧自检不一定要在同一轮输出里完成。你可以先让它生成初稿然后在第二轮输入让它按清单检查并提出修改意见再让它基于修改意见重写。这样多轮交替比一次性让它生成自检更容易发现深层次问题。我通常在高质量要求的场景里用两轮方式一般质量的场景用单轮自检就够了。4. 技巧8-10用工程手段对付不确定性和持续迭代结构稳定后下一步要处理的是生成结果中的不确定性以及如何让一次对话变成可迭代的工作流。这组技巧会更接近工程思维因为它们的核心不是怎么写单条prompt而是怎么设计一套能持续产出高质量结果的机制。4.1 红队视角让模型自己挑自己的毛病模型生成的答案往往有一种迷之自信尤其在方案设计、风险分析这类任务里。一个有效的对抗手段是让模型扮演红队自己反驳自己。请先给你的答案。 然后站在一个非常挑剔的专家角度找出上述答案中可能存在的漏洞、盲区、误导性假设和被忽略的边界情况。 基于这些批评重新给出一版更可靠的答案并在最后单独列出你保留了哪些观点修改了哪些观点。这个技巧我经常用在技术选型类的prompt里。第一次生成的方案往往很常规但经过红队反驳之后第二版方案通常会更全面甚至会主动提出替代方案。这个生成-批评-重写的循环比你在对话里手动纠正高效得多。需要提醒的是红队视角会显著增加token消耗而且如果任务本身很简单会有一种杀鸡用牛刀的感觉。我一般在决策类、高风险任务里才使用。还有一个变体是让模型扮演多个不同立场的角色进行辩论比如成本敏感型决策者和质量优先型决策者这样能产出更立体的分析。4.2 采样参数配合temperature与top_p到底怎么调提示词本身不是孤立的生成参数同样影响结果。很多人不知道调整参数有时比改prompt更直接。参数作用建议场景temperature控制随机性值越低越确定代码生成、数据提取、事实问答top_p控制候选词概率累积范围也影响多样性可与temperature二选一调节max_tokens输出长度上限防止长输出被截断或压缩成本我的习惯是结构化输出和代码任务temperature设0到0.3之间创意写作和头脑风暴设0.7到0.9。top_p一般保持默认只在需要更严格控制时才调低。有一个常见的误区是同时大幅度降低temperature和top_p这可能会让输出退化成一个固定模板反而失去灵活性。参数与提示词是配合关系。比如你已经用自检机制让模型对结果进行审查那就没必要把temperature设得很低该有的多样性已经由自检环节兜住了。反过来如果你的prompt本身写得很模糊那再怎么压低temperature也救不回来因为模型并不知道你到底想要什么。4.3 多轮反馈修正把一次问答变成可迭代的循环我见过很多人遇到模型输出不满意第一时间是开一个新对话把需求重新打一遍。这其实是在丢弃上下文。更高效的做法是就地反馈、迭代修正。上一版回答存在以下问题 1. 第二部分缺乏具体数据支撑 2. 结论与第3节内容不一致 3. 语气过于保守。 请在保留原有结构和正确内容的基础上按上述问题重写。只修改有问题的地方不要改动其他部分。这种多轮修正模式特别适合写长文、方案设计、论文润色这类任务。原因是模型在同一个上下文里保留了你之前所有的约定和修改历史每一轮修正都在前一版基础上演进而不是重新开始。但也要控制轮数一般两三轮就够了轮数过多模型可能会陷入局部最优改来改去反而变差。我把这种模式称为用对话代替重写与其反复开新窗口碰运气不如在同一上下文里把问题一个一个解决掉。实际操作中我会把每一轮发现的典型问题记下来沉淀成未来prompt里的约束这样同一个问题不会在下一个项目里再次出现。5. 模板库四个高频场景改参数就能用前面讲的是技巧这一节给可以直接抄的作业。每个模板都可以替换花括号里的内容直接使用但更重要的是理解模板背后为什么要这样设计这样你才能在场景变化时自行调整。5.1 模板库设计原则为什么模板要参数化很多人的模板只是把一次成功的prompt复制下来下次换个主题就硬套效果往往不稳定。原因是每个prompt里既有结构化的固定部分也有跟具体任务相关的变量部分。模板要做的是把变量用占位符标记出来。我用占位符的规则很简单统一使用{花括号}一目了然在不同场景里替换就行。固定部分包括角色设定、任务描述、输出格式、通用约束。变量部分包括主题、受众、材料、具体需求。每次使用模板时我会强制自己先把所有花括号填满再根据实际情况增删一句话这样不会漏掉关键点。5.2 职场写作模板周报、邮件、汇报你是{岗位}的资深从业者擅长向上级和协作方清晰表达工作进展。 请围绕{本周核心工作}写一份{周报/邮件/汇报材料}受众是{受众}。 要求 1. 开头用一段话概括本周结论 2. 正文按已完成/进行中/风险求助三个模块组织 3. 每个模块不超过3条每条不超过两行 4. 语言客观不使用取得了显著成果这类空话。 输出结构 ## 本周结论 ## 已完成 ## 进行中 ## 风险与求助这个模板的核心是把要求写成可以对照检查的规则而不是形容词。比如不使用空话这种约束看起来抽象但模型在生成时确实会避免类似的表达因为你在要求里明确点名了。在实测中加上每个模块不超过3条的效果比单纯说要简洁好得多因为数量约束是可度量、可执行的。5.3 技术方案分析模板选型与评审你是技术方案评审专家有{领域}一线落地经验。 请评审以下方案{方案描述} 分析维度 1. 技术可行性是否存在已知的技术障碍 2. 落地成本人力、时间、基础设施投入 3. 风险项列出top3风险及应对措施 4. 替代方案给出一个比当前方案更简单或更稳妥的备选。 输出要求 - 先给结论再给理由 - 每个理由后标注置信度高/中/低 - 不使用模糊表达如可能或许如果确实不确定请说明不确定的原因。这个模板里的置信度标注是很容易被忽略但很有用的设计。它迫使模型区分它确定的和它猜的这对技术评审来说非常关键。我在实际使用中还会在模板最后加一句如果有与你的判断相反的证据也请列出来进一步减少盲区。在几次选型评审里这个模板都帮团队提前发现了方案里的隐性风险。5.4 代码生成与调试模板请用{语言}实现{功能}。 函数签名{函数签名} 输入示例{输入} 预期输出{输出} 要求 1. 处理边界情况空值、超长输入、非法参数 2. 代码添加必要注释但不要逐行解释 3. 使用{库名}完成{子功能} 4. 最后用示例输入执行一次并贴出实际输出。 输出分两步先给实现思路再给完整代码。这个模板解决的是代码任务里最常见的几个痛点不处理边界、不验证输出、注释过度或缺失。先给思路再给代码这个顺序尤其重要它能让你在审查代码之前先判断方案是否合理避免在错误的方案上浪费时间。还有一个调试场景的变体当你拿到一段报错信息时把报错信息、相关代码、期望行为三样一起放进prompt让模型先分析可能原因再给出修复方案比直接问这段代码怎么改更有效。6. 比技巧更值钱的经验验证集、上下文取舍与三个坑最后这部分我想聊聊比堆砌技巧更值得关注的事因为它们是决定提示词工程能不能规模复用的关键。6.1 建立你自己的小验证集而不是靠感觉调参很多人调prompt靠的是这次看着不错但下次换一个输入可能就崩了。正确的做法是建立一个小验证集准备10到20个有代表性的输入每次修改prompt后在同一批输入上跑一遍记录哪些通过、哪些失败、失败原因是什么。我自己的习惯是维护一个表格每一行是一个测试用例每一列是输入-期望结果-实际结果-问题描述。每次改动prompt或模型版本都回归一遍。这看起来繁琐但在长期维护的场景里它比感觉可靠得多。你可以在表格里快速看到是哪一个约束导致了大部分失败然后针对性修正而不是每次都从头开始瞎试。6.2 上下文窗口不够用时的取舍长文档处理时上下文窗口不够用是最常见的问题。这时的取舍逻辑是不要把原始全文都塞进去而是提取关键信息放进去。常用的方式包括先让模型分章节摘要再把摘要拼接起来作为后续输入的上下文把需求里的核心约束单独放在prompt开头原文作为附录放在后面如果业务允许用检索增强的方式只把相关片段注入上下文。之前做一个项目需要让模型基于一份80页的PDF回答问题。如果全文塞进去既超窗口又稀释注意力。我先让模型按章节生成结构化摘要再基于摘要回答问题准确率反而更高。这个压缩-再生成的思路在长文档处理中非常实用。6.3 我踩过的三个典型坑第一个坑是迷信绝对化词汇。早期我写prompt特别喜欢用必须绝对不能以为这样约束力就更强。实际效果有限模型对这些词汇的看重程度远不如对具体动作的看重。与其说绝对不能编造数据不如说数据必须来自上面给定的列表如果列表中不存在请明确写无数据。具体动作比情绪化强度词有用得多。第二个坑是一个prompt试图覆盖所有边界。后来我发现把太多约束塞进一个prompt各约束之间会互相干扰尤其是当模型在生成长文本时后面的约束很容易被遗忘。解决办法是拆分阶段先让模型按格式生成再通过自检机制检查是否满足全部约束。这个调整让我的长文本任务成功率提升了不少。第三个坑是忽视输出解析。在自动化流程里我早期没有在prompt里严格要求格式结果模型频繁在JSON前后加解释文字导致解析失败。后来我不仅要求输出纯JSON还会加一句不要输出任何解释性文字解析成功率从不到80%提升到接近100%。这个教训让我意识到prompt设计要站在后处理代码的角度考虑而不是只站在人的阅读角度。写到最后再说一点个人体会。我现在写提示词的习惯是第一版永远先跑通再迭代而不是一上来就要写一个完美提示词。先用最简单的方式拿到一个基础输出观察它哪里不对再针对性地加约束、加示例、加自检机制。提示词工程最关键的能力不是想出一个惊天动地的提示词而是建立起输出-观察-修正的循环。你手里这套10个技巧加上模板库足够覆盖大多数日常和工作场景了。至于更深的路要靠你自己在一个个具体项目里把这套方法论内化成习惯。