Wiki Notes

Appearance

AI面试题专题 ​

版本：v1.2

最后更新：2026-07-08

适用对象：准备 AI / LLM / Agent / 平台工程方向面试，或者想把自己做过的项目讲得更像“真正做过”的读者

很多人学 AI 最容易卡住的地方，不是“没看过资料”，而是：

  • 知道名词，但说不清原理
  • 会调 API，但讲不出系统设计
  • 会做 Demo，但扛不住追问
  • 能讲效果，却讲不清失败、评测、成本和风险

这篇专题的目标不是堆题库，而是帮你建立一套更像工程回答的表达框架。

1. AI 面试到底在考什么 ​

绝大多数 AI / LLM 应用岗位，考察都绕不开下面 6 类能力：

  1. 模型基础是否讲得清。
  2. 模型调用和消息结构是否真的理解。
  3. 是否做过结构化输出、检索、工具调用或 Agent。
  4. 是否有评测、回放、上线、稳定性和安全意识。
  5. 是否能讲清楚技术选型与取舍。
  6. 是否经历过失败、修复和迭代。

换句话说，面试官并不只想知道你“会不会用 AI”。

更想知道的是：

  • 你是不是知道它为什么这样设计
  • 你能不能把问题拆成系统层次
  • 你有没有真的承担过落地责任

2. 不同岗位的关注点不一样 ​

2.1 应用开发岗 ​

更看重：

  • 能不能把一个需求拆成 Prompt、结构化输出、工具调用
  • 会不会做回放、失败样例和简单评测
  • 是否知道什么时候不该上复杂 Agent

2.2 平台工程 / LLMOps 岗 ​

更看重：

  • 模型选型
  • 上下文与 token 成本治理
  • 状态管理
  • schema、工具定义、回放、观测、发布门禁

2.3 算法 / 研究转应用岗 ​

更看重：

  • 能不能从模型原理讲到工程权衡
  • 是否理解 RAG、微调、评测与生产化差异
  • 是否知道“模型能力”与“系统能力”的边界

2.4 交付 / 解决方案岗 ​

更看重：

  • 是否能把技术方案翻译成业务价值
  • 是否能说明边界、风险和组织协作方式
  • 是否知道哪些需求不应该用 AI 硬做

3. AI 面试的高频模块 ​

最常见的题目大体可以分成：

  • 模型基础
  • LLM 工程
  • RAG 与检索
  • Agent 与工具调用
  • 评测与上线
  • 安全与治理
  • 项目设计题

如果岗位偏平台或架构，还会继续追问：

  • 模型路由
  • 观测与成本
  • 审批链和风险控制
  • 多团队协作和版本治理

4. 回答问题的总原则 ​

4.1 不要只背概念 ​

AI 面试最常见的低分回答是：

  • 把定义背对了
  • 但听不出你做过

例如“RAG 是检索增强生成”当然没错，但如果你讲不出：

  • 数据怎么准备
  • chunk 怎么切
  • 召回和重排怎么排查
  • 为什么模型明明有资料却答不出来

那这类回答通常只能算入门。

4.2 回答要尽量带“层” ​

很多问题都可以按层回答：

  • 模型层
  • 输入层
  • 检索层
  • 状态层
  • 工具层
  • 评测层
  • 风险层

比如“为什么效果不稳定”，一个更像工程师的回答通常不是：

  • 因为 Prompt 没写好

而是：

  • 先看任务定义
  • 再看输入结构
  • 再看上下文和证据质量
  • 再看输出约束
  • 最后看模型选择和温度参数

4.3 面试官喜欢“权衡感” ​

不要只说：

  • 这个方案很好

更应该说：

  • 这个方案为什么适合当前场景
  • 它牺牲了什么
  • 什么时候你会换成另一种方案

5. 自我介绍怎么讲，才更像做过项目的人 ​

很多人的自我介绍太像流水账：

  • 做过聊天机器人
  • 做过知识库
  • 做过 Agent

这种说法很难让面试官判断你的深度。

