别只盯着分库分表：AI时代的产品架构设计面试法

多数系统设计准备都在教你“如何设计一个微博”：估算 QPS、分库分表、加 Redis 缓存、讨论写扩散。然而走进面试间，面试官抛出的题目往往是一个具体的产品方案——在这个方案里，用户整天盯着的那个屏幕，和背后的服务器同等重要。

这就是产品系统设计面试（Product System Design），有些公司称之为“产品架构（Product Architecture）”。这类面试也是检验架构设计框架的绝佳试金石。现有的很多系统设计框架是围绕底层基建问题诞生的，而在产品轮次中，它们往往会跳过最关键的部分：用户、界面与工作流。针对基础设施的通关指南很多，面向产品经理的 AI 方案也不少，但面向一线工程师、从头到尾推演产品架构实战的文章却寥寥无几。

本文借用业界知名的框架，以一个“AI 辅助客服回复”的真实问题为案例，推演整套设计逻辑，并复盘框架的适用边界与落地调整。

文中所用的基础步骤源自 Hello Interview 的 Delivery 框架（属于其免费指南 System Design in a Hurry 的一部分）。在此基础上，我们针对 AI 产品场景进行了关键重构。

什么是产品系统设计面试？

这类面试通常在 FigJam、Excalidraw 或 Miro 等协同白板上进行，时长 45 到 60 分钟。面试官给出一个产品命题，你需要一边思考一边在白板上完成系统设计。

面试官的核心评估维度包括：

• 应用层的高阶架构设计能力
• 产品化思维与用户交互链路（User Flow）
• 针对技术权衡（Trade-offs）与边界情况的推演
• 前端、后端以及 AI 系统之间的协同整合

贯穿始终的评价标准是：清晰度远大于完整度。没有人指望你在短短一小时内搞定一个生产级系统。面试官想看的是：你能否快速定下一个合理方向，说清理由，并在面对质疑时动态调整。

它与传统基建架构面试的最大不同在于重心转移。在“设计短链系统”中，用户端往往只是画一个写着“Client”的单薄方块。但在产品架构面试中，用户旅程与 UI 交互是第一公民。面试官会追问：用户看到了什么？点击按钮后发生了什么？报错时界面怎么提示？底层的 API 该如何设计来支撑这种交互？系统扩容和高并发当然也会涉及，但通常是后续的追问，而非主线。

（参考：Hello Interview 曾详细对比过 Meta 产品架构面试备考指南 以及 Meta 系统架构与产品架构的区别）。

结构演进：加入“用户旅程”

标准 Delivery 框架将 60 分钟拆分为五步：

1. 明确需求（Requirements）
2. 核心实体（Core Entities）
3. API 与系统接口（API/System Interface）
4. 高阶架构设计（High-level Design）
5. 深度推演（Deep Dives）

在面向产品的面试中，必须在“需求”后立即加入显式的“用户旅程（User Journey）”。实体和 API 不应该是凭空捏造出来的抽象概念，而应该顺理成章地从用户旅程中掉落出来。

这个改动看似细微，却彻底改变了整场面试的节奏。当你带着面试官一步步走完产品的每个屏幕：

• 核心实体，就是你在描述界面时反复提到的名词。
• API 接口，就是每个屏幕加载数据或提交变更所需的端点。

你无需再凭空猜测，只需照着白板上的工作流逐个提取。

60分钟的合理时间预算

这是一份经过实战检验的时间分配方案：

• 0–5 分钟：互相介绍与破冰。
• 5–10 分钟：界定用户与核心痛点，提出 2-3 个澄清性问题。
• 10–15 分钟：锁定需求（3 个功能需求、约 4 个非功能需求，明确列出非目标 Out-of-scope）。
• 15–22 分钟：推演用户旅程。
• 22–40 分钟：高阶架构设计（在连线上标注 API，在数据库模块中写清关键字段）。
• 40–52 分钟：深度推演（通常由面试官的各种“如果……该怎么办”驱动）。
• 52–60 分钟：反向提问环节。

候选人最容易超时的地方有两个：需求环节和深度推演环节。需求如果放任讨论，会无限膨胀；深度推演技术细节通常很有趣，容易让人恋战。面试时务必将时钟放在视线范围内，时间一到立即切换。

实战推演：AI 客服回复助手

以当前非常典型的一个 AI 辅助产品命题为例：AI 在后台完成准备工作，人类进行审核并执行最终操作。

面试题目：设计一个 B2B 客服工单系统的辅助工具。当新工单进入时，AI 自动生成回复草稿，客服人员负责审核、修改并发送。

