提示工程面试5大范式：从零样本到Agent循环

Prompt Engineering 相关的岗位越来越多，面试问法也早不是“给我一个更好的 prompt”这么简单了。我过去一段时间陪一些候选人做过模拟面试，发现一个很一致的现象：能背出各种花式模板的人不少，但从“模板”跳到“范式”的人很少。这篇文章就围绕面试最常考的 5 个提示词范式——零样本与少样本、思维链、自洽性与思维树、结构化输出与角色设定、工具调用与反思循环——拆开讲讲面试官到底在考什么，以及每种范式一层层追问下去你会遇到哪些坑。

如果你正在准备 AI 应用开发、算法应用、或产品侧偏 AI 的面试，又或者只是负责写提示词但总被结果飘忽不定折磨，这篇文章都能当一份检查清单用。它不提供官方答案，因为提示工程本来就没有标准答案；我更想还原一个经验丰富的一线开发者在面试现场会怎么想、怎么说。

1. 面试官真正考察的，是你对“不可控因素”的态度

提示工程面试题普遍有个特征：题目本身不难，难的是追问。你给出一个方案，面试官不会说“很好”，而是会继续问“如果模型不按格式输出怎么办”“如果这个任务本身有歧义怎么办”“你怎么证明你的方案比另一个方案好”。这些问题没有一个固定答案，但有一个共同的考察核心——你有没有和概率系统协作过的工程直觉。

1.1 一场提示工程面试的典型题目长什么样

我常用一个接近真实的场景做模拟：给你一段客服对话，要求设计一个提示词，让模型输出结构化工单，包含问题类型、紧急程度、摘要三个字段。候选人通常能给出一个像模像样的提示词，但关键在后面的连环追问。

第一问：问题类型里有“功能”和“投诉”，如果用户说“你们的支付页面一直转圈”，模型应该归到哪一类？这是边界划分问题。第二问：如果模型多输出一个你 Schema 里不存在的“用户情绪”字段，你怎么办？第三问：如果用户消息里包含讽刺，比如“太棒了，又白等了半小时”，紧急程度是高还是低？第四问：你打算拿多少条样本验证这个提示词的效果？

这些问题背后没有单纯考文本表达能力，而是在考你有没有完整地想清楚一件事：模型是一个概率系统，你的提示词只能提高它落在正确区间的概率，不能保证它百分之百精准。所以工程上必须有校验、兜底、重试和评测。

1.2 三个最容易暴露水平的错误答法

我见过三类非常典型的错误答法。

第一类是堆模板。开口就是“你是一个资深客服专家，请站在用户角度，结合上下文，输出 JSON 格式的结果”，一口气把角色、背景、步骤、输出格式全部铺满，但问一句“为什么需要资深客服专家”就答不上来。模板不是错，错在不知道每个模块在干什么。

第二类是堆概念。一句话里同时出现“思维链”“少样本”“自洽性”“思维树”“Agent”，听起来全都会，但落到具体任务上说不清到底该用哪一个。面试官就会觉得你只是在背论文，不是在做工程。

第三类是只给方案不给指标。比如“先让模型生成，再写个正则校验”，听起来没问题，但校验失败之后呢？重试几次？失败样本占总量的多少？完全没有度量。真实项目里，没有数据支撑的方案约等于没做。

1.3 可用十分钟说清的回答框架：约束、方案、指标、兜底

我建议所有人在面试时都按这个顺序组织答案，而不是想到哪说到哪。

先说约束。任务目标是什么，输入边界是什么，输出格式是什么，可用资源是什么。比如那个客服工单场景，约束就是：输入一段对话，输出一个 JSON，字段固定三个，紧急程度必须是 low/medium/high 三选一。

再说方案。你准备用哪一个或哪两个范式组合，为什么。如果任务相对常规，就用零样本加结构化输出；如果分类有歧义，就用少样本补上几个边界案例；如果涉及多步推理，再考虑思维链或自洽性。方案不是越复杂越好，而是越匹配越好。

然后说指标。你打算怎么评价，比如分类准确率、字段完整率、人工复核样本量、失败重试次数。没有指标聊方案，面试官就会觉得你没有真正上线过。

最后说兜底。模型输出不合规时怎么办，超时怎么办，连续失败怎么办，有没有默认值，有没有人工介入通道。这一块最容易被忽略，但也最能让面试官看出你有没有实战经验。

这个框架本身不是提示词技巧，但它是所有提示词技巧的容器。后面讲的每个范式，都是往这个框架里填的具体手段。

