最近跟几个准备跳槽的朋友聊了一圈发现大家面试AI应用岗最头疼的往往不是模型算法反而是Prompt Engineering——看着题目简单写起来到处是坑。面试官压根不关心你背过多少模板他会扔给你一个模糊需求让你当场拆解、当场写、当场讲思路这套东西考的就是范式意识。所谓范式不是一条一条零散的技巧而是遇到任务时能立刻调用的方法论框架。今天我把面试里最高频的5个范式系统梳理一遍每个都拆开讲面试官怎么出题、怎么追问、你怎么答才能拿高分以及我实际面试中见过的翻车现场。不管你是正准备面试还是已经在做AI应用开发想补足方法论这份拆解都值得收藏慢慢看。1. 先搞懂面试官为什么要考范式1.1 出题逻辑技巧可以背范式装不了面试题网上到处都是角色扮演、加示例、调温度、让它分步思考这些技巧你花两天就能背完。真正拉开差距的是你拿到一个完全没见过的任务时能不能快速判断该用哪套打法、为什么这么选、出了问题往哪个方向修。这背后体现的就是范式意识。面试官把题目扔出来看的是你脑子里有没有一套决策框架这个需求属于指令控制、上下文学习、推理引导、知识增强还是多轮修正选完范式之后怎么落地写完提示词怎么验证效果不好怎么迭代这一套流程只要走一遍你的水平基本就暴露了。所以面试题表面在考提示词实际在考你有没有做系统化的方法论训练。1.2 五范式总览与适用边界先把5个范式的全貌列出来后面逐个拆开讲范式一句话概括典型应用结构化指令范式用角色、任务、约束、输出格式把需求拆清楚信息抽取、内容生成、格式转换少样本示例范式在上下文里给模型看输入输出对让它照着来风格模仿、格式稳定、分类任务链式思考范式引导模型先推理再给答案算术、逻辑、数学应用题、复杂规划检索增强与输出约束范式先查外部资料再回答用结构锁死输出私有知识问答、实时信息、JSON输出反思修正范式先生成、再批评、再重写高质量文案、长文润色、多轮Agent这5个范式不是互斥的实际项目里经常组合着用。比如一个问答系统可能是检索增强加结构化输出也可能再加一层链式思考处理复杂问题。面试题通常让你在一个场景里选主范式如果你主动说出叠加方案会比单点回答高半档。2. 五大范式逐层拆解出题点与答题策略2.1 结构化指令范式送分题还是送命题全看细节这是最基础的范式核心是把需求结构化表达。面试题往往长这样请写一个Prompt让模型输出JSON对象包含姓名、年龄、职业三个字段。很多人直接开写请输出JSON {name: 张三, age: 25, job: 工程师}这个答案能拿及格分但面试官下一句就会追问如果用户输入是一大段乱序文本怎么办如果模型输出夹了解释文字怎么办如果字段值不在预期范围怎么处理到这一步不少候选人就开始卡壳了。正确的答题思路是给模型画边界。角色、任务、输入、输出、兜底策略都要写到位。我倾向于这样组织你是一个信息抽取助手。用户会发来一段非结构化文本。 你需要从中抽取姓名、年龄、职业三个字段并输出严格的JSON对象。 要求 1. 只输出JSON不要输出任何解释 2. 字段名固定为name、age、job 3. 如果某个字段无法从文本中推断填unknown 4. 年龄输出整数不要带岁字 用户文本……为什么要写成这样大模型本质是续写模型不把输出格式锁死它就会自由发挥后面解析的时候就得处理一堆脏数据。面试官考的就是你有没有输出解析和边界兜底的意识这比把角色描述写得花里胡哨重要得多。再补充一个加分细节如果字段值有枚举范围比如性别只能填男或女一定要在Prompt里写清楚。你不写模型就可能输出“男性”“Male”“男同志”这类变体解析逻辑要写多少分支才能兜住你自己体会一下。2.2 少样本示例范式让模型照着样子干活第二个高频范式是少样本原理一句话在上下文里放几个输入输出对模型就会把后续输出往这个分布上靠。面试官常这样出题想让模型模仿特定风格的文案你怎么设计Prompt如果你只加一句“请用轻松幽默的风格写”效果通常不稳定。更可靠的做法是直接给示例让模型看见风格长什么样请把下面的句子翻译成简单中文语气要像朋友聊天。 示例1 输入Please be advised that we have received your application. 输出我们收到你的申请了啊。 示例2 输入The meeting has been rescheduled to Friday. 输出会议改到周五了。 输入We sincerely apologize for the delay. 输出示例的价值不只是给模型看风格还暗示了输出长度、标点习惯、口语化程度。答题时你要主动说出示例选择的逻辑示例要覆盖典型情况和边界情况最好再放一个反面示例告诉模型“不要往那边跑”。比如上边的翻译题可以追加一个正式公文风格的反例让模型明确避开那种腔调。这个范式有两个必答的坑。第一示例质量远重要于数量5个乱七八糟的示例不如2个精挑细选的第二受上下文窗口限制示例不是越多越好边际收益递减。面试官追问“示例越多越好吗”就等着你这两个答案。2.3 链式思考范式面试高光题答好直接过关链式思考是这几年的必考范式原因是它效果好、有理论可以聊、变体足够多面试官能顺着追问很深。基础题长这样让模型算24乘以17模型经常直接算错。面试官想看你会不会引导它分步计算请计算24乘以17。 请先把24拆成20和4分别乘以17再把两个结果相加最后给出答案。进阶考法是零样本CoT在Prompt结尾加一句“让我们一步一步思考”模型即便没有专门训练也能展现出推理能力。再往上就是Self-Consistency同一条问题采样多条推理路径最后投票选出最一致的答案。能讲到这一层的候选人直接甩开一大半竞争者。面试官最常问的深水问题是为什么CoT有效我的理解是它把一次到位的推理拆成多个小目标每一步都有明确的中间产出降低了一步算到答案的解码压力。你可以打个比方让你心算365乘以48很难但让你先算300乘以48再算60乘以48、5乘以48最后加总难度会低很多。面试官听到这种类比通常会点头。但你必须知道CoT的边界。简单任务比如判断一段话是正面还是负面加不加CoT效果都一样加了反而多花token模型自身推理能力弱时CoT甚至会生成一条看似合理但每一步都错的长篇推理。面试官问“所有任务都适合吗”就是在等你答这两个坑。2.4 检索增强与输出约束工程分水岭这部分考的不是你会不会写提示词而是有没有真实产品意识。最典型的面试题某个知识库的数据是最近更新的模型训练时没见过用户问到了怎么办标准思路是先检索再生成。把相关资料查出来拼进上下文要求模型基于资料回答# 检索增强生成的关键流程 docs retriever.search(user_query, top_k3) context \n.join(doc[text] for doc in docs) prompt f请根据下面的资料回答用户问题。 如果资料中没有相关信息请明确回答“资料中未找到”。 资料 {context} 问题{user_query} response chat_model.chat(prompt)写这段伪代码时面试官会观察你有没有几个细节是否设置了“资料中没有相关信息就直说”的兜底是否控制检索条数、避免超长上下文是否考虑多文档信息冲突时怎么处理。这些点每答出一个都能聊得更深。输出约束的进阶考法是函数调用范式。你需要模型返回机器可读的动作或参数最稳的思路不是让模型自由编JSON而是给一个明确的函数定义让模型只负责填充字段。能画出这条链路——模型决定调用哪个函数、怎么填参数、校验失败怎么重试——你的工程能力就完全体现出来了。2.5 反思修正范式从写一遍到写三遍这个范式这两年出现频率明显上升因为它正好踩在Agent和高质量内容生成的交点上。核心思想生成一遍不够让模型自己当批评者挑毛病再按批评意见重写。面试题通常是模型生成的广告文案太空洞全是“高端大气上档次”这类没有信息量的词你怎么迭代到第三版可以这样推进第一轮请为这款耳机写一段产品介绍。 第二轮请以最挑剔的用户的身份指出上面文案中最不真实的3处表述并说明理由。 第三轮请根据第二轮的批评意见重写文案。要求每条说法都有具体依据禁止使用空泛形容词。这一套多阶段生成思路真实业务里广泛用在长文写作、代码审查、翻译精修上。面试中有一个加分表达主动提成本。每一轮都是一次完整的大模型调用三遍生成意味着三倍token开销。简单任务一次搞定就行只有质量要求高的场景才值得烧这个钱。这种成本权衡感是有经验的人和背题选手的显著区别。3. 面试实战套路拿到题目怎么走完完整答题链路3.1 五步答题框架审题、选型、落笔、验证、兜底面试题千变万化但答题链路固定。我把自己的框架拆成五步每一步对应面试官期待的一个关键信息。第一步审题定位。搞清楚任务是抽取式、生成式、总结式还是多步推理。抽取式任务优先用结构化指令范式生成式任务如果风格要求明确考虑少样本推理类直接上链式思考涉及新知识用检索增强质量要求极高的用反思修正。第二步讲选型理由。说清楚为什么选这个范式而不是别的这一部分往往比Prompt本身更重要。第三步落笔写Prompt。组织成角色层、任务层、输入层、约束层、输出层把一句话需求拆成多层结构。写的时候要克制不要堆叠无意义的强调词。第四步说验证方案。用两三组边缘输入测格式是否稳定、内容是否符合预期。第五步给兜底方案。模型输出解析失败怎么办检索没召回怎么办都要说清楚。把五步走完面试官基本没有继续追问的空间。3.2 一道模拟面试题的完整拆解用一道我实际面过的真题演示让模型从会议记录中生成可执行事项输出JSON。给你3分钟思考你怎么答如果你直接写一句“请从会议记录中提取待办事项并按JSON输出”等于什么也没说。面试官真正想看的是这个层面任务定位是抽取加结构化输出主范式选结构化指令辅助加一个少样本稳定格式。输出必须锁字段执行事项要有负责人和截止日期没写负责人的填“待指派”最终输出要么是能被程序直接解析的JSON数组要么就不要输出。最终Prompt可以这样落地你是一个会议纪要整理助手。下面是一段会议记录你需要提取所有可执行事项。 输出为JSON数组。每个元素包含四个字段 - task具体待办内容 - owner负责人未提及时填待指派 - due_date截止日期未提及时填未确定 - priority高/中/低根据上下文判断 会议记录 {record}写完Prompt要主动补验证思路先跑一段没有明确负责人的记录看owner是否变成“待指派”再跑一段日期格式混乱的记录看due_date是否被归一化如果模型输出了markdown标签或解释文字说明输出约束不够强需要加一个“只输出JSON数组”的负面示例。把这一套完整讲完你实际上已经把5个范式串起来用了一多半。面试分水岭就在这里。4. 高频翻车现场与纠偏方法4.1 6个常见错误速查表我在面试中见过太多相似翻车现场整理成一张表每条都对应一个明确的改法错误表现为什么扣分正确姿势想到哪写到哪没有框架说明没有范式意识纯靠感觉先定位任务类型再选范式提示词写得像长篇小作文关键约束被淹没模型注意力稀释短句分层每条约束独立成行只会加“请务必、非常重要、切记”这类词几乎不改变模型行为说明缺手段用示例和格式约束代替情绪化强调从不提输出解析和容错做不了真实产品停留在玩具Demo主动说解析失败怎么办、字段缺失怎么兜不知道某句话为什么有效没有实验能力迭代只能靠猜逐个删掉Prompt里的句子对比效果变化把简单任务复杂化一刀切加CoT或堆示例浪费token按任务复杂度选最小化方案4.2 为什么“少即是多”反而更显功力不少候选人有个误区以为面试官喜欢越详细越完整的Prompt。其实面试官更愿意听你说清楚什么是必须约束的、什么是不需要约束的。过度的约束会让输出僵化。比如在会议纪要场景里不约束语言风格是因为提取执行事项与风格无关但必须约束字段格式是因为下游要用程序解析。每个约束背后都有理由这比把Prompt雕成一朵花更能证明工程判断力。我还见过一种特有迷惑性的翻车候选人讲了很多“我平时调Prompt靠感觉”。这句话在面试里杀伤力极大等于告诉面试官你没有方法论沉淀。哪怕你真的是靠经验吃饭也要把经验归纳成可以讲的规则——哪个环节出问题、往哪个方向试、判断标准是什么。5. 备考节奏与最后自查5.1 一个月实战备考方案如果面试还有一段时间建议按这个节奏准备。第一周把5个范式分别跑通每个范式建三个用例记录效果差异。第二周做范式叠加比如检索增强加链式思考处理一个既需要外部资料又需要多步推理的混合任务。第三周练限时答题给自己5分钟按第三节的五步链路完整讲一遍。第四周做模拟面试找朋友互相出题专门练输出约束和兜底方案这些最容易暴露短板的环节。强烈建议建一个提示词实验本。每次调整都记录三行改了什么、效果怎么变化、为什么这么改。三个月之后翻一翻你会发现自己已经沉淀出一套适合本行业工作流的方法论面试时随便抽一页都能讲成案例。5.2 出发前最后检查清单去面试前拿这张表自检5个范式能不能不看资料默写出适用场景每个范式能不能举出真实例子而不是背模板能不能解释CoT为什么有效、示例为什么有效、结构化输出解决了什么问题能不能说出每个范式额外消耗的成本。四条都过了你已经高于九成候选人。我这些年面试别人最深的感受是面试官要的不是一个会背技巧的人而是一个拿到问题就能判断方向、快速进入状态、并且能说清楚每一步为什么这样做的工程师。提示词是表层功夫范式是底层能力。把底层练扎实了表面怎么写都是顺理成章的事。希望这份拆解能成为你面试前看的最后一份Prompt Engineering资料准备充分上场不慌。