更推荐按下面这个结构讲：

  1. 你主要做哪类 AI 场景。
  2. 你负责的链路是什么。
  3. 你最熟的技术边界在哪里。
  4. 你解决过什么难点。
  5. 你最拿得出手的结果是什么。

5.1 一个更像工程化的表达模板 ​

例如可以这样组织：

“我这段时间主要做的是企业内知识问答和任务型 AI 应用。我的工作重点不是单纯写 Prompt，而是把输入结构、检索链路、结构化输出、工具调用和评测回放串起来。比较典型的一类问题是模型看起来能回答，但上线后会出现引用错位、工具越权或者多轮状态漂移，所以我更多是在解决稳定性、评测、安全和成本之间的平衡问题。”

这种说法的好处是：

  • 有场景
  • 有职责
  • 有边界
  • 有工程味

6. 模型基础高频问题 ​

6.1 Transformer 为什么能替代 RNN ​

答题重点：

  • Self-Attention 让并行化更容易
  • 更擅长建模长距离依赖
  • 扩展性更强，更适合大规模训练

进一步追问时，最好还能讲：

  • 为什么需要位置编码
  • 为什么注意力复杂度会变高
  • 为什么上下文窗口会变成工程限制

配套阅读：

6.2 Embedding 和生成模型有什么区别 ​

答题重点：

  • Embedding 更偏表示和相似度计算
  • 生成模型更偏续写、问答、推理和生成
  • 两者经常在 RAG 体系里配合使用

更强一点的回答还应补上：

  • Embedding 的稳定性和检索召回直接相关
  • 生成模型负责把证据组织成答案
  • 不能把“检索效果差”误判成“模型太弱”

6.3 token、上下文窗口为什么会影响方案设计 ​

这是基础题，但很多人答得很虚。

更稳的回答应该包含：

  • token 是预算单位，不只是字符数
  • 上下文窗口包含规则、消息、工具、图片、文件和输出预算
  • 历史变长会推高成本和延迟
  • 长上下文并不天然等于高质量，可能出现信息淹没和召回下降

这类回答如果能顺带提到官方文档关于真实 token 计数、结构化输入和工具 schema 也占预算，会更有当前工程感。

7. LLM 工程高频问题 ​

7.1 为什么不是所有问题都该微调 ​

答题重点：

  • 微调成本高、迭代慢
  • 知识更新频率高的场景更适合检索或工具
  • 很多问题通过 Prompt、结构化输出和评测就能解决
  • 微调更适合风格、格式、稳定行为而不是所有知识问题

更进一步还可以说：

  • 先做基线评测，再决定要不要微调
  • 很多团队是在“Prompt 都没做稳”的情况下就急着谈微调

7.2 你会怎么做评测 ​

答题重点：

  • 先定义任务成功标准
  • 再准备评测集
  • 区分离线评测和线上指标
  • 高风险场景要有人工抽检或人工审批

更成熟一点的回答可以继续讲：

  • 对比基线版本
  • 按任务类型拆指标
  • 记录失败样例
  • 把评测结果绑定到发布门禁

7.3 为什么结构化输出往往比“让模型返回 JSON”更稳 ​

这个问题非常适合拉开差距。

答题重点：

  • 自然语言要求“返回 JSON”并不等于稳定结构约束
  • 结构化输出更适合进入程序系统
  • schema 只是第一层，值域和业务语义仍要二次校验

如果你能再补一句“结构化输出解决的是结果格式，function calling 解决的是外部动作执行”，面试官通常会觉得你边界感比较清晰。

7.4 多轮对话为什么不能一直追加历史 ​

答题重点：

  • 成本会越来越高
  • 无关历史会污染当前任务
  • 状态和事实应该分层管理
  • 更好的方式是原始历史、摘要、长期事实和工具结果分开保存

8. RAG 高频问题 ​

8.1 RAG 的核心环节有哪些 ​

答题重点：

  • 数据准备
  • chunking
  • embeddings
  • 召回
  • 重排
  • prompt assembly
  • 最终生成

