Prompt Engineering面试通关：Few-shot、CoT、Self-Consistency与ToT实战拆解

1. 面试官到底在考什么：Prompt Engineering 的考察逻辑拆解

1.1 为什么这个岗位突然成了香饽饽

这两年大模型落地速度肉眼可见地加快，从智能客服到代码补全，从文档摘要到数据分析，几乎每条业务线都在琢磨怎么把模型能力接进自己的产品里。但模型本身是个黑盒，你没法改它的权重，能动的只有输入。于是Prompt Engineering这个岗位就冒出来了——本质上，它是在模型能力边界内，用最小的成本撬动最大输出质量的一门手艺。

我面过也带过不少这个方向的人，说实话，面试官并不指望你背出多少论文，而是想看你对“输入如何影响输出”这件事有没有系统性的认知。热搜词里那几个——CoT、Self-Consistency、ToT、Few-shot——不是让你背定义的，而是面试官用来判断你“有没有真正动手调过”的探针。一个只会说“CoT就是让模型一步步想”的人，和一个能说清楚“什么任务适合CoT、什么任务用了反而掉点”的人，差距一眼就能看出来。

1.2 面试考察的三个层次

我把这个岗位的面试考察拆成三层，你对照一下自己卡在哪一层。

第一层是概念层：知不知道 Few-shot、CoT、Self-Consistency、ToT 这些范式分别是什么，能说出大致原理。这一层靠看几篇综述就能过，但也是最容易被刷掉的，因为面试官一追问细节就露馅。

第二层是应用层：给定一个具体任务，你能不能判断该用哪个范式，怎么设计示例，怎么控制输出格式。这一层考的是实战经验，比如“给你一个情感分类任务，Few-shot 的示例该怎么选”这种问题，没有真正跑过几轮的人是答不好的。

第三层是权衡层：知道每个范式的代价。CoT 会增加 token 消耗，Self-Consistency 要跑多次采样成本翻倍，ToT 更是把推理成本拉到指数级。面试官很爱问“你什么时候不会用 CoT”，这题答不上来，前面说得再花哨也白搭。

提示：面试里最忌讳的是把范式当成万能公式背。面试官更想听到的是“我试过 A 和 B，在这个场景下 B 更稳，因为……”。

1.3 五个必会范式的全景图

先把这五个范式的定位理清楚，后面再逐个拆。Few-shot解决的是“模型不知道你要什么格式和风格”的问题；CoT解决的是“任务需要多步推理”的问题；Self-Consistency解决的是“单次推理不稳定”的问题；ToT解决的是“需要探索多条路径并回溯”的问题；而Prompt Engineering本身是贯穿所有范式的底层能力——你怎么描述任务、怎么给约束、怎么迭代，决定了上面这些范式能不能真正生效。

这张表建议你面试前在脑子里过一遍，被问到任何一个范式，都能快速定位它的作用和代价。

2. Few-shot 与 CoT：最常被追问的两个基础范式

2.1 Few-shot 不是随便给几个例子就行

很多人以为 Few-shot 就是“塞几个例子进去”，但面试官真正想考的是示例的选择和排列。我踩过的坑是：早期做意图分类，随手挑了三个例子，结果模型对某一类的召回特别差，后来才发现是示例的类别分布不均，模型被“带偏”了。

示例选择有几个实操要点。第一是代表性：每个类别至少给一个例子，别让某一类缺席。第二是边界性：除了典型例子，最好给一个容易混淆的边界例子，比如“帮我查下余额”和“我要退款”这种容易混的意图，各给一个，模型区分能力会明显提升。第三是顺序：有研究表明示例顺序会影响输出，尤其是分类任务，把容易混的例子放在最后，模型往往会更关注它。我实测下来，把最难的例子放最后，准确率能稳定几个点。

还有一个常被忽略的点是示例格式的一致性。如果你给的示例里，输入输出用冒号分隔，那所有示例都得统一，别一个用冒号一个用换行。模型对格式非常敏感，格式一乱，输出就开始飘。

任务：判断用户意图 示例1： 输入：我想查一下上个月的账单 输出：查询账单 示例2： 输入：这个订单我要退掉 输出：申请退款 示例3： 输入：帮我看看余额还有多少 输出：查询余额 现在请判断： 输入：我上个月买的东西想退 输出：

上面这个结构就是典型的 Few-shot 模板。注意示例3和示例1容易混，放在最后能帮模型更好地区分“查账单”和“查余额”。

2.2 CoT 的正确打开方式与失效场景