这里需要先建立一个认知：在真正的工程面试中，面试官可能会将复杂的 AI 模型内部结构列为“非核心范围”，重点看你围绕 AI 构建的产品工程架构。正如 Design Gurus 在 AI 系统设计面试指南 中指出的：对业务研发而言，重点在于如何把大模型、RAG 管道或 Agent 组装进业务；算法工程师才需要死磕模型底层。

1. 用户与痛点

• 主要用户：一线客服人员。每天需处理 50 到 100+ 封工单（邮件/在线聊天）。
• 次要用户：客服主管（负责升级介入）。本次将其分析大盘列为非目标。
• 核心痛点：首次响应时长超时突破 SLA；在知识库中检索答案耗时费力；不同客服的回复质量参差不齐。
• 关键前置共识：AI 仅负责起草，人类负责审核与发送。V1 版本绝对不直接对客户自动回复。
• 业务成功指标：首次响应时长、工单平均处理时长、AI 草稿采纳与修改率、AI 辅助回复的满意度。

2. 需求定义

3 个功能需求：

1. 客服能看到按优先级排序的工单收件箱，每张工单都已预先生成好 AI 草稿。
2. 打开工单后，能看到对话上下文与 AI 草稿，草稿中的每一处事实论据都需附带知识库来源引用。
3. 客服可以对草稿进行发送、修改、重新生成或弃用。系统记录每一次人工操作。

明确剔除（Out of Scope）：第三方渠道集成细节、分析报表大盘、模型底层预训练、单点登录与权限大系统、计费系统。

4 个非功能需求：

• 读取极速：收件箱首屏响应控制在 300ms 左右。展示的内容完全来自预先计算好的草稿，绝不在线等待模型响应。
• 异步与解耦：AI 链路必须是完全异步的，任何情况下都不能阻塞人工。若大模型宕机，客服依然能正常使用纯手动流程处理工单。
• 多租户数据隔离：企业租户间的数据严格物理/逻辑隔离，敏感数据（PII）脱敏，模型供应商在合同与技术上均不可留存或使用数据训练。
• 数据一致性：同一条回复绝不能发送两次，绝不能基于过期的旧会话发送新回复。

3. 用户旅程（核心环节）

1. 用户通过邮件或即时聊天提交工单。后台系统异步触发 AI 管道：分类（问题类型、紧急度、情绪）、检索匹配知识库文档、生成回复草稿。这一切在客服点击工单前已全部就绪。
2. 客服进入收件箱，工单已根据 SLA 倒计时、问题优先级与客户等级自动排好序。
3. 点击进入工单详情页：左侧是历史会话，右侧是 AI 草稿。草稿中标注了知识库引用跳转链接，并给出“高/中/低”置信度提示（避免使用具体的百分比，因为大模型的百分比概率在前端容易产生误导性幻觉）。
4. 客服可以直接在行内编辑文本，或使用快捷指令（如“更精简一点”、“语气更正式一点”）重新生成，也可以一键丢弃改为纯手打。支持纯键盘快捷键操作。
5. 客服确认无误后点击发送，或转交给主管处理。
6. 系统持久化客服的操作结果，作为审计日志与后续模型优化的反馈数据。

推演两条关键异常分支：

• AI 服务不可用：收件箱依然能正常加载，工单右侧提示“草稿生成中/不可用”，客服无缝回退到人工输入模式。
• 客服编辑草稿时客户又发了新消息：系统通过长连接通知前端弹出横幅警告，后台重新触发草稿生成。系统保留客服已有的手动修改草稿，但在客服确认看到新消息之前，强行禁用“发送”按钮。

4. 核心实体设计

• Organization（租户）：租户基本信息与数据隔离标识。
• Agent（客服）：用户 ID、角色与权限。
• Ticket（工单）：状态、优先级、SLA 到期时间、分配人、版本号（Version，用于并发控制）。
• Message（会话消息）：所属工单、发言人、正文、渠道类型。
• KnowledgeArticle（知识库文章）：帮助文档元数据及其切分出的文本块（Chunks）。
• DraftJob（草稿生成任务）：触发事件来源、使用的模型与 Prompt 版本号。
• Draft（草稿）：正文、引用信息（关联的文章与段落）、置信度评级、状态。
• Decision（客服决策）：对应的草稿、客服 ID、行为（采纳/编辑/放弃）、最终发送内容、原因。
• AuditEvent（审计事件）：只追加不修改的操作记录流。

在这一步一定要说清实体关系。例如明确说明：“一个 Ticket 包含多个 Message；一个 Draft 可以引用多个 KnowledgeArticle 中的具体段落。”名词定义不严谨，是面试中被打断并浪费时间的高发区。

5. API 接口定义

