老实说，我第一次被问到“你掌握哪些 Prompt Engineering 范式”的时候，是有点懵的。在那之前，我自认为提示词写得挺溜——角色扮演、格式约束、给几个 few-shot 示例，效果都还不错。但面试官问的不是“你提示词写得怎么样”，而是直接问范式。那一瞬间我才意识到，“会写提示词”和“会做提示工程”是两码事。
这 5 个范式，是 Prompt Engineering 面试里绕不开的核心，也是我从那次尴尬之后认真补课、又在实际项目中反复验证过的内容：Few-shot、Chain-of-Thought（思维链）、Self-Consistency（自洽性采样）、ReAct（推理+行动循环）、Tree of Thoughts（思维树）。这篇文章会把每个范式的底层逻辑、适用场景、面试应答口径和常见加分点都拆开讲清楚。无论你是准备面试，还是想把自己零散的 prompt 经验系统化，这套内容都值得收藏对照。
1. 面试官问“范式”，到底在考你什么
1.1 你以为在考“写词”，实际在考“方法论”
很多人的 prompt 经验是“点状”的：今天发现加一句“请用中文回答”效果好，明天发现“扮演专家”能让输出更专业，后天又学会用“逐步思考”解决复杂问题。这些经验是真的，但它们属于“技巧”，不是“范式”。
面试官问范式，本质上是在验证两件事：第一，你有没有把零散经验抽象成方法论的能力；第二，你遇到一个陌生任务时，是凭感觉堆提示词，还是有一整套“分析问题→选择策略→设计提示→评估效果→迭代优化”的工程流程。
这里有个常见的认知误区：很多人以为 Prompt Engineering 是“写提示词”的艺术，实际上它更接近实验科学。工程意味着你要能回答“为什么这么设计”“效果如何衡量”“失败时怎么回退”“成本是多少”。范式就是经过大量验证、可复用的提示策略模板，它让你不再从零开始拍脑袋，而是像查手册一样找到合适的方案。
我在面试中吃过亏以后，复盘出来的结论是：面试官其实不指望你把五个范式背得多流利，他更在意你能不能把每个范式的“适用边界”和“取舍代价”讲清楚。比如 Few-shot 能提效果但会消耗上下文窗口，CoT 能提升推理准确率但会增加输出长度，Self-Consistency 效果更好但推理成本成倍上升——这些“背后的账”才是面试中真正拉差距的地方。
1.2 五个范式的全局地图与考场优先级
先给一张全景表，把五个范式一次看明白：
| 范式 | 一句话定位 | 核心机制 | 常见考题方向 | 面试出现频率 |
|---|---|---|---|---|
| Few-shot | 给模型看几个例子再让它干活 | 上下文学习，通过示例完成格式迁移和规则对齐 | 分类、抽取、格式转换、风格模仿 | 极高 |
| Chain-of-Thought | 让模型先展示推理过程再给结论 | 引导模型生成中间推理步骤，提升多步任务准确率 | 数学题、逻辑推理、多条件决策 | 极高 |
| Self-Consistency | 同一问题采样多条推理路径，多数投票 | 利用多次采样降低单次推理的随机性 | 对答案可靠性要求高的复杂推理 | 中高 |
| ReAct | 推理和调用工具交替进行 | 思考→行动→观察→再思考的循环，打通外部信息 | Agent、工具调用、实时数据获取 | 中高（Agent 岗必考） |
| Tree of Thoughts | 把推理过程展开成树，搜索最优路径 | 分解中间步骤，对每个状态生成多个候选并评估回溯 | 规划类任务、需要验证多条路径的任务 | 中低（进阶题） |
从面试优先级来看，Few-shot 和 CoT 属于“必背”级别，几乎任何岗位的 prompt 面都可能碰到；Self-Consistency 和 ReAct 在涉及推理能力、Agent 场景的岗位里高频出现；ToT 相对进阶，但一旦被问到，往往是区分“会用”和“理解原理”的分水岭。我下面按这个优先级逐个展开，每个范式都会给出实际可用的提示结构、面试回答框架和容易被追问的点。
2. 必考范式一与二：Few-shot 和 CoT，最基础也最容易答空
2.1 Few-shot：不是“给几个例子”，而是“给对例子”
Few-shot 是所有范式里最基础、也最容易被低估的一个。很多人觉得它不就是“给两个例子”嘛，但面试官稍微深挖一下，就露馅了。
先说原理。Few-shot 利用的是语言模型的上下文学习（In-Context Learning）能力：模型在推理时，会把输入上下文里出现的示例当作“任务示范”，从中推断出要做什么、输出什么格式、遵循什么规则。换句话说，你给的示例本身就是一种隐式指令，甚至经常比那句“请你认真分类”更管用。
面试中要讲出深度，至少得覆盖下面四个实操细节：
第一，示例质量优于示例数量。我给过一个三示例的 prompt，效果比之前七示例还好。原因在于那三个示例精准覆盖了任务最难的三个边界情况，而之前的七个示例有一半是“送分题”，白白占上下文却不提供新信息。你应该把示例当作“困难样本集”来设计，而不是“凑数量”。
第二，示例必须包含反例。做文本分类或信息抽取时，只给正例容易出现“什么都往目标类别里塞”的偏向。我通常会在示例里混入一两个反例，明确标注“这个不满足条件”，模型的判别力会明显提升。
第三，示例格式必须与真实输入保持严格一致。这里有个我踩过的坑：示例里用了“标签：科技/体育”这种写法，真实请求里却变成了“类别：科技/体育”，结果模型输出就跟着飘了。格式不一致会让模型困惑到底是模仿内容还是模仿格式。
第四，示例顺序也影响效果。部分模型对示例顺序敏感，重要的示例放在开头或结尾位置往往比放中间效果更好。虽然这背后的机制解释还有争议，但实测中这个现象确实存在，面试提出来会显得你有实战观察。
面试答题时，我建议用“一条完整逻辑链”来组织：先说明 Few-shot 的本质是让模型通过示例做“隐式规则对齐”，再用一个具体任务说明示例如何设计（覆盖边界、正反混合、格式统一），最后主动补充它的代价——占用上下文窗口，示例多到一定程度收益会边际递减。这套回答下来，面试官基本不会觉得你只是会用 prompt。
2.2 CoT 思维链：让模型“先想后说”，比直接逼它给答案稳得多
如果说 Few-shot 是输入侧的技巧，那么 Chain-of-Thought 就是推理路径的重构。CoT 的核心就一句话：让模型在输出最终答案之前，先把中间推理步骤写出来。这个简单的改动，在多步数学、逻辑判断、条件决策等任务上的提升往往是质的。
为什么会有这个效果？一个比较直观的解释是：语言模型在生成文本时，是逐 token 进行的，如果它直接输出答案，中间没有“思考缓冲”，很容易在第一步就沿着错误的语义方向跑偏。当我们在 prompt 里要求它“一步步思考”，等于强制模型在 token 层面多走一段推理路径，这段路径本身会约束后续生成，让它更可能落在正确的结论上。
面试里我会用一个三步结构来回答 CoT 相关的问题：
第一步，明确适用场景。CoT 不是万能的，它适合那些“答案需要多步推导”的任务，比如数学应用题、逻辑推理题、多条件筛选。而像简单实体抽取、文本分类这种一步就能搞定的任务，强行用 CoT 反而增加输出长度和延迟，属于过度设计。
第二步，给出 CoT 提示的完整结构。通常包含三部分：任务指令（要做什么）、推理指令（明确要求逐步思考并在最后给出结论）、可选的一个 CoT 示例（让模型模仿推理格式，效果更稳）。下面是一个我常用的结构模板：
任务：根据已知条件，判断候选人是否满足岗位要求。 条件： 1. 岗位要求三年以上 Python 经验。 2. 候选人李某某，技术栈为 Python，工作年限两年半。 请先逐步分析，再给出最终结论，结论格式为“满足/不满足”。 分析： 候选人李某某的技术栈是 Python，满足语言要求； 工作年限为两年半，不足三年，不满足年限要求； 因此综合判断，候选人不满足岗位要求。 结论：不满足第三步，说明评估方法。面试中只说“我用了 CoT”是不够的，我会补一句“我会在同一组测试集上对比有无 CoT 的准确率差异，观察错误模式从哪一种变成了哪一种”。这说明你把它当工程方案在验证，而不是当咒语在用。
CoT 有两个高频追问点要提前准备：一是“CoT 什么时候会失效”，二是“temperature 怎么设置”。
失效场景主要有三类：模型本身能力边界之外的问题（比如超出其知识容量的事实问答，怎么推理也推不出来）；简单任务（加了 CoT 只是徒增 token）；以及上下文极长、模型已经顾此失彼的情况。temperature 这块，CoT 通常不适合把 temperature 调到接近 0，因为那会减弱推理路径的多样性；但也不要太高，否则中间推理容易信马由缰。我常用的区间是 0.3 到 0.7，视任务稳定性要求调整。
3. 必考范式三与四：Self-Consistency 和 ReAct，从“会想”升级到“会做”
3.1 Self-Consistency：多路推理加投票，用统计学打败单次随机性
CoT 有效，但它有个让人很不放心的特性：随机性。同一个 prompt，同一个模型，在 temperature 不为 0 时，跑两次可能给出不同的推理路径和答案。其中有对的，也有错的。Self-Consistency 的思路特别“暴力”也特别有效：既然单次推理不稳定，那就采样多条推理路径，对最终答案做多数投票。
原理可以这么理解：正确的答案往往有比较一致的推理路径，无论从哪个角度切入，最后都走向同一个结论；而错误答案通常“各有各的错法”，分散在不同方向上。所以多数投票天然会汇聚到正确答案那里。这不是什么高深的数学，但实测下来，在数学推理、复杂问答这类任务上，Self-Consistency 通常比单次 CoT 再提升几个百分点，代价是推理成本乘以 N。
面试时我不会只说概念，而是给出一组可操作的参数配置：
- 采样次数：一般 5 到 10 次。5 次起步能看到稳定的收益，10 次以上收益边际递减明显，但成本线性上升。
- temperature：建议设在 0.5 到 0.7。太低会导致采样路径过于相似，投票失去意义；太高则容易引入过多噪声路径。
- 投票粒度：如果是选择题，直接对选项投票；如果是开放生成，需要先做答案归一化（比如抽取关键词或摘要），再判断一致性。
还有一个面试加分细节：主动说明 Self-Consistency 的成本账。比如 10 次采样意味着 10 倍的推理 token 消耗和延迟，所以在一些实时性要求高的场景里，我会把它降级为“先单次 CoT，置信度低时才触发多路采样”。这种“按需启用的弹性策略”比无脑用满采样更能体现工程判断力。
追问里常有一个问题：“Self-Consistency 和 ensemble 有什么区别？”我的理解是，它本质上就是一种在推理路径层面的 ensemble，但它不需要训练多个模型，而是利用同一个模型的采样随机性去探索不同的“思维路径”，属于测试时计算（test-time compute）的一种。这么答，通常面试官会点头。
3.2 ReAct：推理与行动交替进行，Agent 面试躲不掉的一关
ReAct 是 Reasoning and Acting 的缩写，核心思想听起来也不复杂：让模型在思考（推理）和行动（调工具）之间循环。它的出现背景很现实——大模型的“内部知识”是有限且滞后的，你让它算今天某支股票的走势，它不会；你让它查某系统的最新文档，它也没见过。但如果你允许它调用外部工具，情况就完全不同了。
ReAct 的典型交互循环长这样：
Thought: 用户想查某城市的实时天气，我需要先确定城市名称和查询接口。 Action: 调用天气查询接口，参数 {"city": "某市"} Observation: 接口返回，该市当前温度 24 摄氏度，多云。 Thought: 已获得天气数据，可以直接回答用户。 Final Answer: 某市现在多云，气温 24 摄氏度。注意这里的关键结构：Thought（分析当前状态）、Action（决定调用什么工具、传什么参数）、Observation（工具返回了什么）。每一轮循环都把新信息重新喂回模型，让它基于最新的观察继续推理，直到它能给出 Final Answer 或达到终止条件。
面试官喜欢问 ReAct，通常是因为它直接关联到 Agent 和 Function Calling 这类热门方向。答题时我会拆成四层来讲：
第一层，说清为什么要 ReAct。理由有三：模型知识有截止日期，无法覆盖实时信息；模型内部无法承载外部系统的状态；通过工具调用可以“外包”掉模型不擅长的精确计算或检索。这三点基本把 ReAct 的存在必要性讲全了。
第二层，给出最小可运行的格式化方案。ReAct 是否生效，很大程度取决于模型的输出是否遵循固定格式。我通常会要求模型严格按上面的 Thought/Action/Observation 结构输出，并在代码侧用正则或 JSON 解析来提取 Action 字段。这里最容易踩的坑就是“模型输出格式飘了”，比如 Action 里面混入了自然语言，导致解析失败。解决办法是：给一个或两个完整的 ReAct 示例，并对外部可调用的工具列表和参数 schema 做严格约束。
第三层，讲循环的终止条件。为什么要讲这个？因为 ReAct 有一个非常经典的失败模式：死循环。模型发现 Observation 不对，就再生成一个 Action，又不对，再生成……如果不设上限，一次请求能烧掉大量 token。我一般会设 max_iterations（比如 5 轮），超过就强制输出“无法完成”之类的兜底回复，同时把中间的历史观察传给模型避免重复调用同一个错的工具。
第四层，准备一个追问：ReAct 和 Function Calling 什么关系？我的回答思路是：Function Calling 是一种让模型输出结构化“工具调用意图”的能力/协议，ReAct 则是一种更上层的问题解决框架。你可以用 Function Calling 来实现 ReAct 中的 Action 步骤，让模型直接输出“要调用的函数名+参数 JSON”，再由程序去做真实的 API 调用。两者不是替代关系，而是分层配合的关系。
4. 必考范式五：ToT 思维树，当 CoT 到瓶颈时，用“搜索”代替“单线硬想”
4.1 ToT 的核心思想：从一条路走到底，变成一棵树的探索
CoT 的问题在于它是单线程的：模型沿着一条推理路径往前走，一旦某一步错了，后面基本全错，而且它不会回头。ToT（Tree of Thoughts）则把这个过程升级成了树状搜索：把整个推理过程分解成若干个中间步骤，每个步骤生成多个候选分支，再用评估器给每个分支打分，决定继续探索哪一条。
用大白话讲，CoT 像你只在一条地图路线上开车，错了就回不了头；ToT 则是每个路口都停下来看看几条路，先选一条走一段，发现不对就退回路口换一条。代价是走的路多了，但找到正确终点的概率也大了。
面试中讲 ToT，我会用一个“24 点游戏”的例子把整个机制讲清楚，因为这是论文里也常用的场景，大家听得懂：
- 状态分解：把“用四张牌凑成 24”拆成多轮“选出两张牌做一次运算”的子步骤，每轮都是一个状态。
- 候选生成：当前状态有若干张牌，让模型给出所有可能的两数运算组合，比如 4、6、8 可以生成 4+6=10、6×8=48 等节点。
- 状态评估：对每个候选节点，让模型判断它的“可行性”，是确定可行、可能可行、确定不行，得到一个分数。
- 搜索策略：可以采用深度优先（DFS）或者广度优先（BFS）。24 点这种步骤数很短但分支很多的，用广度优先限制宽度通常更稳。
- 回溯：某个分支走到死路（例如数字越用越多但凑不到 24），就回到上一层状态换一个候选。
这套机制拆解完，面试官会立刻明白你不是只背了个名词。但注意，ToT 的完整实现成本很高，每次状态生成、每次评估都要调用模型，一个 24 点级别的小任务可能就要几十次 LLM 调用。所以面试中一定要主动谈代价。
4.2 ToT 的成本账与“什么时候不该用”，答好了反而加分
ToT 面试中最好的得分点，不是夸它多厉害，而是实话实说“它在什么情况下划不来”。
首先账要算清楚。假设一个问题被分解成 4 个中间步骤，每步生成 3 个候选，每个候选再做一次评估，再考虑回溯，一次完整回答的 LLM 调用次数很容易超过 30 次。对比单次 CoT 的 1 次调用，成本是几十倍。如果任务本身用 CoT 已经能做到 90% 准确率，强行上 ToT 换来的那 5% 提升，性价比就很低。
所以面试中我建议给出一个“ToT 适用判据”：任务本身有明显的中间状态结构，步骤之间可以独立验证；并且错误发生在早期步骤时，后续步骤无法纠偏——这类任务 ToT 的价值最大。反过来，如果任务是一条道走到黑、中间步骤很难评估对错，ToT 只会增加成本，不如用 CoT 加 Self-Consistency。
还有一个务实的“轻量版 ToT”思路可以提一下：不是所有场景都需要完整搜索树。很多生产项目里，我用过“浅层分支 + 单次回溯”的简化方案，也就是只在最关键的一两个中间步骤生成多个候选，评估一次，选最优的那支继续走，不再做深层回溯。这个方案的成本可控，效果又比单线 CoT 好不少。这个实战细节在面试里非常加分，因为它显示你不是只看过论文，而是真的考虑过落地成本。
5. 面试实战：拿到一道 Prompt Engineering 题，完整作答框架
5.1 从拆题到选范式，一条决策链路走到底
前面几个范式是“知识点”，这一节是“解题方法论”。面试官给你一道题时，我最怕看到的情况是候选人上来就写 prompt，三分钟交卷。真正专业的回答应该是先拆题，再选型，最后才落到 prompt 本身。
我习惯把这套决策链路拆成四步：
第一步，界定任务类型。先判断这个任务是单步还是多步，是封闭式答案还是开放式生成，是需要外部信息还是纯靠模型内部知识。这决定了最基础的范式选型方向。
第二步，找任务的核心难点。同样是文本处理，分类任务的难点是边界模糊，抽取任务的难点是格式对齐，推理任务的难点是中间步骤容易错。难点不同，对应的范式也不同。
第三步，估算约束条件。上下文窗口够不够塞示例？推理延迟能不能接受？每次调用的成本预算有多少？很多时候不是你不想用高级范式，而是约束不允许，这时候要能主动说出来。
第四步，选范式组合并给出理由。注意，我不建议把五个范式全堆在一个方案里，那会让面试官觉得你没有取舍能力。通常两两组合就够了，超过三个就要说明必要性。
下面这张决策表是我实际面试和带人时经常用的：
| 任务特征 | 推荐范式组合 | 选择理由 |
|---|---|---|
| 简单分类、信息抽取、格式转换 | Few-shot | 用示例直接对齐输出格式和规则，成本最低 |
| 多步数学、逻辑推理、条件决策 | CoT | 强制显式推理，显著提升多步任务准确率 |
| 高可靠性要求的复杂推理 | CoT + Self-Consistency | 多路采样投票，降低单次推理的随机性 |
| 需要实时数据、外部工具、多轮交互 | ReAct | 推理与行动交替，打通模型外部能力 |
| 开放式规划、多候选路径验证 | ToT 或轻量版 ToT | 树状搜索 + 评估回溯，避免一条路走到底 |
| 上下文极短、实时响应要求极高 | 零样本 + 极简指令 | 优先满足延迟和窗口约束，牺牲部分效果 |
这张表本身就可以当作面试答题的“脚手架”。题目一变，你只要先回答前三个判断问题，表格自然会把范式带出来。
5.2 一道完整面试题模拟：从需求澄清到失败回退
我们现场走一道题。面试官说：“请设计一个 prompt，让模型从一段非结构化的产品反馈中，判断用户是否在抱怨某个功能点无法使用，并提炼出具体功能名称。”
如果真的只写一行 prompt，这题就浪费了。我会按照上面的链路一步步答：
第一，任务类型判断。这是一个二分类加命名实体抽取的复合任务，核心难点有两个：分类边界（“抱怨”和“建议”容易混淆）和功能名词的准确抽取。
第二，范式选择。因为边界模糊，我会用 Few-shot，并且特意设计两个边界示例：一条是“这个功能如果能支持批量操作就好了”，属于建议而非抱怨；另一条是“批量操作一直报错，根本没发用”，属于抱怨。通过正反例对把分类边界钉死。
第三，提示结构设计。我的 prompt 会包含角色约束（你是客服团队的反馈分析助手）、输出格式约束（必须输出 JSON，包含 complaint 布尔值和 feature 字符串）、以及上面说的正反例。这里有个我自己常用的细节：要求模型先输出“判断理由”再输出 JSON，这样它可以先自我校验，提升分类可靠性，本质上是把 CoT 的“先想后说”融进了 Few-shot 场景。
第四，效果评估。说完 prompt 本身，我会主动补一句：我会准备 50 条带标注的测试反馈，跑一遍之后统计分类准确率和功能名词抽取的精确率、召回率，特别看那些“建议类”有没有被误判成“抱怨类”。
第五，失败回退。如果效果不达标，我的下一步不是加更多指令，而是先看错误样本集中在哪一类，然后定向补充对应类型的示例。如果增加示例后上下文快不够了，就考虑把示例压缩成更短的模板，或者把任务拆成“先分类再抽取”两个子任务分步完成。
这套答法走下来，面试官听到的不是一个 prompt，而是一套“发现问题→设计方案→评估验证→迭代优化”的完整工程思路。这才是 Prompt Engineering 面试真正想看到的东西。
5.3 面试官追问的应对策略和三处容易翻车的陷阱
最后一个环节，说说追问。Prompt Engineering 面试的追问几乎都是围绕“边界”和“成本”展开的，方向基本可以提前预判。
陷阱一：把所有范式往上堆。候选人为了展示储备，把 Few-shot、CoT、Self-Consistency、ReAct、ToT 全塞进一个方案里。这看起来很强，实际上暴露了不会取舍。应对策略是主动说“我只选两个范式，因为它们分别解决分类边界和推理可靠性，其他范式在这个任务里没有对应的难点”。主动做减法，反而加分。
陷阱二：只讲概念不讲效果。当面试官问“你怎么知道这个方案有效”，如果你答不上来，前面说得再好也白搭。你至少要能说出：对比了什么基线、用什么指标、提升了多少。哪怕你说“我在 20 条样本上做过快速验证，正确率从 70% 提到 90%”，也比只有空洞的理论强。
陷阱三：忽略成本和约束。面试官问“这个方案上线可行吗”，很多人会忽略推理成本和延迟。应对策略是提前想到约束维度：上下文窗口够不够、单次调用 token 大概多少、P99 延迟能不能接受。这些维度体现的是工程素养，而不是单纯的 prompt 技巧。
至于追问的句式，我自己的应对逻辑是“先回应问题的前提是否成立，再给出我的取舍”。比如面试官问“这里用 ToT 是不是更好”，我会先回答“如果任务有明确分支结构，ToT 确实更好，但这个任务每个中间状态很难评估对错，ToT 的收益无法兑现，成本却实实在在”，然后再补充“如果必须上，我会用浅层版 ToT 控制成本”。这种回答方式能让面试官感觉到你是在做工程决策，而不是在背知识点。
事实上，把这五个范式梳理清楚之后你会发现，Prompt Engineering 面试真正考的从来不是“你会不会写提示词”，而是“你有没有一套可复用、可评估、可控成本的方法论”。有意做这一行的朋友，与其刷一百道所谓的真题，不如先把这五个范式的原理、边界和成本账吃透。我后来带团队面试时，判断标准也是同一套：来了一个候选人，我不看他背了多少名词，只看他遇到一道没见过的题时，能不能自然地走到“拆题→选型→设计→评估→权衡”这条链路上去。能做到这一点的，基本都能把 prompt 工程真正落地。
