企业官网建设流程全解析

我做了几年大模型应用开发，也坐在面试官那一侧聊过很多做 Prompt Engineering 的候选人。这个岗位听起来门槛不高，但真要考起来，许多人第一轮就挂，因为面试问题的重点根本不在“你会不会写提示词”，而在你知不知道提示词背后的范式、边界和取舍。今天把这套面试高频考察点拆开，重点讲五个必须掌握的范式：零样本/少样本、思维链、角色锚定、ReAct、检索增强。这些不是理论名词，是直接在考场上能救命的工具。

如果你正准备投 NLP 算法岗、LLM 应用岗，或者已经在做 AI 产品但被领导问到“提示词怎么设计”，那这篇能帮你把零散经验串成体系。后文会附上我面试时常用的追问和踩坑记录，可直接当题库练习。

1. Prompt Engineering 面试到底在考什么？

1.1 别把面试当 API 问答

我第一次面试别人时，候选人背了二十多个提示词模板，问他“为什么不生效”就答不上来。从那以后我就明白，面试官考察的是一个比“背模板”高一层的东西：你有没有对模型行为建立心智模型。Prompt Engineering 不是写一段话那么简单，它本质上是给模型描述任务、划定边界、分配执行步骤。一个能稳定工作的提示词，背后一定是作者清楚模型在哪一步容易出错，才提前用话术做了兜底。

所以面试题通常不是“写一个天气查询的提示词”，而是“这个提示词在线上失败了，你怎么排查”。题目里会给你日志、输出、用户反馈，你得像看病例一样去找病灶：是任务定义不清晰，是示例太少，还是输出格式没有约束。能定位到范式层面，才算入了门。我见过太多候选人只会照着模板改字段，一遇到“输出里多了解释文字”这种问题就开始乱加限制词，结果把提示词越改越长，问题却还在，这就是缺乏体系化诊断能力的典型表现。

1.2 五个范式为何成为考题常客

范式，简单说就是一组被验证过的提示词设计套路。面试里考五个范式，是因为它们覆盖了模型能力的主要短板：不会举一反三、不会算多步、不会守角色、不会调工具、不知道事实。每个范式都对应一类经典 bug。比如零样本少样本解决的是“指令理解不充分”，思维链解决的是“复杂推理跳步”，角色锚定解决的是“人设不一致”，ReAct 解决的是“需要外部信息却只靠脑补”，检索增强解决的是“内部知识过时和幻觉”。

如果你是面试者，可以把这五个范式当成一套诊断工具：看到输出太飘忽，想到零样本少样本；看到逻辑跳步，想到思维链；看到回复人设崩塌，想到角色锚定；看到需要调用外部动作，想到 ReAct；看到知识过时或幻觉，想到检索增强。面试官只要出一道症状题，你把这五个范式摆出来做筛选，答案自然就完整了。这套“先症状后范式”的思路，也是我自己在线上排查 A/B 实验时最常用的方法。

2. 范式一：零样本与少样本提示

2.1 零样本不是“什么都不给”

零样本提示（zero-shot）指的是不给例子，只靠指令让模型完成任务。很多人以为零样本就是“把一句话丢给模型”，其实设计要点在于把任务定义得足够封闭。比如“帮我写摘要”效果差，因为摘要的口吻、长度、详略全都没说；改成“用三句话概括下面文章，第一句讲现象，第二句讲原因，第三句讲影响，不要出现‘本文’两个字”，就是一个合格的零样本指令。核心不是不加内容，而是让模型没有自由发挥的空间。

面试时常见考法：要求对一段客服对话做情绪分类，只给标签列表“请把用户情绪分为满意、一般、不满三类，只输出一个词”。很多人漏写“只输出一个词”，模型就会回一段解释，后续程序解析就崩了。更隐蔽的坑是标签本身有歧义，比如“一般”到底算中性还是负向，零样本时模型可能自由发挥成“中立”，导致统计分析出错。所以零样本的关键词是“封闭”：封闭字段、封闭格式、封闭长度、封闭语气。封闭得越死，输出飘的概率越低。

2.2 少样本是在“给模型抄作业”

