大模型面试高频8题拆解：注意力、RAG、量化与优化

最近问大模型岗位面试的人特别多，很多准备转行做 LLM 应用的同学都在刷同一类帖子。“LLM 面试必问的 8 个问题，答不上来直接淘汰”这种说法，标题看着吓人，但背后确实有真东西。我这两年断断续续当面试官，也帮不少候选人做过模拟面，发现大模型方向的面试已经高度模块化：跑项目、背八股、刷论文的人一聊就知道，没跑过实践的人也一问就穿帮。这篇就把我从面试和被面试两个角度看到的 8 个高频问题完整拆一遍。每个题都会说清楚面试官在考什么、怎么答能拿分、哪些错一犯就凉，还会把容易卡住的细节补上。适合两类读者：一类是准备投 LLM 算法岗、应用开发岗、Agent 工程岗的同学，另一类是已经在做相关项目但心里没底，想查漏补缺的工程师。

1. 面试官真正想从这 8 个问题里看到什么

1.1 为什么 LLM 岗位面试高度同质化

很多候选人觉得问题“套路化”“八股化”，这是事实。但换个角度想，大模型岗位的供给端变化太快了，三个月前的热门项目和今天可能就不是一回事。面试官没法靠问“你最近做了什么项目”来横向比较所有人，因为候选人的背景五花八门：有从推荐系统转的，有从 NLP 问答转的，有刚毕业只跑过开源 demo 的。这种情况下，面试必须用一套稳定的、能测出核心能力的公共考题。

这 8 个问题恰好覆盖了 LLM 从原理到工程落地的完整链路。它不是为了刁难人，而是为了在 30 到 50 分钟里快速确认一件事：这个人对模型的理解是停留在“调 API 能用”的层面，还是已经到了“知道模型为什么这么设计、遇到问题从哪下手”的层面。后一种人，无论做什么方向的大模型工作都能快速上手；前一种人，聊两句就会被细节问穿。

1.2 8 个问题背后对应的 4 种核心能力

我把这 8 个问题背后的考察点归成四类：模型机制理解、数据处理能力、对齐训练认知、部署优化经验。下面这张表是我自己会用的一个对照关系，分享出来你也好自查。

你看，这 8 个问题并不是平行排列的八个知识点，它背后是一条完整的项目流水线：你拿到一个开源模型，要先懂它的结构，知道数据怎么变成 token，怎么微调对齐，怎么在长上下文中控制显存，怎么用 RAG 缓解幻觉，最后还要量化部署成 API 服务，并且用合理的指标评估效果。这套问题答全了，基本就等于一个人能独立把大模型应用从零做到上线。

2. LLM 面试必问的 8 个问题逐题拆解

2.1 第一题：Transformer 的注意力机制到底强在哪

这是所有 LLM 面试的第一道关，也是淘汰率最高的一题。它问的方式通常很直接：“你讲讲 Transformer 里的 Self-Attention 为什么能替代 RNN？” 如果你只回答“因为可以并行”，那只能得 30 分。完整回答要把三个层次都说清楚。

第一层是计算形式。对输入序列中的每个 token，生成三个向量：Query、Key、Value。注意力分数就是 Query 和所有 Key 做点积，除以 sqrt(d_k) 防止 softmax 后的梯度消失，再做 softmax 得到权重，最后加权求和 Value。公式就是 Attention(Q,K,V) = softmax(QK^T / √d_k) V。这里要主动提一下为什么要除 √d_k：当维度增大时点积结果方差也增大，softmax 会进入饱和区，梯度趋近于零，除以根号维度的本质是归一化方差。

第二层是为什么比 RNN 强。RNN 是串行计算，t 时刻的隐状态依赖 t-1 时刻，长距离信息传递要靠梯度一路传回去，所以容易梯度消失。Self-Attention 每个 token 之间是直接两两计算，信息传递路径为 O(1)，无论两个 token 隔多远，都能直接建立依赖。而且所有位置的注意力分数可以矩阵化并行算，训练效率完全不同。

第三层是能体现功底的细节。你可以主动提到三种变体：MHA（多头注意力）、MQA（多查询注意力）和 GQA（分组查询注意力）。大模型推理时 KV Cache 是显存大头，MQA/GQA 通过让多个头共享 Key 和 Value，把 KV Cache 显著降低，LLaMA 2 和很多开源模型都用了 GQA。再能补一句 FlashAttention 就更好了，它的核心不是减少计算量，而是通过分块计算避免把整个注意力矩阵写回显存，解决的是 IO 瓶颈而不是算力瓶颈。