如果能加上一句“RAG 的问题经常出在上游数据和证据装配，不一定是生成模型本身”，回答会更像实践型。

8.2 RAG 效果不好你怎么排查 ​

一个比较稳的排查顺序是：

  1. 先看数据质量和权限范围。
  2. 再看 chunk 切分和元数据。
  3. 再看 embedding、召回和重排。
  4. 再看证据如何拼进上下文。
  5. 最后再看模型和 Prompt。

很多面试官会通过这个问题判断你到底做没做过线上知识库。

8.3 什么场景不适合 RAG ​

答题重点：

  • 需要实时写操作而不是知识回答
  • 核心问题是动作执行，不是知识获取
  • 数据并不成文档，反而更像结构化查询

这时更适合：

  • 工具调用
  • 数据库查询
  • 工作流节点

9. Agent 高频问题 ​

9.1 什么场景适合 Agent，什么场景不适合 ​

答题重点：

  • 需要多步决策、工具调用、状态管理时更适合
  • 固定格式输出、单步分类、简单摘要往往不需要 Agent

一个更成熟的回答应该加上：

  • Agent 带来的是灵活性，不是免费的稳定性
  • 复杂度、成本、调试难度和风险也会上升

9.2 Agent 最大风险是什么 ​

常见回答点包括：

  • 工具越权
  • prompt injection
  • 多轮状态失控
  • 成本失控
  • 可观测性不足

如果你能补充：

  • 高风险动作应当强制人工确认
  • 工具入参与结果要审计
  • 风险分层路由比“一刀切放行”更稳

这类回答会很加分。

9.3 Agent 和工作流有什么边界 ​

一个稳妥的回答思路是：

  • 工作流更强调预定义节点和明确控制
  • Agent 更强调基于上下文做动态决策
  • 真实系统里往往是工作流包裹 Agent，而不是全靠 Agent 自由发挥

10. 安全与治理高频问题 ​

10.1 模型输出为什么不能默认可信 ​

答题重点：

  • 模型本质是生成和推断，不是事实数据库
  • 结构对了不代表语义对
  • 有工具能力时，错误输出还可能变成错误动作

10.2 你会怎么做高风险动作控制 ​

答题重点：

  • 风险分级
  • 工具白名单
  • 参数校验
  • 双确认 / 人工审批
  • 审计日志

10.3 prompt injection 为什么严重 ​

答题重点：

  • 因为它不是普通输入错误，而是试图重写系统规则或误导工具执行
  • 在 RAG、浏览器、文档解析、电脑操作、跨系统代理中尤其危险

11. 项目题怎么回答更有说服力 ​

讲项目时，不要只讲“做了一个聊天机器人”。

更推荐按这个结构回答：

  1. 业务目标是什么。
  2. 为什么选这个方案。
  3. 系统架构怎么拆。
  4. 最大问题是什么。
  5. 你怎么评测和优化。
  6. 最终效果和收益是什么。
  7. 上线后遇到过什么问题。
  8. 如果再做一遍，你会怎么改。

11.1 一个更强的项目回答模板 ​

你可以按下面顺序讲：

  • 场景：我们要解决什么业务问题。
  • 约束：准确率、时延、权限、预算有什么要求。
  • 方案：为什么用 Prompt / RAG / 工具 / Agent。
  • 链路：输入、检索、模型、工具、输出、审批怎么串。
  • 评测：怎么判断比以前更好。
  • 风险：哪里最容易出事故。
  • 结果：最终带来了什么改善。

11.2 面试官最爱追问的地方 ​

  • 为什么这样切 chunk
  • 为什么不用微调
  • 为什么一定要 Agent
  • 为什么模型明明有资料却答不对
  • 为什么这个动作能自动执行
  • 线上最难的问题是什么

所以准备项目时，一定要提前把这些问题写成自己的“二级答案”。

12. 系统设计题怎么答 ​

AI 方向的系统设计题，常见形式包括：

  • 设计一个企业知识问答系统
  • 设计一个客服辅助系统
  • 设计一个能调多个系统的 Agent
  • 设计一个支持回放和评测的 LLM 平台

