今天想认真聊聊“大模型提示工程”这件事。做内容、写代码、跑数据的人现在多多少少都在用大模型。但很多人会有一种感觉别人用起来很顺手自己用起来像跟一个喝了三杯咖啡的实习生对话——说了半天对方交上来的东西总差一点意思。问题多半不在模型而在“提示词”这个沟通界面。我最早也踩过这个坑。需求写得很辛苦模型完全跑偏以为是模型不行后来认真梳理了提示词的结构和设计方法效果提升是肉眼可见的原本要改三次以上的内容现在经常一遍过。这篇东西就把我实际操作中沉淀下来的思路、模板和排错经验完整写出来。不管是做开发的、做运营的还是偶尔用大模型辅助写作的人只要你想让模型输出的东西更可控这篇内容应该都能直接落地。1. 先搞懂底层逻辑为什么同一句话模型理解差别这么大用提示工程之前最好先花几分钟理解模型到底怎么“读”你的话。这一步不是理论课而是决定你后面所有提示词设计方向的底层依据。1.1 提示词不是在“搜答案”而是在引导概率很多人把大模型当成一个搜索引擎以为输入问题就会去查库返回正确答案。实际不是这样。主流大模型的核心机制是自回归生成它把你输入的整段文字提示词切分成最小单位逐个预测序列中下一个单位最可能是什么。也就是说模型每生成一个字都是根据前文所有内容计算出来的概率结果。它不是“想”出来的是“猜”出来的但“猜”的依据来自海量文本训练出的统计规律。用一个生活化的类比你请一位经验丰富但记性不太好的顾问帮忙写方案。他每次下笔会参考你之前交代的所有背景、需求和约束再根据他见过的类似方案来补全下一句。如果你给他的信息模糊他只能靠最常见的套路补全如果你给了明确的边界和范例他补全出来的内容就会严格贴合你的要求。这个机制解释了提示工程里两个最核心的现象提示词的每个字都在影响后续生成的概率分布。不是只有指令才重要连格式、顺序、语气都会影响最终结果。模型没有“真正理解”你的意图它只是在估算“用户接下来最可能想要的文字”。所以你给的文本越能锁定目标答案所在的文本空间输出就越准。理解了这一点你写提示词时就不会再把它当成“发命令”而是当成“布置场景 给足条件 展示范例”。你在做的事本质上是把模型引导到一片狭窄的、高概率的区域让它只能在这里面输出。1.2 上下文窗口模型眼里只能看到你给它的这些字还有一个不能忽视的东西叫上下文窗口模型在一次对话里能“看到”的文本总量是有限制的几万甚至十几万个单位不等。超出范围的内容模型根本看不到哪怕你之前说过它也会“忘”。实际操作中我见过很多人在一个对话里越聊越长最后模型开始答非所问然后抱怨模型太笨。其实是因为你最开始那几条关键指令已经被挤出了窗口范围或者被淹没在大量对话历史里。这个机制带来的实操经验很直接重要指令尽量放在每轮消息的最前面——模型对开头内容的注意力往往更集中。关键约束在每轮需要时重复一遍不要指望模型记住两小时前的细节。如果任务比较复杂优先考虑每轮都自包含完整上下文而不是依赖多轮聊天累积。我这里说的“注意力更集中”不是玄学。大模型的注意力机制天然会对某些位置的信息给予更高权重很多实际测试都显示提示词前后两端的指令影响力通常大于中间部分。你可以把它理解为读书时的记忆特点开头和结尾记得清楚中间容易模糊。所以写提示词时开头放核心任务结尾放输出要求中间放背景和素材这是比较稳的安排。1.3 模型不是逻辑机器它是“风格模仿器”很多人以为模型天生擅长数学和逻辑推理实际上它的推理能力是“模仿出来的”。模型在训练数据里见过大量“因为……所以……”“先……后……”的文本所以它生成的推理链条看起来很有逻辑。但推理链是否真的正确取决于问题本身是否在训练数据里出现过足够多的相似样本。这就解释了为什么提示工程里会有思维链、少样本、角色设定这些看似花哨的技法——它们本质上都是在“唤醒”模型在训练阶段见过的某种文本模式。角色设定是唤醒“客服语气/专家语气/代码评审语气”思维链是唤醒“解题过程文本”少样本是唤醒“格式范例”。所以提示工程的底层逻辑可以一句话概括用你写的文本去触发模型训练阶段最接近目标任务的文本生成模式。这确实是门沟通艺术不过沟通的对象是一个概率模型。2. 提示工程基础技法从生硬指令到有效对话底层逻辑理解之后进入实操技法层面。我按使用频率和实用程度把核心技法分成四类每一类都附上我自己常用的写法。2.1 零样本与少样本你给不给例子效果完全不同零样本提示就是你直接提出要求不给任何示例适用于简单且常见的任务比如“用一句话概括这段文字”。现代大模型普遍训练过大量通用指令简单任务不需要示例也能完成得不错。但一旦任务复杂、格式要求特殊或领域小众零样本的表现就会明显下降。因为模型缺少一个可参考的文本分布只能凭训练数据里的通用套路来猜。这时候需要少样本提示。所谓少样本就是你在提示词里给出1到3个输入输出示例让模型照着示例的格式和风格生成。举个例子。我让模型从用户评价里提取核心观点零样本写从下面这段评价中提取用户最关心的三个问题点。模型给出的结果可能是乱七八糟的段落甚至夹杂分析。改成少样本之后从用户评价中提取关心的问题点。严格按以下格式输出 评价手机续航太差了半天就关机而且充电很慢。 问题点1. 续航短 2. 充电速度慢评价屏幕颜色偏黄亮度调到最高也不够亮阳光下看不清。 问题点1. 屏幕偏色 2. 亮度不足效果立刻稳定。模型的本质是概率预测示例就是在明确告诉它“我期望的输出长这个样子。”这比你说一百遍“请按格式输出”都管用。实操中我建议示例控制在2到3个太多会占用上下文太少模型学不到模式。还要注意示例与真实输入的相似度示例是手机评价模型更容易处理同类文本示例是新闻评论你再让它处理手机评价效果就打折。2.2 角色设定为什么“你是一个XX”真的有用提示词里写“你是一位资深数据分析师”模型就真的会切换到分析师腔调吗从概率角度看这句话的作用是把后续生成文本快速锚定到一组“以分析师身份表达”的文本分布中。训练语料里存在大量角色化问答模型学到了一种关联当文本出现“你是一个专家”时后续内容更可能是专业术语密集、逻辑严密、结论明确的风格。所以角色设定不是魔法它是风格控制开关。但角色设定有个常见误区只写角色不写任务。“你是一名资深营养师”后面什么都不说模型只能泛泛讲解营养学知识。完整的角色提示应该是你是一名有十年经验的营养师擅长为上班族设计健康食谱。下面帮我设计一份一周工作日晚餐方案要求每餐烹饪时间不超过30分钟。角色给了风格任务给了目标这两者缺一不可。我常用的角色设定模板有几个专家顾问专业风格、严厉导师挑剔风格用于挑错、编辑润色风格、思维伙伴讨论风格。不同角色会显著改变输出的措辞和信息密度大家可以多尝试。2.3 思维链逼模型“把脑子里的草稿写出来”思维链Chain of Thought是提示工程里被验证最有效的技法之一尤其适合数学题、逻辑推理和多步判断类任务。它的原理也好理解。大模型生成的本质是逐单位预测如果你直接问一个复杂问题模型很可能跳过了推理的中间步骤直接预测最终答案结果经常一本正经胡说八道。而思维链提示会要求模型先把推理过程写出来再做结论。当模型把过程写成文字时每个中间步骤都在为下一步生成提供更明确的上下文约束整条推理链会沿着更可控的方向前进。最基础的做法就是加上一句“请一步步思考然后给出答案”。但对我个人来说显式思维链结构效果更稳我会把推理过程拆成小块请按步骤解决下面的问题每一步都输出当前的计算过程和结果最后再给出最终结论。 题目一件商品原价320元打八折后满200减30最后还要加10%的运费最终到手多少钱 第一步计算折后价格 第二步判断是否满足满减条件 第三步加上运费 第四步得出最终价格这样模型会老老实实按你拆解的步骤走而不是把逻辑混在一起。有两点需要警惕。第一思维链不应该用于所有任务像“这句文案是否吸引人”这种主观判断强行要求推理过程反而会让输出变得啰嗦。第二思维链提示词可能让模型暴露错误推理过程但这在多数场景里反而是好事你至少能看到它是怎么错到这一步的。2.4 格式化输出稳定拿到可解析的结果做开发的人最怕模型输出格式不稳定。上一轮还是JSON下一轮就变成了代码块包裹的JSON再下一轮直接多了层Markdown标记。这个问题有一个专门解法在提示词里把“输出格式”作为独立模块并给出实例。我的标准写法是只输出JSON不要输出任何其他内容。格式如下 {标题: 标题文字, 要点: [要点1, 要点2, 要点3]}要点在于三个关键词“只输出”“不要输出任何其他内容”“格式如下”再加上一个准确示例。把示例直接放在要求后面比任何关于格式的长篇描述都有用。同样的逻辑适用于Markdown表格、XML标签、CSV等。举个例子让模型输出对比表将下面的内容整理成Markdown表格包含三列指标名称、标准值、我的建议。不要输出表格以外的文字。然后给一个两行示例。模型生成的结果基本可以直接粘贴使用无需二次清理。3. 结构化提示词设计一套能复用的模板体系很多人写提示词是想到哪写到哪有时候长有时候短换来换去效果飘忽。我自己的做法是固定一套结构化模板所有重要任务都套用同一框架方便迭代也方便复制到不同模型上使用。3.1 一份合格提示词的七个模块我拆解了大量好用提示词之后发现它们大多包含七个模块你可以按需组合角色模型以什么身份输出资深律师/产品经理/技术编辑任务本次要做什么事生成摘要/改写文案/写代码背景任务来自什么场景服务对象是谁输入数据需要处理的原文、数据表、需求描述输出要求格式、长度、语气、语言约束条件不能出现什么、必须包含什么、禁止什么示例1到3个输入输出范例不需要每次都写满七项。简单任务两三项就够复杂任务则需要全部到位。重要的是——每一项都要明确写出来而不是含糊地混在一句话里。3.2 我自己长期在用的通用提示词框架下面这个框架我用了很长时间适配写作、分析、编程、翻译等大多数任务。直接复制过去替换方括号内容即可角色你是一位拥有多年经验的[领域]专家。任务根据以下要求完成[具体任务]。背景这是一个面向[目标受众]的[任务场景]需要[核心目标]。你提供的内容将被用于[后续用途例如发布到博客/提交给产品部门/作为培训材料]。输入数据 [需要处理的具体文本、代码、数据或需求]输出要求用中文输出语气[正式/轻松/专业]结构[总分总/分点/表格/代码注释]长度[约多少字/行]约束条件不得包含[禁止出现的元素]必须覆盖[必须出现的关键内容]如果信息不足请直接说明不要编造示例可选 [输入输出示范]有了这个框架之后我基本不愿意回到自由发挥式提示词。框架的真正价值不只是结构清晰而是它让“提示词”本身成为了一个可以被审视和迭代的对象哪一块效果不好就替换哪一块不用整段重写。3.3 实战演示用模板一次生成一份高质量的会议纪要总结我拿一个真实场景演示。假设你给我一段一个小时的产品讨论会议记录我这里用简化的文本代替你用上面这个框架改写提示词角色你是一位有十年经验的产品负责人擅长提炼关键决策和风险。 任务从会议记录中提取决策项、待办事项和风险点生成一份结构清晰的会议纪要。 背景这份纪要会发送给参会成员需要帮助大家快速对齐结论无需还原所有讨论细节。输入数据 以下是会议讨论记录原文 “大家先聊了新的数据看板需求运营那边希望按渠道拆分转化率技术这边说数据源还没打通最快下周二可以接好。后来确认了新版本优先上线首页改版数据看板放到下一迭代。另外提到最近接口超时问题比较频繁需要单独安排一个技术优化专项。设计那边表示新版首页原型周三能给到评审。”输出要求按“会议决策”“待办事项”“风险与问题”三部分输出每条要点不超过两行语言简洁不用客套话约束条件不要输出讨论过程不要遗漏与时间节点相关的信息输入之后模型会直接给你干净的决策清单而不是罗列式的对话复述。核心逻辑很简单把“繁琐的讨论”留给输入区把“精简的要求”留给指令区模型就知道它只需要提炼不需要再把原文复述一遍。4. 场景化实操提示工程在真实任务中的落地方案框架归框架真正用的时候还得结合具体场景微调。我把高频使用场景逐一拆开讲每个场景都说清楚关键控制点。4.1 写作与内容创作控制风格的几个细节写作类任务的核心痛点有两个风格不对、内容太套话。对应解法是两个关键词参考风格、约束禁区。所谓参考风格是你需要给模型一个“风格锚点”。只说“写得好一点”没有用因为模型不知道你说的“好”是什么标准。我给模型做风格约束时常用的方式是让它模仿一段真实示例仿照下面的文字风格改写目标文本 示例风格“真正的好文案不是说产品有多强而是让用户看完之后觉得这说的就是我。”像这样给一个风格样本往往比给十个形容词都有效。形容词是抽象描述模型对抽象词的理解跟你的理解不一定一致但示例文本是具体的数据模型可以直接做模式匹配。写作场景第二个好用的技法是“反面约束”。告诉模型不要做什么有时比告诉它做什么更有效不要用“赋能”“抓手”“闭环”这类黑话不要用“首先然后最后”这类俗套结构。这些约束直接规定了模型的生成禁区能显著降低“一眼看出是AI写的”的概率。4.2 编程辅助让模型真正看懂你的代码编程场景里提示工程的难点在于模型缺少项目上下文。想让模型生成可用的代码或准确定位问题你得把上下文喂得足够充分。我写代码解释类提示词时固定包含三块内容代码本身、技术栈与语言版本、代码在项目中承担的作用。比如技术栈Java 17 Spring Boot 3.x 项目背景这是一个订单服务模块下面这个方法用于处理退款回调。 代码 [代码粘贴] 请解释这段代码的处理逻辑并指出一个潜在的空指针风险点。相比于直接甩一段代码问“这干什么的”带上项目背景会让模型给出的注释更有针对性。很多看起来像“模型不懂代码”的问题其实是模型根本不了解这段代码在项目里扮演的角色。排查报错时也给模型完整链路不只是报错信息下面是一个服务接口在处理请求时收到的错误日志日志之后附了我这边的接口代码。请结合日志和代码推断最可能的原因并按可能性从高到低列出排查顺序。日志有了代码有了目标有了。模型给出的排查建议基本可以直接照着做比把错误码粘进去问“什么意思”效率高得多。4.3 数据分析与 SQL 生成把表结构变成约束条件数据分析场景里最让我惊艳也最容易翻车的是让模型直接写查询语句。翻车原因十有八九是模型不了解表结构只能靠猜。表名、字段名一旦猜错SQL就是废的。解决思路很直接把表结构作为提示词的一部分。需要用到哪些表就列清字段名和类型并要求模型只能使用提示词中给出的字段。例如数据库包含以下两张表 用户表 usersid, name, register_date, city 订单表 ordersid, user_id, product_name, amount, created_at业务规则一个订单只属于一个用户amount单位为元需要转换为万元。 请写一条SQL统计2024年每月注册用户的下单总金额按月份升序输出。只输出SQL语句不要解释。表结构 业务规则 明确要求这三个要素齐全SQL生成准确率会大幅提升。这也是提示工程最标准的应用方式用结构化信息压缩模型的猜测空间。更复杂的分析场景也可以复用这套逻辑。给模型输入列名、单位、口径定义和价值定义然后让它做数据解读。模型最大的优势不是算得准实际上算不准而是能基于你给的业务口径生成结构合理的分析思路。4.4 翻译与润色重点不是“翻得对”而是“翻得不像AI”翻译任务很多人觉得简单丢一句“翻译成英文”就完事。但真正发出去的译文往往有股生硬的机翻味。我常用的高级翻译提示词会加上目标受众和文体约束把下面这段中文翻译成英文。受众是海外互联网产品的普通用户语气友好口语化不要用太书面的表达也不要逐字直译。专有名词保留中文拼音注释一下含义。比如“不要逐字直译”这六个字会让模型从逐词对应切换到意译模式译文流畅度提升明显。润色任务的逻辑也一样。如果只是说“帮我润色一下”模型可能会大改改动后可能已经不是你的语气。我通常会在润色前加一句控制在原文基础上的微调不改变句子的核心结构和全部信息点只优化表达流畅度。这个约束很重要它划定了模型的修改权限。很多人用好润色功能的第一步不是学怎么写提示词而是先学会写一句“只做什么、不做什么”的边界指令。5. 常见问题与排查实录就算掌握了全部技法实际操作中还是免不了翻车。这里把我高频遇到的四类问题连同排查思路一起整理成速查表遇到问题可以对照着查。现象可能原因排查顺序与方法答非所问、输出无关内容任务描述含歧义模型猜测到了别的意图1. 用一句话复述你的提示词看是否与真实目标一致2. 增加任务背景3. 给出一个标准输出示例格式不稳定时好时坏输出要求描述过于抽象没有示例锚定1. 给出精确样例2. 增加“只输出XX格式”3. 把格式要求从自由文本改成明确的结构内容看起来像套话、缺乏细节约束太宽松没有禁止项背景信息太少1. 增加“不要使用……”禁区2. 补充项目背景3. 要求给出具体案例或数据模型一本正经胡说八道训练语料里缺少该领域信息模型用想象补全1. 先提供参考材料2. 增加“基于以下资料回答不要使用资料之外的信息”3. 强制要求“不知道就说不知道”模型记不住之前的要求上下文过长关键信息被挤出1. 每轮消息补充关键指令2. 压缩对话历史保留摘要3. 把核心要求放在每轮开头5.1 模型“理解偏了”时我一般先检查三个位置第一个位置是任务动词。模型偏了很多时候不是写得不清楚而是动词可能被模型理解成了多种含义。比如“总结一下”模型可能理解为“压缩”也可能理解为“提取重点”还可能理解为“写读后感”。这时把动词替换成更具体的表达比如“提取文中最重要的三个结论”效果立竿见影。第二个位置是背景信息。如果一个任务不带任何背景模型会用通用的常识和套路来补全这对垂直领域内容来说常常是灾难。模块化提示词里“背景”这一项就是为了解决这个问题。第三个位置是示例。没有示例的话模型对输出形态的猜测空间会大很多。我试过很多次同一个任务加一个示例前后效果差距就像换了一个模型。所以当你觉得“模型变笨了”优先怀疑的不是模型而是你的提示词里有没有足够多的约束条件可以降低模型的自由度。5.2 输出格式飘忽不定一个可落地的强制流程上面表格里提到过格式问题这里再展开讲讲我实际执行的强制流程。第一步在输出要求中指定“只输出目标格式”比如“只输出JSON”。第二步紧跟一个正确格式的示例最好用样例而非描述。第三步在约束里写明“禁止输出其他内容”很多模型会乖乖照做。第四步如果任务里有代码或特殊字符可以在提示词里写明“将JSON放入Markdown代码块中”或在代码块中指定语言。第五步也是最后一步如果运行环境允许打开对结构化输出的开关目前多数主流API平台提供JSON模式选项此时格式问题基本可以被系统层解决。还有一个容易被忽略的细节不要要求模型“既输出解释又输出JSON”。混着输出的结果通常既不好解析也不易读。要么纯JSON要么解释结构化内容分段放但两者应该明确分开不要交杂在一起。5.3 防幻觉的几种提示策略模型一本正经胡说八道本质上是它不知道答案但你要求它作答它只能用训练语料里具有“相似风格”的文本去补全所以看起来像模像样。防幻觉最有效的策略是“切断想象来源建立明确边界”。我在提示词里的固定写法是只能根据下面提供的资料回答不要使用资料之外的任何常识或记忆。如果资料中找不到答案直接回答“资料中没有相关信息”。这个限制一出模型就不敢轻易自由发挥生成内容基本会锁定在提供的材料范围内。很多RAG应用底层都在做类似的事情把相关资料检索出来后再用这句话把模型锚定在资料上。另一种防幻觉策略是“让模型先说明信息缺口”。比如在回答前先检查你拥有的信息是否足够支持结论。如果缺少关键信息请先列出你需要知道的内容避免直接输出不确定的结论。这个提示会让模型在做判断前多一步“信息核对”输出稳定性增加不少。5.4 温度参数与随机性什么时候调、怎么调提示词之外还有一个直接影响输出质量的参数温度temperature和top_p。温度用于控制生成随机性数值越高输出越发散数值越低输出越保守和确定。top_p做的是另一种采样控制作用类似。我自己的经验值场景温度建议top_p建议代码生成、数据提取、格式化输出0.2 - 0.30.7 - 0.9翻译、改写、稳定风格写作0.5 - 0.70.8 - 0.9头脑风暴、创意文案0.8 - 1.00.9有标准答案的问答0.1 - 0.30.7 - 0.8降低温度能显著减少格式漂移和重复输出但也会让内容变得无趣。创意场景想要意外之喜就需要适当提高温度。两条参数建议不要同时猛调先固定temperature用top_p做微调效果更容易掌握。很多模型的使用者连参数写在哪里都没找到就开始怪模型“太笨”——先检查参数再优化提示词顺序别搞反。6. 我的迭代调优流程与几条“抄作业”心得提示词不是一次写好的迭代才是常态。我自己有一个比较固定的优化流程分享出来供参考。6.1 一套可复用的五步调优路径第一步写下任务初稿不用讲究把目标和已知信息都放进去。第二步运行一次记录输出结果和失败点比如格式不对、内容太泛、风格偏了。第三步对应失败点针对性修改一个变量不要同时改多个东西否则根本不知道是哪个变量起的作用。第四步重新运行对比前后差异确认修改是否真正解决问题。第五步反复迭代直到输出稳定满足要求然后把最终版保存成模板。6.2 几条减少试错成本的实用心得第一条心得是“短提示词不如完整提示词”。一开始我迷信简洁“写一段招募文案”这种短提示效果完全随机后面加上受众、渠道、语气和示例输出质量才开始稳定。模型不会嫌你信息多前提是信息有条理。完整背景和精确任务描述是稳定输出的基础。第二条心得是“一次只改一个变量”。很多人调提示词时同时改角色、改句式、改示例、改参数输出变了但不知道是哪个改动起了作用效率极低。我会把提示词拆成固定模板和可变区域每次只调整一个区域其它区域保持不变这样每一次调整的反馈都很明确。第三条心得是“提示词也要版本管理”。我自己的提示词库是长期维护的每个模板记录创建日期、适用场景、最新版本效果方便回溯也方便横移到不同模型上测试。定期对比同一提示词在不同模型上的输出差异能发现哪些模型更适合哪些任务。第四条心得是“别神话技巧先确保任务清晰”。思维链、角色设定这些技法确实有用但它解决的是沟通效率问题不是任务定义问题。如果你自己都说不清楚要什么结果再花哨的提示词也救不了你。我在遇到效果不好时会先问自己如果让一个没有AI经验的人来做这个任务我会怎么向他说明如果能清楚说明那提示词多半也没大问题。最后分享一个小技巧把你自己觉得满意的历史回答当作“示例”存入下一次提示词中相当于模型用自己的好答案做自我校准这个做法我实测非常稳比凭空写示例要省力得多。提示工程说到底就是一门“把需求翻译成文本约束”的沟通手艺练习多了手感自然就来了。你现在最该做的是拿一个真实任务套用上面的模板跑一遍完整的迭代流程——跑完你就能直观感受到同样一个模型在精心设计的提示词面前输出水平能差出多少个量级。