这一题常见的扣分点：把 Key 和 Value 说成是从输入里“直接抽取的两列”，记得说清楚它们都是通过线性层学出来的；还有人会把位置编码和归一化混为一谈，上手就说“用 LayerNorm 解决位置信息”，这是基础概念错误。

2.2 第二题：Tokenizer 怎么把文本变成模型能吃的 ID

Tokenizer 是面试里很容易被轻视的一题，但它实际上很能拉开差距。你要是只说“用 BPE 做词表”，大概率会被追问到怀疑人生。问题是“你详细讲讲 BPE 的合并过程，以及中文和英文的差异”。

BPE 的核心是字节对编码。一开始词表只有所有单字符，然后反复统计相邻字符对的频率，把最高频的一对合并成一个新符号，直到词表达到目标大小。举个例子，“low”“lower”“newest”这三个词，初始是 l、o、w、e、r、n、s、t 这些单字符，第一次可能把 l 和 o 合并成 lo，然后是 lo 和 w 合并成 low，继续合并出 lower。这个过程得到的词表里，常见词是一个整 token，生僻词会被拆成多个子词，所以 BPE 天然能处理未登录词，这是它取代 word-level 模型的核心原因。

这里有一个必须主动说出来的点：中文和英文用 BPE 的表现差异很大。英文按空格分词后做子词合并，基本符合词根词缀规律；中文没有天然空格，如果也按字符直接跑 BPE，会把很多语义完整的词拆得七零八落。实务里中文 LLM 通常会在 BPE 前先做预分词，或者在数据里保留词级别的候选合并，让“中国”“北京”这类词成为独立 token。聊到这个层面，面试官就知道你真处理过中文数据。

加分项是讲清楚 token 数量在实际业务里的影响。很多新人不知道，模型是按 token 数收费或者计显存的，同一个问题用不同 tokenizer 表达，消耗可能差 30% 以上。还有一个工程细节：pad token 和 attention mask 如果处理不对，batch 里不同长度的序列会互相影响，导致效果莫名变差。你在回答里提到“训练时要对 padding 部分做 loss masking，否则模型会学习预测一堆无意义 token”，这一句话就能和不看细节的人拉开距离。

2.3 第三题：预训练、SFT、RLHF 三者的关系

这道题的出现率几乎百分之百，因为它直接检验你有没有真做过模型训练。最常见的错误回答是：“先预训练，再微调，最后用强化学习优化一下”，说完就没了。正确的答法要把“为什么需要三步”讲透。

预训练是让模型在海量语料上做自监督学习，目标是 next token prediction，也就是给定前面所有 token，预测下一个 token 是什么。这一步让模型获得语言能力、世界知识和基本推理能力。但预训练模型只会“接着写”，不会“听指令”，你问它“中国的首都是哪里”，它大概率会接一句“中国的首都是北京，故宫是…”之类的话，而不是直接给你答案。

SFT 就是解决“学会听指令”的问题。用人工编写的高质量指令-回答对，让模型在原有能力上学会对话格式。这里有个关键细节：SFT 的训练 loss 通常只算回答部分，指令部分的 loss 要 mask 掉，否则模型会花参数去记忆指令模板。SFT 做得好不好，主要看数据质量，而不是数据量。网上流传一句话，“SFT 是让模型学会格式，RLHF 是让模型学会偏好”，虽然不完全准确，但能帮你快速理解两者定位。

RLHF 分三步：用人类对多个回答的排序训练一个奖励模型，再用奖励模型给生成结果打分，最后用 PPO 等强化学习算法更新策略模型。它的本质是把“人类觉得什么回答好”这个主观标准，变成可优化的目标。为什么不能省？因为 SFT 的数据是“写得不错的答案”，但模型不知道哪些行为是应该被奖励的，通过 RLHF 才能强化符合人类偏好的输出，抑制有毒、有害或空泛的内容。DPO 是一种更轻量的替代方案，不需要单独训练奖励模型，直接在偏好数据上做对比学习，很多开源模型微调都开始用 DPO。

面试里能额外谈的一点是训练顺序和灾难性遗忘。SFT 和 RLHF 都会带来模型能力的偏移，SFT 数据太单一会导致模型在其他领域能力退化，所以有的团队会在 SFT 阶段混入通用数据防止遗忘。这题答到“灾难性遗忘”和“数据配比”这个深度，基本上就是高分段了。