2. 范式一：零样本与少样本，看似基础却最容易翻车

零样本和少样本是所有提示词的底座。即使是再复杂的 ReAct 或思维树，最终也要落到“模型在没有示例或带少量示例的情况下，按指令完成任务”这个基本能力上。但面试里这个看似基础的话题，恰恰是最容易暴露认知深浅的地方。

2.1 零样本不是“一句话加个请”，而是任务描述的结构化

很多人以为零样本就是对着模型说“帮我把这段对话整理一下”，其实这不算一个合格的提示词，因为它没有把任务的边界描述清楚。一个合格的零样本提示词至少要有四个组成部分：任务目标、处理对象、输出格式、边界条件。

拿客服工单场景举例，我会写成这样：

你是一个客服工单整理助手。 请从下面的用户对话中提取字段并输出 JSON： - issue_type：枚举值，只能是 account / function / complaint / other - urgency：枚举值，只能是 low / medium / high - summary：一句话，不超过20个字 要求： - 只输出 JSON，不要输出其他解释 - 如果信息不足以判断 urgency，默认输出 low - 对话中出现退款、报错、等待时间长时，优先标记为 high 对话： {dialog}

这个提示词里每一项都有目的。枚举值是为了压缩模型的输出空间；约定默认值是给不确定情况一个降级路径；“只输出 JSON”是避免模型在格式外加入废话；最后的优先规则是把业务经验直接写进决策逻辑。

面试官问零样本，其实想听的往往不是“什么叫零样本”，而是你能不能把一个开放问题变成一个可执行的封闭任务。你越是能把模糊输入映射到清晰约束，越加分。

2.2 少样本的示例选择、数量与排序

少样本和零样本的区别，就是多给了几个输入输出示例。但给哪些示例、给几个、按什么顺序放，每个细节都有讲究。

先说示例选择。示例要覆盖两类情况：典型情况和边界情况。比如客服工单里的“投诉”和“咨询”是典型情况，但“用户明明在投诉，语气却很平静”就是边界情况。如果示例只覆盖典型情况，模型学到的是一套稳妥但迟钝的映射；一旦加入边界情况，模型才真正开始理解分类规则。

再说示例数量。我的经验是每次只给 3 到 5 个，而不是越多越好。示例太多有两个麻烦：一是挤占输入长度，增加成本和延迟；二是如果示例之间存在不一致，模型会学到噪声。示例太少也不行，一个示例和一个示例之间缺少对比，模型很难理解边界。

最后说排序。这个容易被忽略，但真实影响输出。模型对上下文末尾的内容更敏感，所以如果你想让模型特别关注某个规则，就把体现这条规则的示例放在靠近尾部的位置。反过来，如果前面几个示例全是“投诉”，模型会在后续输出里更倾向于判定投诉，哪怕用户实际是在咨询。

面试里被问到少样本的底层原理，你可以说：少样本学习本质上是改变模型输出的条件分布，示例不是在“教”模型规则，而是在“激活”模型已有的能力，同时提供格式和风格上的先验。这句话一说出来，基本就能和背模板的候选人拉开差距。

2.3 面试官从这个话题想听你讲什么

面试官问零样本和少样本，通常是想知道三件事：第一，你是否清楚任务描述本身的结构；第二，你是否理解示例对模型输出的影响机制；第三，当没有标注数据时，你有没有循序渐进地构建提示词的思路。

一个比较好的回答思路是：先用零样本加结构化输出跑一版，收集 20 条错误样本，看错误集中出现在哪些类别，再挑出 3 到 5 条典型错误样本放进少样本示例里，重新评测，直到错误率不再明显下降。这个过程既体现工程能力，又体现数据分析能力。

另外有一个容易被追问的点：如果少样本示例本身包含错误标签怎么办？这时候要回答“剔除或修正错误示例”之外，最好补充一句：少样本示例需要做质量控制，因为它对模型的影响是不成比例的，一条错误示例可能抵消三条正确示例的效果。这句话很能体现你对概率模型的真实体感。

3. 范式二：思维链，把“一步一步想”讲出原理和边界

思维链大概是提示工程里最出圈的概念。很多人面试时都会说“我会让模型一步一步思考”，但如果追问“为什么有效”“什么时候无效”“代价是什么”，很多人就卡住了。这个范式的进阶点在于讲清楚边界，而不仅仅是背出那句魔法咒语。