12.1 建议的作答框架 ​

  1. 先问清目标与边界。
  2. 再拆输入、处理、输出。
  3. 再明确哪些环节需要模型，哪些环节不用。
  4. 再讲评测、观测、权限和回滚。

12.2 一个常见的好习惯 ​

不要一上来就画大图。

先说：

  • 用户是谁
  • 失败代价是什么
  • 是否需要实时数据
  • 是否需要动作执行
  • 是否允许自动放行

这些信息会直接决定你后面的系统形态。

13. 初级、中级、高级回答的区别 ​

13.1 初级回答 ​

  • 只会解释概念
  • 没有工程细节
  • 没有失败案例
  • 听不出真正做过

13.2 中级回答 ​

  • 能讲链路和模块拆分
  • 能解释为什么这样选型
  • 知道评测、成本和安全问题

13.3 高级回答 ​

  • 能讲线上事故与修复
  • 能讲组织协作与流程治理
  • 能从稳定性、安全、成本、迭代速度一起回答问题

14. 一组很能拉开差距的高频追问 ​

建议你至少提前练下面这些题：

  1. 为什么结构化输出不等于 function calling？
  2. 多轮对话里，历史消息应该怎么治理？
  3. 为什么 RAG 失败不应该先怪模型？
  4. 什么场景不该做 Agent？
  5. 如何判断一个 AI 功能是否能自动执行，而不是必须人工确认？
  6. 评测集怎么构造，失败样例怎么沉淀？
  7. token 成本和工具 schema 为什么会影响架构？
  8. 如果上线后效果漂移，你怎么回放和定位问题？

15. 面试前最值得准备的 6 件事 ​

  1. 把自己做过的项目画成一张架构图。
  2. 给每个项目准备一条“失败排查链路”。
  3. 给每个项目准备一个“为什么这样选型”的版本。
  4. 整理 10 个高频概念的口头解释。
  5. 准备一个最复杂问题的事故复盘故事。
  6. 用自己的话总结 RAG、Agent、评测、安全和成本治理。

16. 7 天面试准备建议 ​

第 1 天 ​

  • 过一遍 AI学习计划
  • 整理自己的项目清单
  • 标出每个项目你真正负责的部分

第 2 天 ​

第 3 天 ​

第 4 天 ​

  • 复习 LLM专题
  • 准备 RAG、微调、评测、成本和延迟相关答案

第 5 天 ​

  • 复习 AI Agents专题
  • 准备 Agent 场景、状态、工具风险和协议边界相关答案

第 6 天 ​

  • 复习 安全治理
  • 准备 prompt injection、审批链、风险路由、红队和门禁相关答案

第 7 天 ​

  • 完整模拟一轮项目问答
  • 至少练 2 次系统设计题
  • 把答案从“概念版”升级到“做过版”

17. 官方资料入口 ​

以下入口在 2026-07-08 检查时可访问，适合拿来校准当前主流工程表达：

18. 最后给一句判断标准 ​

如果你现在已经能做到下面这些事，说明你的 AI 面试表达已经开始从“会背概念”走向“像真正做过项目的人”：

  1. 能把一个 AI 需求拆成输入、规则、上下文、输出、工具、评测和风险控制。
  2. 能讲清楚为什么这个场景该用 Prompt、RAG、工具还是 Agent。
  3. 能说出至少一个失败案例，以及你是怎么定位和修复的。
  4. 能解释成本、延迟、评测和安全为什么不是上线之后再考虑的事。
  5. 能在回答里体现出取舍，而不是只说“这个方案很好”。

做到这些，面试官通常就不会只把你当成“会调几个模型接口的人”。

19. 应用开发岗更常见的追问题 ​

如果你投的是偏应用开发、业务系统接入、AI 功能落地方向，下面这些题出现频率通常很高。

19.1 怎么判断一个需求要不要上 AI ​