2.4 第四题：上下文窗口和 KV Cache 的显存账单

长上下文现在是各个大模型厂商的卖点，面试题也跟着热。问题通常是“为什么模型 context length 越大，推理越贵？你算过一笔账吗”。很多候选人对“贵”停留在直觉层面，说不出一个公式。

先说结论：KV Cache 的显存占用和序列长度是线性关系，而且序列越长增长速度越吓人。公式是：KV Cache 大小 = 2（Key 和 Value 两份）× 层数 × 注意力头数 × head_dim × 序列长度 × 每个元素字节数。

我带你算一个具体例子。以 7B 模型为例，如果它有 32 层，32 个注意力头，每个头的维度是 128，用 FP16（2 字节）存储。那么一个 token 的 KV Cache 就是 2 × 32 × 32 × 128 × 2 = 512KB。你看，一个 token 就要 512KB，那么 2048 个 token 的上下文就是 1GB。而 7B 模型本身的权重用 FP16 也就约 14GB，KV Cache 到了 4096 context 就吃掉 2GB。这就是为什么大模型推理越说越长，显存越紧张。

面试官还会顺带问“既然上下文越长越贵，有没有办法扩展”。这里有几条主线：一是位置编码层面，RoPE（旋转位置编码）本身具备一定的外推能力，配合 YaRN、NTK-Aware Scaling 可以在不做训练的情况下让模型处理超过训练长度的文本；二是架构层面，有些模型用滑动窗口注意力，比如 Mistral 的 sliding window，限制每个 token 只看附近 N 个 token，把 KV Cache 从全局降低到窗口级别；三是输入层面，StreamingLLM 这类工作发现，丢掉中间 token、保留初始 token 和最新 token，可以稳定维持长对话。能把这几个方案讲出来，再配合显存公式，这道题就是加分不是送分。

这道题的坑在“上下文长度”和“有效长度”的区分。很多人以为模型支持 128K 上下文，就真的能完美处理 128K 的输入。实际上注意力分数在远端容易稀释，中间信息容易丢失，这就是为什么会有“Lost in the Middle”这个经典现象。你在实际项目中如果把 128K 文档直接塞进去，开头和结尾的信息能答上来，中间部分经常答错，这不是 bug，是注意力分布本身的特性。

2.5 第五题：幻觉怎么治，RAG 的完整链路

幻觉问题几乎出现在每个 LLM 应用面试里。面试官的典型问法是“你做的项目里，模型胡说八道怎么办”。要是你只回答“加 RAG”，那十个面试官里九个会继续追问“RAG 链路你完整走通过吗”。

先说幻觉的成因。大模型训练目标是最大化下一个 token 的概率，它本质是在“续写”，不是在“查证知识”。加上训练数据本身存在时效性，2024 年的模型不知道 2025 年的事；即使知道的知识，也可能在参数化存储时被压缩、丢失或混淆。所以幻觉不是 bug，而是这种生成机制的自然产物。回答里能说出这一层，你就和只会喊“加检索”的人分开了。

然后是 RAG 的完整链路。我把它拆成五步：

第一步，query 改写。直接把用户原问题拿去检索，效果通常一般，特别是口语化问句。要先把问题转成适合检索的表达，比如“广州上周天气怎么样”改成“2025年6月15日至21日广州市天气记录”。

第二步，混合检索。只做向量检索不够，因为 embedding 模型对专有名词、缩写、数字不敏感。工程上常用 BM25 关键词检索和向量检索并行，再合并结果。这个环节我实测对提升召回率帮助极大，尤其是问答里带型号、日期、编号时。

第三步，重排。召回 Top 50，但上下文窗口有限，不能全塞进去。用 reranker 模型对召回的候选段落重新打分，挑出和问题最相关的 Top 3 到 5 段。跳过重排直接取向量相似度最高的几段，经常会把高度相似但答非所问的文本送进 prompt。

第四步，上下文组装。把检索到的段落按相关度排序拼进 prompt，同时附上来源。这里注意 token 长度控制，塞太多无关段落反而会干扰模型。

第五步，生成并强制引用。要求模型只能在提供材料的基础上回答，材料没有就说不知道，并且回答里标上对应来源编号。这一步是在 prompt 层面约束模型不要自由发挥。

