题 1：设计一个 AI Copilot（代码/写作助手）#

答题骨架（按这个顺序讲，别跳）：

1. 先问清楚：单轮补全还是多轮对话？延迟要求（首 token < 500ms 还是 2s 可接受）？要不要引用上下文里的代码？
2. 输入侧：上下文组装——当前光标位置 ± N 行 + 打开的文件摘要 + 项目级符号表。别把整个 repo 塞进去，用 retrieval 先缩到相关文件再拼。
3. 生成侧：流式输出是刚需。后端用 SSE，模型侧一旦出 token 就往前端推，别等整句。
4. 中断/续写：用户打字时要能中断上一个请求——前端 AbortController，后端要感知客户端断开（很多框架默认不感知，是个坑）。
5. 落库：采纳率（accept rate）必须埋点，这是 Copilot 类产品唯一重要的北极星指标。

加分点：主动提「补全建议要做去重和去抖（debounce），否则用户每敲一个字就发一次请求，token 账单和延迟都会爆」。这一句证明你真的上线过。

题 2：设计一个企业知识库 RAG 系统#

骨架： ingestion（解析→切分→embedding→入库）+ query（改写→混合召回→重排→生成→溯源）。

面试官会追问的，永远是这三层：

• 多租户：向量库怎么按租户隔离？是物理分库、逻辑分 collection，还是 metadata 过滤？三者成本和隔离强度完全不同，得说出取舍。
• 权限：召回阶段就按用户权限过滤，还是生成前再过一遍？前者快但容易漏，后者安全但 token 浪费。正确答案是两者都做，召回粗筛 + 生成前精筛。
• 更新：文档改了，旧 embedding 怎么办？版本号 + 软删除，还是定时重建？增量更新比全量重建难十倍，说出来。

RAG 的检索召回、切分、评估的细节八股，见 《AI 开发岗面试速查》，这里不重复。

题 3：设计一个 AI 客服#

这一题考的是「AI 和人的协作」，不是纯 AI 能力：

• 人工接管（human handoff）：什么信号触发转人工？（用户连说两次”转人工”、模型置信度低于阈值、检测到情绪）。转过去要把完整上下文给到人工，别让用户重说一遍。
• 会话存储：用什么存？会话很长，关系库存 JSON 字段还是文档库？历史消息怎么裁剪进上下文（滑动窗口 + 摘要）？
• 成本：每个会话 token 预算上限，超了强制降级到更便宜的模型或模板回复。
• 合规：通话记录要不要脱敏？PII 识别在入库前还是入库后？

一句话总结三题：系统设计题答得好，靠的不是知道多少名词，而是你主动说出每一层的取舍和坑。面试官每追问一层，你都早一步说「这里有个坑，我们是这么填的」——这才有全栈味。

1. 长上下文 vs RAG，怎么选#

别再说「长上下文时代 RAG 要死了」这种话——面试官一听就知道你没做过。

正确回答：两者不互斥。长上下文（把 100 万 token 一次性塞进去）解决「一次性把材料给模型」，RAG 解决「选择性把材料给模型」。区别是：

• 全量塞进上下文：答案完整，但每次请求都付费、每次都重新算 KV cache，成本线性涨。适合低频、高价值、材料固定的场景（比如合同审查）。
• RAG：只召回相关片段，成本低、可扩展到 TB 级，但召回不准就答错。适合大规模、高频、材料动态更新的场景。

工程上常见做法：RAG 粗筛 + 长上下文兜底——先 recall top-K 扩大召回，再连同上下文一起塞进长上下文模型，让模型自己挑。这叫 hybrid，不是非此即彼。

2. 成本治理#

AI 应用的成本不治理，三个月账单能翻十倍。四个杠杆，按投入产出排序：

1. Prompt 缓存：系统提示、few-shot 示例这些不变的部分，用 provider 的 prompt caching。命中率高的应用能省 80%+ 输入成本。注意 cache TTL——各 provider 不同，跨 TTL 请求等于全量重算。
2. 模型分级路由：简单问题走小模型，难题走大模型。用一个小模型或分类器做意图判定，再决定后端用哪个。这一招省得最多。
3. 上下文裁剪：历史对话别无限累积，滑动窗口 + 摘要压缩。每多 1k token 的历史，每次请求都多付一份钱。
4. 结果缓存：相同或语义相似的 query，直接返回缓存，不打模型。query 归一化（去标点、转小写、同义词归并）能显著提高命中率。

面试加分：主动说「我们会给每个用户/租户设 token 预算，超了降级而不是报错——AI 功能不能因为一个用户把整月配额烧光」。

3. 可观测性：trace 一次请求穿过整条链#

普通应用的 trace 是「HTTP → DB」。AI 应用的 trace 是「HTTP → 意图分类 → 向量召回 → Rerank → Prompt 组装 → LLM → 工具调用 → 后处理 → 返回」，每一步都可能出错，每一步都要能看见。

必须埋的：

• 每一步的耗时和 token 消耗（不是总耗时，是分步的，否则不知道卡在哪）。
• 召回的 chunk 内容（线上答错了，你得能回放看见当时召回了什么）。
• 模型的原始输出（在后处理之前），否则你永远不知道是模型答错还是你的后处理改错了。
• 工具调用的入参出参（Agent 场景，工具参数填错是最高频 bug）。