CoT（Chain-of-Thought）的核心就一句话：让模型把中间推理步骤写出来，而不是直接给答案。最经典的触发词是“Let's think step by step”，但在实际工程里，我更推荐用结构化引导，比如“请先分析已知条件，再列式计算，最后给出答案”。

为什么 CoT 有效？因为大模型是自回归生成的，它每一步的输出都会成为下一步的上下文。当它被迫写出中间步骤时，相当于给自己搭了脚手架，后面的推理就建立在前面已经写出来的内容上，而不是一次性“猜”答案。这就像你心算一道复杂应用题容易错，但拿张草稿纸一步步写下来，正确率就上去了。

但 CoT 不是万能的。我实测下来，简单的事实查询、单步分类任务，用 CoT 反而会掉点。原因很简单：模型本来直接答就对，你让它“一步步想”，它反而可能想多了，把简单问题复杂化，甚至引入不存在的推理步骤。所以面试被问“什么时候不用 CoT”，你就答：任务不需要多步推理时不用，输出格式要求严格时慎用，延迟敏感场景不用。

2.3 Few-shot 和 CoT 怎么组合

这两个范式经常一起用，也就是Few-shot CoT：给几个带推理步骤的示例，让模型模仿这种“先推理再回答”的模式。这在数学应用题上效果特别明显。

示例： 问题：小明有5个苹果，吃了2个，又买了3个，现在有几个？ 推理：开始5个，吃掉2个剩3个，又买3个，3+3=6个。 答案：6个 问题：小红有8支笔，送给同学3支，又买了5支，现在有几支？ 推理：

这种写法比单纯说“step by step”更稳，因为示例本身就把推理的粒度和格式定死了。我一般会在示例里刻意控制推理步骤的数量，别太长也别太短，2到4步比较合适。步骤太多，模型容易在中间跑偏；太少，又起不到脚手架的作用。

注意：Few-shot CoT 的示例里，推理步骤的措辞要统一，别一个示例用“首先/然后”，另一个用“第一步/第二步”，模型会困惑。

3. Self-Consistency 与 ToT：进阶范式的取舍之道

3.1 Self-Consistency 的本质是投票

Self-Consistency说白了就是：同一个问题，让模型用 CoT 跑多次（比如5次或10次），每次采样温度调高一点，然后对最终答案做多数投票。它的前提假设是——如果模型真的会做这道题，那么它多次推理的答案会收敛到同一个；如果它不会，答案就会散开。

这个范式在数学和逻辑题上特别有效。我做过一个对比实验，同一批数学题，单次 CoT 准确率大概在七成左右，用 Self-Consistency 跑5次投票，能拉到八成五以上。代价也很直接：成本翻5倍，延迟翻5倍。所以面试官问“什么时候用 Self-Consistency”，你要答：有唯一正确答案、且单次推理不稳定、且成本可接受的时候用。

有个细节很多人不知道：投票的粒度可以是答案，也可以是推理路径。如果最终答案格式不统一（比如“6”和“六个”），直接对答案投票会失败，这时候要么做答案归一化，要么对推理路径聚类。我在实际项目里一般会先做答案抽取和归一化，再投票，稳得多。

3.2 ToT 不是 CoT 的简单升级

ToT（Tree of Thoughts）经常被误解成“更高级的 CoT”，其实它解决的是完全不同的问题。CoT 是一条路走到黑，ToT 是同时探索多条路，并且允许回溯。它的典型流程是：把问题拆成多个思考步骤，每一步生成多个候选，然后评估每个候选的好坏，保留好的继续往下，差的剪掉。

ToT 适合什么场景？需要规划、需要试错、需要回溯的任务。比如“用给定数字凑出24点”这种，CoT 容易一条路走死，ToT 可以同时试几种组合，发现不对就退回来换一条。再比如复杂的行程规划，先定城市再定交通再定住宿，中间任何一步不合理都能回溯调整。

但 ToT 的代价是指数级的。每一步生成 k 个候选，走 d 步，理论上就是 k 的 d 次方次调用。所以实际工程里必须做剪枝，比如每步只保留 top-2 候选，或者设置最大深度。面试里如果你能说出“ToT 我会配合剪枝和深度限制来控制成本”，面试官会觉得你是真跑过。

3.3 四个范式的成本与效果对照

把四个范式放一起对比，面试时被问到选型就能快速反应。

我一般的原则是：能用 Few-shot 解决就不上 CoT，能用 CoT 解决就不上 Self-Consistency，ToT 是最后手段。这个优先级顺序面试时说出来，能体现你有成本意识。

4. 面试实战：从题目到方案的完整推演

4.1 一道典型面试题的拆解过程