少样本提示（few-shot）是在指令里插入一组高质量示例。面试官爱问“示例放几个最合适”，答案不是越多越好。示例多到十组以上，提示词会拉长、成本上涨，模型还会被反例带偏，出现“过度模仿”。关键是示例的“代表性”而不是“数量”。每个示例应该覆盖一种容易错的边界情况，而不是全部放简单的例句。

我在做商品评价分类时，只放了三组示例：一组很明显的正面，一组略带反讽的正面，一组中性但像差评的文本。模型看到带反讽的那个例子，就会明白“不能只看关键词”，准确率明显提升。这就是少样本范式最常见的面试套路：让你挑三个示例，同时讲明白为什么选这三个。谁能讲出“边界覆盖”这四个字，评委通常会给高分。因为这说明你不是随手抄了几个样例，而是基于对落地数据的理解在做刻意设计。

2.3 面试回答范式的标准话术

如果面试题让你直接设计提示词，我建议按这个顺序答：先说明模型需要完成什么任务；再设计输出格式，最好给出 JSON 或表格模板；接着决定是否需要示例，如果需要，告诉面试官示例选在哪几种边界情况；最后说明失败兜底——如果模型输出不符合格式，怎么重试或降级。把这个步骤背熟，你就不会只在“写一句话”，而是在“设计一个系统”。

这里有个容易翻车的细节：少样本示例必须和主指令字段一致。有人示例里用的是“商品：洗发水/评价：好用”，但预测时输入字段写的是“产品”，模型就会犯迷糊。面试官通常会故意把示例与正式输入格式不同，考察你有没有发现。及时发现并修正，比背一百个模板有用得多。另外，示例的标签也要保持一致性，不要同一类情绪写三种不同叫法，否则模型会认为这些叫法有细微差别，最终分桶混乱。

提示：面试答题时，说“我用少样本提示来解决”是不够的，一定要补一句“因为这类任务有边界样本，模型仅靠指令容易误判，显式示例能把这些边界固定住”。能讲出动机，才算真正理解范式。

3. 范式二：思维链 CoT

3.1 面试官问“先想再说”的隐藏逻辑

思维链（Chain-of-Thought，CoT）是五个范式里最容易被误解的一个。它不只是“让模型写步骤”，而是利用模型自回归的特点，把原本需要一步输出的复杂推理拆成多个中间结果，让每一步都在更小的搜索空间里生成，降低整体跳错的概率。面试官问“为什么加一句‘请逐步思考’有效”，背后想听的就是这个机理。

但 CoT 也有明显的坑：不是所有任务都适合。简单分类、抽取字段这类任务加了 CoT 反而容易过度推理，制造幻觉。面试题常给一个场景，让你判断要不要用 CoT。合格的回答应区分：多步计算、逻辑推导、代码调试这类“推理性任务”适合 CoT；高精度抽取、事实性问答这类“检索性任务”更适合直接出答案或配合检索增强。能答出“分场景”三个字，而不是把 CoT 奉为万能药，面试官才会觉得你靠谱。

3.2 自洽性：让模型多跑几遍再投票

面试进阶题会问：如果 CoT 偶尔还是出错怎么办？答案是自洽性（self-consistency）。做法是对同一条提示词做多次采样，得到多条推理路径，然后对最终答案做多数投票。原理类似团队评审：单个人可能想岔，多个人分开想再投票，不容易一起掉进同一个坑，因为推理路径不同，错误模式也不同。

去年我做过一个数学应用题评测，单次 CoT 的正确率只有 68%，把采样次数从 1 提到 5 并做投票后，正确率涨到 81%。面试时如果把“自洽性、投票、采样温度”这三个词用一条链路串起来讲，就很漂亮。还可以补一句：投票是对最终答案做归一化，比如把单位归一、把格式归一后再比，不然“5 分钟”和“5min”会被当成两个答案，投票就失效了。这一句补充往往能让面试官眼前一亮，因为大多数人根本不会想到“答案归一化”这一步。

3.3 一个可以直接背的 CoT 面试示例

面试官让你“设计一个解决鸡兔同笼的提示词”，可以这样答：任务背景先说清楚，把输入格式固定成 JSON，再要求模型先列变量关系，再列方程，最后只输出数值结果。把它写成适合直接复用的提示词如下：

