提示词工程实战：从四块骨架到少样本与思维链

前阵子有个朋友跑来找我说外面把 AI 大模型说得天花乱坠他充值之后试了一周觉得也就那样——写出来的东西全是正确的废话。我把他的原始提问要过来看了一眼屏幕上就一句话帮我写个活动方案。没背景、没目标、没预算、没对象甚至连要什么格式都没说。看到这儿我就明白了模型没问题问题出在提示词。同一个大模型有人用得像个二十四小时在线的资深助理有人用得像个糊弄事儿的临时工区别往往不在会员套餐也不在模型版本而在于提示工程这门基本功有没有真正练到位。这篇内容不聊模型测评、不做工具对比只聊怎么把提示词写好。我会把平时自己反复在用的方法拆成几大块来讲为什么提示词这么重要、一份合格提示词的四块骨架是什么、少样本提示和思维链该怎么用、我踩过的高频坑有哪些以及提示词迭代的具体方法论。如果你是刚开始接触大模型的新手这篇文章可以帮你少走不少弯路如果你已经用得挺顺但总觉得差点意思里面几个细节也值得对照检查一遍。1. 同一个模型为什么有人用得像神有人用得像人工智障1.1 提示工程不是在命令模型而是在对齐模型先讲清楚一个底层逻辑。大模型的本质是一个根据上下文预测下一个词的概率系统。你给它一段文字它顺着你写的内容基于训练时见过的海量语料继续把后面最像样的文本补完。注意它不是在检索答案也不是在执行什么明确的指令协议而是在进行一种统计意义上的续写。所以你这个开头给的信息越多、越具体它的续写空间就越窄越容易落在你想要的区域里你给的越模糊它的选择就越多最后只能走向最平均、最安全也最没用的答案。这跟带新人其实是一回事。你扔一句把这个活动弄一下新人大概率只能按自己的理解随便弄你把背景、目标、预算、对象、交付时间、不要做什么都交代清楚他才知道往哪个方向使劲。大模型也一样它甚至比新人更需要结构化的交代因为它没有你的行业经验也不会主动追问你。提示工程本质上就是在做这件事把脑中的模糊需求翻译成模型能听懂、能执行的清晰指令。1.2 一个反直觉的小测试提问的颗粒度决定回答的质量拿同一个问题实测一下。你直接问AI 大模型是什么模型会给你一段四平八稳的定义式回答先解释概念再说几个特点最后补一句未来可期。信息没错但你把这段拿去发给任何人都建立不了沟通。换成下面这种写法呢假设你要给一位完全没有技术背景的餐饮店老板解释AI 大模型是什么。 要求 1. 不要使用任何专业术语 2. 多用餐饮行业能理解的类比 3. 控制在 300 字以内 4. 先讲它是什么再讲他能用它解决什么具体问题 5. 最后给一句现在就能上手的行动建议。同样一个模型背后知识一点没变但第二次输出会明显活起来——它知道听众是谁、篇幅多长、结构怎么排、结束语该落在哪。对比起来大概是这样的对比维度第一种回答第二种回答内容结构概念定义式起承转合式面向场景术语浓度高默认面向技术人员低懂的类比落地程度泛泛而谈有明确的下一步行动换个听众复用基本没法直接用换行业类比即可复用核心不是模型变聪明了而是约束变多了。提示词里每一条具体要求都在压缩模型的选择范围把生成结果往你真正想要的方向推。很多人觉得提示词嘛就是多说几句话其实更准确的说法是提示词是给模型画一条更窄的跑道。1.3 衡量提示词质量的三个维度可执行、可约束、可复现跟模型打交道的次数多了我习惯用三个维度快速判断一条提示词好不好。第一是可执行。模型看完提示词能不能明确知道要干什么如果它还得靠猜说明指令不够具体。帮我润色这段话是可执行的但只执行了一半把这段话改得更正式保留所有事实信息控制在一段以内不要加新观点才是完整可执行。第二个是可约束。提示词里有没有足够的限制条件让输出收敛限制可以是字数、格式、角度、禁止项、优先级。约束越多偏离你预期越难。很多人说模型乱发挥多数时候是提示词里压根没写边界。第三个是可复现。同一段提示词今天跑和明天跑输出水准是不是稳定可复现性决定了这件事能不能工程化。如果同样输入时好时坏绝大多数情况是提示词里有大片的模糊空间模型每次都在不同的平均答案之间随机摇摆。用这三个维度去检查现有提示词基本一眼就能看出短板在哪。2. 提示词的四块骨架角色、任务、上下文、输出格式调了这么多提示词我发现再复杂的提示词拆开看都是四块拼起来的角色、任务、上下文、输出格式。掌握了这四块你就有了自己的提示词骨架。2.1 角色设定为什么你是一个……真的有用很多人觉得角色设定是玄学其实它有明确的机理。在海量训练语料里模型见过太多带有身份标签的内容专家写的文章、客服的话术、医生的诊断建议、程序员的技术回复。你给出你是一名资深儿科医生模型就把后续生成往儿科医生表达方式这个统计方向引导——措辞更谨慎、结构更像专业建议、甚至会用儿科领域的表达习惯。它不是真的变成了医生但它会按训练数据里医生回答的样子来回答你。角色设定的细节有两个。一是角色要和任务匹配让一个营销专家去写代码它只会写出看起来像代码的文本因为它的知识区域被引导到了不对的地方。二是最好顺便交代你是谁和在什么场景下用。同样的专业建议讲给普通顾客和讲给同行的写法完全不一样。比如你问帮我看下这段 Python 代码有什么问题如果补一句我是一名刚入门的开发者请用通俗的方式解释模型的表达方式会立刻降低难度。2.2 任务描述把模糊诉求翻译成可执行的指令任务描述是四块骨架里最核心的。很多人的提示词里全是名词文案方案总结一个动词都没有。模型得到的指令其实是给我一个关于这些东西的文本它当然只能给最平庸的版本。合格的任务描述要让模型明确四件事做什么、对什么做、做到什么程度、交付成什么样。举个例子。你说这段文案帮我改一下模型只会给一个不痛不痒的版本。你可以这样写请把下面这段产品文案改写得更简洁有力 1. 删除形容词堆砌每句不超过 20 字 2. 保留原文的核心卖点 3. 结尾加一句行动号召 4. 按修改前 / 修改后 / 改了什么三列表格输出。差别在哪第一版只有改这个动作好坏的判定标准全在模型手里第二版给了明确的动作改写、明确的尺度每句不超过 20 字、明确的结果三列表格。模型不需要猜也就没机会用平庸的默认风格糊弄你。2.3 上下文注入让模型站在正确的信息环境里同样一句帮我分析一下这个数据后面跟一张只有两列的表和跟一张带用户分群、时间周期、活动标记的表模型给出的分析深度完全不同。上下文就是模型的临时记忆你希望它的回答建立在哪些事实上就要主动把这些事实写进提示词里。但上下文不是越多越好。上下文窗口是有限的而且很多模型对长文本中间位置的信息敏感度会下降塞进去一堆无关背景等于稀释有效信息。我的习惯是最关键的背景事实紧挨着任务描述放次要信息放后面与回答无关的内容一律不贴。另外如果要让模型处理一段原文最好用分隔线把它标出来明确告诉模型下面是要处理的原料以下是要处理的原文 --- 原文内容 --- 请完成上面的改写要求不要改动不属于原文的部分。这样模型不容易把分隔线两侧的信息混在一起。很多人多轮对话越聊越乱就是因为原料和指令混在一起模型分不清哪些东西该参考、哪些只是过程。2.4 输出格式约束从一坨字变成你要的结构格式约束是最容易被忽略、但性价比最高的一层。大部分人不写格式模型就会用大段文字总分结构这种默认形式输出阅读成本高也没法直接进下游流程。格式约束可以有很多种用 markdown 表格呈现输出 JSON字段按指定命名先一句话结论再分点解释控制在 500 字以内按 1、2、3 编号每条不超过三行。如果你想把模型接入自动化流程比如批量生成商品描述后同步到店铺后台那格式就不仅是好看的问题而是能不能机器解析的问题。我一般会直接要求模型输出 JSON并给出字段定义请输出 JSON格式为 { title: string, description: string, keywords: string[] } 只输出 JSON 本身不要输出任何解释或多余文字。把这一条写进提示词之后模型输出的东西可以直接被程序读取省去大量清洗工作。你要把它理解为格式约束不是在限制模型是在替下游省麻烦。2.5 一个完整骨架示例把这四块拼起来看一个我实际保存过的模板角色你是一名有 8 年经验的电商运营擅长新品冷启动。 背景我经营一家线上灯具店主打一款可调光、可语音控制的床头灯 目标用户是 25-35 岁租房年轻人。 任务为这款灯写一条抖音短视频的 30 秒口播脚本。 要求语气轻松口语化前 3 秒必须有钩子 突出租房也能轻松提升幸福感这个点 不夸大功能不出现价格。 输出格式按开头钩子 / 产品展示 / 使用场景 / 行动号召四个段落输出 每段不超过 80 字。拆开看第一行是角色第二到五行是背景再往下是任务和要求最后是输出格式。这个提示词不需要多长但每一句都在限制模型的选择空间。实际跑下来输出基本不需要大改。我把这套骨架保存成了模板换个产品名、换个平台风格就能复用后面会细说模板库的建立方法。3. 从零样本到少样本让大模型照葫芦画瓢的正确姿势3.1 零样本提示默认能力够用但容易跑偏什么叫零样本提示就是只给任务描述不给任何例子。对翻译、总结、改写这类通用任务零样本完全够用因为模型在训练阶段见过太多类似语料你一张嘴它就知道你要什么。但你一旦进入有特定口吻、特定结构、特定判定标准的任务零样本就容易跑偏——它会默认输出大众均值风格而不是你想要的风格。这里打个比方。你让一个实习生按公司风格写周报他大概率会写一份四平八稳但完全不像公司风格的周报。你要是直接甩给他两份上一任同事写的标准周报他照着的样子来写风格立刻就对上了。对模型来说这个甩样子的操作就是少样本提示。3.2 少样本提示给模型几个输入-输出对把标准立起来少样本提示的写法是在任务描述后面加上几个输入-正确答案对然后再抛出一个新的输入让模型照着示例的风格和判断标准去作答。举个例子我想让模型做用户评论的情感分类请对用户评论进行情感分类只输出以下三种之一满意、一般、不满。 示例 1 评论包装很用心拆开的时候太惊喜了会回购。 分类满意 示例 2 评论物流有点慢但东西本身还行。 分类一般 示例 3 评论收到就发现有一个角磕坏了客服半天不理人。 分类不满 评论客服态度很好但是发货确实是太慢了前后等了八天。 分类这里最有价值的是中间那条有褒有贬的示例。模型看完前两个极端案例可能学到的规律是带负面词就归为不满但看到示例 2 之后它就明白了轻微不满但整体能接受要归为一般判定边界一下清楚了。文字指令说一百遍注意区分主次情绪不如给一个边界样本来得直接。3.3 样本数量、排序与选择的讲究少样本是不是越多越好不是。对大多数任务两到五个高质量示例就能把风格和边界立起来继续加样本收益递减还会带来两个副作用一是消耗上下文窗口和生成成本二是噪声样本会干扰模型。我自己的经验是超过八个示例以后效果提升非常有限那时候更应该考虑的是微调而不是继续堆提示词。样本的排列顺序也很有讲究。模型对靠近末尾的内容记忆更深刻存在明显的近因效应。如果你希望模型特别重视某条规则或某种风格把它放在最后一个示例的位置比放在开头更有效。很多人踩过这个坑费劲挑了最好的样例放在第一条收尾时却放了一条风格跑偏的结果模型全学成收尾那条的样子前功尽弃。选择示例时还要注意覆盖边界情况而不是只放最典型的极端案例。做情感分类不能只给明显好评和明显差评要专门放一条有褒有贬的模型才能学会你的判定标准。做内容生成也一样如果示例全是同一种结构模型会以为世界只有这一种结构。3.4 坏样本比没有样本更可怕少样本是一把双刃剑。示例一旦写错模型的错误会被放大而且它往往更相信示例而不是你的文字指令。我见过一个典型的翻车指令里明明写了只输出分类结果但示例里每条后面都跟了一行原因分析模型最终把原因分析也带进了输出。这解释了为什么很多人在实际使用中会遇到我说东它偏往西——不是模型叛逆是示例把它带偏了。所以给示例之前务必像审查代码一样审查示例标签对不对、格式对不对、风格是否统一、边界是否合理。另外示例和真实任务之间的距离越近越好。你是做跨境电商的就别拿国内电商的客服话术当示例语言习惯和场景对不上迁移效果会大打折扣。我现在的习惯是每次要调少样本提示先写下参考示例再把示例当作检测标准去倒查任务描述两边对得上了才跑。4. 思维链让大模型把推理过程写出来4.1 为什么直接给答案容易在推理任务上翻车直接让模型做数学题或逻辑题它经常会在看起来很自信的地方出错。原因在于模型默认的续写习惯是尽快给一个形式完整的答案它会在中间步骤还没算出来之前就跳到结论于是出现了那种一本正经的错误步骤全对、结论错或者结论对、但解释全靠编。举个简单例子。你直接问一个水池进水管单独开 3 小时可以灌满出水管单独开 4 小时可以放空。两管同时打开多长时间能灌满模型可能会凭直觉给出一个看起来差不多的数字比如 1 小时或者 7 小时因为它跳过了中间计算。但如果你要求它一步一步思考结果就完全不一样——它先把每小时进水量算成 1/3、出水量算成 1/4再算差值 1/3 减 1/4 等于 1/12最后得出 12 小时。中间过程一旦被显式写出来错误就被暴露了正确率自然上去了。4.2 思维链的标准用法先列步骤再给结论思维链提示的标准做法是在任务描述里明确要求模型先给出推理过程再给出最终结论。中文环境下我通常这样写请一步一步分析 1. 先列出已知条件和需要求解的目标 2. 写出每一步的计算过程 3. 得出最终结论并在结论前加答案。这里的每一步都对应模型实际要做的工作列条件是为了让它准确提取信息写过程是为了给中间计算留出草稿纸加答案是为了把结论和过程分开。对模型来说过程不是装饰而是让推理有地方落脚。很多复杂任务里错误往往发生在过程中途强制写出过程能把错误拦截在早期。还有一种更强的方式是在少样本提示里直接放一个带推理过程的示例问题小明买一本书花 20 元又买一支笔花 5 元最后口袋里还剩 8 元他原来有多少钱 思考花的钱是 20 5 25 元剩 8 元原来有 25 8 33 元。 答案33 元 问题你的问题模型看过一个先思考后答案的完整样本就会照着同样的结构输出。这比单纯要求写出步骤更稳定因为它连步骤长什么样都照出来了。4.3 零样本思维链一句请一步一步思考就够了更省事的是零样本思维链不用给例子只要在问题后面加一句请一步一步思考推理能力通常就会有明显提升。这是提示工程研究里一个非常经典的现象背后逻辑也不复杂——这句话等于给模型一个明确的信号别急着收尾把中间状态写出来。中文环境下我习惯写得更完整一点请一步一步思考并在最后给出结论。在此基础上如果你要的答案非常关键还可以用上多次推理取多数的思路同一个问题独立跑三到五次每次都要求完整推理最后把结果取多数。大模型推理本身带有随机性单次生成可能有偶然失误多个推理路径互相印证能过滤掉不少错误。代价是时间和 token 消耗所以我的使用习惯是重要决策场景才用日常聊天犯不着。4.4 思维链不是万能的什么时候反而别用思维链的能力再强也不是所有场景都适合。第一简单任务别用翻译、改写、提取关键词这类任务加思维链纯属浪费输出长度模型反而可能把一个简单结论包装得很啰嗦。第二创意写作别死用请它一步一步分析之后再写文案产出的文字会变得僵硬少了自然感和灵气文案创作更适合直接给风格示例。第三输出空间受限时慎用模型有输出上限思维链会占用大量额度导致最终结论被截断。第四非推理问题上别硬解释你让它解释一个凭经验判断的事它会为了自洽而编造理由这种合理但不正确的灾难比直接犯错更隐蔽。我的判断标准很简单需要算、需要推、需要做多步决策的任务用思维链需要感、需要风格、需要信息提取的任务不用。心里有这条线之后你基本不会再被那种一本正经胡说八道的结果气到。5. 实测翻车现场六个高频错误与急救方案下面这些坑是我在过去大半年里从自己和身边人最常在真实使用中踩到的问题里筛出来的。每个都给出症状、根因和可以直接套用的改法。5.1 问题一只给主题不给动作全是名词写周报做计划写文案这类提示词全是名词没有明确动作和标准。模型能做的只有给一个叫这个名字的东西这当然是最平庸的版本。急救方案是补上动作、对象和衡量标准。把帮我写一份本周周报改成请根据我下面列出的本周工作和数据写一份周报 结构为本周进展 / 数据表现 / 问题与风险 / 下周计划 数据必须用列表呈现语气客观不要夸大 总字数控制在 400 字以内。5.2 问题二把三件事拧在一个提示词里帮我总结这份报告然后翻译成英文再写一封邮件发给客户。这种一条龙式提示词模型往往只做第一件或混着做后面两件被敷衍带过。原因是模型缺乏任务编排能力多任务挤在一起时容易顾此失彼。急救方案是拆开调用或者用清晰的流程结构请按以下顺序处理 第一步总结下面的报告输出 200 字中文摘要 第二步把摘要翻译成英文 第三步将英文摘要改写为一封语气正式的邮件正文。 每一步都单独标出标题不要混在一起。5.3 问题三只让做不说边界给我几个推广渠道模型能列十条出来但里面有一半不适合你。不是它笨是你没告诉它边界。急救方案是把限制条件量化预算多少、面向谁、在哪个城市、什么时间节点、不要什么渠道。改成请推荐 5 个适用于二线城市大学生群体的推广渠道。 预算 5000 元以内 优先线上渠道不考虑线下地推 每个渠道给出推荐理由和预估成本。边界一旦给足模型的筛选能力立刻被激活输出的可用性完全不一样。5.4 问题四把大模型当搜索引擎问2026 年最新政策是什么现在某个城市的房价走势模型没有实时联网能力时会基于过时的训练数据自信地编一个答案看起来还特别像真的。急救方案分两步一是明确告诉它只基于已有知识回答并标注信息来源不确定的地方允许它诚实地说不知道二是不确定的信息主动开启联网检索能力或单独去查。让模型承认不知道不是示弱反而是防止幻觉的最有效手段。我会直接在提示词里写如果你不确定答案请直接说我不确定不要猜测。基于你截止到训练数据的知识回答并注明这一点。5.5 问题五同一个会话里前文把后面的回答带偏了多轮对话里前面聊了别的话题后面再问正事模型还在延续前面的口吻或思路。这是典型的上下文污染。急救方案有两种轻度污染时在消息里先重置忽略上面所有的对话内容以下是一个全新的任务……再输入新需求污染严重时干脆新开一个会话。会话隔离是成本最低、效果最确定的操作很多人忽略了。5.6 问题六输出格式没约定拿回来的东西没法直接用批量生成内容时模型输出一长段自然语言夹杂注释程序无法解析人工还得二次清洗。急救方案是明确给格式契约并禁止附加内容。我写过的最有效的一句是只输出 JSON不要输出任何解释、注释或 Markdown 代码块标记。别小看这句它能从根上解决解析问题。输出格式约定这件事在提示词里常常只占一句话的位置但对下游效率的影响是决定性的。6. 好提示词是调出来的不是想出来的6.1 拿到不理想的结果先判断问题出在哪一层遇到糟糕的输出别急着把整个提示词重写。先判断是哪一层出了问题再精准修改。我通常按下面这个对照表来定位症状可能出问题的层修改方向内容空泛、像百科词条任务或上下文补充具体场景、目标、约束风格不对、口吻不像角色设定换角色或补少样本结构混乱、没法用输出格式明确格式、段落、字数越聊越偏、答非所问上下文新开会话或重置逻辑硬伤、算错推理要求加思维链引导结果不稳定、时好时坏示例或约束加高质量少样本、补边界定位之后一次只改一个变量。很多人效果不稳定是因为同时改了三四个地方效果变好了都不知道是哪个改动起了作用下回翻车还得从头试。6.2 三个高性价比的修改动作加约束、换视角、给示例如果不知道从哪里下手我用得最多的是这三招。第一招加约束。把范围、字数、格式、禁止项一项项列出来是最快的收敛手段。第二招换视角。让模型从读者、用户、对手的角度回答有时候效果极其明显。比如你写了一条宣传文案可以问如果你是目标客户看到这条文案会不会下单为什么模型的反馈比直接问这条文案怎么样有价值得多。第三招给示例。有时候示例比任何形容词都管用直接甩一段你理想中的样稿说照着这个风格来比描述三遍要有网感、要年轻化都有效。这三招可以单独用也可以组合但记住一次只动一处。6.3 建立自己的提示词模板库调好的提示词不要每次重新敲一遍攒成模板。我自己按场景分类存了一套每套都是固定的四段骨架角色、背景、任务、输出格式。大致是这个结构场景模板骨架复用方式短视频脚本角色 平台风格 时长 内容钩子要求换产品名周报总结角色 项目背景 本周事件 格式要求换事件内容代码审查角色 语言 代码 关注点 格式换代码片段文档润色角色 原文 改法要求 格式换原文文档模板库的意义不只是省时间它让你的提示词质量有了一个基准线。每次新建任务都以模板为起点而不是从零开始裸写出错的概率低得多。6.4 记录变更是最容易被忽略的工程习惯调提示词最忌讳凭感觉这版感觉好一点——到底好在哪里改了什么导致的完全说不清。我现在会把每次改动的文本和对应输出都记录在案哪怕只是存到一个备忘录里。改了一个字输出变了你要能对得上是哪次改动引起的。有了这个版本记录你对模型行为的理解会越来越准从玄学调参转向工程迭代。这个习惯还有一个附带好处翻车记录本身就是最好的教材。我保存过很多今天这个写法不行的案例过两个月翻出来看能很清楚地看到自己是怎么一步步把提示词调好的。7. 写在最后提示工程其实是委托能力的延伸做了几年 AI 应用我的体会是提示工程学到后面练的不是跟机器打交道的技巧而是把一件事说清楚的能力。你越清楚自己要什么、边界在哪里、交付物长什么样你和模型的配合就越顺。这个能力放到现实中带团队、写需求文档、跟同事沟通一样是通用的。反过来如果你现实中交代事情就喜欢含糊其辞那模型给你的回应也会同样含糊——它只是把你给的模糊感放大了一百倍还给你。如果你今天看完只想记住一个动作我建议先记住那四段骨架角色、背景、任务、输出格式。下次不管给模型提什么问题先在脑里过一遍这四层哪怕只补上其中任意一层输出的变化都会极其明显。等这四层成了习惯再往里加少样本、思维链、版本记录这些进阶工具你会发现自己已经从一个用模型的用户变成了一个把模型使明白的人。