GET    /v1/inbox?status=open&sort=sla&cursor=...
POST   /v1/tickets/{id}/claim
GET    /v1/tickets/{id}
POST   /v1/tickets/{id}/drafts
GET    /v1/tickets/{id}/events
PATCH  /v1/drafts/{id}
POST   /v1/tickets/{id}/send
POST   /v1/tickets/{id}/escalate
POST   /v1/drafts/{id}/feedback

在白板上列出接口时，主动带出设计取舍：

• 租户与身份注入：租户 ID 和身份直接从 Auth Token 解析，严禁放在 Request Body 里由前端传递。
• 游标分页（Cursor Pagination）：收件箱数据随着新工单的进入和解决处于高频变动中，传统的 Offset 分页会产生跳页或漏页，必须使用 Cursor。
• 附件处理：客户端不直接通过应用服务器上传下载附件，而是向服务申请有时效性的私有存储预签名 URL（Presigned URL），鉴权后直连对象存储。
• 实时事件通知：使用 SSE（Server-Sent Events） 替代 WebSockets 推送“草稿就绪”和“客户新回复”。因为服务端到前端的消息流纯粹是单向通知，SSE 基于 HTTP，实现更轻量，更易于穿透企业防火墙（参考 Hello Interview 关于实时更新模式比较）。
• 前端自动保存：编辑中的草稿定时防抖保存，避免浏览器标签误关导致劳动成果丢失。
• 发送幂等与版本检查：Send 接口强制带上幂等键与版本号，杜绝重复发送。

6. 高阶架构设计

架构整体拆分为两条核心链路：客服在线交互链路与后台异步 AI 链路。

• 客服链路：React 前端应用通过 API 网关（处理鉴权与限流）访问应用服务。业务服务由 PostgreSQL（配合只读副本）支撑，并将关键操作追加写入审计日志。附件通过预签名 URL 直连云存储获取。对外回复通过事务性发件箱（Outbox）交给下游渠道发送服务。
• AI 链路：第三方接入层接收到 Webhook 回调后，写入消息并推进工单版本，随后向消息队列发布事件。后台 AI Worker 消费任务，完成工单文本分类，从基于租户隔离的向量索引中检索相关文档，通过 LLM 网关生成草稿，执行引用合规性校验，最后将结构化草稿持久化至主数据库。另一条定时同步任务则负责在知识库更新时刷新向量索引。

核心设计论点：AI 在后台以异步方式生产结构化且经过引证校验的草稿，客服前端永远只读取预计算好的现有数据。哪怕大模型响应慢或宕机，客服界面的体验依然是毫秒级。

在白板绘图时，建议遵循逐步展开的原则：顺着用户发起的第一个请求开始连线，按需添加组件。如果一开始就把所有框框线线画满，既显得像在背八股，又容易让面试官抓不住重点。

7. 深入推演（Deep Dives）

面试通常会挑选两到三个技术深水区展开攻防：

问题一：大模型产生幻觉，答非所问怎么办？

多层防御体系：

1. 检索增强与结构化输出：只允许模型基于检索出的文档回答，并强制要求返回结构化 JSON（包含陈述句与对应的引用段落 ID）。
2. 引用确定性校验：通过程序校验模型给出的引用文本是否存在于知识库源文中，不存在则直接判定校验失败。
3. 硬编码规则拦截：设置确定性的规则层，例如严禁承诺具体的退款金额或物流时效。
4. 动态置信度降级：模型打分过低时，放弃输出完整草稿，仅在侧边栏向客服推荐相关知识库文章链接。
5. 人在回路（Human in the loop）：V1 版本坚持人工审核点击。
6. 校验模型引入：可以设计一个极小型的二次校验服务（Verifier），输入断言与引用段落，专门输出布尔值。OpenAI 的 Decisions API 或 TypeSafe 的 Jev 正是在朝这种判定式接口演进。

问题二：如何百分之百保证回复不被漏发、重发，且状态不错乱？

四重防护机制：

1. 认领锁（Claim Lock）：客服打开工单时在 Redis 获取一个带 TTL 的分布式软锁，避免多名客服同时处理同一张工单。机制类似大麦或票务网站在结账时临时锁定座位的逻辑（可参考 Ticketmaster 架构拆解）。
2. 前端生成 Idempotency Key：点击发送时附带客户端幂等键，并透传给最终的邮件/短信发送网关，避免网络抖动导致重试重发（参考 Stripe 幂等性设计）。
3. 工单版本乐观锁：发送请求必须携带读取时的工单版本号。如果在客服编辑期间客户追加了新问题，版本号递增，当前发送接口直接返回 409 Conflict 冲突，拦截发送。
4. 事务性发件箱（Transactional Outbox）：更新工单状态与插入“待发送消息”放在同一个数据库事务中，再由独立的消息中继服务拉取并投递外部系统，彻底消除“数据库改了但外部消息没发出去”的分布式不一致问题（参考 Transactional Outbox 模式）。