推荐回答框架：

  1. 先看输入是不是天然模糊、非结构化、规则难穷举。
  2. 再看输出是不是允许概率式结果，还是必须强一致。
  3. 再看错误代价，如果错一次代价很高，就要更谨慎。
  4. 最后看是否需要检索、工具或人工确认做兜底。

更像做过项目的回答，不是“适合自然语言就上 AI”，而是：

  • 先看任务边界
  • 再看风险等级
  • 再看是否能建立评测和回滚

19.2 为什么很多看起来适合 AI 的功能最后没上线 ​

答题重点：

  • Demo 可行不等于生产可行
  • 缺少结构化输出和校验
  • 缺少评测、回放和观测
  • 错误代价高但没有人工兜底
  • 成本和延迟不满足业务要求

19.3 如果一个功能“偶尔对、偶尔错”，你会先看哪里 ​

推荐排查顺序：

  1. 任务定义是否稳定。
  2. 输入结构是否清晰。
  3. 上下文是否被污染。
  4. 输出协议是否稳定。
  5. 是否存在检索、工具或状态管理问题。

这道题特别适合拉开和“只会继续调 Prompt”的候选人的差距。

19.4 什么时候只做结构化输出，什么时候一定要工具调用 ​

答题重点：

  • 结构化输出解决“结果怎么稳定进程序”
  • 工具调用解决“结果之外是否还要执行外部动作”
  • 只读型判断、抽取、分类通常优先结构化输出
  • 查实时数据、写业务系统、调用外部动作通常需要工具调用

20. 平台 / LLMOps 岗更常见的追问题 ​

20.1 你怎么看 Prompt、模型、工具和配置的版本治理 ​

一个更成熟的回答可以从四层讲：

  • Prompt / instruction version
  • model version
  • tool / schema version
  • serving / release version

然后再补：

  • 这些版本要和评测结果绑定
  • 不能只记录“改过”，要能回答“哪次上线生效了什么”

20.2 你会怎么做模型选型 ​

答题重点：

  • 先看任务复杂度和质量要求
  • 再看时延和成本约束
  • 再看工具调用、结构化输出、多模态等能力需求
  • 最后看是否需要多模型路由或回退

更像平台工程视角的回答，通常会补一句：

  • 模型选型不是“一次选完”，而是要和评测、灰度和回退一起看

20.3 你会怎么做上线前的门禁 ​

推荐回答结构：

  1. 明确任务级成功标准。
  2. 准备固定评测集和高风险样例集。
  3. 检查成本、时延、稳定性和安全基线。
  4. 必要时做灰度、影子流量和人工抽检。
  5. 通过后再进入发布。

20.4 你怎么看 tracing / observability 在 AI 系统里的价值 ​

答题重点：

  • 不是为了“看日志更多”
  • 而是为了回放输入、上下文、工具调用、引用和最终输出
  • 让失败能定位到 Prompt、检索、工具或状态层
  • 让评测和事故复盘有真实证据

21. 算法 / 研究转应用岗更常见的追问题 ​

21.1 训练视角和应用视角最大的差异是什么 ​

推荐回答重点：

  • 训练更关注能力上限和泛化
  • 应用更关注稳定性、成本、延迟、权限、可回滚
  • 线上问题很多不是模型能力问题，而是系统能力问题

21.2 为什么模型更强了，系统效果却不一定更稳定 ​

答题重点：

  • 上下文构造可能变复杂
  • 工具调用和状态管理带来新风险
  • 结构化输出约束、工具 schema、评测集可能没跟上
  • 新模型换来更高能力，也可能换来更高成本和新分布偏移

21.3 你怎么看微调在企业场景里的位置 ​

更稳的回答通常是：

  • 微调不是默认答案
  • 很多企业问题先由 Prompt、RAG、结构化输出和工作流解决
  • 微调更适合长期稳定的风格、术语、格式或行为强化
  • 真正要不要做微调，要由评测数据而不是主观感觉决定

22. AI 系统设计面试题的展开模板 ​

很多人知道要“先问目标和边界”，但真正展开时还是会空。下面给几个更接近实战的展开模板。

