企业官网建设流程全解析

大模型用了一年多，我发现身边不少朋友对 Prompt 工程的理解还停留在"把话说清楚"这个层面。话是没错，但远远不够。同一个模型，同一件事，有人写三行字就能拿到能直接用的结果，有人来回改十几轮还是差点意思——差距往往不在文笔，而在有没有用对提示范式。Zero-shot、Few-shot、CoT 思维链，这三个词你可能天天在热搜上刷到，但真正能把它们用对场景、用出效果的人并不多。这篇就把这三套基础范式拆开讲透：它们各自解决什么问题、底层为什么有效、什么场景该用哪个、实际写的时候有哪些坑。不管你是刚接触 Prompt 的新手，还是已经写过一堆提示词但效果时好时坏的老手，都能从里面找到能直接抄作业的东西。

1. 先把三个范式摆到同一张桌子上

很多人学这三个概念是分开学的，结果脑子里是三个孤立的定义。我更建议先把它们放在一条连续的轴上理解，这样你才知道什么时候该往哪边挪。

1.1 它们本质上是"给模型多少信息"的三个档位

把大模型想象成一个刚入职、能力很强但完全不了解你公司业务的同事。Zero-shot 就是你直接甩一句"帮我写个周报"，他凭常识给你写；Few-shot 是你先给他看两份以前的周报当样例，他照着格式和风格写；CoT 则是你不仅给样例，还要求他"先列这周做了啥，再归类，再总结成三条"，把思考过程显式地走一遍。

所以这三者不是互斥的三选一，而是可以叠加的：Few-shot + CoT 就是既给样例又要求分步推理，这在复杂任务里是最常见的组合。理解这一点，后面所有的选型判断都会顺很多。

1.2 一张表看清三者的适用边界

这张表建议你存下来。实际工作中遇到一个新任务，先问自己两个问题：模型对这个任务熟不熟？任务需不需要多步推理？两个问题的答案基本就能定位你该从哪个档位起步。

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？我的经验是三条里中一条就该上：

1. 输出格式有严格要求（JSON、表格、特定模板）
2. 任务风格很特殊，文字描述说不清（比如某种品牌调性）
3. 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；不需要的（翻译、改写、简单分类），别上。

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 记录每次改动和结果

这一步很多人省了，但特别重要。你改了哪句话、效果变好还是变差，记下来。不然改到后面你自己都忘了哪版最好。我用一个简单的表格记：

有了这个表，你一眼就能看出哪次改动有效，哪次是白费功夫。

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，现在有些模型内置了推理能力，你只需要触发它。

所以与其焦虑会不会过时，不如把这三个范式的底层逻辑吃透。你理解了"为什么要给样例""为什么要分步"，无论模型怎么迭代，你都能快速找到对应的用法。这才是真正值钱的东西。

我自己现在的习惯是，每换一个新模型，都会拿这三个范式各跑一遍手头的典型任务，看看新模型在哪方面变强了、哪方面还需要提示词补。这个习惯帮我省了很多瞎调的时间。