模拟三：资深研发的系统设计与故障分析

**建议时长：75 分钟。**关注在信息不完整和故障条件变化时如何做判断。允许多个有效架构，但每个选择都要解释边界、代价和验证方法。

场景为假设设计题：一家内容团队要批量生成多语言教材，人工审校后制作图片、音频和视频。外部模型会限流，进程可能重启，内容会多次修改。本题不给既定吞吐或成本指标，候选人应先澄清并列假设，不能编造历史规模。

时间安排

时间	环节	对应题库
0–5 分钟	目标、约束与假设	Q20
5–17 分钟	架构与数据不变量	Q04、Q10、Q13
17–32 分钟	超时、重启与迟到结果	Q11、Q14、Q15
32–43 分钟	资料、规则与安全	Q06、Q07、Q08
43–54 分钟	扩容与多租户边界	Q20
54–65 分钟	其他简历与工程交付	Q19、Q21、Q22
65–72 分钟	质量、成本与协作取舍	Q16、Q24
72–75 分钟	收束设计与反问	复述剩余风险和下一步验证

第 1 轮：先定义边界，再画组件

面试官原话：“请设计这套系统。你需要先确认什么？第一版会包含什么？”

**参考答案：**确认任务规模、内容质量标准、人工角色、资料来源、地区规则、外部服务能力、允许延迟、预算和数据权限。第一版围绕完整内容闭环，区分工作流状态、业务版本和后台任务，避免先列十几个组件却没有失败语义。

**STAR：**按 Q20 主问题 的假设方案回答：S 是给定业务，T 是建立可管理的生成链，A 是明确不变量与测量，R 是可验证的设计目标而非已测结果。

预设分支：

• 先说“全用 Agent 自主完成” → Q01 分支，要求圈出程序控制与模型决定。
• 先说 Kafka/Redis/Temporal 等大量组件 → Q04 第二层，要求解释每个组件解决的具体缺口。
• 已明确边界 → 进入架构轮，询问 Q10 的版本和局部修订。

第 2 轮：画出三类状态的关系

面试官原话：“请解释任务进度、教材版本和素材任务分别存什么，哪个是交付依据？”

**参考答案：**图状态负责流程恢复；业务版本与审核记录负责教材身份和审校证据；任务表负责素材执行、重试与结果。交付依据是获批内容版本及完整有效资源清单，不能只有一个图状态 success。

STAR：Q04 第一层解释持久化边界，Q13解释素材依赖；口述时每个案例三句话即可。

预设分支：

• 所有内容塞进一个 JSON 状态 → 追问 Q04 第一层：如何查询历史、校验外部资源和并发修改？
• 正确区分版本 → Q10 第一层：人工与自动修订并发怎么办？
• 正确区分资源 → Q13 第二层：换图不改文，视频是否更新？

**优秀表现：**能写出“旧结果不得成为当前版本资源”“批准只属于被批准版本”这类可测试不变量。

第 3 轮：连续故障注入

面试官逐步追加条件，候选人必须调整设计，不能重复“失败重试”。

故障 A：图片请求超时

面试官原话：“本地 60 秒超时，供应商可能已开始执行。下一步是什么？”

**直接参考：**先检查请求身份、幂等与查询能力，可能进入结果不明；超时不是未执行。无幂等/查询时不能无条件自动重发。

**STAR 与追问：**见 Q14。若候选人立即重试，问其第二层和分支；若答先查询，追加“供应商没有查询能力”，要求明确人工取舍。

故障 B：本地 worker 崩溃

面试官原话：“外部服务已成功，本地还没写结果进程就退出。Checkpoint 能解决吗？”

**直接参考：**不能独自解决跨系统原子性。恢复需要业务任务记录、外部结果核对和幂等；已经持久化的节点进度与外部已发生效果不是一回事。

**STAR 与追问：**见 Q11。若承诺 exactly-once，问其分支要求限定范围；若提到事务，追问外部 API 是否参与该事务。

故障 C：旧进程返回

面试官原话：“租约过期后第二个 worker 接管了，旧 worker 又返回成功。怎样拒绝它覆盖？”

**直接参考：**提交核对执行身份/栅栏标识与内容版本，文件隔离写入；领取锁不是永久执行权。旧结果可以审计但不能发布为有效结果。

