你觉得它和普通补全题有什么本质区别这句话是我半个月前面试某大模型应用岗时面试官问的第一个问题直接让我愣了两秒。Prompt Engineering这两年从会写一句咒语变成了实打实的面试科目几乎每家做AI应用的团队都会考但大部分候选人的准备方式还停留在背几个模板。这篇内容我想把我梳理过的提示工程面试链路完整讲清楚。核心是5个必须掌握的范式少样本示例、思维链、角色扮演、自洽性采样、ReAct行动循环。我会逐个拆原理、给场景、还原面试官真正的追问方式最后补一套我自己的实战复盘。不管你是准备面试还是单纯想把这套方法论用到业务里应该都能直接抄走。1. 先搞明白提示工程面试官到底在考察什么很多候选人以为提示工程面试就是看谁会写提示词这是最大的误解。我观察下来面试官真正在考察的是三个层次底层机制理解、系统调试能力、工程判断力。1.1 三个能力维度原理理解、调试能力、落地判断原理理解考察的是你知不知道提示词为什么有效。比如让模型扮演资深HR这个角色设定背后是模型在海量语料中见过无数种对话风格角色词激活的是特定语域的语言分布。面试官会追问角色设定失效怎么办如果你回答换个角色试试那就还停在调参层面没有进入机制层面。调试能力考察的是你是否有一套系统化的排错逻辑。提示词效果不好时你会先检查任务定义是否清晰还是直接加示例你会通过对比实验定位是格式问题还是语义问题还是凭感觉改词我面试过不少人一遇到输出不稳定就说加个exactly follow试试这种答案是没有方法论的。工程判断力考察的是性价比意识。提示词短了效果不好长了成本翻倍延迟变高你怎么权衡few-shot到底给几个示例最合算CoT虽然准确率高但token消耗大什么场景必须用、什么场景可以用朴素提示词凑合这些都是面试官会反复追问的。1.2 面试题的两大类别概念辨析题与实战情境题概念辨析题通常长这样CoT和few-shot什么关系角色提示和指令提示冲突时听谁的这类题没有标准答案但考察的是你的知识体系是否结构化。实战情境题则是给你一个具体业务场景比如设计一个提示词让大模型从客服对话里提取用户诉求并输出JSON然后一步步追问你的设计理由。这类题最考验人因为它没有唯一解面试官是在看你的思考过程。接下来进入正题五个面试必考范式。每一块我都会按原理→例子→面试官怎么问→我踩过的坑这个顺序展开。2. 五个必会的范式逐个拆解2.1 范式一少样本示例Few-shot Prompting原理层面few-shot是让模型从输入输出对中推断任务模式。它不是在学习新知识而是在校准输出分布。比如你想让模型把口语改写成商务邮件你给两条口语原文→邮件的示例模型就大概明白了你要的格式和语气。面试里的典型考法是这样的如果你只能给3个示例你会怎么选很多人的答案是随便找几个典型的正确思路是让示例覆盖任务的不同难度。比如改写任务示例一选简单的短句示例二选带术语的长句示例三选带有情绪化的口语这样模型才能学到不同维度上的改写策略。面试官还爱追问示例顺序有没有影响。经验上首个示例决定了模型对任务的第一印象最后一条示例对近期上下文的影响最大所以最难的示例可以放前面最标准的示例放最后。这个细节说出来面试官会觉得你真的调过模型。我的坑有次做情感分类我在示例里混入了两条边界模糊的样本结果模型在正式预测时开始输出解释而不是标签。后来我意识到示例必须全部是确定性强的、能代表决策边界的样本带歧义的示例会让模型学去不确定时怎么办的风格。2.2 范式二思维链Chain-of-Thought思维链的本质是把复杂问题拆解成中间推理步骤让模型在正式输出答案之前先亮出草稿纸。它的理论基础是每一步推理需要的计算量被显式地分摊到多个token上模型生成中间结论时也在做自我约束。面试最经典的问题是让我们一步一步想这句咒语为什么有效面试官不想听因为它有效所以有效。你需要说到点子上这句指令把单次难推理转化为多次简单推理同时暴露推理过程相当于让模型在生成过程中自带了一个检查点。如果回答时能补一句但它不是万能的模型推理能力不足时反而会产生更长的错误路径基本就稳了。另一个高频追问是CoT和few-shot结合使用和单独用有什么差别。我自己的实测是纯靠一句think step by step在小模型上效果很差因为模型没有足够的推理容量但配上2到3个带推理过程的示例小模型也能被带出像样的推理链。所以面试答题时最好强调CoT不是咒语是示例指令模型容量三者配合的结果。还有一个方向值得说清楚——什么时候不能依赖CoT。如果任务是事实性问答比如某市GDP是多少再长推理也不会从模型参数里变出准确知识。面试官出一个这种场景其实是在考察你能不能判断提示词与知识边界的匹配度。2.3 范式三角色扮演式提示Role Prompting角色扮演可能是被最高估也被最低估的一个范式。高估是指很多人以为加个高质量角色词就能解決一切。低估是指它其实包含一个普适原理角色设定约束了回答的角度、语域和信息粒度。比如你是客服质检专家和你是只回答是或否的机器人两者激活的不是同一个语言区域。角色词本质上是一个压缩了任务约束的语义索引它告诉模型现在处在什么场景、该用什么身份视角、关注哪类信息。面试里的进阶题是角色设定和具体指令冲突时模型会听谁的我实测下来具体指令的优先级更高但角色设定会污染输出风格。比如你让模型扮演财务分析师同时又让它简洁输出它可能会在简洁中不自觉地加一些术语。这个问题回答得好就能展示你的机制理解程度。实战中角色词不是越长越好。面试官给你场景让模型做纠错改写你可以拆成三层身份背景、行为约束、输出格式。写成你是一位有十年经验的文档校对员只改正错别字和语法错误不改变原意输出时按原文→修订→原因三条给出比你是专家请认真要实用得多。我的经验是角色扮演失败时九成原因不是角色不够强而是角色与任务的匹配度不够。比如你是小学数学老师去解高数题模型会倾向用教小孩子的方式解释极限反而降低了专业性。所以面试时我一般会在答案里主动加一句角色设定要服务于任务本身的认知复杂度。2.4 范式四自洽性采样Self-Consistency自洽性是思维链的增强版。它的做法是对同一个问题用带随机性的采样参数生成多条推理路径然后对最终答案做投票取众数作为结果。原理是正确答案的推理路径可能有多条但错误答案通常是路径特有的所以多数投票可以摊薄随机错误。面试官喜欢把这道题和思维链怎么配合放在一起考。你应该回答自洽性建立在多次CoT采样之上它解决的是单条推理链看似有道理但结论错误的问题。如果在面试手写时只有两个示例一定要说明白先采样十条再按答案聚类选最大簇而不是我自己觉得某个答案对就选它。还有一个必考追问自洽性的代价和适用边界是什么代价很直白十次采样的token成本和延迟还有需要结果存在可比较性——封闭式任务选择题、判断题、分类标签非常适合自洽性开放式创作任务用自洽性反而会把多样性抹平。面试官这么问就是在看你会不会为了效果而忽略成本。我在一个分类项目里用过自洽性稳定性从86%提到了93%但每请求的token用量翻了十倍。后来我调整到只在置信度低的时候才做二次采样效果和成本才取得了平衡。这个条件触发自洽性的思路面试官听完会觉得你是在做真实工程不是套论文公式。2.5 范式五ReAct推理行动循环ReAct把推理与行动交叉进行模型感知到信息缺口时会生成一个工具调用行动比如查数据库、跑代码拿到反馈结果后继续推理直到答案收敛。它本质上是把单次问答变成了一个闭环决策过程。面试里如果聊到ReAct面试官基本默认你已经会写普通提示词了他更关心三件事第一你怎么设计行动空间也就是允许模型调用哪些工具第二怎么防止模型反复调用同一个工具导致死循环第三工具返回错误时模型该怎么反应。我的建议是回答时带上成本意识。比如你可以说我会在系统提示里显式声明可用工具列表和参数格式并用一个最大迭代次数作为兜底。每次行动后强制模型先总结已知信息再决定下一步避免无意义循环。这种回答不是在背ReAct的论文描述而是真的跑过类似的事情。我还遇到过面试官让现场给一个用ReAct解决某研究助理场景的方案。我当时给的结构是先定义问题边界再给三个工具语义搜索、公式计算、信息判断然后约定每一步输出的格式为思考→行动→观察。面试官接下来追问如果搜索返回空结果你要怎么设计提示词这里你要答出不调用搜索而是直接输出信息不足也是一种行动这个细节会让面试官觉得你考虑过真实世界的数据稀疏问题。3. 面试里最常见的几类题喂给你一套回答框架3.1 对比类问题按解决的问题—适用条件—成本三维回答面试官一旦问这几个范式有什么区别不要按顺序背定义。你按三个坐标展开解决什么问题、适用什么条件、代价是什么。几个范式的关系我用一张表来总结范式解决的核心问题适用条件主要代价Few-shot让模型快速对齐任务格式和分布有代表性样本、单轮任务示例选择不当会带偏输出CoT提升多步推理准确率模型容量足够、任务可分解输出变长时延和token上升Role Prompting约束回答风格、角度和信息粒度角色与任务复杂度匹配角色冲突时风格迁移不可控Self-Consistency消除单条推理路径的随机误差封闭式答案、可比较投票采样次数放大成本和延迟ReAct通过工具补足模型知识盲区有外部工具、需闭环决策循环风险、工具设计复杂度面试官基本都是顺着这张表往下追问的。你可以主动说我习惯先判断任务属于格式问题、推理问题还是知识边界问题再用对应的范式组合。这句话等于把五个范式统一到了决策框架里展示的是思考体系。3.2 现场设计提示词题的答题SOP遇到请你现场设计一个提示词解决XX任务的题我推荐一套稳定的答题流程需求澄清→范式选择→初稿设计→效果自评→扩展方案。需求澄清先说出口别听完题目就写。比如面试官说让模型提炼会议纪要看板你要快速追问纪要是一段还是多段输出是延续原文还是摘要重写要不要区分决策和待办事项这种追问展示了你不是在背模板而是在做需求分析。然后是范式选择。我会口述出来这个任务核心是结构化提取格式对齐很重要所以我会先用few-shot的方式给出两条真实样例再用角色提示词限定视角为项目经理最后在输出层用JSON格式约束。听到这里面试官基本就能判断你确实理解这几个范式的适用场景了。最后一定要做效果自评。你可以说我会准备二十条历史会议记录做评测先人工定好三条维度完整度、准确性、格式正确率跑一版后根据错误类型决定是修示例还是加后处理。这套说法在面试里的杀伤力很大因为它透露两件事你知道怎么验证你知道怎么迭代。3.3 高频追问温度、k值、JSON稳定性怎么答追问一温度设多少为什么不要答0.7比较好。正确答案是温度控制采样的随机性事实抽取类任务调低0—0.3创意生成类任务调高0.7—1.0自洽性采样时提高温度以增加路径多样性。把温度和一个具体决策绑定起来面试官才会有你是用户的真实感受。追问二few-shot的k值怎么定别背越多越好。要区分场景简单分类任务1到2个示例即够格式迁移任务3到5个困难推理任务配合CoT给2到3个带步骤的示例就足够。k值增大边际收益会快速递减还要考虑最长输入的限制。末尾再补一句k值要到评测里去定不是拍脑袋定。追问三输出JSON一会格式错乱怎么办这题几乎每次都考。你的回答应该分三层第一层提示词里明确schema示例直接照这个格式输出第二层降低温度并关闭择优采样带来的发散第三层程序侧做兜底解析或让模型自己更正自己的输出。模型自己纠正自己这件事面试官很少听到但实际很管用你可以说检测到解析失败时把错误信息和期望schema拼回去让它再生成一次。4. 从会背概念到能过面试我的实战复盘4.1 一次现场手撕题的完整翻车记录有次面试对方让我设计一个提示词让模型从用户评价中提取产品、问题、情绪倾向三个字段并输出JSON。我当时一上来就写了一大段提示词身份、规则、示例全塞进去结果面试官问你这条方案的失败模式是什么我卡住了。复盘发现我的问题很典型只考虑链路完整没有考虑边界case。比如用户评价里同时出现两个产品JSON里product字段是数组还是字符串评价情绪是混合的产品不错但客服差sentiment该取严格单一标签还是允许带子情绪这四个字是提示词怎么写都绕不开的。正确的做法是先用5到10个标注样本把所有边界情况想清楚再反推到提示词里。后来我重构答案时用了任务分解思路第一层先用few-shot把原文中的产品名、问题短语、情绪标签分别抽取第二层用一条规则提示词把抽取结果整理成JSON。面试官明显对这一版更满意因为我把不确定性留在了程序逻辑里而不是指望一句提示词包打天下。4.2 面试官真正想听到的经验点在反复被拷打之后我总结出面试官最认的三个经验点。第一个是你判断过一个方案失败。面试官不想听全能的提示词想听你说清这个方案的失效条件是什么、失效时表现什么样、怎么发现它失效。这其实是把提示词当作软件工程对象来对待。你主动说出这是我这个方案最脆弱的地方反而比藏着掖着加分。第二个是你会靠评测说话而不是靠感觉。至少在面试中提到一句我离不了评测集。哪怕没有真实数据集你也可以说我会先构造20条黄金样例作为回归基线每次改提示词后跑一遍防止修了一个case坏了另外十个。这句话直接把你和其他候选人区分开了。第三个是你有成本意识。聊到CoT时提输出长度翻倍聊到自洽性时提请求量翻十倍聊到ReAct时提工具调用延迟。面试官在业务侧最头疼的就是候选人不计成本地堆效果你主动算这笔账他会觉得你能直接上手。我在面试中还有一个习惯是随时准备一张失败案例清单。每条都长这样任务X尝试把角色和指令混合失败原因是他俩冲突了把角色写详细后输出风格变化但格式还是不稳定最终用示例解决。面试官对具体案例的注意力远超对抽象概念背诵的注意力。最后还想多说一句提示工程面试的爆发式需求是因为现在做AI应用的人都意识到一个稳定可落地的提示词和一段稳定可维护的代码一样需要方法论。五个范式不是用来背的是用来做决策的。多拿自己手头的真实任务做实验记录每次失败几个月之后你再遇到面试题会发现自己能聊的东西根本聊不完。 
长河君 · 2026/10/22 16:27:42 · 阅读 1.2k 提示工程面试必考五大范式：原理、追问与实战复盘
你觉得它和普通补全题有什么本质区别这句话是我半个月前面试某大模型应用岗时面试官问的第一个问题直接让我愣了两秒。Prompt Engineering这两年从会写一句咒语变成了实打实的面试科目几乎每家做AI应用的团队都会考但大部分候选人的准备方式还停留在背几个模板。这篇内容我想把我梳理过的提示工程面试链路完整讲清楚。核心是5个必须掌握的范式少样本示例、思维链、角色扮演、自洽性采样、ReAct行动循环。我会逐个拆原理、给场景、还原面试官真正的追问方式最后补一套我自己的实战复盘。不管你是准备面试还是单纯想把这套方法论用到业务里应该都能直接抄走。1. 先搞明白提示工程面试官到底在考察什么很多候选人以为提示工程面试就是看谁会写提示词这是最大的误解。我观察下来面试官真正在考察的是三个层次底层机制理解、系统调试能力、工程判断力。1.1 三个能力维度原理理解、调试能力、落地判断原理理解考察的是你知不知道提示词为什么有效。比如让模型扮演资深HR这个角色设定背后是模型在海量语料中见过无数种对话风格角色词激活的是特定语域的语言分布。面试官会追问角色设定失效怎么办如果你回答换个角色试试那就还停在调参层面没有进入机制层面。调试能力考察的是你是否有一套系统化的排错逻辑。提示词效果不好时你会先检查任务定义是否清晰还是直接加示例你会通过对比实验定位是格式问题还是语义问题还是凭感觉改词我面试过不少人一遇到输出不稳定就说加个exactly follow试试这种答案是没有方法论的。工程判断力考察的是性价比意识。提示词短了效果不好长了成本翻倍延迟变高你怎么权衡few-shot到底给几个示例最合算CoT虽然准确率高但token消耗大什么场景必须用、什么场景可以用朴素提示词凑合这些都是面试官会反复追问的。1.2 面试题的两大类别概念辨析题与实战情境题概念辨析题通常长这样CoT和few-shot什么关系角色提示和指令提示冲突时听谁的这类题没有标准答案但考察的是你的知识体系是否结构化。实战情境题则是给你一个具体业务场景比如设计一个提示词让大模型从客服对话里提取用户诉求并输出JSON然后一步步追问你的设计理由。这类题最考验人因为它没有唯一解面试官是在看你的思考过程。接下来进入正题五个面试必考范式。每一块我都会按原理→例子→面试官怎么问→我踩过的坑这个顺序展开。2. 五个必会的范式逐个拆解2.1 范式一少样本示例Few-shot Prompting原理层面few-shot是让模型从输入输出对中推断任务模式。它不是在学习新知识而是在校准输出分布。比如你想让模型把口语改写成商务邮件你给两条口语原文→邮件的示例模型就大概明白了你要的格式和语气。面试里的典型考法是这样的如果你只能给3个示例你会怎么选很多人的答案是随便找几个典型的正确思路是让示例覆盖任务的不同难度。比如改写任务示例一选简单的短句示例二选带术语的长句示例三选带有情绪化的口语这样模型才能学到不同维度上的改写策略。面试官还爱追问示例顺序有没有影响。经验上首个示例决定了模型对任务的第一印象最后一条示例对近期上下文的影响最大所以最难的示例可以放前面最标准的示例放最后。这个细节说出来面试官会觉得你真的调过模型。我的坑有次做情感分类我在示例里混入了两条边界模糊的样本结果模型在正式预测时开始输出解释而不是标签。后来我意识到示例必须全部是确定性强的、能代表决策边界的样本带歧义的示例会让模型学去不确定时怎么办的风格。2.2 范式二思维链Chain-of-Thought思维链的本质是把复杂问题拆解成中间推理步骤让模型在正式输出答案之前先亮出草稿纸。它的理论基础是每一步推理需要的计算量被显式地分摊到多个token上模型生成中间结论时也在做自我约束。面试最经典的问题是让我们一步一步想这句咒语为什么有效面试官不想听因为它有效所以有效。你需要说到点子上这句指令把单次难推理转化为多次简单推理同时暴露推理过程相当于让模型在生成过程中自带了一个检查点。如果回答时能补一句但它不是万能的模型推理能力不足时反而会产生更长的错误路径基本就稳了。另一个高频追问是CoT和few-shot结合使用和单独用有什么差别。我自己的实测是纯靠一句think step by step在小模型上效果很差因为模型没有足够的推理容量但配上2到3个带推理过程的示例小模型也能被带出像样的推理链。所以面试答题时最好强调CoT不是咒语是示例指令模型容量三者配合的结果。还有一个方向值得说清楚——什么时候不能依赖CoT。如果任务是事实性问答比如某市GDP是多少再长推理也不会从模型参数里变出准确知识。面试官出一个这种场景其实是在考察你能不能判断提示词与知识边界的匹配度。2.3 范式三角色扮演式提示Role Prompting角色扮演可能是被最高估也被最低估的一个范式。高估是指很多人以为加个高质量角色词就能解決一切。低估是指它其实包含一个普适原理角色设定约束了回答的角度、语域和信息粒度。比如你是客服质检专家和你是只回答是或否的机器人两者激活的不是同一个语言区域。角色词本质上是一个压缩了任务约束的语义索引它告诉模型现在处在什么场景、该用什么身份视角、关注哪类信息。面试里的进阶题是角色设定和具体指令冲突时模型会听谁的我实测下来具体指令的优先级更高但角色设定会污染输出风格。比如你让模型扮演财务分析师同时又让它简洁输出它可能会在简洁中不自觉地加一些术语。这个问题回答得好就能展示你的机制理解程度。实战中角色词不是越长越好。面试官给你场景让模型做纠错改写你可以拆成三层身份背景、行为约束、输出格式。写成你是一位有十年经验的文档校对员只改正错别字和语法错误不改变原意输出时按原文→修订→原因三条给出比你是专家请认真要实用得多。我的经验是角色扮演失败时九成原因不是角色不够强而是角色与任务的匹配度不够。比如你是小学数学老师去解高数题模型会倾向用教小孩子的方式解释极限反而降低了专业性。所以面试时我一般会在答案里主动加一句角色设定要服务于任务本身的认知复杂度。2.4 范式四自洽性采样Self-Consistency自洽性是思维链的增强版。它的做法是对同一个问题用带随机性的采样参数生成多条推理路径然后对最终答案做投票取众数作为结果。原理是正确答案的推理路径可能有多条但错误答案通常是路径特有的所以多数投票可以摊薄随机错误。面试官喜欢把这道题和思维链怎么配合放在一起考。你应该回答自洽性建立在多次CoT采样之上它解决的是单条推理链看似有道理但结论错误的问题。如果在面试手写时只有两个示例一定要说明白先采样十条再按答案聚类选最大簇而不是我自己觉得某个答案对就选它。还有一个必考追问自洽性的代价和适用边界是什么代价很直白十次采样的token成本和延迟还有需要结果存在可比较性——封闭式任务选择题、判断题、分类标签非常适合自洽性开放式创作任务用自洽性反而会把多样性抹平。面试官这么问就是在看你会不会为了效果而忽略成本。我在一个分类项目里用过自洽性稳定性从86%提到了93%但每请求的token用量翻了十倍。后来我调整到只在置信度低的时候才做二次采样效果和成本才取得了平衡。这个条件触发自洽性的思路面试官听完会觉得你是在做真实工程不是套论文公式。2.5 范式五ReAct推理行动循环ReAct把推理与行动交叉进行模型感知到信息缺口时会生成一个工具调用行动比如查数据库、跑代码拿到反馈结果后继续推理直到答案收敛。它本质上是把单次问答变成了一个闭环决策过程。面试里如果聊到ReAct面试官基本默认你已经会写普通提示词了他更关心三件事第一你怎么设计行动空间也就是允许模型调用哪些工具第二怎么防止模型反复调用同一个工具导致死循环第三工具返回错误时模型该怎么反应。我的建议是回答时带上成本意识。比如你可以说我会在系统提示里显式声明可用工具列表和参数格式并用一个最大迭代次数作为兜底。每次行动后强制模型先总结已知信息再决定下一步避免无意义循环。这种回答不是在背ReAct的论文描述而是真的跑过类似的事情。我还遇到过面试官让现场给一个用ReAct解决某研究助理场景的方案。我当时给的结构是先定义问题边界再给三个工具语义搜索、公式计算、信息判断然后约定每一步输出的格式为思考→行动→观察。面试官接下来追问如果搜索返回空结果你要怎么设计提示词这里你要答出不调用搜索而是直接输出信息不足也是一种行动这个细节会让面试官觉得你考虑过真实世界的数据稀疏问题。3. 面试里最常见的几类题喂给你一套回答框架3.1 对比类问题按解决的问题—适用条件—成本三维回答面试官一旦问这几个范式有什么区别不要按顺序背定义。你按三个坐标展开解决什么问题、适用什么条件、代价是什么。几个范式的关系我用一张表来总结范式解决的核心问题适用条件主要代价Few-shot让模型快速对齐任务格式和分布有代表性样本、单轮任务示例选择不当会带偏输出CoT提升多步推理准确率模型容量足够、任务可分解输出变长时延和token上升Role Prompting约束回答风格、角度和信息粒度角色与任务复杂度匹配角色冲突时风格迁移不可控Self-Consistency消除单条推理路径的随机误差封闭式答案、可比较投票采样次数放大成本和延迟ReAct通过工具补足模型知识盲区有外部工具、需闭环决策循环风险、工具设计复杂度面试官基本都是顺着这张表往下追问的。你可以主动说我习惯先判断任务属于格式问题、推理问题还是知识边界问题再用对应的范式组合。这句话等于把五个范式统一到了决策框架里展示的是思考体系。3.2 现场设计提示词题的答题SOP遇到请你现场设计一个提示词解决XX任务的题我推荐一套稳定的答题流程需求澄清→范式选择→初稿设计→效果自评→扩展方案。需求澄清先说出口别听完题目就写。比如面试官说让模型提炼会议纪要看板你要快速追问纪要是一段还是多段输出是延续原文还是摘要重写要不要区分决策和待办事项这种追问展示了你不是在背模板而是在做需求分析。然后是范式选择。我会口述出来这个任务核心是结构化提取格式对齐很重要所以我会先用few-shot的方式给出两条真实样例再用角色提示词限定视角为项目经理最后在输出层用JSON格式约束。听到这里面试官基本就能判断你确实理解这几个范式的适用场景了。最后一定要做效果自评。你可以说我会准备二十条历史会议记录做评测先人工定好三条维度完整度、准确性、格式正确率跑一版后根据错误类型决定是修示例还是加后处理。这套说法在面试里的杀伤力很大因为它透露两件事你知道怎么验证你知道怎么迭代。3.3 高频追问温度、k值、JSON稳定性怎么答追问一温度设多少为什么不要答0.7比较好。正确答案是温度控制采样的随机性事实抽取类任务调低0—0.3创意生成类任务调高0.7—1.0自洽性采样时提高温度以增加路径多样性。把温度和一个具体决策绑定起来面试官才会有你是用户的真实感受。追问二few-shot的k值怎么定别背越多越好。要区分场景简单分类任务1到2个示例即够格式迁移任务3到5个困难推理任务配合CoT给2到3个带步骤的示例就足够。k值增大边际收益会快速递减还要考虑最长输入的限制。末尾再补一句k值要到评测里去定不是拍脑袋定。追问三输出JSON一会格式错乱怎么办这题几乎每次都考。你的回答应该分三层第一层提示词里明确schema示例直接照这个格式输出第二层降低温度并关闭择优采样带来的发散第三层程序侧做兜底解析或让模型自己更正自己的输出。模型自己纠正自己这件事面试官很少听到但实际很管用你可以说检测到解析失败时把错误信息和期望schema拼回去让它再生成一次。4. 从会背概念到能过面试我的实战复盘4.1 一次现场手撕题的完整翻车记录有次面试对方让我设计一个提示词让模型从用户评价中提取产品、问题、情绪倾向三个字段并输出JSON。我当时一上来就写了一大段提示词身份、规则、示例全塞进去结果面试官问你这条方案的失败模式是什么我卡住了。复盘发现我的问题很典型只考虑链路完整没有考虑边界case。比如用户评价里同时出现两个产品JSON里product字段是数组还是字符串评价情绪是混合的产品不错但客服差sentiment该取严格单一标签还是允许带子情绪这四个字是提示词怎么写都绕不开的。正确的做法是先用5到10个标注样本把所有边界情况想清楚再反推到提示词里。后来我重构答案时用了任务分解思路第一层先用few-shot把原文中的产品名、问题短语、情绪标签分别抽取第二层用一条规则提示词把抽取结果整理成JSON。面试官明显对这一版更满意因为我把不确定性留在了程序逻辑里而不是指望一句提示词包打天下。4.2 面试官真正想听到的经验点在反复被拷打之后我总结出面试官最认的三个经验点。第一个是你判断过一个方案失败。面试官不想听全能的提示词想听你说清这个方案的失效条件是什么、失效时表现什么样、怎么发现它失效。这其实是把提示词当作软件工程对象来对待。你主动说出这是我这个方案最脆弱的地方反而比藏着掖着加分。第二个是你会靠评测说话而不是靠感觉。至少在面试中提到一句我离不了评测集。哪怕没有真实数据集你也可以说我会先构造20条黄金样例作为回归基线每次改提示词后跑一遍防止修了一个case坏了另外十个。这句话直接把你和其他候选人区分开了。第三个是你有成本意识。聊到CoT时提输出长度翻倍聊到自洽性时提请求量翻十倍聊到ReAct时提工具调用延迟。面试官在业务侧最头疼的就是候选人不计成本地堆效果你主动算这笔账他会觉得你能直接上手。我在面试中还有一个习惯是随时准备一张失败案例清单。每条都长这样任务X尝试把角色和指令混合失败原因是他俩冲突了把角色写详细后输出风格变化但格式还是不稳定最终用示例解决。面试官对具体案例的注意力远超对抽象概念背诵的注意力。最后还想多说一句提示工程面试的爆发式需求是因为现在做AI应用的人都意识到一个稳定可落地的提示词和一段稳定可维护的代码一样需要方法论。五个范式不是用来背的是用来做决策的。多拿自己手头的真实任务做实验记录每次失败几个月之后你再遇到面试题会发现自己能聊的东西根本聊不完。