3.1 一句话让它生效，但面试分层的核心是边界

零样本思维链的做法很简单，就是在提示词末尾加一句“请一步步思考，最后给出答案”。这句提示确实对数学、逻辑、多步推理类任务有明显提升。

它有效的原理是：大模型在生成时，如果只要求直接输出答案，模型会跳过中间的推理分布，直接去猜一个答案；如果明确要求先输出推理过程，模型等于把“猜答案”变成了“生成一段合理的推理路径”，并且推理路径本身约束了最终答案的落点。

但面试只会停在这一层。接着往往会有这么一个问题：所有任务都适合思维链吗？这时候要从三个维度答。一是任务类型，只有需要多步推理的任务适合；单步常识、简单分类、纯事实检索，思维链帮助不大。二是输出性质，如果任务是生成一段文案，你让它“先思考再写”，它大概率会把思考过程也写进去，反而破坏结果。三是成本，思维链会显著增加输出 token，你还要考虑延迟和服务成本。

我在模拟面试里会这样问候选人：同样是“提交订单后页面报错”这句话，让你判断问题类型，你会用思维链吗？正确答案是“不一定”。如果这句话本身足够明确，直接分类更快；如果上下文里还包含订单状态、支付方式、报错码等多段信息，那么让模型先把关键信息抽取出来再归类，可能更稳。

3.2 什么时候不该用思维链，越早说出来越显成熟

有经验的候选人会主动讲“不使用思维链的场景”，这比一味夸思维链有用更能打动面试官。

第一类场景是事实检索。如果模型本身不具备某条知识，你让它“仔细想想”，只会让它编得更流畅，而不是更准确。这种情况下更应该做的是引导模型承认“不确定”，或者给它检索工具。第二类场景是低延迟实时对话。语音助手、客服机器人这类场景，每多生成 500 个 token，用户体感就会差很多，这时候你需要的不是更多推理，而是更短的路径。第三类是输出纯度要求很高的场景。你让模型写一句营销语，它先来一段分析，那结果就是不可用的。

第四类场景尤其值得讲：涉及安全边界的场景。如果模型被要求对敏感内容进行判断，一套完整的推理链反而可能生成一个非常详尽的“仿冒样本”，这个副作用比单纯拒绝更严重。面试官听到你能主动说出这种边界，通常都会比较认可。

3.3 如何回答“那成本怎么办”

面试官一旦问成本，很多人只会说“我会减少思维链的使用”，这个答案太薄。更好的是给出一种可落地的方案：路由。

我会这样答：先准备一个轻量分类器，或者用模型自身能力做一层预判。如果问题本身简单，比如单步分类或纯格式提取，就走零样本快速路径；如果问题被判定为需要多步推理，再将 prompt 切到思维链模式。这相当于在应用层加了一道路由，而不是所有请求都背着思维链的 token 开销跑。

除此之外还可以补充两个优化手段。一是把思维链示例压缩成精简模板，比如“已知条件、目标、关键步骤、最终答案”，每一步都控制在几个词以内。二是显式限制输出，在 prompt 里写“请只输出最后答案”或“请控制推理过程在 100 字以内”。这些细节都很小，但面试官听到的是什么呢？是你想过线上真实成本，而不只是看过一个概念。

4. 范式三：自洽性与思维树，让答案从“碰运气”到“有统计保障”

自洽性和思维树都属于“推理增强类”范式，它们的目的不是优化单次生成，而是通过多次生成和路径搜索来减少随机性。面试里这两个概念出现的频率不低，但很多人只会说名字，说不出操作细节。这一层恰恰是最能体现工程能力的地方。

4.1 自洽性：多次采样再投票，参数怎么配

自洽性的核心逻辑很简单：同一个问题，让模型生成 N 条推理链，最后把答案聚合成多数投票。单条思维链可能走偏，但多条路径如果大部分落在同一个答案上，这个答案的置信度就更高。它本质上是把随机采样变成一种统计估计。

面试官会问的很具体：temperature 设多少？采样多少次？我一般会给出自己的默认起点：temperature=0.3，采样 5 次，然后在验证集上做对照，再扫 0.1、0.3、0.5、0.7 四个温度。之所以不直接把温度调到 0，是因为自洽性需要的是多样性，temperature=0 的时候每次输出完全一样，投票就没有意义了。但温度太高也不行，0.7 以上时推理链可能漂移得太厉害，多数投票的收益反而下降。