22.1 设计企业知识问答系统 ​

建议回答顺序：

  1. 问清用户是谁、知识范围是什么、是否多租户。
  2. 说明知识源、解析、切片、metadata、索引的处理链。
  3. 说明检索策略是纯向量、混合检索还是带 rerank。
  4. 说明答案如何做结构化引用和权限控制。
  5. 说明评测、回放、失效检测和版本治理。

22.2 设计客服辅助 Copilot ​

建议重点：

  • 不一定直接给最终答案
  • 可以先做摘要、建议回复、风险提示、知识引用
  • 高风险动作必须人工确认
  • 要区分“建议”与“自动执行”

22.3 设计一个能调多个系统的 Agent ​

建议重点：

  • 先定义工具边界
  • 再定义状态管理和失败恢复
  • 再定义审批和越权控制
  • 最后再谈模型和规划能力

这类题最忌讳一上来就讲“多智能体很强大”。

22.4 设计 AI 平台 ​

建议至少覆盖：

  • Prompt / model / tool / config 版本治理
  • 评测与基线
  • tracing 和回放
  • 发布门禁、灰度、回滚
  • 成本与配额
  • 权限与审计

23. 项目深挖题的高频问法 ​

项目题通常不是让你复述简历，而是看你能不能扛住细问。

23.1 “这个项目最难的不是搭起来，而是什么” ​

推荐回答不要太泛。更好的方向通常是：

  • 如何把成功标准说清楚
  • 如何让输出稳定进入系统
  • 如何处理失败样例
  • 如何避免上线后成本失控
  • 如何给高风险动作做兜底

23.2 “如果把时间倒回去，你会推翻哪一个设计决定” ​

这是非常好的拉分题。

高质量回答通常体现：

  • 你知道当时为什么这么做
  • 你知道它后来暴露了什么问题
  • 你能给出更成熟的替代路径

23.3 “你做的这件事，怎么证明是你做的而不是团队一起做的” ​

这类题的回答最好落到：

  • 你负责哪一段链路
  • 你做了哪些关键决策
  • 哪些具体问题是你排查或推动解决的
  • 哪些指标或结果与你的动作直接相关

23.4 “这个项目线上最尴尬的一次事故是什么” ​

建议回答结构：

  1. 事故现象是什么。
  2. 影响范围多大。
  3. 最早是怎么发现的。
  4. 根因在哪一层。
  5. 修复动作是什么。
  6. 后面如何避免再次发生。

24. 一组更像真实面试的快问快答 ​

下面这些题，适合拿来自己做口头模拟。

24.1 为什么不能把历史消息一直追加下去 ​

因为上下文是预算，不是无限容器。历史越长，成本、延迟和信息污染都会上升，而且长上下文不等于高质量。

24.2 为什么“返回 JSON”不等于结构化输出 ​

因为自然语言要求模型“尽量返回 JSON”不等于强约束；真正工程上可用的结构化输出还需要 schema 和程序端校验。

24.3 为什么很多知识库项目越做越重、效果却越来越难提升 ​

常见原因不是模型不够强，而是知识源、metadata、版本、引用、失败样例和发布治理没有一起建设。

24.4 为什么 Agent 不是默认答案 ​

因为 Agent 带来的是动态性，不是免费的稳定性。复杂度、成本、调试难度和风险通常都会上升。

24.5 为什么高风险动作最好不要只让模型自动决定 ​

因为模型输出不是事实裁决，工具执行会把生成错误变成真实动作，所以必须配审批、白名单、参数校验和审计。

25. 面试时可以反问什么 ​

很多候选人忽略了反问环节，但这其实也能体现成熟度。

比较好的反问方向包括：

  • 团队现在 AI 系统最大的稳定性问题是什么
  • 团队是怎么做评测、灰度和回滚的
  • 现在更缺模型能力、工程能力，还是治理能力
  • 团队做 RAG / Agent 时最大的坑是什么
  • 岗位在项目里更偏平台、应用，还是方案和交付