Hmm 我在实际项目里踩过一个坑：chunk size 设得太大，一段 2000 字，检索出来四段就是 8000 字，模型生成时被大量“相关但不直接”的上下文干扰，回答反而变差。后来改成 400 到 600 字的小 chunk，召回和生成质量都稳定了。这个经验你可以直接拿去用，面试聊细节的时候也很有说服力。

2.6 第六题：量化方案和 GGUF 端侧部署

大模型量化不只是部署岗会问，算法岗也常被问到。因为现在开源模型的落地路径里，量化几乎是必选项。问题通常是“讲讲 GPTQ、AWQ、GGUF 这几个量化方案的区别，你用过哪个”。你要是区分不开这几个名词，这道题基本就丢了。

先讲原理。量化就是用一个更低 bit 的数去近似高 bit 的浮点数，比如把 FP16 的权重变成 INT8 或者 INT4，核心是给每个参数找一组 scale（缩放因子）和 zero point（零点偏移），让低 bit 整数能还原出接近原值的浮点数。常见做法是 PTQ（训练后量化）和 QAT（量化感知训练）。PTQ 不用重新训练，只需要少量校准数据；QAT 在训练时模拟量化误差，精度更高但成本大。大部分开源模型落地都用 PTQ。

GPTQ 和 AWQ 都是做 weight-only 量化，也就是只量化权重，不量化激活值。GPTQ 是逐层最小化量化前后输出的均方误差，需要校准集；AWQ 的思路是根据激活值分布来保护重要的权重通道，量化精度通常比 GPTQ 更稳。工程部署的时候，如果你用 vLLM 或者 TensorRT-LLM 做 GPU 推理，这俩是比较主流的选择。

GGUF 不一样，它是 llama.cpp 生态的模型格式，针对 CPU 推理做了大量优化。这正好对应一个热词“安卓本地运行 gguf 格式 llm 软件”——现在很多端侧工具确实都用 GGUF 格式，处理器较弱的手机也能靠 CPU 跑起来小尺寸模型。常见后缀像 Q4_K_M、Q8_0，你选模型的时候能看到，它表示不同的量化精度和变体。Q4_K 的 7B 模型大概 4 到 5GB，Q8 大概 8GB，内存有限就选 Q4，追求效果就选 Q8。

这里有个重要的坑：量化位数越低，显存占用越小，但模型效果退化越明显，尤其在数学推理和代码生成上。有人在面试里说自己把模型量化到 2bit，效果还和原来一样，这种话一听就不真实。我实测下来，7B 模型 INT8 基本无损，INT4 会损失少量能力，2bit 基本已经不太能用了。你得有这种对量化极限的清醒认识，才像一个真跑过模型的人。

2.7 第七题：大模型的评估指标怎么选

这道题常以情景题形式出现：“你做了一个客服问答机器人，老板问你怎么证明它变好了，你怎么办”。回答里直接抛“Perplexity”的，通常会被追问到卡住。

先说 Perplexity 是什么。它本质是模型对下一个 token 预测概率的倒数，越低代表模型对语料“越不困惑”。但很多人不知道，Perplexity 衡量的是模型对自身预测的置信度，不代表回答质量。模型完全可以用流畅但错误的话获得低困惑度。所以它适合在训练阶段看，不适合在业务评估阶段当唯一标准。

接着要区分三类评估方式。第一类是传统文本指标，BLEU、ROUGE，适合机器翻译、摘要这种有标准答案的任务，但对开放式问答几乎没用，因为正确表述可能和参考答案完全不一致，字面匹配会误杀。第二类是公开基准，MMLU 考知识广度、GSM8K 考数学推理、HumanEval 考代码生成、C-Eval 是中文评估集。这些适合横向对比模型，说明“我这个微调模型比 base 提升了多少”，但业务落地时不能直接等价。第三类就是 LLM-as-a-Judge，用 GPT-4 或 Qwen 这类强模型给回答打分。这个方法效率高、能处理开放式答案，但有三个注意点：一是模型偏好冗长回答，写得越长分越高，要明确评分维度；二是位置偏见，把候选答案换顺序结果可能变；三是必须抽样本让人工验证，不能盲目相信机器打分。

真正好的回答是我称之为“业务评估五件套”的思路：从要解决的具体问题出发，定义一组任务场景；准备一批高质量黄金测试集；确定核心指标，比如正确率、幻觉率、拒绝率；跑离线对比，base 和 SFT 模型同时在测试集上出结果；再拿一个批次线上真实流量做小流量验证。面试的时候你能从“指标”讲到“评估体系”，这道题就完全没悬念了。