面试官常出的题是这样的：“给你一个用户评论，判断它是正面、负面还是中性，并说明理由。你会怎么设计 Prompt？”

这题看着简单，其实考的是你对范式的综合运用。我的答法是分三步走。第一步，先明确这是分类任务，格式要求严格，所以Few-shot是基础，给每个类别两到三个示例，覆盖典型和边界情况。第二步，要求模型先给理由再给结论，这相当于轻量级 CoT，能提升判断质量，但要注意理由不能太长，否则 token 消耗大。第三步，如果发现模型在边界样本上不稳定，再考虑Self-Consistency，跑三次投票。

任务：判断评论情感，先给理由，再给结论。 示例1： 评论：物流很快，包装也完好，满意。 理由：提到物流快、包装好，表达满意。 结论：正面 示例2： 评论：东西一般，但也没啥大问题。 理由：既没有明显好评也没有明显差评，态度中立。 结论：中性 示例3： 评论：等了半个月才到，客服还爱答不理。 理由：提到等待久、客服态度差，表达不满。 结论：负面 现在判断： 评论：质量还行，就是价格有点贵。 理由： 结论：

这个模板的关键在于理由和结论分离，方便后续做答案抽取。如果模型把理由和结论混在一起，投票时就没法归一化了。

4.2 面试官追问的常见方向

答完基础方案，面试官通常会追问三个方向。第一个是**“如果准确率不够怎么办”，这时候你要能说出：增加示例、调整示例顺序、引入 Self-Consistency、换更强的模型、做后处理规则兜底。第二个是“成本怎么控制”，你要能说出：示例精简、理由限长、只在边界样本上用多次采样。第三个是“怎么评估效果”**，你要能说出：准备标注集、算准确率和混淆矩阵、重点看边界类的表现。

我见过不少候选人，方案说得漂亮，一问评估就卡壳。其实评估很简单，就是准备一批带标注的测试样本，跑一遍看指标。但你要能说出“我会重点看中性类的召回，因为这类最容易混”，这就体现你懂业务。

4.3 现场写 Prompt 的注意事项

有些面试会让你现场写一段 Prompt。这时候有几个细节特别加分。第一是明确角色和任务，开头就写“你是一个情感分析助手”。第二是明确输出格式，用“结论：正面”这种固定格式，方便解析。第三是给约束，比如“理由不超过20字”。第四是留好接口，把待判断的内容放在最后，方便程序拼接。

提示：现场写 Prompt 时，别追求花哨，追求可解析、可复现、可评估。面试官看的是工程思维，不是文采。

5. 避坑指南与高频问题速查

5.1 我踩过的五个真实坑

第一个坑是示例泄露答案。做抽取任务时，示例里的答案和待抽取内容太像，模型直接抄示例，换个输入就废了。解决办法是示例和测试数据分布要拉开。

第二个坑是CoT 让简单任务变复杂。有次做二分类，加了 CoT 后准确率反而降了，去掉就恢复。教训是：先跑 baseline，再决定要不要加范式。

第三个坑是Self-Consistency 投票失败。答案格式不统一，投票时“6”和“六”被当成两个答案。解决办法是投票前做归一化。

第四个坑是ToT 成本失控。没做剪枝，一次调用跑了几十次模型，账单直接爆了。教训是：ToT 必须设深度上限和候选上限。

第五个坑是Prompt 版本没管理。改了一版 Prompt 效果变差，想回滚发现没存旧版。现在我都会用版本号管理 Prompt，每次改动都记录。

5.2 高频面试问题速查表

5.3 给准备面试的人几句实在话

这个岗位的面试，背概念只能过第一轮，真正拉开差距的是你有没有动手调过。我的建议是：找三五个真实任务，每个任务把 Few-shot、CoT、Self-Consistency 都跑一遍，记录准确率和成本，形成自己的对照表。面试时你随口说出的“我实测下来 CoT 在这个任务上提升了 8 个点，但成本翻了一倍”，比任何理论都有说服力。

另外，别把范式当教条。模型在迭代，今天有效的 Prompt 明天可能就失效了。真正值钱的能力是快速实验和迭代的方法论，而不是记住某个固定模板。我个人的习惯是每接一个新任务，先跑 Zero-shot 看 baseline，再逐步加 Few-shot、CoT，每一步都记录指标，这样既知道每个范式的边际收益，也能在面试里讲出完整的故事。

最后分享一个小技巧：面试前把你做过的项目整理成“任务-范式-指标-踩坑”四段式，每个项目都能讲三分钟。面试官问哪个范式，你都能从项目里拎出对应的例子，这种“有据可查”的回答，比空谈原理稳得多。