工具上，LangSmith、Langfuse、Helicone 都行，重点不是选哪个，而是你能不能解释一次线上 bad case 的完整回放路径。面试官追问「线上答错了你怎么排查」，你拿不出 trace 体系就输了。

4. 评测：离线和线上两套#

• 离线：固定评测集，每次改 prompt、换模型、调召回策略都跑一遍。指标分检索（Recall@K、MRR）和生成（忠实度、答案相关性），别混在一起评。评测集必须有，哪怕只有 50 条真实问题，比 500 条合成数据强。
• 线上：点踩率、重问率、人工接管率、会话时长。重问率是最敏感的信号——用户重新问同一个问题，基本就是上次答得不行。

5. 模型替换的抽象层#

面试官爱问：「明天 GPT/Claude 涨价或者出新模型，你要多久能切？」

错误回答：「我们直接调 SDK」。正确回答：在业务代码和模型之间加一层抽象。输入归一化成自己的 schema，输出归一化成自己的 schema，provider 切换只改适配层。再加一个影子流量（shadow traffic）机制：新模型先接 5% 流量并行跑，对比输出质量，没问题再切。

这个答案证明你考虑过 provider lock-in，而且真的做过迁移。

前端#

• 流式渲染：LLM 输出是 token 流，前端要做增量 Markdown 渲染。坑在边界——token 可能切在一个 Markdown 标记中间（比如 ``` 被切成两半），直接渲染会闪烁或错乱。要么缓冲到完整语法单元再渲染，要么用能容忍不完整输入的 Markdown parser。
• XSS：模型输出里有用户的富文本，别用 dangerouslySetInnerHTML 直接渲染。Markdown → HTML 后必须过 sanitizer（DOMPurify）。模型输出和用户输入同级，都是不可信的——这条心智是 AI 前端安全的全部。
• 中断：流式请求要能中断，AbortController 是标配。中断后已经渲染的内容留还是删，是个产品决策，但技术上必须支持。

后端#

• 并发控速：LLM provider 都有 RPM（每分钟请求数）和 TPM（每分钟 token 数）双限制。你的网关要做令牌桶限流，而且要按 token 预估提前限流，不是请求发出去了才被 provider 429。被 429 后的退避重试要带抖动，否则雪崩。
• 幂等：用户重试同一个请求，别真的再调一次模型（贵 + 慢）。用请求 ID 做幂等键，缓存结果。
• 异步：长任务（批量生成、长文档处理）别让 HTTP 一直挂着，拆成「提交任务 → 轮询/Webhook 取结果」。用任务队列，别用线程池硬扛。

数据库与向量库#

• 向量索引选型：HNSW（图，查询快、内存大、构建慢）vs IVF（倒排，内存小、查询稍慢、可量化）。别无脑选 HNSW——百万级以下它最快，但内存吃得多；上亿级时 IVF+PQ 更现实。说出这个取舍。
• 会话存储：会话消息别只存最新一轮。完整历史 + 摘要分两张表，历史用于回放和训练，摘要用于快速装上下文。
• Embedding 模型升级：换 embedding 模型 = 全量重新 embedding，旧索引不兼容。这是个大坑——要么双索引灰度迁移，要么一开始就把 embedding 模型版本写进索引元数据。

部署与运维#

• GPU/CPU 分层：embedding、rerank 可能要 GPU，普通业务后端 CPU 即可。别把所有服务都塞进 GPU 节点，贵得离谱。
• 灰度：AI 功能改 prompt、换模型都属于「逻辑变更」，必须灰度，不能全量上。A/B + 质量监控指标。
• 回滚：模型权重、prompt 版本都要能回滚。只回滚代码不回滚模型/prompt = 没回滚。

Prompt 怎么版本管理#

很多人把 prompt 写死在代码里，改一版就 git 提交一次——这是 AI 工程的反模式。

正确做法：prompt 独立成版本化文件（或表），每次修改有版本号、作者、评测结果。线上跑哪个版本要有记录，这样线上 bad case 能定位到具体 prompt 版本。进阶：prompt 的 A/B 测试框架，和模型路由一样重要。

AI 功能怎么写测试#

普通功能的测试是「输入 A 期望输出 B」。AI 功能的输出不确定，传统断言失效。三个替代策略：

1. 确定性输出用传统断言——结构化输出（JSON schema 校验）、工具调用参数的校验，这些是确定的。
2. 非确定性输出用 LLM-as-judge——用另一个模型评维度分（忠实度、相关性、有害性）。注意 judge 模型本身也要校准。
3. 回归测试用 golden set——固定一组输入，每次跑完看输出是否「还行」（不是完全一致，是语义在可接受范围）。人工或 LLM 判定。

别试图用传统单元测试覆盖 AI 功能的输出——你会陷入维护地狱，而且测不出真问题。

怎么跟业务对齐 AI 的不确定性#

这是软实力但极重要。AI 功能不是「需求 → 开发 → 上线」的瀑布，而是「需求 → 原型 → 评测 → 调整预期 → 上线 → 监控」的循环。

面试常问：「业务方要求准确率 99%，你怎么回应？」错误回答是「我尽量」。正确回答：「先明确 99% 是什么的准确率——是工具调用准确率、答案忠实度、还是用户满意度？这三个数完全不同。然后一起定评测集和可接受范围，把『准确率』从口号变成可度量的指标。AI 功能的预期管理比技术实现更重要。」