2.8 第八题：推理服务怎么提高吞吐和降低延迟

最后一题偏工程，问法通常是“你部署过 API 服务吗？并发用户一多，模型响应特别慢，怎么优化”。这道题和前面的原理题不同，它需要你有真实的压测经验或者读过开源推理框架的文档，纯靠背概念很容易露馅。

先记两个关键术语。TTFT（Time To First Token）是用户发出请求到收到第一个 token 的时间，这个决定了“感觉快不快”；TPOT（Time Per Output Token）是每生成一个输出 token 的时间，这个决定了“后续输出流不流畅”。优化的核心就是压低这两个指标的同时把吞吐提上去。注意，这两个目标有时候是冲突的，不是无脑加并发就能解决。

主流优化手段有四条。第一是连续批处理（Continuous Batching），这是 vLLM 最核心的优化。传统批处理必须等整个 batch 全部生成完才能释放资源，但每个序列实际生成长度差异很大，短的早就该结束，长的还在跑，结果大量显存被短序列浪费。连续批处理在 token 级别做调度，每步生成时，新请求可以插入刚空出来的位置，吞吐能提升几倍。第二是 PagedAttention，把 KV Cache 按小块分页管理，类似操作系统内存分页，避免 KV Cache 碎片化，利用率显著提高。第三是投机采样（Speculative Decoding），用一个小模型先草拟多个 token，大模型一次验证，虽然多了一个模型开销，但整体延迟降很多，适合批处理场景。第四是量化结合批处理，INT8 或 FP8 把权重显存减半后，同批并发数直接翻倍。

面试官还喜欢问和多用户并发相关的估算题。你要是能把显存和并发数联系起来，就是高分：7B FP16 权重 14GB，加上一个 batch 的 KV Cache，假设单用户单请求 4K context，KV Cache 约 2GB，那么 24GB 的显卡最多同时跑约 10 来个并发，再往上就会 OOM。INT8 量化后权重变 7GB，可以撑更多。这种估算虽然不是精确值，但能证明你真的理解资源边界。

这道题的目的也适合用来复盘项目：你部署服务时有没有做压测？压测工具选的什么？有没有看 TTFT 的 P95 而不是只看平均值？这些问题没有实操经历是编不圆的。

3. 我当面试官时真实遇到的“翻车”现场

3.1 三个典型的答不上来瞬间

前面讲了 8 个题的标准答法，这一节我想把节奏放慢一点，聊几个我真实遇到的翻车瞬间。因为面试题解析到处都是，但“为什么有人会在最好答的题上挂掉”这种事，反而更值得看。

第一个翻车发生在注意力机制上。候选人讲了十来分钟项目，简历上写“用 LLaMA 做文本生成”，等我一问“那 QKV 是怎么来的”，他愣了一下说“应该是对输入序列切三份”。这不是紧张，是真心没拆过源码。做 LLM 应用的人天天用 transformer，但很少有人看过代码里 QKV 对应的三个 Linear 层。这个细节不难，但很能反映你到底是在调 API 还是真的研究过模型。

第二个翻车是 RLHF。候选人能把 PPO 的公式背出来，但我说“假如我只有虚拟环境，你来设计一个三步法拉近 SFT 模型和用户偏好的距离”，他直接原地愣住。很多刷面试题的人把 RLHF 当成预设知识在背，不知道它本质是“根据反馈更新策略”的工程系统，涉及奖励数据收集、模型更新、策略漂移抑制。你哪怕没用过 PPO，只要能从“人类反馈”角度设计一套流程，面试官也能给你不少分，但背公式答非所问就没有挽回余地。

第三个翻车是部署问题。候选人说用过 GGUF 格式做端侧部署，我问“Q4_K_M 和 Q8_0 有什么区别，你根据什么选的”，他答不上来。这就有点伤了，因为你实际用过一定会知道 Q4 是 4bit 量化，Q8 是 8bit，区别是精度和文件大小。用过和听说过之间的差异，就是在这种小问题上现形的。

3.2 一句话就能救场的加分回答

面试肯定会遇到不会的题，这不丢人，丢人的是僵在那里或者强行编。我比较认可的应对套路是：先明确说出自己掌握到哪个边界，再把问题往自己熟悉的经验上拉，最后给出一个可验证的下一步。