采样次数也一样，5 到 10 次是一个性价比不错的区间。少于 3 次，投票几乎没有统计意义；超过 15 次，成本上升明显，准确率收益却进入平台期。这个结论不是所有任务都适用，但足够作为你回答的起点。

然后你要主动补一句：自洽性不是免费的。每增加 5 次采样，推理成本就变成原来的 5 倍，所以在真正上线前，我会先看单次思维链的错误模式。如果错误高度集中在同一类边界问题上，说明问题不是随机性，而是任务描述有歧义，这时候应该去改提示词或加示例，而不是通过投票硬扛。

4.2 思维树：面试不会让你实现，但要讲清楚搜索

思维树是思维链的进一步扩展。思维链只有一条推理路径，第一步错了后面全跟着错；思维树则把问题拆成多个中间状态，每个状态生成多个候选，再评估候选，保留有希望的分支，剪掉差的，必要时回溯。

面试官一般不会让你真的写出完整的思维树代码，但会通过场景题来考察你是否理解这套机制。比如一道算 24 点的题，你会怎么设计 prompt？你可以说：第一步，让模型把四个数字的所有两两组合列出来；第二步，对每个组合生成可能的运算结果，形成中间状态；第三步，用评分规则判断哪些中间状态更接近 24；第四步，只在保留的状态上继续扩展。这个流程不是单纯一句话“用思维树”，而是把节点生成、评估、剪枝、回溯都讲出来了。

我建议回答时多强调评估函数的设计。思维树能不能跑起来，很多时候不取决于生成，而取决于你怎么判断一个中间状态值得继续探索。比如在代码调试场景，评估函数就是“编译是否通过”，这个标准非常硬；在创意写作场景，评估就很难定义，需要人工规则或另一个模型打分。你可以说：如果评估函数不清晰，我不会强行用思维树，而是退回自洽性或者思维链。

4.3 一个考题实例：从“错误解题”到“多路径校验”

我把一道常见面试追问组合成一个完整例子。题目是：一个数学应用题，单一思维链得到的结果是错的，怎么改进？

初级答案：用自洽性，采样 5 次投票。进阶答案：我会先分析错误样本集中在哪个环节，比如是第一步列式错还是最后计算错。如果错误集中在列式，就加少样本示例，把列式思路演示清楚；如果错误集中在计算，就引入外部计算器工具，不让模型做算术，只让它列式。最后再结合自洽性做校验：如果是多步题，要求模型生成两条不同路径的解法，两条路径答案一致才输出，不一致则走失败处理。

这个例子的价值在于，它不是单一范式，而是把少样本、自洽性、工具调用组合成一个完整方案。面试官要的就是这种组合判断能力。你说完这条，基本就能跳出“只会背概念”的评价。

5. 范式四：结构化输出与角色设定，把不可控输出纳入 Schema

做提示工程落地久了会发现，绝大多数线上问题不是模型“答错”，而是模型答了一个“格式不能用”的结果。所以结构化输出不是锦上添花，而是命门。这个章节在面试里出现频率极高，因为任何真实系统都需要对接下游。

5.1 结构化输出的三层解法：schema、示例、校验

要保证模型输出是合法的 JSON，不能只靠一句“请你输出 JSON”。我的固定做法是三层配合。

第一层，在系统提示里写清楚 Schema。字段名、类型、默认值、是否必填、枚举范围全部列出来。字段名用英文，枚举值用英文，说明用中文，这能让模型更容易对齐常见语料，也方便下游直接消费。第二层，给一个完整示例。你只描述格式，模型还要猜；你给一个输入输出对，模型立刻知道你想要什么风格。第三层，后处理校验。即使有了 Schema 和示例，模型偶尔仍然会多字段、漏字段，或者把 JSON 包在 Markdown 代码块里，所以必须有代码层面的兜底。

校验失败之后怎么办？不要只做一次失败重试，而是把失败信息拼回提示词重新请求一次。我会这样写：

你上次输出的 JSON 缺少 urgency 字段，并且被 Markdown 代码块包裹。 现在请重新输出： - 只输出原始 JSON，不加代码块标记 - 必须包含 issue_type、urgency、summary 三个字段 - 不要输出解释 上次输出： {model_output}

这种“错误回传再修正”的做法，在面试里是非常加分的细节。它说明你不是把提示词当成一段静态文本，而是把它当成一个能和模型动态交互的协议。

5.2 “角色设定到底有没有用”该怎么回答

