大模型用了一年多我发现身边不少朋友对 Prompt 工程的理解还停留在把话说清楚这个层面。话是没错但远远不够。同一个模型同一件事有人写三行字就能拿到能直接用的结果有人来回改十几轮还是差点意思——差距往往不在文笔而在有没有用对提示范式。Zero-shot、Few-shot、CoT 思维链这三个词你可能天天在热搜上刷到但真正能把它们用对场景、用出效果的人并不多。这篇就把这三套基础范式拆开讲透它们各自解决什么问题、底层为什么有效、什么场景该用哪个、实际写的时候有哪些坑。不管你是刚接触 Prompt 的新手还是已经写过一堆提示词但效果时好时坏的老手都能从里面找到能直接抄作业的东西。1. 先把三个范式摆到同一张桌子上很多人学这三个概念是分开学的结果脑子里是三个孤立的定义。我更建议先把它们放在一条连续的轴上理解这样你才知道什么时候该往哪边挪。1.1 它们本质上是给模型多少信息的三个档位把大模型想象成一个刚入职、能力很强但完全不了解你公司业务的同事。Zero-shot 就是你直接甩一句帮我写个周报他凭常识给你写Few-shot 是你先给他看两份以前的周报当样例他照着格式和风格写CoT 则是你不仅给样例还要求他先列这周做了啥再归类再总结成三条把思考过程显式地走一遍。所以这三者不是互斥的三选一而是可以叠加的Few-shot CoT 就是既给样例又要求分步推理这在复杂任务里是最常见的组合。理解这一点后面所有的选型判断都会顺很多。1.2 一张表看清三者的适用边界范式给模型的信息量典型适用场景主要成本Zero-shot只有任务指令通用任务、模型已充分训练的能力结果不稳定格式难控Few-shot指令 若干输入输出样例格式固定、风格特定、分类任务消耗上下文长度样例选择敏感CoT指令 分步推理要求可叠加样例数学、逻辑、多步推理、复杂决策输出变长简单任务反而变差这张表建议你存下来。实际工作中遇到一个新任务先问自己两个问题模型对这个任务熟不熟任务需不需要多步推理两个问题的答案基本就能定位你该从哪个档位起步。1.3 为什么档位这个视角比定义更有用因为真实项目里你几乎不会只用一种。比如做一个合同信息抽取你可能会先用 Few-shot 固定输出格式再对其中判断条款是否对己方不利这种需要推理的子任务加 CoT。如果只记定义你会纠结这到底算 Few-shot 还是 CoT用档位视角你只会关心这一步我需要给模型补什么信息。我见过太多人卡在概念分类上反而耽误了真正该做的调优。记住范式是工具不是考试题。2. Zero-shot别小看什么都不给的难度Zero-shot 看起来最简单其实最考验你对任务描述的精准度。因为模型没有任何参照全靠你的指令去对齐它的理解。2.1 Zero-shot 真正难在哪难在你以为说清楚了其实没有。比如总结一下这篇文章模型不知道你要多长、给谁看、要不要保留数据、要不要带观点。它只能猜而猜的结果十有八九不是你要的。我自己的经验是Zero-shot 的提示词里至少要交代清楚四件事任务是什么、输出给谁看、输出什么格式、有什么约束。这四件事缺一件结果就会飘。举个具体的请把下面这段产品介绍改写成给非技术用户看的版本。 要求 - 面向完全没有技术背景的普通消费者 - 控制在 150 字以内 - 不使用任何专业术语如果必须用要加一句大白话解释 - 语气亲切不要用感叹号对比一下帮我改写得更通俗一点你会发现前者几乎不需要二次修改后者你得来回好几轮。差别就在于约束是否显式。2.2 指令的颗粒度怎么把握颗粒度太粗模型自由发挥太细又容易把模型框死反而写出机械的答案。我的判断标准是凡是结果对不对取决于它的必须写死凡是风格好不好的给方向就行。比如做数据清洗输出必须是合法 JSON这个必须写死甚至要给字段名和类型。但如果是写营销文案你只需要说活泼一点、面向年轻人具体怎么活泼交给模型它往往比你规定得更自然。2.3 一个常被忽略的技巧用角色 任务 约束三段式这是 Zero-shot 里最稳的结构我几乎在所有简单任务里都用角色你是一位有十年经验的财务分析师任务请分析下面这份利润表指出三个最值得关注的问题约束每个问题用一句话说明并给出对应的数据支撑不要泛泛而谈角色不是玄学它的作用是帮模型快速定位到某个知识分布和表达风格。你让它当财务分析师它调用的就是财务领域的表达习惯和关注点比你不给角色要准得多。提示角色要具体到领域 经验层级你是一个助手这种等于没写。3. Few-shot样例给对了效果翻倍给错了全盘皆输Few-shot 是我在工程里用得最多的范式因为大部分业务任务都需要固定格式和特定风格而这些靠文字描述很难说清给两个样例模型立刻就懂了。3.1 样例数量不是越多越好很多人一上来就给十个样例觉得越多越准。实测下来3 到 5 个高质量样例通常就够了再多边际收益很低还白白吃掉上下文长度。更重要的是样例的覆盖度而不是数量。什么叫覆盖度就是你的样例要覆盖任务里可能出现的各种情况。比如做情感分类你不能五个样例全是正面和负面得有一个中性或者模棱两可的否则模型遇到边界情况就懵。3.2 样例的顺序会悄悄影响结果这一点很多人不知道。模型对样例顺序是有敏感性的尤其是分类任务。如果你把某一类的样例都放在前面模型可能会轻微偏向这一类。我的做法是打散顺序让各类样例交替出现减少位置偏差。另外最后一个样例的影响往往最大因为它离你的真实输入最近。所以如果你有特别想强调的格式或风格把它放在最后一个样例里。3.3 样例的格式必须和真实输入完全一致这是踩过坑才知道的。有一次我做信息抽取样例里的输入是规整的短句结果真实数据里全是带各种符号和换行的长文本模型直接崩了输出格式全乱。后来我把样例换成和真实数据同分布的长文本问题立刻解决。所以给样例前先看一眼你的真实输入长什么样样例必须长得像它。格式、长度、噪声程度都要接近模型才能泛化过去。3.4 Few-shot 和 Zero-shot 的取舍判断什么时候该上 Few-shot我的经验是三条里中一条就该上输出格式有严格要求JSON、表格、特定模板任务风格很特殊文字描述说不清比如某种品牌调性Zero-shot 试了两三次还是不稳定反过来如果任务很通用、格式随意、模型本来就擅长那就别浪费上下文Zero-shot 直接上。4. CoT 思维链让模型想出来而不是猜出来CoT 是这三个里最容易被神化也最容易被误用的。它的核心思想很简单让模型把推理过程写出来而不是直接给答案。但什么时候用、怎么用讲究很多。4.1 CoT 为什么有效把隐式计算变成显式步骤大模型本质上是逐 token 生成的它没有真正的思考过程。当你直接问一个多步问题它必须在一次前向计算里把答案蹦出来中间步骤全被压缩了容易出错。CoT 的做法是强制它把中间步骤一个个写出来。每写一步这一步的结果就变成了下一步的输入条件相当于把一个大计算拆成了多个小计算。这就是为什么在数学、逻辑、多步推理任务上加了 CoT 之后准确率能明显提升。用个类比你让一个人心算 37 乘 24他可能算错但你让他拿纸笔一步步写正确率立刻上去。CoT 就是给模型递了张纸。4.2 最简 CoT一句话触发最简单的 CoT 甚至不需要样例只要在提示词末尾加一句请一步一步思考并展示你的推理过程最后再给出结论。这一句话在很多任务上就能带来明显提升。但要注意展示推理过程和给出答案要分开要求否则模型可能把推理和答案混在一起你提取结果时很麻烦。4.3 Zero-shot CoT 和 Few-shot CoT 的区别Zero-shot CoT只加一步步思考的指令不给推理样例。适合模型本身就会推理、只是没被激发的情况。Few-shot CoT给几个带完整推理过程的样例让模型模仿推理的格式和深度。适合推理路径比较特殊、或者你希望推理风格统一的情况。Few-shot CoT 的样例里推理过程要写得像人话不要跳步。我见过有人样例里推理写得太简略结果模型也学着跳步最后还是错。4.4 CoT 的适用边界不是所有任务都该用这是最重要的一点。CoT 在需要多步推理的任务上有效但在简单任务上反而可能变差。原因有两个一是简单任务本来一步就能出结果强行分步反而引入噪声二是输出变长模型有更多机会想多了跑偏。所以判断标准是这个任务人需不需要打草稿需要打草稿的数学、逻辑、规划、复杂判断上 CoT不需要的翻译、改写、简单分类别上。任务类型是否建议 CoT原因数学应用题强烈建议多步计算中间易错逻辑推理强烈建议需要逐步排除情感分类不建议一步判断加了反而飘文本翻译不建议直接映射无需推理复杂决策分析建议需要权衡多个因素5. 三者组合真实项目里没人只用一种讲完三个单独的范式该说说组合了。真实项目里尤其是稍微复杂一点的任务几乎都是组合使用。5.1 Few-shot CoT复杂任务的标准配置这是最常用的组合。样例里既包含输入输出又包含推理过程。模型既学到了格式又学到了推理路径。写这种样例时有个技巧推理过程要写得比实际需要稍微详细一点给模型留出模仿空间。但也不能太啰嗦否则模型会学得又臭又长。我的经验是推理步骤控制在 3 到 6 步之间比较合适。5.2 分层使用不同子任务用不同范式一个复杂任务往往可以拆成几个子任务每个子任务用最适合它的范式。比如做一个从用户反馈里提取问题并判断优先级的任务第一步提取问题用 Few-shot 固定输出格式第二步判断优先级用 CoT因为需要权衡影响范围和紧急程度第三步生成回复建议用 Zero-shot因为格式随意、模型擅长这样拆开之后每一段都更可控出问题也容易定位是哪一步的锅。5.3 组合时的上下文预算管理组合用得多上下文消耗就快。这时候要有预算意识样例不是越多越好推理不是越细越好。我一般会先跑一版看哪部分对结果影响最大把预算往那部分倾斜其他部分能省则省。注意上下文塞太满模型对中间部分的注意力会下降反而影响效果。宁可精简不要堆砌。6. 那些文档里不会写的实操坑前面讲的都是方法论这一节讲点真金白银踩出来的经验。6.1 样例里的错误会被模型完美复制这是最坑的一点。你样例里但凡有个错别字、格式不一致、逻辑小错误模型会一丝不苟地学过去。所以样例给出去之前一定要逐字检查。我现在的习惯是样例写完先自己当模型跑一遍看有没有歧义。6.2 指令和样例冲突时模型往往听样例的如果你文字里说输出用中文但样例全是英文模型大概率跟着样例走。所以指令和样例必须一致不能打架。这个坑我在做多语言任务时踩过改了半天指令没用最后发现是样例语言不对。6.3 CoT 的推理过程可能看起来很对但结论错模型写出来的推理过程是它生成的不是它真实计算的。所以它可能写出一段逻辑通顺但结论错误的推理。这时候不能只看推理像不像样必须验证结论。我的做法是让模型给出结论后再单独问一遍这个结论对吗请检查相当于让它自查一次。6.4 温度参数和范式要匹配Zero-shot 想要稳定输出温度调低CoT 想要多样推理温度可以稍高。但很多人调范式的时候忘了调温度结果效果忽好忽坏。这两个是要一起调的。6.5 别指望一次写对迭代才是常态我写过的提示词几乎没有一次成型的。都是先写一版跑一批测试数据看哪类错得多针对性改再跑。这个过程通常要三到五轮。所以别追求一次写出完美提示词追求快速迭代到能用。7. 从零搭一套自己的提示词测试流程光会写还不够你得能验证写得好不好。这一节讲怎么搭一个简单的测试流程。7.1 准备一批有代表性的测试样本不用多20 到 50 条就够但必须覆盖各种情况典型的、边界的、容易出错的。这批样本是你判断提示词好坏的唯一依据比拍脑袋感觉靠谱得多。7.2 定义清楚的评判标准什么叫好是格式对、内容准、还是风格像不同任务标准不同。我一般会列三到五条硬标准比如输出必须是合法 JSON关键字段不能漏语气符合要求逐条打分。7.3 记录每次改动和结果这一步很多人省了但特别重要。你改了哪句话、效果变好还是变差记下来。不然改到后面你自己都忘了哪版最好。我用一个简单的表格记版本改动内容通过率主要问题v1初始版本60%格式偶尔错v2加了一个格式样例85%边界情况漏字段v3补了边界样例95%基本可用有了这个表你一眼就能看出哪次改动有效哪次是白费功夫。7.4 什么时候算够用不要追求 100% 通过率那通常意味着你过拟合到测试集了。我的标准是核心场景全过边界场景大部分过错误可接受且可兜底。剩下的交给后处理或者人工兜底比无限调提示词划算得多。8. 几个真实场景的完整提示词拆解理论讲完来看几个能直接抄的例子。8.1 场景一结构化信息抽取Few-shot你是一位专业的信息抽取助手。请从下面的文本中抽取指定字段输出 JSON。 字段说明 - name: 人名字符串 - company: 公司名字符串没有则填 null - role: 职位字符串没有则填 null 示例1 输入张三在字节跳动担任产品经理。 输出{name: 张三, company: 字节跳动, role: 产品经理} 示例2 输入李四最近离职了暂时没有新东家。 输出{name: 李四, company: null, role: null} 现在请处理 输入王五加入了美团负责骑手运营。这个例子的关键点字段说明写清楚、样例覆盖了有值和null两种情况、格式严格一致。8.2 场景二多步推理判断CoT你是一位资深运营分析师。请判断下面这条用户反馈的紧急程度高/中/低并说明理由。 请按以下步骤思考 1. 这条反馈涉及的问题影响多少用户 2. 问题是否影响核心功能 3. 是否有替代方案 4. 综合以上给出紧急程度。 反馈内容今天下午开始所有用户都无法登录提示密码错误但我们后台看密码没问题。这个例子里步骤是显式给出的模型会照着走。对于判断类任务把判断维度列出来比让它自由发挥稳定得多。8.3 场景三风格化改写Zero-shot 角色你是一位有十年经验的科技媒体编辑擅长把技术内容写得让普通人也能看懂。 请把下面这段技术说明改写成面向普通读者的版本 - 控制在 200 字以内 - 不使用专业术语 - 用一个生活化的类比帮助理解 - 语气平实不夸张 技术说明本系统采用分布式架构通过一致性哈希算法实现数据分片并利用多副本机制保证高可用性。这个例子没有样例全靠角色和约束把方向定死。对于改写类任务角色 约束的组合往往比给样例更灵活。9. 关于提示词工程会不会过时这件事最后聊个大家常问的问题。总有人说模型越来越强提示词工程迟早没用。我的看法是基础范式不会过时但具体技巧会不断更新。Zero-shot、Few-shot、CoT 这三个东西本质上是在解决如何把任务信息有效地传达给模型这个根本问题。只要模型还是通过上下文来理解任务这个问题的解法就不会消失。变的只是形式——以前要手写 CoT现在有些模型内置了推理能力你只需要触发它。所以与其焦虑会不会过时不如把这三个范式的底层逻辑吃透。你理解了为什么要给样例为什么要分步无论模型怎么迭代你都能快速找到对应的用法。这才是真正值钱的东西。我自己现在的习惯是每换一个新模型都会拿这三个范式各跑一遍手头的典型任务看看新模型在哪方面变强了、哪方面还需要提示词补。这个习惯帮我省了很多瞎调的时间。