老实说我第一次被问到“你掌握哪些 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 的问题在于它是单线程的模型沿着一条推理路径往前走一旦某一步错了后面基本全错而且它不会回头。ToTTree of Thoughts则把这个过程升级成了树状搜索把整个推理过程分解成若干个中间步骤每个步骤生成多个候选分支再用评估器给每个分支打分决定继续探索哪一条。用大白话讲CoT 像你只在一条地图路线上开车错了就回不了头ToT 则是每个路口都停下来看看几条路先选一条走一段发现不对就退回路口换一条。代价是走的路多了但找到正确终点的概率也大了。面试中讲 ToT我会用一个“24 点游戏”的例子把整个机制讲清楚因为这是论文里也常用的场景大家听得懂状态分解把“用四张牌凑成 24”拆成多轮“选出两张牌做一次运算”的子步骤每轮都是一个状态。候选生成当前状态有若干张牌让模型给出所有可能的两数运算组合比如 4、6、8 可以生成 4610、6×848 等节点。状态评估对每个候选节点让模型判断它的“可行性”是确定可行、可能可行、确定不行得到一个分数。搜索策略可以采用深度优先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 工程真正落地。