这类反问的价值是：

  • 让你判断岗位真实难点
  • 也让面试官感受到你在意的是落地而不只是热点词

26. 30 分钟面试前速查清单 ​

如果只剩最后半小时，建议至少快速过一遍这些问题：

  1. 我能不能用 2 分钟讲清最近一个项目。
  2. 我能不能讲清一次失败排查链路。
  3. 我能不能解释结构化输出、工具调用、Agent 的边界。
  4. 我能不能说明 RAG 常见失败为什么不能一律怪模型。
  5. 我能不能讲清成本、延迟、评测和安全各自怎么影响方案。
  6. 我能不能说出一个“如果重来会改什么”的例子。

27. 建议继续补的方向 ​

如果后面还要继续扩展这篇专题，最值得增加的几个方向是：

  • 按岗位拆分的面试题库：应用开发、平台工程、算法转应用、解决方案
  • AI 系统设计题题库：知识问答、客服辅助、Agent 平台、LLM 网关
  • 项目追问清单：从简历项目反推 50 个高频追问
  • 口头表达示例：把“概念版回答”改写成“做过版回答”

28. 按岗位拆开的高频题单 ​

如果你时间有限，不要平均用力。

更高效的方式是先按目标岗位拆题，再决定优先级。

28.1 应用开发岗优先准备这 10 题 ​

  1. 怎么判断一个需求到底该不该上 AI。
  2. 为什么很多场景只做结构化输出，不一定要上 Agent。
  3. 为什么“返回 JSON”不等于系统可用。
  4. RAG 里 chunk、metadata、rerank 分别影响什么。
  5. 为什么明明资料里有，模型还是答不对。
  6. 工具调用什么时候比静态知识更合适。
  7. 多轮会话为什么不能一直堆历史。
  8. 如果结果偶发不稳定，先看 Prompt 还是先看链路。
  9. 上线前至少要补哪几类评测。
  10. 你做过的项目里，最典型的一次失败是怎么定位的。

28.2 平台工程 / LLMOps 岗优先准备这 10 题 ​

  1. 模型、Prompt、工具、配置为什么要分层版本治理。
  2. 你会怎么做 tracing、回放和线上证据留存。
  3. 模型选型如何平衡质量、延迟和成本。
  4. 灰度、影子流量、回滚在 AI 系统里分别解决什么问题。
  5. 评测门禁怎么和发布流程绑定。
  6. 为什么 token 成本和上下文预算会影响架构。
  7. 多模型路由和回退应该怎么定触发条件。
  8. RAG 系统为什么要区分内容版本、索引版本和服务版本。
  9. 高风险工具调用如何做审批和审计。
  10. 线上效果漂移时，怎么定位是模型变了还是系统链路变了。

28.3 算法 / 研究转应用岗优先准备这 8 题 ​

  1. 为什么模型能力增强不等于系统效果自然增强。
  2. 训练视角和应用视角最大的工程差异是什么。
  3. 为什么很多企业场景先做 RAG、工作流和评测，而不是先微调。
  4. 结构化输出、工具调用、Agent 分别解决什么边界问题。
  5. 为什么很多线上事故不是模型问题，而是状态、上下文或权限问题。
  6. 你怎么定义一个 AI 功能“可以上线”。
  7. 如何从失败样例反推系统设计缺口。
  8. 如果给你一个已有 Demo，你会先补哪三层工程能力。

28.4 解决方案 / 交付岗优先准备这 8 题 ​

  1. 怎么把技术能力翻译成业务收益。
  2. 怎么向客户解释 AI 能力边界，而不是只讲最好情况。
  3. 为什么很多自动化动作必须保留人工确认。
  4. RAG 和 Agent 在企业交付里最容易踩什么坑。
  5. 如何定义验收标准，而不是只做演示效果。
  6. 出现幻觉、引用错误和越权动作时怎么对外说明。
  7. 如何设计试点范围，避免一开始就全量放开。
  8. 如何判断客户真正缺的是模型能力、流程能力还是治理能力。