面试官如果问“角色设定有用吗”，千万不要只答“有用”或“没用”。比较好的回答是分两种情况。

角色设定对风格、语气、详略程度的影响是真实存在的。比如同样是写一段产品介绍，“你是一名产品经理”会让模型倾向于结构化、抠细节；改成“你是一名面向普通用户的文案写手”，表述会更口语、更有感染力。所以如果你要做风格控制，角色设定可以作为一个轻量手段。

但如果你指望“你是一名资深律师”能让模型的法律知识更准确，那大概率会失望。模型的参数是固定的，角色设定改变的是输出分布，而不是给模型注入新知识。它可以把回答组织得更像律师，但无法把不知道的法条变成知道的。面试官想听到的正是这种“不迷信角色设定”的清醒判断。

另外可以补充一句：角色设定和少样本一样，本质上是在引导条件分布。所以你不需要把它当成什么神秘技巧，只需要把它当作和“请用正式语气”并列的一种表达方式。面试官一听就知道你是从原理层理解，而不是只会套模板。

5.3 面试现场常见的延伸追问与应对

结构化输出方向有几个追问特别常见，我这里直接列一下应对思路。

如果问“输出格式和语义正确冲突了怎么办”，你可以回答拆成两步：第一步先让模型按语义自由生成，第二步把上一步的结果当作输入，让模型重新整理成 JSON。分步处理比一次到位要稳得多。

如果问“枚举值里要不要加‘其他’”，结论是要加，但要在提示词里写清楚“只有当前面对无法归入任何已知枚举类型时，才选择 other”，否则模型会把所有模糊情况全部丢进垃圾筐。同时可以补充：加了 other 之后要定期对 other 样本做聚类，看是不是有新的高频类别需要拆出来。

如果问“模型为什么偶尔把 JSON 包在 Markdown 代码块里”，原因是训练数据里常见这种格式，模型学到的输出分布就是如此。解决方案是在提示词里显式写“不要使用代码块”，同时在后处理时做一次 strip 和解析失败重试。这种细节问题没有标准答案，但能答到“分布”和“后处理”这两个层面，面试官基本就会满意。

6. 范式五：工具调用与反思循环，提示词开始向 Agent 演化

前四个范式解决的都是“让模型在单次生成里输出更好”的问题；第五个范式开始把模型放到一个循环里，让它调用工具、观察结果、反思修正，直到完成任务。这也是面试里最接近真实项目的一类题目，因为它直接考察系统设计能力。

6.1 工具调用的考察重点：异常与状态管理

工具调用类题目的典型问法是：设计一个能调用数据库、搜索或者计算器的小助手，你的提示词怎么组织。很多人第一反应是“让模型知道有哪些工具就行”，但真正会被反复追问的是异常处理和状态管理。

一段基本的 ReAct 风格提示词会长这样：

你是一个能调用工具的小助手。 可用工具： - search(query)：搜索公开资料并返回片段 - calculator(expr)：计算数学表达式 严格按以下格式循环，直到可以输出最终答案： 思考（Thought）：你打算做什么 行动（Action）：工具名称(参数) 观察（Observation）：工具返回的结果 要求： - 如果没有合适工具，或者工具返回空结果，不要编造，直接说“当前信息不足以完成回答，请补充关键词” - 最终答案请以“Answer:”开头

这里面“工具返回空结果怎么办”就是关键考点。模型是一个文本生成器，如果没有工具结果，它很容易编造一个看起来合理的回复。要防止幻觉，就必须把“空结果”当成一个合法状态，用提示词和代码同时兜底。代码层可以判断工具返回值是否为空，为空则直接返回给用户，而不是让模型自由发挥。

另一个细节是状态管理。Agent 循环不只是一次“思考-行动-观察”，它可能持续好几轮。每一轮产生的中间结果要不要保留？保留多少轮？建议是在提示词里明确“只保留最近 3 轮观察结果”，因为超出窗口的旧信息不仅占 token，还可能干扰模型后续判断。这个细节在面试里说出来，会显得你真的做过 Agent 类项目。

6.2 反思循环的正确设计：要有触发条件和终止条件

工具调用之外，很多面试题会涉及“反思”这个动作。比如考官会问：如果模型写出代码跑测试失败了，你会怎么让它修正？很多人会说“让它反思一下再重试”，但这句暗示太弱了，没有标准，没有终止条件。