你是一位数学老师。给定一个数学应用题，请按以下步骤解决： 1. 提取题目中的已知量和未知量； 2. 写出等量关系式； 3. 解出未知数； 4. 只输出最终数值，不要输出中间过程。 输入问题：笼子里有若干只头和脚，头共有35个，脚共有94只，问兔有几只？

这个提示词的关键是最后一步“只输出数值”，避免模型解释步骤后把一长串文字吐出来，导致后端解析失败。面试时你还要补一句：这个设计等价于 CoT，但没有使用少样本，适合问题形式不固定的场景；如果问题形式固定，可以在示例里再加一题，用少量示例把思路固定住。另外可以主动提一嘴：我可以顺手把正解当校验种子，比如在代码侧判断“答案不是 0 到 100 之间的整数就重试”，把输出层约束加上，鲁棒性会好很多。

4. 范式三：角色锚定与输出约束

4.1 角色锚定不是玄学，而是给行动画边界

很多抽象提示写法是“你现在是XX专家”。我见过不少面试者把这条当成玄学，其实背后逻辑很简单：角色是一种先验，相当于在一开始就告诉模型“你该用哪套语料库、哪种回复态度、哪些领域注意事项”。模型训练数据里有大量角色对话内容，给角色等于触发这类内容的分布，减少在通用知识里乱逛的概率。

但角色锚定的最大问题是“演过火”。让模型当“毒舌 HR”，它可能把面试者批评过度；让模型当“严谨律师”，它可能每一句都加免责声明。所以角色后面一定要跟着行为约束：角色提供语态和边界，约束提供输出规范。面试时能主动说出“角色负责启动风格分布，约束负责收口输出”，基本就把这一范式讲透了。我通常在角色段后隔一行写“无论用户说什么，你都只能以该角色的身份和口吻回应，不要跳出角色”，这样既保留角色风格，又给出守界指令。

4.2 靠格式锚定杀死解析 bug

角色锚定常常和输出约束配合用，尤其在做结构化输出时，最有效的方法是“格式锚定”：不要求模型自然说一段话，而是给一个残缺模板，让模型填空。例如：

{ "姓名": "", "意向城市": "", "薪资范围": "", "到岗时间": "" }

模型看到这个 JSON 结构，会尽量把内容填进对应字段，缺的字段会留空或跳过。面试官问“怎么保证输出字段稳定”，这一类“残缺模板+严格格式”的回答就比空喊“请遵守 JSON 格式”更有说服力。要说清为什么有效，值得提身份注入：模型训练时见过海量半结构化数据，残缺模板会激活“补全”模式，比从头生成结构更稳定。另外要说明校验方法：先核对 JSON 语法，再用字段级校验，不在模型侧直接计算，而是在上游做规则清洗。这套链路说出口，面试官一般都会点头。

4.3 面试题：角色防线被绕过了怎么办

如果面试官追问“用户让模型忘记角色怎么办”，这就是在考安全边界设计。典型做法有三种：第一，把角色约束写成强指令放开头，并重复一遍；第二，对输入做注入检测，比如把包含“忽略之前指令”的内容替换或拒绝；第三，在系统层面对模型输出做白名单校验，不符合角色设定直接回退。

我个人的经验是，简短的一句话攻击往往能得手，凡是遇到“忽略上一句话”这类内容，最稳的是不走模型，直接返回默认话术。面试时你讲得出“模型层加限制，输出层加校验”这种双保险思维，比单纯背提示词加分很多。还有一个隐藏考点：这类攻击不一定藏在用户输入里，有时检索片段里也会有，所以对 RAG 文档同样要做指令注入过滤。能把过滤范围从“用户输入”扩展到“全部上下文来源”，说明你已经系统性地思考过安全问题。

5. 范式四：ReAct 推理与行动

5.1 ReAct 为什么成了 Agent 面试标配

ReAct 的全称是“推理 + 行动”（Reasoning + Acting），它把思维链和动作决策放到同一个循环里：模型先想我要查什么，再发起工具调用，看到调用结果后继续想下一步。它解决了 CoT 只能“空想”的问题——遇到事实性、实时性信息，模型必须借助外部工具才能得到靠谱答案。

