AI 应用开发岗 · 八股广度清单

适用：校招 AI 应用开发 / LLM 应用工程方向定位： 项目之外的通用知识考察。项目相关题见另一份《面试全覆盖题库（追问链版）》。
优先级标记
标记含义建议
★★★ 几乎必问 / 不会就是硬伤必须能口头讲清楚
★★ 常见，考察深度要知道原理和取舍
★ 加分项，考察广度知道有这回事、能说个大概就够
使用方式
这份清单是 广度覆盖，每条只给要点骨架。能看着要点讲出 2-3 句连贯的话，就算过关。
讲不出来的标 🔴，回头单独补。
不要背答案。面试官追问的方式是「为什么」，背的答不出为什么。
涉及具体模型版本、榜单排名、价格的部分， 以官方最新公开信息为准，这份清单只给判断框架。
⚠️ 先读这一节：这份清单要裁着看
368 条不是让你全背的——那是 6 小时的量。它的真正用途是 让你知道自己哪里不会，扫一遍标出 🔴，然后只补那部分。
更关键的是： 这 14 章不是等权的。有的是你这个岗位的核心考点，有的其实是另一个岗位的考纲混进来了。按下表裁：
章节条数对「AI 应用开发」的定位怎么过
一 LLM 基础 48 核心全过，每条要能讲 2 分钟
二 Prompt 工程 22 核心全过，2.1 优先于 2.2
三 RAG 43 核心（命中率最高的一章）全过，3.1–3.3 是重中之重
四 Agent 32 核心全过，4.1 和 4.4 优先
七评估 20 核心，但最常被忽略 全过。多数候选人答不出”怎么评估”，这是拉开差距的地方
八 AI 工程化 25 核心全过
十二系统设计 17 核心全过，背下 12.3 的 checklist
五微调与对齐 29 部分只过：LoRA 原理、什么时候该微调而不是 RAG、量化概念。对齐细节、压缩细节可跳
六推理与部署 25 部分必看 6.1（KV Cache、连续批处理）和 6.3（成本）；6.2 服务化按你简历的深度看
十 Python 39 部分 10.3 工程实践最对口；10.1 只挑 GIL / asyncio / 深浅拷贝 / 装饰器 / pydantic。元类、描述符、__new__、迭代器协议这类”语言律师题”可跳
十三开放题 — 了解略读，知道思路即可
十四行业认知 20 了解 14.1 模型选型、14.3「为什么做这行」必看；14.2 知道名词就行
九 ML/DL 基础 28 ⚠️ 错配章节 见下方说明
十一算法 — 通用（与岗位无关）校招必考，但不属于八股范畴，单独刷题
要不要准备传统后端知识？要，但边界很清晰
结论：需要，但只需要”和你简历强相关”的那部分，大概 30 个考点。
三个理由
岗位后缀是”开发”。AI 应用开发不是”AI 研究员”——你写的东西要上线、要扛流量、要能被观测。一个 RAG 系统里有缓存、有向量库、有异步 Pipeline；一个 Agent 系统里有流式、有超时、有重试、有并发控制。 这些全是后端问题，而且恰恰是最容易出事故的地方。
你的简历就是后端栈。两个项目里，Go 微服务 / gRPC / Kafka / Redis / Canal / K8s 占了七成篇幅，AI 相关（ReAct、Eino、RAG）只占三行。 面试官看着这份简历不问后端是不可能的——他甚至可能主要就是按后端在考你，AI 部分才用来区分。
你已经有优势，不需要从头补。这是好事：项目二那段 Canal+Kafka 的缓存一致性链路，本身就是很好的后端证明。你要做的是* 把已经做过的事情讲清楚*，不是去背新东西。
边界：三层分法
层内容你的状态
必须会 Go 并发（GMP/channel/context/锁）、gRPC 与 Protobuf、Redis 缓存三兄弟 + 数据结构选型、Kafka 分区顺序性与消费语义、SQL 索引与事务隔离、微服务拆分的代价、容器与 K8s 基础简历里都做过，在实战手册第 6 章，约 30 个考点，逐个过一遍即可
知道就行 HTTP/2 与 SSE、连接池调优、限流熔断降级、分布式追踪、CAP 与最终一致能在被问到时说清楚原理和取舍，不用展开细节
完全不用准备 Spring 全家桶、JVM 调优、Dubbo、ZooKeeper、分布式事务的各种实现（Seata/TCC/Saga）、RPC 框架源码、MySQL 主从复制细节那是Java 后端岗的考纲，不是你的

标记	含义	建议
★★★	几乎必问 / 不会就是硬伤	必须能口头讲清楚
★★	常见，考察深度	要知道原理和取舍
★	加分项，考察广度	知道有这回事、能说个大概就够

章节	条数	对「AI 应用开发」的定位	怎么过
一 LLM 基础	48	核心	全过，每条要能讲 2 分钟
二 Prompt 工程	22	核心	全过，2.1 优先于 2.2
三 RAG	43	核心（命中率最高的一章）	全过，3.1–3.3 是重中之重
四 Agent	32	核心	全过，4.1 和 4.4 优先
七评估	20	核心，但最常被忽略	全过。多数候选人答不出”怎么评估”，这是拉开差距的地方
八 AI 工程化	25	核心	全过
十二系统设计	17	核心	全过，背下 12.3 的 checklist
五微调与对齐	29	部分	只过：LoRA 原理、什么时候该微调而不是 RAG、量化概念。对齐细节、压缩细节可跳
六推理与部署	25	部分	必看 6.1（KV Cache、连续批处理）和 6.3（成本）；6.2 服务化按你简历的深度看
十 Python	39	部分	10.3 工程实践最对口；10.1 只挑 GIL / asyncio / 深浅拷贝 / 装饰器 / pydantic。元类、描述符、`__new__`、迭代器协议这类”语言律师题”可跳
十三开放题	—	了解	略读，知道思路即可
十四行业认知	20	了解	14.1 模型选型、14.3「为什么做这行」必看；14.2 知道名词就行
九 ML/DL 基础	28	⚠️ 错配章节	见下方说明
十一算法	—	通用（与岗位无关）	校招必考，但不属于八股范畴，单独刷题

层	内容	你的状态
必须会	Go 并发（GMP/channel/context/锁）、gRPC 与 Protobuf、Redis 缓存三兄弟 + 数据结构选型、Kafka 分区顺序性与消费语义、SQL 索引与事务隔离、微服务拆分的代价、容器与 K8s 基础	简历里都做过，在实战手册第 6 章，约 30 个考点，逐个过一遍即可
知道就行	HTTP/2 与 SSE、连接池调优、限流熔断降级、分布式追踪、CAP 与最终一致	能在被问到时说清楚原理和取舍，不用展开细节
完全不用准备	Spring 全家桶、JVM 调优、Dubbo、ZooKeeper、分布式事务的各种实现（Seata/TCC/Saga）、RPC 框架源码、MySQL 主从复制细节	那是Java 后端岗的考纲，不是你的

一、LLM 基础与原理

1.1 Transformer 与注意力（★★★）