我一般这样设计反思循环：先设定触发条件，再设定终止条件。触发条件必须来自外部信号，而不是模型自己的感觉。比如代码场景，触发条件是“测试用例执行失败”；客服场景，触发条件是“用户明确表示不满”。没有这个信号，反思就不会被激活。终止条件也很重要，比如最多反思 3 轮；或者连续两轮输出内容一致就停止；或者外部校验通过即停止。没有终止条件的反思循环，最后的结局通常就是无限自我怀疑，浪费时间还烧钱。

还要提醒一点：反思不是让模型把原来的话换一种说法再说一遍。真正有效的反思需要引入新信息。比如用编译错误信息、测试结果、用户在对话里新提到的关键词作为新输入，再让模型修正。如果模型手里没有新信息，它只能对着自己刚才的胡说八道继续胡说八道。面试时说出“反思必须伴随外部新信号”这句话，质量非常高。

6.3 讲项目经历时如何把几个范式组合成故事

模拟面试到了后半段，往往会有开放式问题：给我讲一个你用提示工程解决实际问题的项目。很多人的描述是“我用了思维链加 ReAct 加自洽性，最终效果很好”，但这就是没有落到实处的技术名词堆叠。

我的建议是讲项目时用这个顺序：问题、约束、选型理由、评测、兜底。比如你做一个知识库问答系统，你可以说：“最初我用零样本提示让模型直接回答，发现一批问题答案不完整。分析之后发现是模型缺少推理依据，所以我改成检索加引用的工具调用模式，让模型先检索再回答。为了验证效果，我抽了 50 条提问，人工判断回答是否相关且是否有引用支撑，准确率从 60% 提升到 85%。针对检索结果为空的情况，我加了兜底回复：明确告知用户知识库中没有相关内容，而不是让模型自由发挥。”

这段描述里没有任何一个多余的概念，但你其实已经用到了零样本、工具调用、反思循环和后处理。面试官想听的就是这种“为了解决问题而选范式，而不是为了用范式而堆积概念”的表达方式。

7. 临场应变与考前自检

最后这部分，我把模拟面试里反复出现的高频追问和检查事项整理出来，供你在面试前集中过一遍。

7.1 我总结的高频追问与回答要点

这张表不是为了让你背答案，而是帮你快速定位哪个环节薄弱。每个方向都值得展开讲两三句话，真正面试时不用全说，挑最相关的展开就可以。

7.2 一页纸的快速自检清单

面试前最后半小时，可以按这份清单过一遍你自己准备的项目方案和知识点。

• 任务边界是否清楚？输入是什么，输出是什么，枚举值是否写全。
• 是否真的需要示例？示例覆盖典型和边界了吗？顺序是否合理。
• 如果用了思维链，有没有说明为什么这个任务适合，以及成本怎么控制。
• 是否想到多次采样？有没有明确评测方法和温度参数。
• 输出格式是否有三层保障：Schema、示例、后处理校验。
• 引入工具后，空结果、超时、连续失败是否都有对应兜底。
• 反思循环有没有触发条件和终止条件，是不是有外部信号介入。
• 是否准备了一个完整项目故事，能讲清问题、约束、选型、评测和兜底。
• 是否准备了一组数字，哪怕是一个小样本集上的准确率变化，也能有效增强说服力。

7.3 一点个人经验

陪人做模拟面试时，我印象最深的一幕是：一个候选人把五个范式背得滚瓜烂熟，但被问到“你怎么知道你的提示词比原来好”时沉默了很久，最后憋出一句“感觉更顺了”。另一位候选人只用了零样本和结构化输出，却清清楚楚地说“之前提取的字段完整率是 70%，重写之后是 92%，我在 30 条测试样本上验过”。如果你是面试官，你会选谁？

我自己的体会是，提示工程面试到最后，考的已经不是“会不会写提示词”，而是“会不会用工程方法逼近一个可靠的结果”。范式是支点，但你手里真正要握住的是任务边界、评测数据、成本意识和失败兜底。准备面试的时候，与其花一个晚上背十种花式模板，不如拿一条真实任务，把这五个范式挨个试一遍，记下每版的效果差异和失败案例。真的到了面试现场，你能讲出来的每一个“为什么”和“我试过”，都比任何模板都值钱。

最后分享一个小技巧：哪怕面试题目没有直接问，你也可以在陈述方案时主动加一句“我打算用一个 30 条样本的小评测集来验证这个设计”。这句话不需要额外准备，但它会把你的回答从“纸上谈兵”直接拉到“工程落地的语气”，很多人就是在这一步拿到加分的。