比如被问到完全没听过的推理加速方案，你可以说：“这个具体方案我没在线上用过，不敢乱讲。但按我的理解，它的核心目标应该是降低显存或计算量，我在部署 vLLM 时处理过类似问题，当时用 INT8 量化加增大 batch，TTFT 从 4 秒降到了 1.5 秒。这个方案如果在原理上有类似思路，我可以快速读源码后补充细节。” 这段话既承认了盲区，又展示了迁移能力，还给出了落到实处的经验值。面试官不怕你不懂，怕的是不懂还硬撑。

4. 考前 10 天怎么准备这套题

4.1 按优先级安排复习顺序

如果距离面试只有十天，我建议按四步走，不要一上来就刷论文。

前三天主攻原理题，也就是第 1、2、3 题。这三天要把注意力公式手推两遍，把 BPE 的合并流程用一个小例子走一遍，把预训练、SFT、RLHF 各自解决的问题用一段话写出来。你可以找一个没有网课的下午，用纸笔把这三题默写成答题稿，说出来能通顺，才算过。

第四到第六天主攻工程题，也就是第 4、6、8 题。这三道题的共同点是都涉及资源和性能。你要能背出 KV Cache 显存公式和 24GB 显卡的并发估算，要知道 GGUF 的 Q4、Q8 区别，要能把 vLLM 的连续批处理讲成“等车游戏”：一辆车到了就发车，而不是非要凑满一整个站台的人。同时找一台机器，哪怕 CPU 机器，跑一个开源小模型，亲眼看模型文件大小和推理速度，印象会深得多。

第七到第八天集中整理 RAG 和评估，也就是第 5、7 题。RAG 建议自己搭一个最小链路：找一个文档集，切 chunk，灌向量库，写检索和重排，最后让模型带引用生成回答。这套流程半天就能跑通，但它能让你在面试时讲出“切 chunk 不是越大越好”“rerank 不是可有可无”这种真实经验。

最后两天做模拟面试。找朋友或者对着录音把自己的回答讲一遍。很多人觉得自己会了，一开口才发现一堆“然后”“那个”。你面试时的流畅度会直接影响面试官对你熟练度的判断，同样的内容，磕磕绊绊讲出来和大方讲出来，分数差一个档。

4.2 实践路线，别让知识点漂在嘴上

我还想多说一句：这 8 个题再熟练，也只是过面试的底线，不是大模型能力的全部。真正能在候选人里杀出重围的，是那些能把“知道”变成“做过”再变成“有改进”的人。比如你做过一次 RAG，发现长 query 召回差，通过 query 改写把命中率提了上来——这个故事比十个背得滚瓜烂熟的原理都要有说服力。

没有条件用大模型训练的话，建议从小模型开始。HuggingFace 上找开源权重模型，用 transformers 库加载起来，自己写一条数据做 SFT 微调，再导成 GGUF 格式跑到手机上，这条链路全走通，你的工程认知提升速度会很快。大模型面试不是考试，它更像一场工程经验交流，你手里有真东西，聊什么题都不慌。

我还想再补充一个备考细节：这 8 个题是最常问的，但面试官通常会在你答得不错的时候追加一个“延伸问题”，比如“KV Cache 你讲得很清楚，那一层有多少 KV，怎么落到实际显存里”，或者“你 RAG 里用的是什么向量库，为什么选它”。所以在复习时，每个题都往下多想一层，想想面试官还能顺着哪里追问，提前准备好延伸素材，效果会比只背主干好很多。

5. 写在最后：面试问的是下限，工程看的是上限

我见过很多人因为做题做得顺就觉得稳了，也见过有人技术明明不错，败在一句“这个我没实际用过”上。这 8 道题只能帮你评估在下限，真正决定你能不能拿到 offer 的，是你能不能把每个知识点放进一个具体场景里给出自己的选择和理由。面试官最后通常会问一句“你最近踩过什么坑”，这个问题没有标准答案，但他能从你的回答里听出你是不是真的在跟模型打交道。所以，别把自己当成背题机器，把这 8 个问题当成一条实践的起点，顺着它把模型跑起来、把问题修一遍，收获会比刷十遍题多得多。我这里也一直建议准备面试的同学：答题之前先把模型跑起来，让 token 真正流过你的代码，再回头背这些题，你会觉得每一个问题都立体得多。