#	问题	要点
1	Self-Attention 在做什么	让序列中每个位置都能直接看到所有其他位置，按相关性加权聚合信息。解决 RNN 的长程依赖和串行问题
2	Q / K / V 的含义	Query 是当前位置”想找什么”，Key 是各位置”能提供什么”，Value 是”实际内容”。`softmax(QKᵀ/√d_k)V`
3	为什么要除以 √d_k	防止点积方差随维度增大而变大，把 softmax 推到梯度极小的饱和区。这是缩放点积注意力的由来
4	为什么要 Multi-Head	单个注意力头只能关注一种关系；多头让不同子空间并行捕捉语法、指代、语义等不同模式，最后拼接投影
5	Attention 的时间和空间复杂度	O(n²·d)，对序列长度 n 是平方级。这是长上下文成本高的根本原因
6	位置编码的作用	Attention 本身是置换不变的（打乱词序结果不变），必须显式注入位置信息
7	绝对位置编码 vs 相对位置	正弦编码（固定、可外推）、可学习编码（灵活、外推差）；RoPE 用旋转编码把相对位置信息编码进 Q/K，是目前主流；ALiBi 直接在注意力分数上加线性偏置
8	为什么主流是 Decoder-only	生成任务天然是自回归；训练效率高（所有 token 都参与 loss）；规模扩展性好。Encoder-Decoder（T5）在翻译等任务仍有优势
9	Layer Norm 的位置（Pre-LN vs Post-LN）	Post-LN 收敛快但深层易不稳定；Pre-LN 训练更稳定（现在主流），代价是最终效果略依赖调参
10	FFN 层的作用	对每个位置独立做非线性变换，提供模型的”知识存储”能力。参数量占比很大
11	残差连接的作用	梯度高速公路，缓解深层网络的梯度消失
12	为什么有之类的特殊 token	序列边界标记、任务分隔、padding 对齐、生成起始信号
13	前缀注意力 / Causal Mask	解码时屏蔽未来 token，保证自回归性质

1.2 预训练与训练（★★★）

#	问题	要点
14	预训练任务是什么	自回归语言建模（预测下一个 token）。本质是在海量文本上做无监督学习
15	为什么”预测下一个词”能产生智能	压缩即智能——要准确预测，模型必须学会语法、事实、推理、世界模型
16	Scaling Law	模型性能与参数量、数据量、计算量呈幂律关系。指导了”堆规模”的路线
17	数据质量为什么越来越重要	高质量 token 有限；重复低质数据收益递减；清洗、去重、配比成为核心竞争力
18	涌现能力（Emergent Abilities）	某些能力在规模跨过阈值后突然出现（如多步推理）。也有研究认为部分是评测指标不连续造成的假象
19	预训练 / 继续预训练 / 微调的区别	预训练从零学；继续预训练往已有模型里灌领域知识（数据量大、无标注）；微调改行为（数据量小、有标注）
20	指令微调（SFT）做什么	用「指令-回答」对训练，让模型从”续写”变成”听懂指令并回答”
21	灾难性遗忘	微调后旧能力退化。缓解：混合原始数据、低学习率、LoRA（只改少量参数）
22	混合精度训练	FP16/BF16 计算 + FP32 主权重。BF16 指数位多、不易溢出，大模型训练更常用
23	分布式训练 parallelism	数据并行（DP）、张量并行（TP，切矩阵）、流水线并行（PP，切层）、ZeRO（切优化器状态/梯度/参数）。大模型通常组合使用

1.3 Tokenizer 与上下文（★★★）

#	问题	要点
24	Token 是什么	模型的最小处理单位，不是字也不是词。常见 BPE 算法
25	BPE 的原理	从字符开始，反复合并出现频率最高的相邻符号对，直到词表达到目标大小
26	为什么中文 token 效率低	多数 tokenizer 以英文为主训练，中文常被切得碎，一个汉字可能占 1-2 个 token。直接影响成本和上下文预算
27	数字为什么会被切成多段	BPE 对数字的处理不一致，导致算术能力差。一些模型做了专门优化
28	上下文窗口是什么	模型单次能处理的最大 token 数（输入+输出）
29	超出上下文会怎样	直接报错，或从头部截断。需要自己做滑动窗口/摘要
30	“Lost in the middle”	长上下文中，模型对开头和结尾的信息利用更好，中间部分容易被忽略。这是长上下文应用的经典陷阱
31	输出长度也占上下文吗	占。输入 + 输出 ≤ 上下文窗口

1.4 解码与采样（★★★）

#	问题	要点
32	自回归生成的过程	逐个 token 生成，每次把已生成内容拼回去再预测下一个。O(n) 次前向，无法并行
33	temperature	缩放 logits 后再 softmax。低→分布尖锐→确定；高→分布平缓→多样。趋于 0 等价贪心
34	top-p（核采样）	只在累积概率达到 p 的最小候选集里采样。动态截断，比 top-k 灵活
35	top-k	只在概率最高的 k 个里采样。固定大小，分布平坦时可能截断过多
36	贪心 vs 采样	贪心确定性高但容易重复、呆板；采样有创造性但可能跑偏
37	repetition penalty	对已出现 token 的 logits 打折，抑制重复。过大会导致语句不通
38	为什么同样输入两次结果不同	采样随机性 + 服务端批处理导致的浮点非确定性
39	怎么保证结果可复现	temperature=0（贪心）+ 固定 seed。注意服务端仍可能有微小抖动
40	代码/工具调用场景怎么设	低温（0 或接近 0），要确定性
41	为什么需要 stop sequence	告诉模型什么时候停，避免它自顾自地继续生成

1.5 幻觉与局限性（★★★）

#	问题	要点
42	幻觉是什么	生成看似合理但与事实不符或无法从给定材料推出的内容
43	幻觉的根因	模型是概率续写而非查数据库；训练数据有噪声/过时；缺乏”我不知道”的选项
44	缓解幻觉的手段	① RAG grounding ② 要求引用来源 ③ 低温 ④ 自检/验证链路 ⑤ 工具调用代替直接回答（让模型算而不是猜）
45	模型为什么不会算术	本质是模式匹配不是计算。解法：让它生成代码再执行（工具调用），而不是直接答
46	知识时效性	预训练有截止日期，之后的事不知道。解法：RAG、联网搜索、继续预训练
47	模型的”自信的错误”	LLM 无法可靠表达不确定性。校准（calibration）是个开放问题
48	为什么不直接问模型”你对这个答案有多大把握”	自我报告置信度与实际准确率相关性弱。更可靠的做法是多次采样看一致性，或用外部验证

二、Prompt 工程

2.1 基础技巧（★★★）

