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本身是贯穿所有范式的底层能力——你怎么描述任务、怎么给约束、怎么迭代决定了上面这些范式能不能真正生效。范式核心作用典型适用场景主要代价Few-shot对齐格式与风格分类、抽取、格式化输出示例占 tokenCoT激发多步推理数学、逻辑、多跳问答输出变长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 的正确打开方式与失效场景CoTChain-of-Thought的核心就一句话让模型把中间推理步骤写出来而不是直接给答案。最经典的触发词是“Lets think step by step”但在实际工程里我更推荐用结构化引导比如“请先分析已知条件再列式计算最后给出答案”。为什么 CoT 有效因为大模型是自回归生成的它每一步的输出都会成为下一步的上下文。当它被迫写出中间步骤时相当于给自己搭了脚手架后面的推理就建立在前面已经写出来的内容上而不是一次性“猜”答案。这就像你心算一道复杂应用题容易错但拿张草稿纸一步步写下来正确率就上去了。但 CoT 不是万能的。我实测下来简单的事实查询、单步分类任务用 CoT 反而会掉点。原因很简单模型本来直接答就对你让它“一步步想”它反而可能想多了把简单问题复杂化甚至引入不存在的推理步骤。所以面试被问“什么时候不用 CoT”你就答任务不需要多步推理时不用输出格式要求严格时慎用延迟敏感场景不用。2.3 Few-shot 和 CoT 怎么组合这两个范式经常一起用也就是Few-shot CoT给几个带推理步骤的示例让模型模仿这种“先推理再回答”的模式。这在数学应用题上效果特别明显。示例 问题小明有5个苹果吃了2个又买了3个现在有几个 推理开始5个吃掉2个剩3个又买3个336个。 答案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 的简单升级ToTTree of Thoughts经常被误解成“更高级的 CoT”其实它解决的是完全不同的问题。CoT 是一条路走到黑ToT 是同时探索多条路并且允许回溯。它的典型流程是把问题拆成多个思考步骤每一步生成多个候选然后评估每个候选的好坏保留好的继续往下差的剪掉。ToT 适合什么场景需要规划、需要试错、需要回溯的任务。比如“用给定数字凑出24点”这种CoT 容易一条路走死ToT 可以同时试几种组合发现不对就退回来换一条。再比如复杂的行程规划先定城市再定交通再定住宿中间任何一步不合理都能回溯调整。但 ToT 的代价是指数级的。每一步生成 k 个候选走 d 步理论上就是 k 的 d 次方次调用。所以实际工程里必须做剪枝比如每步只保留 top-2 候选或者设置最大深度。面试里如果你能说出“ToT 我会配合剪枝和深度限制来控制成本”面试官会觉得你是真跑过。3.3 四个范式的成本与效果对照把四个范式放一起对比面试时被问到选型就能快速反应。范式调用次数相对成本效果提升幅度适用判断Zero-shot1基准基准简单任务Few-shot1略高示例占token格式对齐明显需要固定格式CoT1中输出变长推理任务显著多步推理Self-ConsistencyN高N倍稳定性提升有唯一答案ToT指数级极高复杂规划提升需探索回溯我一般的原则是能用 Few-shot 解决就不上 CoT能用 CoT 解决就不上 Self-ConsistencyToT 是最后手段。这个优先级顺序面试时说出来能体现你有成本意识。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 高频面试问题速查表问题回答要点CoT 和 Few-shot 区别CoT 重推理过程Few-shot 重格式对齐可组合什么时候不用 CoT简单任务、格式严格、延迟敏感Self-Consistency 成本N 倍调用需权衡准确率与成本ToT 怎么控成本剪枝、深度限制、候选数限制怎么评估 Prompt标注集、准确率、混淆矩阵、边界类召回Prompt 怎么迭代小步改动、版本管理、A/B 对比5.3 给准备面试的人几句实在话这个岗位的面试背概念只能过第一轮真正拉开差距的是你有没有动手调过。我的建议是找三五个真实任务每个任务把 Few-shot、CoT、Self-Consistency 都跑一遍记录准确率和成本形成自己的对照表。面试时你随口说出的“我实测下来 CoT 在这个任务上提升了 8 个点但成本翻了一倍”比任何理论都有说服力。另外别把范式当教条。模型在迭代今天有效的 Prompt 明天可能就失效了。真正值钱的能力是快速实验和迭代的方法论而不是记住某个固定模板。我个人的习惯是每接一个新任务先跑 Zero-shot 看 baseline再逐步加 Few-shot、CoT每一步都记录指标这样既知道每个范式的边际收益也能在面试里讲出完整的故事。最后分享一个小技巧面试前把你做过的项目整理成“任务-范式-指标-踩坑”四段式每个项目都能讲三分钟。面试官问哪个范式你都能从项目里拎出对应的例子这种“有据可查”的回答比空谈原理稳得多。