29. 90 秒项目介绍模板 ​

很多候选人的问题不是“没做过”，而是说得太散。

如果只能说 90 秒，建议强制按下面 6 句讲：

  1. 场景：这个项目服务谁，解决什么业务问题。
  2. 约束：准确率、时延、权限、预算里最重要的约束是什么。
  3. 方案：为什么用了 Prompt / RAG / 工具 / Agent，而不是别的方案。
  4. 职责：你真正负责的是哪一段链路。
  5. 难点：最难的问题出在哪一层。
  6. 结果：上线后效果、风险控制或效率收益是什么。

29.1 一个可直接套用的表达骨架 ​

你可以直接照着这个骨架练：

“我们当时要解决的是 业务问题，约束主要在 准确率 / 时延 / 权限 / 成本。方案上没有直接把问题做成大而全的 Agent，而是先用 Prompt / RAG / 工具 / 工作流 拆链路。我主要负责的是 输入组织 / 检索链路 / 输出协议 / 工具接入 / 回放评测 这一段。上线前最大的难点是 某一类失败，最后通过 某个关键改动 把问题收住。最终结果是 指标改善 / 风险下降 / 人效提升。”

29.2 这个模板为什么有效 ​

因为它天然会逼你回答三个面试官最关心的问题：

  • 这件事为什么存在。
  • 你在里面到底做了什么。
  • 你有没有处理过真正的复杂性。

30. 一轮高质量回答应该长什么样 ​

很多人一紧张就会把回答讲成“知识点背诵”。

更稳的做法是强制自己带上下面四层：

  1. 定义层：先说清这个概念在解决什么问题。
  2. 边界层：再说它不解决什么，别和相邻概念混掉。
  3. 工程层：再说真实系统里这件事通常落在哪条链路。
  4. 权衡层：最后说它的代价、限制和替代方案。

30.1 以“为什么不是所有问题都该上 Agent”为例 ​

一个较弱的回答通常只有一句：

  • 因为 Agent 很复杂。

一个更像做过项目的回答会是：

  • Agent 适合多步决策、工具调用和状态管理，但它带来的不是免费的智能，而是更多的不确定性。
  • 如果任务本身是单步抽取、分类、改写或固定格式输出，通常优先结构化输出或简单工作流更稳。
  • 只有当任务真的存在动态决策、外部系统交互和状态推进时，Agent 才有明显价值。
  • 即使决定用 Agent，也要配回放、评测、审批和越权控制，否则上线后很难收住。

这就是“定义 + 边界 + 工程 + 权衡”的回答结构。

31. 面试后复盘模板 ​

准备 AI 面试，最怕的是每次面完只记得“感觉一般”。

更有效的做法是把每轮面试复盘成结构化记录。

31.1 建议至少记这 6 类信息 ​

  1. 哪些问题答得顺。
  2. 哪些问题答得空。
  3. 哪些追问暴露出你没有真实案例。
  4. 哪些概念你会解释，但不会落到工程链路。
  5. 哪些问题其实需要图、表或例子辅助表达。
  6. 下次面试前最该补的是哪一个专题。

31.2 一个最小复盘表 ​

题目当时怎么答暴露的问题下次怎么改
为什么不用微调只讲了成本高没讲评测先行和知识更新频率补上 RAG / Prompt / 微调的选型边界
Agent 为什么风险高只讲了越权没讲状态漂移、审计和审批补上高风险动作控制链路
项目里最难的问题讲得太泛没说现象、根因和修复动作按事故复盘模板重讲一遍

31.3 最值得反复练的不是“标准答案”，而是“稳定表达” ​

真正能帮你拉开差距的，往往不是多背 20 道题，而是把下面几件事讲稳定：

  • 一个项目的 90 秒版本。
  • 一个失败案例的 3 分钟版本。
  • 一个系统设计题的 5 分钟版本。
  • 一个技术取舍题的 2 分钟版本。

如果这四类表达已经比较稳，AI 面试通常就不会再只停留在“背没背过概念”的层面。