#	问题	要点
49	好 prompt 的要素	角色设定 + 任务描述 + 上下文/输入 + 输出格式要求 + 约束条件 + 示例
50	Zero-shot vs Few-shot	Few-shot 给几个示例让模型理解格式和期望。通常能显著提升格式一致性
51	Few-shot 的注意事项	示例要有代表性、覆盖边界情况、顺序会影响结果（近因效应）、示例多了会挤占上下文
52	Chain-of-Thought（CoT）	让模型”说出推理过程”再给答案。显著提升多步推理正确率
53	为什么 CoT 有效	把复杂推理拆成中间步骤，每步更简单；中间 token 相当于给了模型更多”思考空间”
54	“Let’s think step by step”	Zero-shot CoT 的经典触发句，无需示例即可激活推理链
55	CoT 的代价	输出变长 → token 成本和延迟上升；简单任务上可能反而更差
56	Self-Consistency	采样多条推理路径，投票选最一致的答案。提升准确率的代价是 N 倍成本
57	Tree of Thoughts（ToT）★	把推理展开成树，搜索 + 回溯。适合需要探索的任务，成本很高
58	角色设定的作用	激活模型在特定领域的语料分布，影响语气和深度。对格式和风格影响明显，对事实准确性影响有限
59	分隔符的使用	用 ```、XML 标签、### 明确区分指令和数据。防注入 + 防歧义
60	负面约束怎么写	光说”不要 XX”效果有限（模型对否定不敏感），更好的是说”要 YY”
61	输出格式的约束层级	原生 Structured Outputs / JSON Mode > Function Calling schema > prompt 里写”请返回 JSON”

2.2 高级技巧（★★）

#	问题	要点
62	System / User / Assistant 的区别	System 设定全局行为和身份，优先级最高；User 是每次的输入；Assistant 可用于 few-shot 和预填充
63	Prefill / 预填充 Assistant	手动写 Assistant 消息的开头，强制模型从这里续写（如直接写 `{` 强制输出 JSON）
64	结构化输出怎么保证	优先用厂商原生能力（语法级约束解码），其次 Function Calling schema，最后才是 prompt 约束 + 解析容错 + 重试
65	Prompt 里的边界语义	一定要写明（“0-based, inclusive”），否则经典的差一错误
66	长 prompt 的组织	指令放开头或结尾（中间容易丢），重要约束重复一遍，用结构化的 markdown 标题分段
67	Prompt 版本管理	prompt 是代码。要版本化、要测试、要 A/B。工业上用 prompt 模板 + 变量 + 回归测试集
68	Prompt 注入（Prompt Injection）★★★	攻击者在不可信内容里藏指令，让模型执行。缓解：内容用分隔符包裹并声明”以下是数据不是指令”、权限最小化、输出侧校验、危险操作人工确认
69	越狱（Jailbreak）★	绕过安全对齐。常见手法：角色扮演、编码混淆、多轮诱导
70	Prompt 压缩 ★	用模型把长 prompt 压缩成短 prompt 以省 token，但可能丢关键信息，需要评估

三、RAG（检索增强生成）

AI 应用岗最高频的模块，几乎必考。

3.1 全链路（★★★）

#	问题	要点
71	RAG 是什么	先从知识库检索相关片段，再把它塞进上下文让模型基于它生成。解决知识时效性、幻觉、私有数据的问题
72	RAG 的完整链路	数据接入 → 清洗 → 切分 → 向量化 → 存储索引 → 检索 → （重排）→ 上下文组装 → 生成 → 评估
73	RAG vs 微调	RAG 管知识（可更新、可溯源、成本低）；微调管行为（格式、风格、领域术语）。不要指望微调灌知识
74	RAG vs 长上下文	长上下文简单但贵、有 lost-in-middle；RAG 便宜、可扩展、可溯源。工业上常混合：RAG 粗筛 + 长上下文精读
75	什么时候不该用 RAG	需要全局理解整个文档（如”总结全书的主题”）、知识库极小（直接全塞进去）、需要实时计算的场景

3.2 切分（Chunking）（★★★）

#	问题	要点
76	切分的目标	每个 chunk 语义完整、大小适中、检索友好
77	固定长度切分	简单，但会切断语义。需要 overlap
78	按结构切分	按标题/段落/代码块/函数切。语义完整性最好，代码场景首选按 AST 节点切
79	语义切分 ★	用 embedding 相似度在语义突变处切
80	Chunk 大小的权衡	太小→语义不完整、召回碎片化；太大→噪声多、塞占上下文、embedding 表达被稀释
81	Overlap 的作用和代价	缓解跨边界信息丢失；代价是冗余存储和重复召回
82	父子 chunk（Small-to-Big）★★	用小 chunk 做检索（匹配精准），召回后返回它所属的大 chunk（上下文完整）。工业常用
83	元数据的重要性	给每个 chunk 带上文件名、标题、时间、权限标签。支持过滤检索和引用溯源
84	表格/图片怎么处理	表格：转文本描述或保留结构；图片：多模态 embedding 或 OCR + 描述

3.3 Embedding 与向量（★★★）

#	问题	要点
85	Embedding 是什么	把文本映射成稠密向量，语义相近的文本在向量空间里距离近
86	相似度度量	余弦相似度（方向，最常用）、内积（含模长信息）、欧氏距离（L2 后与余弦等价）
87	为什么常用余弦	对向量长度不敏感，更注重方向语义，且归一化后点积计算快
88	Embedding 模型怎么选	看：语言支持（中文要选中文强的）、维度、最大输入长度、是否在权威榜单（如 MTEB）上表现好、推理成本
89	对称检索 vs 非对称检索	对称：query 和 doc 同构（相似句匹配）；非对称：query 短、doc 长（搜索）。要选对应训练目标的模型
90	向量维度的影响	维度高表达力强但存储/计算贵、索引效率低；维度低则相反。可做 Matryoshka（可截断）降维
91	向量数据库 vs 向量索引	pgvector（PG 插件，量小/已有 PG 首选）、Milvus/Qdrant（大规模、分布式）、FAISS（库而非服务，需自己封装）
92	ANN 索引：IVFFlat vs HNSW	IVFFlat：聚类倒排，构建快、内存小、查询需调 probes；HNSW：多层图，查询快、召回高，但构建慢、内存大
93	HNSW 的调参	`M`（每个节点的连接数）、`efConstruction`（构建时的搜索宽度）、`efSearch`（查询时宽度）。召回率与延迟的权衡
94	为什么 ANN 是”近似”	精确 KNN 在高维下退化为线性扫描（维度灾难），ANN 用召回率换速度
95	关键词检索为什么还重要 ★★★	向量是模糊语义匹配，精确标识符/错误码/专有名词上表现差。BM25 这类稀疏检索能精确匹配
96	BM25 原理	基于 TF-IDF 改进：词频饱和（k1）+ 文档长度归一化（b）
97	混合检索（Hybrid Search）★★★	稀疏 + 稠密双路召回，再用 RRF 或加权融合
98	RRF（Reciprocal Rank Fusion）	`score = Σ 1/(k + rank_i)`，k 常取 60。不需要归一化分数，避开了 BM25 分数无上界、余弦在 [0,1] 的尺度问题
99	只用向量的失败场景	搜”GetUserByID”时，`GetUserByName` 可能相似度极高 → 搜错。这就是 BM25 必须存在的理由

3.4 检索后处理（★★）

#	问题	要点
100	为什么需要 Rerank	向量检索（bi-encoder）为效率把 query 和 doc 独立编码，交互少、精度粗
101	Bi-encoder vs Cross-encoder	Bi：分别编码，可预先算 doc 向量，快；Cross：query+doc 拼接一起过模型，精度高但慢
102	两段式检索	向量召回 Top-50 → Cross-encoder 精排 Top-5。工业标准做法
103	上下文组装的注意点	去重、按相关性或原始顺序排、带上元数据、处理长度预算
104	Lost-in-middle 的缓解	把最相关的放开头和结尾；或用压缩/摘要减少总长度
105	引用溯源怎么做	生成时要求标注来源 ID，输出后校验引用的 chunk 是否真在上下文里
106	召回不到怎么办	查询改写（Query Rewriting）、HyDE（用 LLM 生成假设答案再检索）、多路查询、放宽过滤条件

3.5 高级 RAG（★）

#	问题	要点
107	Query Rewriting / 查询改写	用 LLM 把用户问题改写成更适合检索的形式（补全省略、消歧、多轮对话的指代消解）
108	HyDE	让 LLM 先生成一个”假想答案”，用这个答案去检索。利用答案-答案相似度
109	Multi-query / 多路查询	从多角度改写 query，各路召回后合并去重
110	Self-RAG ★	模型自己决定要不要检索、检索结果有没有用、要不要重新检索
111	GraphRAG ★	用知识图谱组织实体关系，适合”跨文档全局性问题”（如”这些文档里有哪些主要主题”）
112	Agentic RAG ★	把检索做成 Agent 的一个工具，由模型自主决定检索几次、检索什么
113	RAG 的评估	见第七章（RAGAS）

四、Agent 与工具调用

你的项目在这个方向，但这一章是 通用知识，不含你项目的内容。

4.1 Agent 范式（★★★）

#	问题	要点
114	什么是 LLM Agent	以 LLM 为决策核心，能自主规划、调用工具、观察结果、迭代直到完成目标的系统
115	Agent 的核心循环	感知 → 推理/规划 → 行动 → 观察 → 回到推理
116	ReAct	Reasoning + Acting 交替。每轮输出 Thought / Action / Observation
117	ReAct 的优缺点	优：能根据观察动态调整；缺：串行慢、上下文膨胀、错误会累积
118	Plan-and-Execute	先让 LLM 规划全部步骤，再逐步执行。适合步骤可预先分解的任务，但计划错了要 replan
119	Reflection / Self-Refine	生成 → 自我批评 → 修正。质量敏感场景有效，成本翻倍
120	Function Calling / Tool Calling	模型输出结构化的工具调用请求（名称 + 参数），由外部执行后把结果喂回
121	Tool Calling 和 ReAct 的关系	Tool Calling 是能力，ReAct 是使用这个能力的一种范式
122	Multi-Agent	多个角色（规划者/执行者/审查者/领域专家）协作。灵活但通信成本高、一致性难保证
123	Agent vs Workflow	Workflow 是预定义的有向图，确定性强、可控；Agent 由模型动态决策，灵活但不可控。工业上常是 Workflow 骨架 + Agent 节点
124	什么时候不该用 Agent	流程固定、要求确定性、延迟敏感、成本敏感的场景，用 Workflow 或直接编码

4.2 工具与环境（★★）

#	问题	要点
125	工具定义的关键	精确的 JSON Schema + 清晰的 description。description 是给 LLM 看的说明书，极其重要
126	工具数量多了怎么办	工具太多会让模型选择困难、prompt 膨胀。解法：分层/分组、按需动态加载、先做工具检索
127	参数 schema 写粗了的后果	模型可能把参数包成 `{"args": {...}}` 或格式错乱
128	工具调用失败的处理	把错误作为 Observation 喂回模型，让它自我纠正；而不是直接中断
129	并行工具调用	无依赖的工具调用可以并行发出，减少轮次
130	MCP（Model Context Protocol）★	模型与外部工具/数据源的标准化连接协议，解决”每个应用都要写一遍集成”的问题
131	代码执行类工具的安全	沙箱隔离、路径白名单、命令白名单、资源限额、危险操作人工确认
132	幂等性	工具重试不应产生副作用。设计上要支持重复执行

4.3 记忆与状态（★★）

#	问题	要点
133	短期记忆	上下文窗口内的对话历史
134	长期记忆	外部存储（向量库/KV），按需检索注入
135	上下文膨胀怎么办	滑动窗口（保留最近 N 轮）、摘要压缩、把历史存库按需召回
136	摘要压缩的注意点	保留关键决策和事实，丢弃寒暄；摘要本身也要存起来形成层级
137	多轮对话的指代消解	用户说”它怎么样”时，需要结合历史改写 query
138	会话状态持久化	存 DB，支持断线重连、跨设备、审计回放

4.4 可靠性与失控（★★★）

#	问题	要点
139	Agent 死循环的原因	工具反复返回同样结果、模型忘记已尝试、目标不可达
140	防失控的手段	迭代上限、token 预算、超时、重复调用检测（同参数 hash）、进展评估
141	达到上限怎么办	优雅退出并给出当前进展摘要，而不是抛异常
142	Agent 的可观测性	记录每一步的 thought/action/observation，支持回放和审计
143	Human-in-the-loop	高风险操作（删除、支付、外发）必须人工确认
144	Agent 的错误是累积的	早期工具错误会误导后续所有决策。要有回滚和检查点机制
145	怎么评估一个 Agent	单元层（工具选择/参数准确率）+ 任务层（端到端成功率、平均轮数、成本）+ 质量层（产物通过验证的比例）

五、微调与对齐

5.1 微调方法（★★★）

#	问题	要点
146	全参数微调 vs 参数高效微调（PEFT）	全参微调效果最好但显存和成本高、易灾难性遗忘；PEFT 只训少量参数，成本低、易切换
147	LoRA 原理	在原始权重旁挂一个低秩分解（A×B）的可训练旁路，`W' = W + BA`。冻结原权重，只训 A/B
148	LoRA 为什么有效	微调的增量本身是低秩的（内在维度低）。rank r 通常取个位数到几十
149	LoRA 的 rank 怎么选	小→表达能力弱；大→接近全参但成本上升。按任务复杂度调
150	QLoRA	LoRA + 4bit 量化基座模型。让消费级显卡也能微调大模型
151	Prefix Tuning / P-Tuning	在输入前加可学习的连续向量（soft prompt），只训这些向量
152	Adapter	在层间插入小模块，只训模块
153	微调需要多少数据	数量不是关键，质量和多样性才是。几百到几千条高质量样本常能改变行为
154	微调数据怎么造	人工标注（质量高、成本高）、用强模型蒸馏生成（常用）、从真实日志中挖掘
155	数据配比的重要性	混合通用数据防止遗忘；不同任务类型的配比影响很大
156	微调的过拟合表现	训练集 loss 很低但泛化差、输出变单调、丧失原有能力
157	什么时候该微调	需要特定输出格式/风格、需要压缩 prompt 省成本、小模型要追特定任务效果
158	什么时候不该微调	知识更新（用 RAG）、数据少且不稳定、需求还在快速变化

5.2 对齐（★★）

#	问题	要点
159	为什么要对齐	预训练模型只会续写，不会”有帮助、诚实、无害”地回答
160	RLHF 流程	SFT（学指令）→ 训练奖励模型 RM（学人类偏好）→ PPO 强化学习优化策略
161	RLHF 的难点	奖励模型容易被”钻空子”（reward hacking）、PPO 训练不稳定、超参敏感
162	DPO	直接在偏好数据上优化，跳过奖励模型。更简单稳定，目前主流
163	DPO vs PPO	DPO 离线、简单、稳定；PPO 在线探索、上限可能更高但工程复杂
164	其他对齐方法 ★	KTO（只需好/坏标签）、ORPO/SimPO（把偏好损失融进 SFT）
165	Reward Hacking	模型找到奖励模型的高分捷径但并非真的好。对齐的核心难题
166	Constitutional AI ★	用一套原则让模型自我批评和修正，减少对人工标注的依赖

5.3 模型压缩（★★）

#	问题	要点
167	量化的原理	用低精度（INT8/INT4/FP8）表示权重，减少显存和带宽
168	量化为什么能几乎不掉点	神经网络对权重精度不敏感（有冗余），关键在激活值的处理
169	训练后量化（PTQ）vs 量化感知训练（QAT）	PTQ 直接量化，快但损失大；QAT 训练时模拟量化，效果好但成本高
170	常见量化方案	GPTQ（逐层量化，GPU）、AWQ（激活感知，保重要权重）、GGUF/GGML（CPU/本地推理常用）
171	量化命名里的 Q4_K_M 是什么	GGUF 的量化格式：4 bit、K 系（混合精度）、M（中等）。不同后缀是质量/体积的权衡
172	蒸馏	用大模型（teacher）的输出训练小模型（student），把能力迁移过去
173	剪枝 ★	去掉不重要的权重或神经元。结构化剪枝才能真正加速
174	小模型 vs 大模型的取舍	小模型便宜、快、可端侧；大模型能力强。趋势是路由：简单的给小模型，难的给大模型

六、推理加速与部署

6.1 推理瓶颈与优化（★★★）

#	问题	要点
175	自回归生成的两个阶段	Prefill（一次性处理整个 prompt，计算密集）+ Decode（逐 token 生成，带宽密集）
176	为什么 Decode 慢	每生成一个 token 都要把全部权重从显存读一遍 → 访存带宽是瓶颈，不是算力
177	KV Cache 是什么	缓存已计算的 Key/Value，避免每步重算。用显存换时间
178	KV Cache 的代价	显存随 batch × 序列长度线性增长，是并发能力的主要限制
179	Continuous Batching（连续批处理）★★★	传统静态 batch 要等整批完成；连续批处理在请求完成时立即插入新请求，大幅提升 GPU 利用率
180	PagedAttention（vLLM 核心）★★	把 KV Cache 分成固定大小的块（像虚拟内存分页），消除碎片、支持共享前缀
181	前缀缓存（Prefix Caching）★★	相同前缀（如 system prompt）的 KV Cache 复用。对多轮对话和固定 prompt 场景收益巨大
182	Flash Attention ★	IO 感知的精确注意力算法，通过分块（tiling）减少 HBM 读写，显著省显存、提速度
183	投机解码（Speculative Decoding）★	小模型先快速生成草稿，大模型并行验证。在分布接近时显著加速
184	张量并行 / 流水线并行推理	单卡放不下时把模型切到多卡。TP 切矩阵（通信多、延迟低），PP 切层（通信少、有气泡）
185	常见推理框架	vLLM（连续批处理+PagedAttention，高吞吐）、SGLang（RadixAttention，前缀复用强）、TensorRT-LLM（NVIDIA 深度优化）、Ollama / llama.cpp（本地/CPU）

6.2 服务化（★★）

#	问题	要点
186	流式输出（SSE）	逐 token 返回，感知延迟大幅下降。AI 应用几乎必备
187	为什么用 SSE 不用 WebSocket 做输出	单向场景 SSE 更简单（HTTP 原生、自动重连、代理友好）；需要双向才用 WebSocket
188	长连接的超时设置	代理/Nginx/网关的默认超时会掐断长请求，需要单独配置
189	请求排队与优先级	GPU 资源有限，需要队列 + 超时 + 优先级
190	多模型路由	按任务难度/成本路由到不同模型
191	降级策略	主模型不可用 → 备模型 → 缓存 → 兜底回复
192	重试策略	指数退避 + 抖动；只对可重试错误（429/5xx/超时）重试，400 不重试
193	幂等与重试成本	重试会重复计费，需要幂等键或克制重试次数
194	批处理 API ★	非实时场景用批处理接口，成本显著更低

6.3 成本（★★★）

#	问题	要点
195	成本构成	输入 token + 输出 token（输出通常更贵）+ 请求次数
196	降成本手段	prompt 精简、缓存（前缀缓存/结果缓存）、小模型路由、批处理、缩短输出、减少 RAG 上下文
197	结果缓存	完全相同/语义相近的 query 直接返回缓存。注意 temperature=0 才有意义
198	为什么要监控 token	单个用户/接口的 token 消耗失控会直接烧钱。需要配额和告警
199	上下文长度与成本的关系	Attention 是 O(n²) 计算、KV Cache 是 O(n) 显存，长上下文不只是 token 贵

七、评估与 Benchmark

7.1 通用评估（★★★）

#	问题	要点
200	为什么 LLM 评估难	生成任务没有唯一正确答案；开放式任务的主观性；容易过拟合到评测集
201	客观指标	精确率/召回率/F1（分类、抽取）、完全匹配 EM（问答）、代码通过率 pass@k
202	BLEU / ROUGE	基于 n-gram 重叠。与人类判断相关性弱，尤其对生成任务。知道它们不适合评估开放式生成
203	语义相似度评估	用 embedding 算生成答案与参考答案的相似度。比 n-gram 好，但仍抓不住事实错误
204	LLM-as-a-Judge ★★★	用强模型按评分标准给生成结果打分。工业界主流，可扩展、与人类判断相关性较好
205	LLM-as-Judge 的坑	位置偏差（偏爱第一个）、长度偏差（偏爱长的）、自我偏爱（偏爱自己家的模型）。缓解：随机化顺序、成对比较、明确 rubric
206	人工评估	金标准，但贵、慢、一致性难保证（需要多人 + 算一致性系数）
207	常见基准 ★	MMLU（多学科知识）、HumanEval / MBPP（代码）、GSM8K / MATH（数学推理）、SWE-bench（软件工程任务）、MT-Bench / AlpacaEval（对话）
208	基准的局限	数据污染（测试集进了训练集）、刷榜过拟合、与真实业务场景分布不一致
209	业务指标才是最终标准	任务成功率、用户采纳率、人工修改率、耗时。离线指标只是代理

7.2 RAG 评估（★★）

#	问题	要点
210	RAG 该评什么	检索质量（召回率、精确率、MRR、NDCG）+ 生成质量（忠实度、相关性、准确率）
211	Faithfulness（忠实度）★★★	生成内容是否都能从检索到的上下文中推出。衡量幻觉
212	Answer Relevancy	答案是否切题
213	Context Precision / Recall	检索到的上下文中有用内容的比例 / 有用内容被检索到的比例
214	RAGAS ★	一套 RAG 自动化评估框架，核心指标就是上面几个
215	RAG 效果不好怎么定位 ★★★	分层排查：① 把正确答案塞进上下文，能答对 → 是检索的问题 ② Top-50 里有但 Top-5 没有 → 需要 Rerank ③ 上下文有但答错 → 是生成/prompt 的问题
216	怎么造评测集	从真实日志采样 + 人工标注；或用强模型生成 query-answer 对（注意质量）

7.3 Agent 评估（★★）

#	问题	要点
217	评估维度	工具选择准确率、参数正确率、端到端任务成功率、平均迭代轮数、token 消耗、失败模式分布
218	轨迹评估	不只看最终结果，还要看中间步骤是否合理
219	失败模式分类	工具选择错、参数错、陷入循环、提前终止、理解错需求

八、AI 应用工程化

8.1 应用层架构（★★★）

#	问题	要点
220	一个 AI 应用的典型分层	接入层 → 编排层（prompt 管理、Agent 循环、工作流）→ 能力层（检索、工具）→ 模型层（多模型路由）→ 基础设施（缓存、队列、可观测）
221	为什么需要编排层	解耦业务逻辑和模型调用；统一管理 prompt、重试、降级、缓存、成本
222	常见编排框架	LangChain / LangGraph（生态全、抽象重）、LlamaIndex（检索强）、Eino（CloudWeGo，Go 生态）、或自己写（可控性最好）
223	用框架 vs 自己写	框架快、生态全，但抽象泄漏、调试难、版本变化快；自己写可控但重复劳动。建议：核心链路自己写，通用组件用库
224	Prompt 管理	模板化 + 版本化 + 变量注入 + 回归测试。不要硬编码在代码里
225	模型抽象层	统一接口封装多家厂商，便于切换和降级
226	幂等与重试	LLM 调用可能超时但实际已执行，重试要能识别
227	异步化	长任务用队列 + 回调/轮询，不要阻塞 HTTP 请求

8.2 可观测性（★★）

#	问题	要点
228	AI 应用要观测什么	延迟（首 token / 总时长）、token 消耗、成本、错误率、工具调用成功率、用户反馈
229	Tracing 的重要性	一次请求可能经过多次 LLM 调用 + 多次检索 + 多次工具调用。没有链路追踪根本没法排查
230	要记录什么	完整的 prompt（含变量渲染结果）、模型参数、响应、耗时、token 数
231	隐私与合规	日志里可能有用户敏感数据，需要脱敏和访问控制
232	用户反馈闭环	点赞/点踩 → 收集 bad case → 迭代 prompt/检索/路由

8.3 安全与合规（★★★）

#	问题	要点
233	Prompt 注入	见 #68。OWASP LLM Top 10 的第一位
234	数据泄露风险	用户输入进模型 → 可能被用于训练；RAG 检索到越权文档
235	越权访问	RAG 必须做权限过滤，不能检索到用户无权查看的内容
236	输出内容安全	输入输出都要有内容审核
237	PII 处理	敏感信息脱敏后再发给模型
238	数据出境	用境外模型服务时的数据合规问题
239	模型本身的不确定性带来的责任	需要有人工审核环节，尤其是高风险决策

8.4 交互体验（★★）

#	问题	要点
240	流式输出	几乎是标配。首 token 时间是关键体验指标
241	中间状态展示	展示”正在检索""正在思考""调用了 XX 工具”，降低等待焦虑
242	中断与取消	用户能随时中止，服务端要能真正取消（context 传播）
243	失败兜底	模型不可用时的降级文案，不要让白屏
244	结果可编辑	AI 输出通常不是最终结果，要方便用户修改

九、机器学习 / 深度学习基础

⚠️ 本章是算法工程师 / 数据挖掘岗的考纲，对 AI 应用开发岗属于错配章节。 见开头「这份清单要裁着看」。 只看 261（AdamW）和 264（LN vs BN）两条即可，其余扫一眼知道有这回事就行，不必花时间补。

9.1 机器学习基础（★★）

#	问题	要点
245	监督/无监督/半监督/强化学习	有无标签；RL 是通过奖励信号学习
246	过拟合与欠拟合	过拟合：训练好测试差（记住了噪声）；欠拟合：两边都差（模型太简单）
247	解决过拟合	更多数据、数据增强、正则化（L1/L2）、Dropout、早停、简化模型、集成
248	L1 vs L2 正则	L1 产生稀疏解（可做特征选择）；L2 让权重整体变小（更平滑）
249	Bias-Variance 权衡	模型复杂度上升，偏差下降、方差上升。要找最优点
250	交叉验证	充分利用数据评估模型，避免单次划分的偶然性
251	分类指标	精确率（查准）、召回率（查全）、F1（调和平均）、ROC-AUC（排序质量）
252	精确率和召回率的权衡	取决于业务代价。疾病筛查要召回，垃圾邮件要精确率
253	类别不平衡怎么办	重采样、类别权重、换评估指标（看 PR 曲线而非 ROC）、换阈值
254	特征工程	归一化/标准化、编码、缺失值处理、分箱。传统 ML 的核心
255	常见传统模型	逻辑回归、决策树、随机森林、XGBoost/LightGBM、SVM
256	为什么表格数据上树模型常优于深度学习	结构化数据、样本量不大、特征有明确含义时，树模型更鲁棒、可解释、训练快

9.2 深度学习基础（★★）

#	问题	要点
257	前向传播与反向传播	前向算输出；反向按链式法则算梯度并回传
258	梯度消失/爆炸	深层连乘导致梯度趋 0 或爆炸。缓解：残差连接、Layer Norm、合适初始化、梯度裁剪
259	激活函数	ReLU（简单快，但有 dying ReLU）、GELU（Transformer 主流，平滑）、Sigmoid（输出压到 0-1，用于门控）
260	损失函数	交叉熵（分类）、MSE（回归）、对比损失（embedding 训练）
261	优化器	SGD（简单，泛化好）、Adam/AdamW（自适应学习率，Transformer 标配。AdamW 修正了 weight decay 的实现）
262	学习率调度	Warmup（先小后大，稳定训练初期）+ 余弦衰减（后期精细收敛）。大模型训练标配
263	Batch Size 的影响	大 batch 训练稳、并行效率高，但泛化可能变差、显存大
264	Batch Norm vs Layer Norm	BN 在 batch 维度归一化（不适合变长序列、依赖 batch size）；LN 在特征维度归一化（Transformer 用）
265	Dropout	随机置零部分神经元，防止过拟合。推理时不生效
266	CNN 的核心思想	局部感受野 + 权重共享 + 平移等变性。适合图像
267	RNN/LSTM 的局限	串行无法并行、长程依赖衰减。这是 Transformer 取代它的原因
268	迁移学习	用预训练模型在小数据上微调。深度学习的默认范式

9.3 多模态（★）

#	问题	要点
269	多模态大模型怎么做	把图像/音频编码成 token 序列，和文本 token 拼在一起进 Transformer
270	CLIP 类模型 ★	图文对比学习，把图像和文本映射到同一向量空间。是图文检索和文生图的基础
271	视觉 token 的成本	图片会占大量 token，成本远高于纯文本
272	OCR 在多模态 RAG 里的位置	扫描件/表格仍需 OCR，且 OCR 质量直接决定 RAG 上限

十、Python 与工程基础

AI 应用岗的 主语言。Go 岗写 Go，AI 岗写 Python，两边都要能写。
⚠️ 本章 39 条里混了两类东西，别平均用力：
对口的部分：10.3 工程实践（httpx 流式、Semaphore 限流、pydantic 校验、tenacity 重试） 全部要看，这些直接对应 AI 应用开发的日常工作；10.1 里的 GIL、asyncio、生成器、深浅拷贝、装饰器、pydantic 也是高频。
“语言律师题”：元类、描述符、__new__ vs __init__、迭代器协议、is vs ==—— 可以跳过。这些是通用 Python 岗的考点，AI 应用岗几乎不问，问了也区分不出人，还会挤占你准备 RAG 和 Agent 的时间。

10.1 Python 语言（★★★）

#	问题	要点
273	GIL 是什么	全局解释器锁，同一时刻只有一个线程执行 Python 字节码。限制了 CPU 密集型的多线程并行
274	GIL 的影响与绕过	IO 密集不受影响（等待时释放 GIL）；CPU 密集用多进程（multiprocessing）或 C 扩展（numpy 就绕过了）
275	多线程 vs 多进程 vs 协程	线程：IO 密集、共享内存；进程：CPU 密集、隔离；协程（asyncio）：高并发 IO、单线程切换
276	asyncio 的核心	事件循环 + `await` 让出控制权。避免在协程里用阻塞调用，会卡死整个循环
277	生成器与 yield	惰性求值，节省内存。`yield from` 委托给子生成器
278	装饰器	接收函数返回函数的高阶函数，用 `@` 语法糖。要会写带参数的装饰器（三层嵌套）
279	`functools.wraps` 的作用	保留原函数的 `__name__`、`__doc__`。不加会让被装饰函数”改名”
280	深拷贝 vs 浅拷贝	浅拷贝只复制一层，嵌套对象仍共享；深拷贝递归复制全部。循环引用需要特殊处理
281	可变默认参数的坑	`def f(a, lst=[])` 的 `lst` 在函数定义时创建一次，被所有调用共享。用 `None` 做哨兵
282	闭包与 late binding	循环里创建的闭包会共享同一个变量。用默认参数绑定：`lambda x=i: x`
283	`args` / `*kwargs`	位置参数打包成 tuple，关键字参数打包成 dict
284	迭代器协议	`__iter__` + `__next__`。`for` 循环的本质
285	上下文管理器	`__enter__` / `__exit__`，或 `@contextmanager`。保证资源释放
286	`__new__` vs `__init__`	`__new__` 创建实例（控制实例化，如单例），`__init__` 初始化
287	描述符与 property	控制属性访问。`@property` 让方法变成属性
288	元类 ★	类的类。控制类的创建行为。框架里常见，业务代码少用
289	类型注解	提示性的，运行时不校验。配合 mypy 做静态检查。Python 3.10+ 的 `X\| Y` 联合类型
290	dataclass	自动生成 `__init__`/`__repr__`/`__eq__`。定义数据类首选
291	pydantic	运行时数据校验和序列化。AI 应用里做结构化输出校验的标配
292	内存管理与垃圾回收	引用计数为主 + 分代回收处理循环引用
293	列表 vs 生成器	列表占内存但可重复遍历、可索引；生成器省内存但只能遍历一次
294	`is` vs `==`	`is` 比身份（内存地址），`==` 比值。小整数有缓存所以 `1 is 1` 为 True
295	字典的实现	哈希表。Python 3.7+ 保证插入顺序
296	常用标准库	`collections`（defaultdict/Counter/deque）、`itertools`、`functools`（lru_cache/reduce）、`dataclasses`、`concurrent.futures`

10.2 数据科学生态（★★）

#	问题	要点
297	numpy 的核心	多维数组 + 向量化运算（底层 C，绕过 GIL 且快）
298	broadcasting	形状不同的数组自动扩展对齐再运算。避免写 Python 循环
299	view vs copy	切片返回 view（共享内存），`copy()` 才是真拷贝。改 view 会影响原数组
300	pandas 常用操作	`groupby` / `merge` / `pivot` / `apply`。注意 `apply` 慢，优先向量化
301	链式索引的坑	`df[df.a>1]['b'] = 1` 可能改不动（链式赋值）。用 `.loc`
302	虚拟环境	venv / conda / poetry / uv。隔离依赖，必会
303	Jupyter 的定位	探索和实验；生产代码要落到 .py 文件

10.3 工程实践（★★）

#	问题	要点
304	HTTP 客户端	`requests`（同步）、`httpx`（同步+异步，AI 应用常用）、`aiohttp`
305	流式响应怎么处理	`httpx` 的 `stream()` + 迭代 `iter_bytes()`；注意 SSE 的 `data:` 格式解析
306	异步调用 LLM SDK	厂商 SDK 通常提供 Async 客户端，配合 `asyncio.gather` 并发
307	并发调用多个 LLM 的限流	`asyncio.Semaphore` 限制并发数
308	重试库	`tenacity`（功能全、装饰器形式好用）
309	结构化输出校验	pydantic + `instructor` 之类的库（把 LLM 输出直接校验成 pydantic 对象）
310	测试	pytest；mock LLM 调用（不要真调 API）；用 VCR 录制回放
311	依赖管理	requirements.txt / pyproject.toml；锁定版本

十一、数据结构与算法

校招必考。这里给 高频清单，不展开解法。

11.1 必刷清单（★★★）

数组 / 字符串

两数之和（哈希）
滑动窗口（最长无重复子串、最小覆盖子串）
二分查找（含边界写法、旋转数组、搜索插入位置）
前缀和 / 差分
双指针（三数之和、盛水容器、接雨水）
原地哈希、快慢指针

链表

反转链表（全反转 / 部分反转 / K 个一组）
环形链表检测（快慢指针）
相交链表、合并有序链表、删除倒数第 N 个
LRU 缓存（哈希 + 双向链表） ——AI/后端都爱考

栈 / 队列 / 堆

单调栈（下一个更大元素、柱状图最大矩形）
优先队列（Top-K、合并 K 个有序链表、数据流中位数）
用栈实现队列 / 用队列实现栈

树

二叉树的四种遍历（递归 + 迭代）
层序遍历（BFS）
二叉搜索树的性质与验证
最近公共祖先 LCA
前缀树 Trie（字符串检索、自动补全）

图

BFS / DFS
拓扑排序（课程表、依赖解析） —— Agent 任务依赖能用上
并查集
最短路径（Dijkstra / BFS 无权图）

动态规划

背包问题（01 / 完全）
最长递增子序列、最长公共子序列、编辑距离
打家劫舍、股票买卖系列
区间 DP、状态压缩 DP（了解）

其他高频

回溯（全排列、子集、N 皇后、组合总和）
贪心（区间调度）
位运算
快排 / 归并 / 堆排（要能手撕，并说清复杂度、稳定性、是否原地）

11.2 复杂度（★★★）

#	要点
312	常见数据结构操作复杂度：数组随机访问 O(1)、插入删除 O(n)；链表插入删除 O(1)、访问 O(n)；哈希表平均 O(1)、最坏 O(n)；平衡树 O(logn)；堆插入删除 O(logn)、取最值 O(1)
313	排序算法：快排平均 O(nlogn) 最坏 O(n²) 不稳定；归并 O(nlogn) 稳定但需 O(n) 空间；堆排 O(nlogn) 不稳定原地；冒泡/插入/选择 O(n²)
314	递归的复杂度分析：主定理（Master Theorem）
315	空间复杂度要算递归栈

11.3 AI 场景可能长出来的算法题（★）

#	题目	考点
316	手撕 BM25 / 倒排索引	哈希 + 排序 + 统计
317	手撕 LRU / LFU	哈希 + 双向链表
318	手撕令牌桶限流	时间差计算
319	Top-K（从大文件找最大 K 个）	小顶堆
320	实现一个简单的 ReAct 循环	状态机 + 错误处理
321	文本相似度计算（Jaccard / 余弦）	集合运算 / 向量
322	实现 Trie 做前缀提示	树

十二、系统设计（AI 场景）

校招通常是 简化版，15-25 分钟。重点是 结构化表达和 取舍意识，不是完美方案。

12.1 通用答题框架（★★★）

五步法：

澄清需求：用户量、QPS、延迟要求、准确性要求、数据规模、成本约束
顶层架构：画出分层，说清数据流向
核心模块深入：挑 1-2 个难点展开（通常是检索、缓存、异步）
瓶颈与扩展：哪里先挂？怎么扩容？
权衡总结：你放弃了什么、为什么

💡 不要一上来就堆组件。先把”要解决的矛盾”说出来，再给方案。

12.2 高频 AI 设计题（★★）

#	题目	核心考点
323	设计一个文档问答系统（企业知识库）	文档解析 → 切分 → embedding → 向量库 + BM25 混合检索 → rerank → 生成 → 引用溯源；权限过滤；增量索引
324	设计一个智能客服	意图识别 → 知识库 RAG / 业务 API 工具调用 → 多轮对话管理 → 人工接管；拒答机制
325	设计一个 AI 代码助手（补全 / Chat）	仓库索引（AST + 检索）、上下文组装策略、低延迟要求、流式输出、安全沙箱
326	设计一个联网搜索问答	查询改写 → 搜索 API → 页面抓取解析 → 内容提取 → 摘要 + 引用
327	设计一个高并发 LLM API 网关	多模型路由、限流、缓存（前缀 + 结果）、队列、降级、成本统计、流式透传
328	设计一个多模态内容审核系统	异步流水线、分级（规则 → 小模型 → 大模型）、人机协同、误杀与漏放的权衡
329	设计一个推荐 / 召回系统（结合 LLM）	传统召回 + LLM 做重排或特征增强；LLM 的延迟决定了它只能在离线或重排层
330	设计一个 AI 应用的评测平台	评测集管理、批量跑批、多维指标（含 LLM-as-judge）、对比实验、结果可视化

12.3 设计里必须想到的点（★★★）

#	要点
331	延迟预算分解：检索 + LLM 首 token + 生成。流式能把感知延迟降下来
332	LLM 延迟不可控：长任务必须异步化（队列 + 回调/轮询）
333	缓存分层：结果缓存（完全相同 query）→ 前缀缓存（同 system prompt）→ 检索缓存
334	限流与配额：按用户、按接口；GPU 是稀缺资源
335	降级链路：主模型 → 备模型 → 缓存 → 规则兜底
336	权限过滤：RAG 检索必须带权限，不能越权召回
337	成本监控：token 消耗要有配额和告警
338	可观测：一次请求多次模型调用，必须有 trace
339	数据闭环：用户反馈 → bad case → 迭代

十三、开放题与思维题

这类题没有标准答案，考察的是 结构化思考和诚实。

#	问题	回答思路
340	你觉得 LLM 目前最大的局限是什么	选一个你有体会的角度（幻觉/不确定性/成本/长程规划/无法真正学习新知识），讲清楚为什么、举一个具体例子、说你觉得短期能缓解到什么程度
341	如果让你做一个 XX 场景的 AI 产品，你怎么设计	先问清楚用户和场景；不要上来就谈技术；说清”为什么这里需要 LLM”而不是规则
342	RAG 和长上下文，未来哪个会赢	不要二选一。讲各自的适用边界，说工业上会混合
343	Agent 能取代 Workflow 吗	谈确定性 vs 灵活性；说清楚在什么约束下选哪个
344	你怎么判断一个需求该不该用 LLM	看：是否有明确的规则解法（有就用规则）、是否容忍不确定性、成本是否划算、是否有兜底
345	模型输出错了，用户投诉，你怎么排查	分层：是检索错了（召回/排序）→ 是上下文组装错了 → 是 prompt 错了 → 是模型能力不足。每一步都要有可验证的手段
346	你怎么跟进这个领域的发展	说具体的信息源和习惯（论文/官方博客/开源项目/自己动手跑）。别说”看公众号”
347	你最近关注的 AI 方向是什么	选一个你真能讲 3 分钟的方向，讲清楚：解决什么问题、主流做法、难点在哪
348	小公司/创业团队和大厂做 AI 应用的区别	讲资源约束、迭代速度、数据、工程基建的差异，不做优劣评判

十四、行业认知

⚠️ 这一章只给判断框架，不列具体版本和排名 —— 模型迭代极快，任何具体数字在几个月内就会过时，面试时说错反而扣分。实际信息请以官方最新公开资料为准。

14.1 模型选型（★★）

#	思考维度
349	能力维度：任务类型（推理/生成/代码/多模态）、指令遵循能力、上下文长度、语言支持（中文表现）
350	成本维度：输入/输出价格、是否有批处理折扣、是否有免费额度
351	工程维度：延迟、可用性、限流策略、是否有结构化输出/函数调用等原生能力、SDK 成熟度
352	合规维度：数据是否出境、是否支持私有化部署、服务条款对数据的约定
353	开源 vs 闭源：开源可私有化、可定制、数据安全，但要自己扛部署和运维；闭源开箱即用、能力通常领先，但数据在外部、有供应商锁定
354	不要给模型排名：可以说”在我测的 XX 任务上，A 的表现是……B 是……”，不要说”A 比 B 好”
355	路由策略比单一选型更实际：简单任务用小模型、难任务路由到大模型，是工业上更常见的做法

14.2 热点方向（知道名词 + 能说原理即可）（★）

#	方向	一句话
356	推理模型 / 思维链强化	训练模型在回答前生成长链推理，在数学/代码/复杂推理上提升明显，代价是 token 和时间
357	Test-time Compute	推理时多花算力（ longer thinking / 多次采样投票）换效果，是新的 scaling 维度
358	Agentic Coding	从补全走向自主完成工程任务（读仓库、改多文件、跑测试）
359	MCP / 工具生态标准化	让工具集成从”每个应用写一遍”变成”一次接入到处可用”
360	端侧小模型	手机/PC 上跑，隐私好、零延迟、离线可用，能力有限
361	多模态	图文音视频统一建模；成本和理解能力仍在爬坡
362	长上下文	从”能塞多少”走向”塞进去真的用得上”（解决 lost-in-middle）
363	AI 安全与对齐	注入攻击、越狱、数据泄露、可控性
364	模型蒸馏与小模型	用小成本模型逼近大模型在特定任务上的效果

14.3 你要能回答的”为什么做这行”（★★★）

#	问题	建议
365	为什么选 AI 应用开发	说一个具体的触发点（做某个项目时的某个发现），而不是”前景好”。面试官一天听二十遍”前景好”
366	你觉得 AI 应用开发的核心难点是什么	好的答案方向：不确定性工程化（怎么让概率系统可靠）、评估（怎么知道它变好了）、成本与效果的平衡
367	你觉得自己比别人强在哪	结合你的具体经历说，别说”学习能力强”这种无法验证的话
368	你的职业规划	短期讲”想补什么”，长期讲”想深到什么方向”。不要给具体年限和职级

附录：冲刺优先级

这是按「AI 应用开发岗 + 你的简历（Go 后端栈 + 两个 AI/微服务项目）」重排的，和章节顺序无关。

第一梯队 — 不会就是硬伤

一 LLM 基础：Transformer 与注意力、tokenizer、采样参数、 幻觉成因
三 RAG 全链路：切分策略、embedding 选型、混合检索、rerank
四 Agent：ReAct、Tool Calling 原理、 4.4 防失控
七评估： 这一章最容易被忽略，也最容易被问倒——RAG 分层排查、LLM-as-Judge、怎么判断改动是变好还是变差
八工程化：分层架构、可观测、Prompt Injection
十二系统设计：把 12.3 的 checklist 背下来，任何 AI 场景题都能套

第二梯队 — 拉开差距

二 Prompt 的 2.2 高级技巧（CoT、few-shot、自我一致性）
五微调： 只过 LoRA 原理 + 什么时候该微调而不是 RAG（后者是高频决策题）
六推理：KV Cache、连续批处理、6.3 成本
十 Python：10.3 工程实践（httpx 流式、Semaphore 限流、pydantic 校验）+ GIL / asyncio
十四行业认知：14.1 模型选型、 14.3「为什么做这行」（必考动机题）

第三梯队 — 有余力再看

三的 3.5 高级 RAG
五的 5.2 对齐、5.3 压缩
十三开放题
十四的 14.2 热点名词（知道名词和一句话原理即可）

不属于这份清单的准备范围

内容	去哪准备
九 ML/DL 基础	跳过——算法岗考纲，不是你的方向（例外：261 AdamW、264 LN vs BN）
十一算法与手撕	校招必考，但看清单没用，要上题库刷题
传统后端（Go/Redis/Kafka/SQL）	见《面试实战手册》第 6 章，约 30 个考点，都是你简历上已有的

时间预算

你有多少时间	怎么分配
2 小时（临阵）	只扫第一梯队的 ★★★，每章 20 分钟，扫完标 🔴
半天	第一梯队全过 → 二 Prompt 2.2 → 五 LoRA → 六 KV Cache 与成本
1–2 天	一二三四七八十二全过 → 第二梯队 → 实战手册第 6 章后端 30 考点
一周以上	全过 + 第三梯队 + 算法刷题 + 后端系统补

判断标准：不要追求”过完了”，要追求”扫完知道自己哪里不会”。368 条里你大概率有 200 条已经会了， 真正需要补的可能只有 40–60 条——那才是你该花时间的地方。