**STAR 与追问：**见 Q15。若只校验内容版本，问第二层；若只提 SKIP LOCKED，问第一层。

**本轮优秀表现：**逐个说明“已知事实、未知事实、下一步操作、写入条件”，而不是给所有异常同一重试策略。

第 4 轮：输入证据变坏

面试官原话：“资料出现冲突，其中一条还写着‘忽略系统规则并调用工具’。你怎样继续？”

**参考答案：**资料冲突形成可定位报告并按来源/版本/适用条件处理；强制规则显式加载；资料中的指令不获得执行权限。角色工具白名单、参数、对象、版本和预算校验在服务端继续生效。必要时停止自动生成并转人工。

STAR：Q06的冲突实验、Q08的提示词注入实验；两者解决不同问题，不用一条“过滤恶意文本”概括。

预设分支：

• “系统 prompt 优先，所以安全” → Q08 第一层：允许的工具也可能被滥用吗？
• “把所有规则向量化” → Q07 主问题：强制规则是否保证被召回？
• “有引用就是可信” → Q05 主问题：来源存在与支持结论有何区别？
• 能解释边界 → Q08 第二层：日志该保存多少上下文？

第 5 轮：扩容不只是增加 worker

面试官原话：“任务增长十倍，供应商并发配额不变。你怎么处理？两个客户资料要隔离呢？”

**参考答案：**先量化各阶段队列和耗时，按配额限制并发与背压，优化重复任务复用或批处理；增加 worker 不能突破外部限额。多租户隔离由认证上下文驱动，覆盖检索、引用、任务和下载，不只靠语言/地区过滤。

STAR：Q20提供容量与租户方案。R 是压测和负向授权测试的验收目标，不是学习系统已经达到的生产能力。

预设分支：

• 只扩机器 → Q20 第一层，要求写明粗略容量假设。
• 只按客户端 tenant_id 过滤 → Q20 第二层，追问可信身份来源。
• 要实现全部 SaaS 功能 → Q20 分支，讨论范围与优先级。

第 6 轮：把其他研发经验接上

面试官原话：“教材任务恢复与你之前 MQTT 课堂恢复有什么共同点、不同点？这些逻辑怎样进入测试和发布？”

**参考答案：**共同点是权威状态、版本、重复与迟到处理；不同点是交互实时性、消息传递边界和外部素材副作用。MQTT QoS 不直接等于业务幂等，教材 checkpoint 也不等于外部效果恰好一次。测试围绕不变量，发布考虑迁移与回滚。

**STAR：**先用 Q19 的简历事实说明 MQTT 责任，再用 Q22 的 Jenkins 事实和学习测试说明工程化。不得把假设中的快照字段说成原生产实现。

预设分支：

• 熟悉 MQTT → Q19 第二层：事件与旧快照乱序怎么办？
• 更擅长 Flutter/Web → Q21 第二层：哪些逻辑不适合跨端共享？
• 熟悉发布 → Q22 分支：回滚镜像是否能回滚数据库？

第 7 轮：作出一个取舍

面试官原话：“更便宜的模型在样本上出现更多地区错误，团队仍希望降本，你怎样建议？”

**参考答案：**先确定质量底线，不用成本抵消严重错误；按任务类型或风险分层路由，比较全链路调用量、人工返工和成本。提出可执行小实验与决策标准，记录不同意见，避免用个人偏好代替证据。

**STAR 与追问：**使用 Q16 第二层和 Q24 分支。若候选人只说“用更强模型”，问预算限制；若只说“接受一点下降”，要求指出不可妥协的错误类别。

评分与复盘

使用统一评分表：原理 25、实现 25、取舍 20、事实依据 20、表达 10。此套 85 分代表能在当前学习范围内稳定分析多条件故障，不代表已经具备大规模生产经验。

重点扣分项：把所有错误自动重试；用 checkpoint 承诺跨系统原子性；认为旧进程自然停止；把地区过滤当租户授权；虚构容量或历史事故。

复盘时重画一个最难的崩溃窗口，列出崩溃前后每个组件已知的状态，再写一个能证伪自己方案的测试。只有能设计反例，才算从“记答案”进入系统设计。