学习材料 vs 面试输出

备考中最容易犯的一个错误是试图在面试中展示自己知道的一切。

将你的储备划分为两个层次：

1. 显式展示层（The Board）：白板上的便签和箭头必须言简意赅。例如写下“预计算草稿”、“严禁自动外发”、“乐观锁防冲突”。你边画边讲，每个便签只需配一两句话解释。
2. 口袋知识层（Back-pocket Knowledge）：深层次的方案细节藏在口袋里，只有在面试官追问时才拿出来。面试官问你“怎么防重”，你再展开幂等键和事务发件箱；如果面试官不关心，切忌自顾自讲上五分钟。

经验法则：如果你无法用一句话讲清楚某个概念的核心取舍，它就属于口袋知识，先不要写在主架构图上。

口袋概念速查表

• RBAC：基于角色的访问控制。权限绑定在“客服”、“主管”等角色上，而非具体的人。
• PII：个人身份信息。在进入日志系统或大模型提示词前，必须统一脱敏洗掉。
• 零数据留存（Zero Data Retention）：大模型厂商在合同与技术层面上承诺不落盘缓存、不将 API 数据用于模型迭代的条款。
• KMS：密钥管理系统。进阶多租户架构中，每个租户可自带密钥（BYOK）加密敏感数据。
• 预签名 URL（Presigned URL）：由服务端生成、带有时效性限制的临时下载/上传直链，保护后端带宽与源站安全性。
• 乐观并发控制（Optimistic Locking）：更新时匹配版本号，版本不一致则终止并报错，将决策权交还给用户。
• SSE vs WebSockets：SSE 是基于 HTTP 的单向服务器推流；WebSocket 是全双工通信通道。非双向输入场景，优先选择实现成本更低的 SSE。
• CRDT：无冲突复制数据类型（如 Yjs），允许多人在弱网下协同编辑并自动收敛文本。协同场景适用，但关键的状态提交（如“最终发送”）必须退回到强一致的乐观锁拦截，绝不能通过算法静默合并。

框架之外的那些隐形坑

框架提供了一条跑道，但没法替你跑完整个过程。真实的面试常常充满各种变数：

1. 前三分钟没框定实体名称：一会叫 Ticket，一会叫 Case，或者把 Conversation 和 Message 混用。面试官一旦概念错乱，就会打断你，白白浪费 10 分钟澄清词义。
2. 无视面试官给出的侧重点：当面试官明确说“我们先聚焦在客服前台体验”，你却花 15 分钟死磕 RAG 的向量分块算法。记住：一旦被列入 Out-of-Scope 的模块，一句话带过即可，省下的时间全部投向核心业务交互。
3. 过度设计多租户：一上来就讨论每个租户一套独立数据库、租户自持 KMS 密钥加密。正确节奏是先从最简单直接的“每个表带 Tenant ID、网关层根据 Auth Token 强制注入查询上下文”讲起，在后续拓展中再探讨物理隔离与加密。
4. 拒绝面试官的善意协作：很多面试官会主动说“我来帮你画这两个组件”。痛快答应即可，面试考察的是架构思考，不是白板手绘手速。

一周冲刺备考策略

• 第 1–2 天：研读 Delivery 框架与相关文档，整理出属于你自己的单页白板模板。
• 第 3 天：挑选一个面向业务的具体命题（例如在线文档协作、客服 Copilot、外卖调度后台）。拿出一张纸，专攻用户、痛点、功能/非功能需求以及端到端用户旅程。
• 第 4 天：演练架构与 API 映射。在空白白板上由浅入深、逐步推导架构连线。
• 第 5 天：梳理 4–5 个深水区 Topic。按“问题 - 解决方案 - 架构权衡 - 一句话总结”的四段论形成肌肉记忆。
• 第 6 天：将所有方案精炼为白板便签。打开计时器，大声说出来，进行一场 30 分钟的高强度实战自测。
• 第 7 天：轻量复习。熟悉画图工具的快捷键，调整作息，保持清醒的头脑。

面试临场实用 Tips：

• 在屏幕旁贴一张小便利贴，写上 3 个最容易忘记的原则：先讲用户旅程、关注数据一致性、异步预计算。
• 准备好一句坚定的开场白，迅速切入主题，避免在前两分钟手足无措。
• 遇到模糊点，不要无休止地反问面试官，而是主动亮明假设：“这里存在两种可能，我先基于 A 场景设计，后续有需要我们再看 B 场景。”
• 把控节奏，主动探测：“这块细节如果需要，我可以展开推演，或者我们继续往下推进高阶架构？”