面试题里最高频的设计是：给你一个查询天气的助手，要求支持查实时温度。如果只用 CoT，模型会瞎编一个 26 度；用 ReAct，模型会先解析城市和日期，然后拼一个查询参数，调天气 API，拿到结果再撰写回复。整个流程里，“动作”和“思考”交替出现，这就是范式名中“Re”和“Act”的含义。面试官出这类题，其实是在考察你有没有真正跑过 Agent，懂不懂工具调用的闭环。

5.2 一个可以落地的 ReAct prompt 模板

如果面试官让你给 Agent 写提示词，可以用这种结构：先定义角色；再给出可用的动作集合；接着要求每轮输出“思考”和“动作”两个字段；最后说明怎么处理工具返回结果。为了直观，我把动作集合放在提示词里：

你是一个智能助理，可以调用以下动作： - search_web(query): 搜索互联网信息 - get_weather(city, date): 查询城市天气 - calculate(expression): 计算数学表达式 工作方式： 1. 每轮先写“思考：根据用户问题，我需要查什么”； 2. 再写“动作：动作名(参数)”，只输出一个动作； 3. 工具返回结果后，继续思考下一步； 4. 直到信息充分，输出“回答：最终结果”。 用户问题：下周北京天气怎么样？需不需要带伞？

这里的关键是每轮只输出一个动作，避免模型一次生成好几个动作导致执行混乱。实际开发中，我会用 JSON 严格约束动作字段，再在代码侧解析。面试时主动提“动作集合要白名单化，不让模型自由发明动作”，证明你真的在工程化，而不是只在写嘴上提示词。还要提醒一句：动作名和参数都要做格式校验，比如城市名必须用拼音或标准地名，否则工具端很容易解析失败。

5.3 面试追问：模型陷入死循环怎么办

ReAct 最常见的线上事故是模型反复调用同一个动作不结束。解决方案通常有四种：设定最大轮数，例如 5 次；给动作结果加超时；对重复动作做去重并提醒；最后兜底输出“信息不足”。面试官问“如何防止 Agent 失控”，从这四个点回答基本就完整了。

有个容易被忽略的细节是“动作参数合法性校验”。模型可能把城市名拼成“北京-beijing”，工具解析就会失败。所以提示词里要写清参数格式，比如城市用标准拼音，日期用 YYYY-MM-DD，并在工具层再做一遍校验。能把动作层的防御手段和提示词层的约束结合起来的候选人，在面试里非常稀少。我还见过一个技巧：把“动作”字段限定为枚举，代码里逐个匹配，匹配不上就走默认重问流程。这一招比让模型随机发挥好得多。

6. 范式五：上下文外化与检索增强

6.1 为什么要把知识放模型外面

第五个范式理解起来有点反直觉：既然模型知道很多知识，为什么还要把内容塞进上下文？答案很直接——模型的知识会过时，也会记错，而且它不知道自己不知道。用户问“今天的项目负责人是谁”，模型可能凭借训练数据里某天的信息硬答，出现幻觉。解决方案是“上下文外化”：不指望模型用内部记忆回答，而是把权威资料、最新数据插到提示词里，让模型只做“基于资料回答”这件事。

面试里这叫 RAG（Retrieval-Augmented Generation）。光说“用 RAG”很水，有经验的人会说清楚提示词分层：系统提示定义角色和任务；上下文注入检索片段；用户输入是原始问题。三层职责不同，不能混在一起写。因为如果检索片段和指令搅在一起，模型容易把干扰文本当成规则，输出被污染。面试时把“指令层、资料层、问题层”三层结构讲清楚，胜过背十篇 RAG 综述。

6.2 检索增强提示词的配置技巧

写检索增强提示词时，我习惯在最前面标出“以下内容是参考材料，不一定全部相关”，然后放检索片段，最后再放用户问题。这个顺序很重要：模型对“靠近结尾的用户问题”关注度最高，对“开头参考材料”更倾向于当作参考资料，而不是新指令。面试官如果让你设计一个客服问答提示词，你可以把这个顺序讲得清清楚楚。

