1. 面试官到底在考什么干了几年大模型应用开发我面过不少人也被面过不少次。Prompt Engineering这个岗位名称听起来很“软”好像会写几句提示词就能上岗但实际上面试官想考察的东西非常硬核根本不是“你用过哪些Prompt技巧”这种流水账而是三个层面第一层你是否理解大模型的工作机制。提示词只是表面背后是Token预测、注意力机制、上下文窗口、指令遵循能力这些底层逻辑。面试官会给你一个看似简单的Prompt让你分析“为什么这样写有效”如果你只回答“因为指令清晰”那基本就凉了。第二层你是否具备系统化的方法论。遇到复杂任务你能不能把问题拆解成“任务分析-范式选型-模板设计-评测迭代”的完整流程而不是想到什么写什么。第三层你是否踩过真实的坑。面试官最常问的其实是“你遇到过什么失败案例怎么排查的”这个问题能迅速区分出背题家和实战派。为了应对这种考察方式我把日常工作中最常用的Prompt模式收敛成了五个范式。这五个范式基本覆盖了面试中99%的场景题而且每个范式都有对应的经典追问。全文会用“面试官怎么问”和“你应该怎么答”两条线穿插来讲帮你看清考题背后的意图。提示本文适合准备大模型应用类岗位面试的同学读也适合正在做Prompt设计但总觉得缺一套方法论的朋友。看完之后你不仅知道这五个范式是什么更知道什么时候选哪个、怎么应对考官的深度追问。2. 范式一思维链CoT——考的不是提问是拆解2.1 面试题的经典出法面试官一般会直接甩一道推理题过来比如“一个容器里有红球和蓝球红球占总数的40%又加入20个蓝球后红球占比变成25%请问原来有多少个球”如果你直接给答案哪怕答对了分数也不高。这道题真正想考察的是“你回答问题的路径”——你是让模型直接输出结果还是引导它分步推理。这个场景在真实业务里太常见了。我在做客服问答系统的时候用户问“我上个月账单为什么多了80块”模型如果直接回答很可能把“多了80块”和“套餐变更”错误关联。但如果你在提示词里强制模型先拆解——先查账单周期、再对比项目明细、最后定位差异项——准确率能提升一大截。思维链范式的核心公式是复杂问题 分解步骤 逐步推理 每步验证。面试官想看的就是你有没有这个意识。2.2 标准答法与变体最稳妥的现场作答模板是请按照以下步骤思考 1. 列出题目给出的已知条件 2. 找出需要求解的未知量 3. 用数学表达式表示数量关系 4. 逐步计算并验证每一步但这只是基础版。面试官如果想区分高手会接着问“如果模型分步推理时某一步算错了怎么办”这就是在考察你对CoT局限性的认识。我一般这样回答纯粹靠“请你一步步思考”并不能保证正确率因为模型可能在中途幻觉出一个错误的中间结论然后顺着错的方向越走越远。更可靠的做法是引入“自我验证机制”——在提示词里要求模型在得出最终答案前先用另一种方式重新推导一遍或者把中间结果代入原题检查。这就是Self-Consistency的思路生成多条推理路径投票取最优。这个回答能展示三层能力你懂CoT的原理、你知道它的短板、你有真实场景中的应对方案。面试官要的就是这个。2.3 高频追问与避坑指南关于CoT面试里还有三个高频追问值得提前准备。第一个追问是“CoT和直接问有什么区别”。你可能会下意识回答“CoT更准确”但更准确的表述是CoT将隐式的推理过程显式化让模型在每一步都占据明确的语义空间从而减少跳跃性错误。打个比方直接提问就像让一个新手直接写一篇论文CoT则是让他先列提纲再逐节写作显然后者更可控。第二个追问是“什么时候不该用CoT”。这个问题很刁钻但答案很明确当任务是简单事实检索时CoT是画蛇添足还可能引入不必要的幻觉。比如“某公司CEO是谁”这种问题你让模型“先分析、再推理、后回答”反而增加了出错概率。正确做法是任务难度匹配范式复杂度简单任务直接用零样本提示复杂任务才上CoT。第三个追问是“如何控制CoT的推理长度”。有些模型在“仔细思考”的引导下会输出冗长的废话反而干扰最终答案。我的经验是显式限制“请用不超过3步完成推理每步不超过30字。”实测下来这种约束能显著提升输出质量同时节省Token消耗。3. 范式二Few-shot 示例学习——考的是一手资料3.1 为什么示例比指令更有效面试官经常会问“如果模型不按你的格式输出你怎么办”很多人第一反应是“在指令里强调格式”。实际上更有效的做法是给示例。这是我在真实项目里反复验证过的指令是抽象的模型对“请输出JSON格式”这句话的理解可能不稳定但如果你给它两个“输入-输出”的配对示例它就能通过模式匹配学会格式。这个范式在面试里的出题方式通常是给出一个任务比如情感分类让你现场设计一个包含两个示例的Prompt。这里考察的不是你会不会写“你是一个情感分析助手”而是你有没有能力设计出高质量的few-shot示例。这里有一个关键技巧示例的顺序比内容更敏感。我做过一个意图识别项目同一组示例顺序调换后准确率从92%降到了88%。原因是模型对最后一条示例的“近因效应”更强如果你希望模型用某种特定风格输出就把这种风格的示例放在最后。3.2 高质量示例的四个原则面试官让你设计few-shot示例时你可以按下面四个原则来组织答案这比直接给结果要加分得多第一示例必须覆盖边界情况。如果任务是判断客服对话是否包含投诉示例不能全是“明显的投诉”和“明显的非投诉”至少要有一条“边界模糊”的样本比如用户说“你们产品还行吧就是发货慢了点”这是中性还是抱怨模型看过这种例子后对真实场景的泛化能力会好很多。第二示例的输入输出要保持一致性。有些同学喜欢在一个Prompt里混用不同格式的示例比如第一条输出是JSON第二条输出是纯文本模型会无所适从。业界做法是指令部分负责说明任务示例部分负责锁定格式和风格各司其职。第三示例数量一般控制在2到6个之间。太少模型学不到模式太多可能超出上下文窗口还会引入噪声。面试时你可以说“我通常从2个示例开始逐步增加直到准确率不再提升为止”这个表述能体现你有评测意识。第四示例的内容要贴近真实场景。不要为了展示能力而用过于理想化的例句用真实业务中用户的实际说法更有说服力。3.3 现场发挥示例如果面试官让你现场写一个“把用户评价分类为正面/负面/中性”的Prompt我建议这样答请对以下用户评价进行情感分类只输出“正面”、“负面”或“中性”。 示例1 评价这个耳机音质太棒了续航也超出预期。 分类正面 示例2 评价收到货发现包装破损申请售后半天没人理。 分类负面 示例3 评价用了三天总体还行就是手感一般。 分类中性 评价物流比预计晚了两天但是客服态度很好东西也不错。 分类答完记得补一句“这三个示例分别对应强烈的正面、强烈的负面和边界模糊的中性这样模型能学到分类的边界。”面试官听你说出“边界”这两个字就知道你不是背的。4. 范式三结构化输出与约束生成——考的是代码思维4.1 让模型输出格式化数据大模型应用开发中最痛苦的莫过于模型吐出一段语义正确但格式全乱的文本下游代码一解析就报错。所以“结构化输出”几乎成了面试必考项。面试官的常见问法是“你如何保证模型稳定输出JSON如果JSON格式偶尔出错你怎么兜底”很多人的回答是“在Prompt里写清楚字段要求”。这个回答没错但是太浅了。一个真正合格的答案应该分层来讲第一层Prompt层面的约束。明确指定输出字段、类型和取值范围并且提供JSON Schema示例。第二层采样参数层面的配合。JSON这种结构化输出对温度敏感高温度会让模型随意发挥一般建议temperature降到0.2以下。第三层代码层面的兜底。Prompt再完善也有失败概率一定要在代码里做格式校验和修复比如利用“从文本中提取第一个JSON对象”这种解析策略。4.2 实战案例带约束的Prompt写法这里直接给出一段我在项目中验证过的Prompt结构你可以把它当作面试回答的模板你是一个数据抽取助手。根据用户输入输出一个JSON对象字段如下 { order_id: 字符串订单号如ORD-20240101-001, items: [字符串数组商品名称], total_amount: 数字订单总金额单位元保留两位小数, risk_flag: 布尔值是否命中风控规则 } 要求 1. 只输出JSON不要输出任何解释性文字 2. 如果输入中缺少某个字段设为null 3. 金额必须为数字类型禁止使用字符串 用户输入我在1月2号买了一件羽绒服和两条围巾总共花了599.9元。面试官如果追问“为什么金额要特别强调保留两位小数、必须是数字类型”你可以回答模型默认倾向于输出自然语言风格的数值如果不显式约束类型很可能输出字符串599.9导致下游聚合计算出错。这个细节能体现你在真实项目中踩过坑。4.3 面试官高频追问的三道必答题结构化输出这块有三道追问几乎每场面试都会出现提前准备好能省不少力。第一道“你刚才说用Schema约束但如果模型输出缺失字段怎么办”我的回答是与其事后补救不如事前规避。在Prompt末尾显式加上一句“请确保输出包含所有字段若信息不足使用null填充”这样能显著降低字段遗漏概率。代码层面我还会写一个默认值填充函数把缺失字段补上“unknown”或空值。两种手段结合稳定性才能保证。第二道“模型输出的是JSON数组而不是单个对象怎么处理”这其实是考察你的解析容错能力。我通常的策略是在Prompt里明确“只输出一个JSON对象”同时在代码里对模型输出做“截取首尾大括号”的预处理再用JSON解析器尝试。如果解析失败使用正则或大模型二次修复作为最后兜底。第三道“结构化输出会不会限制模型的创造力”这个问题的标准答法是结构化输出主要面向机器消费的场景比如API返回值、数据管道输入在这种场景下“可解析性”远比“文采”重要。如果面向用户展示则可以采用“先结构化后重写”的两阶段策略既保证程序可处理又保证文本可读。5. 范式四自我反思与迭代优化——考的是工程闭环5.1 从一次失败开始谈起面试官有一个很经典的场景题“你设计了一个Prompt上线后发现准确率只有60%你会怎么做”这道题没有标准答案但考察的是你有没有工程化的调试方法。如果你说“我会修改Prompt反复试”那就等于白说。面试官想听的是你的迭代路径是什么你如何确定问题出在Prompt、模型还是数据上我在真实项目中总结了一套四步排查法第一步收集Bad Case至少20条错误样本逐条分析错误类型——是格式错、语义错、还是漏检错。第二步分类归类错误根因——是Prompt指令歧义、示例覆盖不足、还是模型本身能力限制。第三步针对性修正每轮只改一个变量。第四步回归测试用一个固定测试集评估改动前后的指标变化。这套方法背后的逻辑是“控制变量法”。很多开发者改Prompt像抽盲盒改一句没效果就再改一句最后也不知道哪句起了作用。而工程化做法是通过版本管理为每一版Prompt打Tag记录改动内容和效果指标这样每一轮迭代都有迹可循。5.2 面试得分点用提示词做“自我批判”自我反思范式是面试官很喜欢深挖的一个点。具体来说它是让模型对自己的输出进行批判性检查。这个范式在复杂生成类任务中非常有效。比如你让模型写一段营销文案它可以先写一版然后要求自己从“目标用户清晰度、卖点突出度、行动号召力”三个维度打分并修正。这种“先写后审”的模式比一次性生成的文案质量高不少。面试时的加分答法是把这种思路延伸到“多轮反思”中。设计一个循环生成答案 → 让模型自己找出3个问题 → 带着问题重新生成 → 再次检查。但要注意反思轮数不是越多越好一般两轮就够。再往后模型可能会过度修改引入新的错误。我在一个报告生成项目中实测两轮反思准确率最高第三轮反而下降了2%到3%。5.3 紧接追问如何做回归评测面试官听完你的调试思路后通常还会追问一句“你如何设计评测集”这里记住一个关键原则评测集必须有“黄金标准答案”并且覆盖典型场景的边界情况。我给一个面试现场能用上的回答框架评测集至少包含100条样本分为三类比例——70%的常规样本、20%的边界样本、10%的对抗样本比如故意带歧义或长尾说法。评测指标根据任务不同而选分类任务用准确率和召回率F1生成任务用“通过率人工抽检”抽取任务用“字段级别的精确匹配率”。最后一定要提一句话“评测不是一次性的上线后我还会持续从线上日志里挖掘Bad Case回流到评测集里。”这个回答的杀手锏在于展示了“持续迭代”的意识面试官最怕来了一个只会写提示词的人但一个知道“建立评测集”的人至少在团队里能独立推动优化闭环。6. 范式五工具调用与Agent式提示词——考的是架构观6.1 面试新宠让模型学会用API最近半年面试官特别喜欢问“Agent”相关的场景题。你不需要会写复杂的框架代码但必须理解一个核心观点Prompt的本质是API设计。这句话在面试中非常加分因为它把Prompt从“写几句话”提升到了“设计系统接口”的高度。常见的出题方式是“你要做一个日程助手用户说‘帮我安排下周三下午三点的会议’你如何设计Prompt让模型正确调用日历API”这道题考察的是Function Calling场景下的提示词设计你需要向面试官展示三件事定义清晰的函数语义、提供参数抽取规则、设置意图判断逻辑。比如这样你是个人助理。你的任务是从用户输入中抽取日程信息。 可用函数create_event(title, date, time, duration_minutes) 抽取规则 - 如果用户输入中没有明确的会议主题title设为“待定会议” - 日期格式化为YYYY-MM-DD - 如果用户输入的是“下周三”需要根据今天日期推算具体日期 - 如果用户输入不包含时间time设为“09:00”duration_minutes设为60 - 如果用户只是闲聊不涉及日程操作请回复“抱歉我无法处理该请求”6.2 为什么说这是“架构观”面试官听完你给的Prompt通常会追问“如果用户的需求涉及多个API调用呢比如订会议还要同步通知参会人你怎么设计”这就是在考察Agent式编排思维。你可以这样回答多步操作不能靠一次性抽取完成而要把任务拆成“意图理解 → 计划生成 → 分步调用 → 结果汇总”四个阶段。每个阶段对应不同的Prompt模块而不是一段话搞定一切。这种设计的好处是每段Prompt只负责一个职责便于调试和替换。坏处是会增加Token消耗和响应延迟所以需要判断任务的复杂程度简单任务就不该上Agent架构。这里有一个面试官极为看重的点你能不能意识到“Prompt不是万能的”。真正复杂的场景应该在Prompt之外配合代码逻辑比如状态机、工作流编排Prompt在其中只是“理解层”负责把自然语言转成结构化指令具体的流转身段交给代码。6.3 避坑要点上下文窗口的边界关于工具调用范式面试中还有一个容易踩坑的延伸问题“如果工具返回的结果很长超过上下文窗口怎么办”这个问题很现实。我的标准答案是工具返回内容不应该全量塞回Prompt而是做摘要或结构化裁剪。比如搜索返回20条结果你不能让模型一次读完而是先只给标题列表让模型选出最相关的3条再展开这3条的完整内容做深读。这种“分阶段选择性读取”的思路是面试中的高分回答它体现的不是你会写提示词而是你会设计一套信息处理流程。7. 面试现场的表现技巧与常见误区7.1 面试官最反感的三类行为面试这件事技术能力只是基础表达方式同样决定结果。结合我自己的面试和被面经验以下三类行为在Prompt Engineering岗位面试中特别容易减分第一类是“背诵知识点”。有些候选人上来就抛术语“我会使用CoT、ReAct、Self-Consistency、Tree of Thoughts……”但一问到“你上一次项目里为什么选CoT而不是Self-Consistency”就答不上来了。面试官想听的是“决策过程”不是术语堆砌。解决方法是每个范式都准备一个“我在什么场景下用了它、效果如何、有什么局限”三件套这比背十个范式都有用。第二类是“忽略成本意识”。给模型设计Prompt不只是追求效果还要考虑Token成本和推理延迟。面试中如果能在回答里提到“这个方案效果提升约3%但Token消耗增加了40%所以我最终选择了另一套方案”面试官会立刻对你的工程判断力加分。第三类是“不敢承认失败”。有一类常见问题是“你之前做过的Prompt项目有没有失败的”如果你说“都成功了”反而让人怀疑你项目的真实性。更好的回答是坦诚讲一个失败案例但重点放在“我怎么定位问题、怎么调整方案、最终学到什么”上。这一点在AI工程师面试里尤为重要因为做AI本来就是高不确定性工作敢于面对不确定性并在失败中迭代恰恰是技术成熟度的体现。7.2 临场发挥的实战套路再分享一个面试中很实用的万能应对框架适用于任何你不确定答案的Prompt场景题第一步复述问题并确认目标。比如“你希望我用尽量少的Prompt实现这个任务对吧”这样既给自己争取了思考时间又避免理解偏差。第二步拆解任务类型。这是分类、抽取、生成、推理还是多步操作不同的任务类型对应不同的首选范式。第三步给出方向性答案。哪怕你不太确定哪种方案最优也可以基于“先分析任务约束再选范式再给示例最后说评测”的框架来组织语言。第四步主动抛出权衡。比如“如果要保证格式稳定我会用Few-shot加JSON Schema如果更看重灵活性我会用思维链配合后处理。”这套框架的好处是结构完整能让你在完全不熟悉题目时也能输出一套听上去很有逻辑的答题路径。面试本质上是沟通只要你框架清晰哪怕细节不够完美面试官也愿意往下聊。7.3 真题模拟三道综合场景题到最后我用三道综合场景题帮大家串一下这五个范式你可以试着在脑子里过一遍答题思路第一题“你有一个任务需要从合同PDF中抽取关键条款并对有歧义的条款做判断。你会怎么设计Prompt”这道题的考点是结构化输出加CoT的组合。抽取部分用结构化JSON歧义判断部分用“先罗列可能解释再选择最合理的一项”的思维链引导。第二题“一个法律问答机器人用户会用各种生活化语言提问你的Prompt怎么设计”考点是Few-shot与意图识别的结合难点在于示例覆盖法律场景的边界情况比如“我能告他吗”这种开放性表达。第三题“你设计了一个智能客服用户问‘你们产品多少钱’结果返回了促销活动的长文而不是价格怎么排查”考点是结构化约束和意图判定的配合。我的思路是先确认模型是否被系统提示词里的“促销活动介绍”干扰再检查是否缺少“用户问价格时直接输出价格区间”的显式规则。这三道题能让你比较综合地检验自己对五个范式的掌握程度。回答的时候不用追求统一模板关键是体现出“先分析任务、再选范式、最后给可行方案”的思路。我个人在实际面试中的体会是面试官真正喜欢的不是“知识渊博的你”而是“遇到问题时能快速定位、并给出可验证方案的你”。所以比起刷更多的范式不如把自己过往做过的两三个Prompt项目按照“目标、选型、迭代过程、最终效果、踩坑经验”五个维度反复复盘。你复盘越深面试时就越有料任何追问都能从真实经验中调取答案而不是现场现编。这才是通过Prompt Engineering面试最可靠的路。 
长河君 · 2026/10/22 11:32:33 · 阅读 1.2k Prompt Engineering面试核心：五大范式带你拆解考官意图
1. 面试官到底在考什么干了几年大模型应用开发我面过不少人也被面过不少次。Prompt Engineering这个岗位名称听起来很“软”好像会写几句提示词就能上岗但实际上面试官想考察的东西非常硬核根本不是“你用过哪些Prompt技巧”这种流水账而是三个层面第一层你是否理解大模型的工作机制。提示词只是表面背后是Token预测、注意力机制、上下文窗口、指令遵循能力这些底层逻辑。面试官会给你一个看似简单的Prompt让你分析“为什么这样写有效”如果你只回答“因为指令清晰”那基本就凉了。第二层你是否具备系统化的方法论。遇到复杂任务你能不能把问题拆解成“任务分析-范式选型-模板设计-评测迭代”的完整流程而不是想到什么写什么。第三层你是否踩过真实的坑。面试官最常问的其实是“你遇到过什么失败案例怎么排查的”这个问题能迅速区分出背题家和实战派。为了应对这种考察方式我把日常工作中最常用的Prompt模式收敛成了五个范式。这五个范式基本覆盖了面试中99%的场景题而且每个范式都有对应的经典追问。全文会用“面试官怎么问”和“你应该怎么答”两条线穿插来讲帮你看清考题背后的意图。提示本文适合准备大模型应用类岗位面试的同学读也适合正在做Prompt设计但总觉得缺一套方法论的朋友。看完之后你不仅知道这五个范式是什么更知道什么时候选哪个、怎么应对考官的深度追问。2. 范式一思维链CoT——考的不是提问是拆解2.1 面试题的经典出法面试官一般会直接甩一道推理题过来比如“一个容器里有红球和蓝球红球占总数的40%又加入20个蓝球后红球占比变成25%请问原来有多少个球”如果你直接给答案哪怕答对了分数也不高。这道题真正想考察的是“你回答问题的路径”——你是让模型直接输出结果还是引导它分步推理。这个场景在真实业务里太常见了。我在做客服问答系统的时候用户问“我上个月账单为什么多了80块”模型如果直接回答很可能把“多了80块”和“套餐变更”错误关联。但如果你在提示词里强制模型先拆解——先查账单周期、再对比项目明细、最后定位差异项——准确率能提升一大截。思维链范式的核心公式是复杂问题 分解步骤 逐步推理 每步验证。面试官想看的就是你有没有这个意识。2.2 标准答法与变体最稳妥的现场作答模板是请按照以下步骤思考 1. 列出题目给出的已知条件 2. 找出需要求解的未知量 3. 用数学表达式表示数量关系 4. 逐步计算并验证每一步但这只是基础版。面试官如果想区分高手会接着问“如果模型分步推理时某一步算错了怎么办”这就是在考察你对CoT局限性的认识。我一般这样回答纯粹靠“请你一步步思考”并不能保证正确率因为模型可能在中途幻觉出一个错误的中间结论然后顺着错的方向越走越远。更可靠的做法是引入“自我验证机制”——在提示词里要求模型在得出最终答案前先用另一种方式重新推导一遍或者把中间结果代入原题检查。这就是Self-Consistency的思路生成多条推理路径投票取最优。这个回答能展示三层能力你懂CoT的原理、你知道它的短板、你有真实场景中的应对方案。面试官要的就是这个。2.3 高频追问与避坑指南关于CoT面试里还有三个高频追问值得提前准备。第一个追问是“CoT和直接问有什么区别”。你可能会下意识回答“CoT更准确”但更准确的表述是CoT将隐式的推理过程显式化让模型在每一步都占据明确的语义空间从而减少跳跃性错误。打个比方直接提问就像让一个新手直接写一篇论文CoT则是让他先列提纲再逐节写作显然后者更可控。第二个追问是“什么时候不该用CoT”。这个问题很刁钻但答案很明确当任务是简单事实检索时CoT是画蛇添足还可能引入不必要的幻觉。比如“某公司CEO是谁”这种问题你让模型“先分析、再推理、后回答”反而增加了出错概率。正确做法是任务难度匹配范式复杂度简单任务直接用零样本提示复杂任务才上CoT。第三个追问是“如何控制CoT的推理长度”。有些模型在“仔细思考”的引导下会输出冗长的废话反而干扰最终答案。我的经验是显式限制“请用不超过3步完成推理每步不超过30字。”实测下来这种约束能显著提升输出质量同时节省Token消耗。3. 范式二Few-shot 示例学习——考的是一手资料3.1 为什么示例比指令更有效面试官经常会问“如果模型不按你的格式输出你怎么办”很多人第一反应是“在指令里强调格式”。实际上更有效的做法是给示例。这是我在真实项目里反复验证过的指令是抽象的模型对“请输出JSON格式”这句话的理解可能不稳定但如果你给它两个“输入-输出”的配对示例它就能通过模式匹配学会格式。这个范式在面试里的出题方式通常是给出一个任务比如情感分类让你现场设计一个包含两个示例的Prompt。这里考察的不是你会不会写“你是一个情感分析助手”而是你有没有能力设计出高质量的few-shot示例。这里有一个关键技巧示例的顺序比内容更敏感。我做过一个意图识别项目同一组示例顺序调换后准确率从92%降到了88%。原因是模型对最后一条示例的“近因效应”更强如果你希望模型用某种特定风格输出就把这种风格的示例放在最后。3.2 高质量示例的四个原则面试官让你设计few-shot示例时你可以按下面四个原则来组织答案这比直接给结果要加分得多第一示例必须覆盖边界情况。如果任务是判断客服对话是否包含投诉示例不能全是“明显的投诉”和“明显的非投诉”至少要有一条“边界模糊”的样本比如用户说“你们产品还行吧就是发货慢了点”这是中性还是抱怨模型看过这种例子后对真实场景的泛化能力会好很多。第二示例的输入输出要保持一致性。有些同学喜欢在一个Prompt里混用不同格式的示例比如第一条输出是JSON第二条输出是纯文本模型会无所适从。业界做法是指令部分负责说明任务示例部分负责锁定格式和风格各司其职。第三示例数量一般控制在2到6个之间。太少模型学不到模式太多可能超出上下文窗口还会引入噪声。面试时你可以说“我通常从2个示例开始逐步增加直到准确率不再提升为止”这个表述能体现你有评测意识。第四示例的内容要贴近真实场景。不要为了展示能力而用过于理想化的例句用真实业务中用户的实际说法更有说服力。3.3 现场发挥示例如果面试官让你现场写一个“把用户评价分类为正面/负面/中性”的Prompt我建议这样答请对以下用户评价进行情感分类只输出“正面”、“负面”或“中性”。 示例1 评价这个耳机音质太棒了续航也超出预期。 分类正面 示例2 评价收到货发现包装破损申请售后半天没人理。 分类负面 示例3 评价用了三天总体还行就是手感一般。 分类中性 评价物流比预计晚了两天但是客服态度很好东西也不错。 分类答完记得补一句“这三个示例分别对应强烈的正面、强烈的负面和边界模糊的中性这样模型能学到分类的边界。”面试官听你说出“边界”这两个字就知道你不是背的。4. 范式三结构化输出与约束生成——考的是代码思维4.1 让模型输出格式化数据大模型应用开发中最痛苦的莫过于模型吐出一段语义正确但格式全乱的文本下游代码一解析就报错。所以“结构化输出”几乎成了面试必考项。面试官的常见问法是“你如何保证模型稳定输出JSON如果JSON格式偶尔出错你怎么兜底”很多人的回答是“在Prompt里写清楚字段要求”。这个回答没错但是太浅了。一个真正合格的答案应该分层来讲第一层Prompt层面的约束。明确指定输出字段、类型和取值范围并且提供JSON Schema示例。第二层采样参数层面的配合。JSON这种结构化输出对温度敏感高温度会让模型随意发挥一般建议temperature降到0.2以下。第三层代码层面的兜底。Prompt再完善也有失败概率一定要在代码里做格式校验和修复比如利用“从文本中提取第一个JSON对象”这种解析策略。4.2 实战案例带约束的Prompt写法这里直接给出一段我在项目中验证过的Prompt结构你可以把它当作面试回答的模板你是一个数据抽取助手。根据用户输入输出一个JSON对象字段如下 { order_id: 字符串订单号如ORD-20240101-001, items: [字符串数组商品名称], total_amount: 数字订单总金额单位元保留两位小数, risk_flag: 布尔值是否命中风控规则 } 要求 1. 只输出JSON不要输出任何解释性文字 2. 如果输入中缺少某个字段设为null 3. 金额必须为数字类型禁止使用字符串 用户输入我在1月2号买了一件羽绒服和两条围巾总共花了599.9元。面试官如果追问“为什么金额要特别强调保留两位小数、必须是数字类型”你可以回答模型默认倾向于输出自然语言风格的数值如果不显式约束类型很可能输出字符串599.9导致下游聚合计算出错。这个细节能体现你在真实项目中踩过坑。4.3 面试官高频追问的三道必答题结构化输出这块有三道追问几乎每场面试都会出现提前准备好能省不少力。第一道“你刚才说用Schema约束但如果模型输出缺失字段怎么办”我的回答是与其事后补救不如事前规避。在Prompt末尾显式加上一句“请确保输出包含所有字段若信息不足使用null填充”这样能显著降低字段遗漏概率。代码层面我还会写一个默认值填充函数把缺失字段补上“unknown”或空值。两种手段结合稳定性才能保证。第二道“模型输出的是JSON数组而不是单个对象怎么处理”这其实是考察你的解析容错能力。我通常的策略是在Prompt里明确“只输出一个JSON对象”同时在代码里对模型输出做“截取首尾大括号”的预处理再用JSON解析器尝试。如果解析失败使用正则或大模型二次修复作为最后兜底。第三道“结构化输出会不会限制模型的创造力”这个问题的标准答法是结构化输出主要面向机器消费的场景比如API返回值、数据管道输入在这种场景下“可解析性”远比“文采”重要。如果面向用户展示则可以采用“先结构化后重写”的两阶段策略既保证程序可处理又保证文本可读。5. 范式四自我反思与迭代优化——考的是工程闭环5.1 从一次失败开始谈起面试官有一个很经典的场景题“你设计了一个Prompt上线后发现准确率只有60%你会怎么做”这道题没有标准答案但考察的是你有没有工程化的调试方法。如果你说“我会修改Prompt反复试”那就等于白说。面试官想听的是你的迭代路径是什么你如何确定问题出在Prompt、模型还是数据上我在真实项目中总结了一套四步排查法第一步收集Bad Case至少20条错误样本逐条分析错误类型——是格式错、语义错、还是漏检错。第二步分类归类错误根因——是Prompt指令歧义、示例覆盖不足、还是模型本身能力限制。第三步针对性修正每轮只改一个变量。第四步回归测试用一个固定测试集评估改动前后的指标变化。这套方法背后的逻辑是“控制变量法”。很多开发者改Prompt像抽盲盒改一句没效果就再改一句最后也不知道哪句起了作用。而工程化做法是通过版本管理为每一版Prompt打Tag记录改动内容和效果指标这样每一轮迭代都有迹可循。5.2 面试得分点用提示词做“自我批判”自我反思范式是面试官很喜欢深挖的一个点。具体来说它是让模型对自己的输出进行批判性检查。这个范式在复杂生成类任务中非常有效。比如你让模型写一段营销文案它可以先写一版然后要求自己从“目标用户清晰度、卖点突出度、行动号召力”三个维度打分并修正。这种“先写后审”的模式比一次性生成的文案质量高不少。面试时的加分答法是把这种思路延伸到“多轮反思”中。设计一个循环生成答案 → 让模型自己找出3个问题 → 带着问题重新生成 → 再次检查。但要注意反思轮数不是越多越好一般两轮就够。再往后模型可能会过度修改引入新的错误。我在一个报告生成项目中实测两轮反思准确率最高第三轮反而下降了2%到3%。5.3 紧接追问如何做回归评测面试官听完你的调试思路后通常还会追问一句“你如何设计评测集”这里记住一个关键原则评测集必须有“黄金标准答案”并且覆盖典型场景的边界情况。我给一个面试现场能用上的回答框架评测集至少包含100条样本分为三类比例——70%的常规样本、20%的边界样本、10%的对抗样本比如故意带歧义或长尾说法。评测指标根据任务不同而选分类任务用准确率和召回率F1生成任务用“通过率人工抽检”抽取任务用“字段级别的精确匹配率”。最后一定要提一句话“评测不是一次性的上线后我还会持续从线上日志里挖掘Bad Case回流到评测集里。”这个回答的杀手锏在于展示了“持续迭代”的意识面试官最怕来了一个只会写提示词的人但一个知道“建立评测集”的人至少在团队里能独立推动优化闭环。6. 范式五工具调用与Agent式提示词——考的是架构观6.1 面试新宠让模型学会用API最近半年面试官特别喜欢问“Agent”相关的场景题。你不需要会写复杂的框架代码但必须理解一个核心观点Prompt的本质是API设计。这句话在面试中非常加分因为它把Prompt从“写几句话”提升到了“设计系统接口”的高度。常见的出题方式是“你要做一个日程助手用户说‘帮我安排下周三下午三点的会议’你如何设计Prompt让模型正确调用日历API”这道题考察的是Function Calling场景下的提示词设计你需要向面试官展示三件事定义清晰的函数语义、提供参数抽取规则、设置意图判断逻辑。比如这样你是个人助理。你的任务是从用户输入中抽取日程信息。 可用函数create_event(title, date, time, duration_minutes) 抽取规则 - 如果用户输入中没有明确的会议主题title设为“待定会议” - 日期格式化为YYYY-MM-DD - 如果用户输入的是“下周三”需要根据今天日期推算具体日期 - 如果用户输入不包含时间time设为“09:00”duration_minutes设为60 - 如果用户只是闲聊不涉及日程操作请回复“抱歉我无法处理该请求”6.2 为什么说这是“架构观”面试官听完你给的Prompt通常会追问“如果用户的需求涉及多个API调用呢比如订会议还要同步通知参会人你怎么设计”这就是在考察Agent式编排思维。你可以这样回答多步操作不能靠一次性抽取完成而要把任务拆成“意图理解 → 计划生成 → 分步调用 → 结果汇总”四个阶段。每个阶段对应不同的Prompt模块而不是一段话搞定一切。这种设计的好处是每段Prompt只负责一个职责便于调试和替换。坏处是会增加Token消耗和响应延迟所以需要判断任务的复杂程度简单任务就不该上Agent架构。这里有一个面试官极为看重的点你能不能意识到“Prompt不是万能的”。真正复杂的场景应该在Prompt之外配合代码逻辑比如状态机、工作流编排Prompt在其中只是“理解层”负责把自然语言转成结构化指令具体的流转身段交给代码。6.3 避坑要点上下文窗口的边界关于工具调用范式面试中还有一个容易踩坑的延伸问题“如果工具返回的结果很长超过上下文窗口怎么办”这个问题很现实。我的标准答案是工具返回内容不应该全量塞回Prompt而是做摘要或结构化裁剪。比如搜索返回20条结果你不能让模型一次读完而是先只给标题列表让模型选出最相关的3条再展开这3条的完整内容做深读。这种“分阶段选择性读取”的思路是面试中的高分回答它体现的不是你会写提示词而是你会设计一套信息处理流程。7. 面试现场的表现技巧与常见误区7.1 面试官最反感的三类行为面试这件事技术能力只是基础表达方式同样决定结果。结合我自己的面试和被面经验以下三类行为在Prompt Engineering岗位面试中特别容易减分第一类是“背诵知识点”。有些候选人上来就抛术语“我会使用CoT、ReAct、Self-Consistency、Tree of Thoughts……”但一问到“你上一次项目里为什么选CoT而不是Self-Consistency”就答不上来了。面试官想听的是“决策过程”不是术语堆砌。解决方法是每个范式都准备一个“我在什么场景下用了它、效果如何、有什么局限”三件套这比背十个范式都有用。第二类是“忽略成本意识”。给模型设计Prompt不只是追求效果还要考虑Token成本和推理延迟。面试中如果能在回答里提到“这个方案效果提升约3%但Token消耗增加了40%所以我最终选择了另一套方案”面试官会立刻对你的工程判断力加分。第三类是“不敢承认失败”。有一类常见问题是“你之前做过的Prompt项目有没有失败的”如果你说“都成功了”反而让人怀疑你项目的真实性。更好的回答是坦诚讲一个失败案例但重点放在“我怎么定位问题、怎么调整方案、最终学到什么”上。这一点在AI工程师面试里尤为重要因为做AI本来就是高不确定性工作敢于面对不确定性并在失败中迭代恰恰是技术成熟度的体现。7.2 临场发挥的实战套路再分享一个面试中很实用的万能应对框架适用于任何你不确定答案的Prompt场景题第一步复述问题并确认目标。比如“你希望我用尽量少的Prompt实现这个任务对吧”这样既给自己争取了思考时间又避免理解偏差。第二步拆解任务类型。这是分类、抽取、生成、推理还是多步操作不同的任务类型对应不同的首选范式。第三步给出方向性答案。哪怕你不太确定哪种方案最优也可以基于“先分析任务约束再选范式再给示例最后说评测”的框架来组织语言。第四步主动抛出权衡。比如“如果要保证格式稳定我会用Few-shot加JSON Schema如果更看重灵活性我会用思维链配合后处理。”这套框架的好处是结构完整能让你在完全不熟悉题目时也能输出一套听上去很有逻辑的答题路径。面试本质上是沟通只要你框架清晰哪怕细节不够完美面试官也愿意往下聊。7.3 真题模拟三道综合场景题到最后我用三道综合场景题帮大家串一下这五个范式你可以试着在脑子里过一遍答题思路第一题“你有一个任务需要从合同PDF中抽取关键条款并对有歧义的条款做判断。你会怎么设计Prompt”这道题的考点是结构化输出加CoT的组合。抽取部分用结构化JSON歧义判断部分用“先罗列可能解释再选择最合理的一项”的思维链引导。第二题“一个法律问答机器人用户会用各种生活化语言提问你的Prompt怎么设计”考点是Few-shot与意图识别的结合难点在于示例覆盖法律场景的边界情况比如“我能告他吗”这种开放性表达。第三题“你设计了一个智能客服用户问‘你们产品多少钱’结果返回了促销活动的长文而不是价格怎么排查”考点是结构化约束和意图判定的配合。我的思路是先确认模型是否被系统提示词里的“促销活动介绍”干扰再检查是否缺少“用户问价格时直接输出价格区间”的显式规则。这三道题能让你比较综合地检验自己对五个范式的掌握程度。回答的时候不用追求统一模板关键是体现出“先分析任务、再选范式、最后给可行方案”的思路。我个人在实际面试中的体会是面试官真正喜欢的不是“知识渊博的你”而是“遇到问题时能快速定位、并给出可验证方案的你”。所以比起刷更多的范式不如把自己过往做过的两三个Prompt项目按照“目标、选型、迭代过程、最终效果、踩坑经验”五个维度反复复盘。你复盘越深面试时就越有料任何追问都能从真实经验中调取答案而不是现场现编。这才是通过Prompt Engineering面试最可靠的路。