AI 系统设计面试：如何作答

"设计一个客服 AI 助手" 现在已是高级工程师面试的标准问题，而且有特定的失败方式：直接说"我会用 RAG 加向量数据库"的候选人会挂；而先问需求、画好基础架构、讨论评估和失败模式的候选人能过。本指南提供答题框架，并附上两道最常见问题的完整解答。

框架（请大声说出来）

需求优先，AI 其次（5 分钟）：谁用？查询量？延迟容忍度？错误答案的代价——是烦人还是诉讼？准确率标准及如何衡量？数据新鲜度要求？*错误成本问题是高级信号*——它驱动后续所有选择（模型层级、人工审核、评估严格度）。

非 AI 骨架（5 分钟）：客户端 → API 网关 → 服务层 → 数据存储 → 异步工作器。AI 是普通系统里的一个组件；面试官会挂掉那些画"魔法 LLM 盒子"架构的人。

AI 层，有据可依（15 分钟）：模型选择（及层级路由）、检索设计、提示/上下文策略、结构化输出——每个选择都要关联步骤 1 的需求。

评估 + 运维（10 分钟）：这是拿 offer 的关键——评估集、回归门控、成本监控、降级方案、监控。大多数候选人在这里无话可说；有*任何*内容都能让你脱颖而出。

失败模式 + 迭代（5 分钟）：幻觉处理、供应商故障、提示注入、漂移。以"v1 发布 X；我们测量 Y；v2 增加 Z"结尾。

真题示例 1：客服助手

需求：每天 1 万工单，聊天延迟秒级，错误答案损害信任（中高）→ 必须引用 + 逃生通道。

骨架：聊天前端 → API → 编排服务 → 基于帮助文档的 RAG（pgvector——说明*原因*：已有 Postgres、支持过滤、单一备份故事）+ 受限的账户查询工具（身份来自认证，而非提示）→ 工单创建转交。

AI 层：小型模型用于意图路由；中型模型用于答案合成并强制引用；结构化输出用于任何操作；流式 UX（SSE）。

评估/运维：200 个历史工单作为评估集，基于 groundedness 和解决率评判；同时关注分流率和满意度指标；供应商降级；人工升级始终可见。

失败模式：通过工单文本注入（数据隔离）、过时文档（版本感知的摄入）、自信的错误答案（引用要求 + 抽样审计）。

真题示例 2："设计一个做 X 的 AI Agent"

陷阱是 Agent 最大化。通过的答案：从工作流开始，为每一步自主性提供理由。如果步骤已知，使用固定流水线（何时不使用 Agent）；仅对真正动态的任务添加规划循环；对关键操作设置审批门控，按风险分级；限制一切（步骤、预算、时间）并持久化状态以便崩溃恢复（检查点）。提及成本：无限制的 Agent 就是一次计费事故。

快问快答深度问题（一句话强答案）

*"如何处理幻觉？"* → "分层：基础事实 + 引用要求、模式验证、尽可能程序化验证（引用文本必须字符串匹配）、人工审核按错误成本缩放——以及一个评估集来测量残余率。"

*"向量数据库选择？"* → "pgvector 直到规模迫使改变——运维简单性在大多数规模下胜过基准差异；升级阈值是数千万向量或严格的 p99。"

*"如何控制成本？"* → "按任务层级路由、缓存友好的提示结构、批量处理离线工作、从第一天起按功能进行成本监控。"

*"微调还是 RAG？"* → "RAG 用于知识（可删除、可更新、可审计）；微调用于形式（风格/格式在规模下）——并且永远不要用于受删除请求约束的数据。"

*"如何安全地发布模型/提示更改？"* → "注册表 + 评估门控 + 金丝雀——与代码部署相同的严谨性。"

面试官实际在评什么

需求追问（尤其是错误成本）、有理由的权衡而非堆砌名词、评估故事、运维成熟度（降级方案、优雅关闭级别的思考）。练习方法：设计两次——一次自由发挥，一次在写下五个需求之后——第二次设计总是不同，而*这个差异就是被测试的技能*。

---

*最后更新：2026 年 6 月。*