检索片段还要做去重和裁剪。很多候选人事先没准备，面试时只说“把资料塞进去”，没有提到“如果资料里有互相矛盾的说法怎么处理”。正确的做法是给检索结果按相似度排序，保留 top-k，再在提示词里加一句“如果参考材料之间存在矛盾，以最近更新的材料为准”。这个细节非常加码。另外，如果检索片段太长，可以先把无关段落裁掉，只保留与问题最相关的几个句子块，token 成本和上下文噪音都会下降。

6.3 面试话术：如何证明你的方案会少幻觉

面试官问“你怎么减少幻觉”，不要只说“加了 RAG”。话术应该包含三层：第一，在上下文层面，把检索片段作为唯一事实源，并明确要求模型不要使用外部记忆；第二，在生成层面，要求模型只根据参考材料作答，材料里没有就回答“材料未提及”；第三，在评估层面，用“引用片段”检验模型，让它输出答案时附带依据出处，方便后端审核。

讲到第三层时，我一般会补一个小 trick：让模型输出“依据：片段序号”，比如“依据[2]”。这样代码能做自动化血缘追踪，哪条片段支撑了答案一目了然。面试官听到这里，通常就知道你是真的曾在生产环境里折腾过这套东西。最后还能再加一句：如果模型引用了材料里没有的内容，说明幻觉又出现了，需要在提示词层加上“只允许引用材料原文”的强约束。

7. 面试突击清单与避坑实录

7.1 一周速成复习路线

如果离面试还有一周，我的建议是别刷题，把这五件事做一遍。第一，每天用一个小时手写五个范式的提示词，各写三个不同场景；第二，把温度参数调高和调低各试一次，记录输出差异，因为在面试中经常被问“温度怎么选”；第三，做一次带格式锚定的结构化输出，体会 JSON 模板的效果；第四，跑一个带 CoT 和自洽性的数学题对比实验，记住准确率提升的数字；第五，开口把每个范式的优缺点用一分钟讲完，对着镜子或录音设备练，面试时找不到合适的词就没资格谈工程化。

这个复习路线的逻辑是：先理解、再手写、再对比实验、最后复述。前面三个帮你在面试时“扛住具体题”，复述帮你在提强调性题时“显得像老手”。我见过很多开发者能跑代码却不会表达，录一遍音你就会发现自己哪些词说得磕磕绊绊，那些地方就是要补的概念盲点。如果时间紧张，至少把“零样本少样本”“CoT”“RAG”三个范式练到能默写，性价比最高。

7.2 面试官最常追问的五个问题

有些问题你只要准备一次，就能覆盖八成面试。我总结出的高频追问如下：

这五个追问几乎覆盖了前文反复强调的全部要点。面试前你可以自己当面试官，挨个拿题去口头作答。能流畅答完这五问，再遇到随机题目，你至少不会冷场。我还会多准备一个数字来佐证“格式锚定的收益”，比如“加了 JSON 模板后解析失败率从 23% 降到 4%”，真实数字比形容词更有说服力。

7.3 候选人最常翻车的三件事

第一件事是把 Prompt Engineering 等同于“聊天话术”，答不出“为什么有效”。面试考的不是感觉，是机制。建议不要只说“效果好”，一定要补充“因为模型是自回归生成，给出中间步骤能减少大面积错误”。第二件事是忽略成本与延迟。一次性把几十个示例塞进上下文，效果可能好，但 token 成本和延迟都高，面试官问到“为什么不用更多示例”，你至少得答出“要在效果与成本之间权衡”。第三件事是遇到输出异常只会重试，不会设计兜底。比如模型漏了字段，代码侧要做完整性检查；缺字段就二次修复或返回默认值。能把这些工程细节讲出来，说明你真的在解决生产问题。

最后我再分享一个实际摸出来的体会：面试官看重的不是你会多少个花哨模板，而是你面对烂输出时的第一反应。如果第一反应是“再加一句魔咒式提示词”，说明你还在让模型替你思考；如果第一反应是“我该在模型外面加校验逻辑吗”，说明你已经在做大模型应用工程。五个范式只是起点，把输出层、逻辑层、校验层串起来，才是面试真正的分水岭。这个思路在你后面做 Agent 和 RAG 项目时，会反复出现在每一个深夜调模型的过程中。