案例研究轮是 FDE 面试的标志性环节，通过率最低、权重最高。这里提供一个可复用的框架，帮助你在压力下把一个模糊的客户问题拆解为范围明确、站得住脚的方案。
作者：MEI LIN · FDEINTERVIEWS 编辑部 · 更新于 2026 年 6 月 21 日 · 阅读时长 9 分钟
练习这些：行为类与客户类问题 ·客户约束下的系统设计 ·必知的 FDE 面试题 ·完整的 FDE 面试流程
TL;DR： 在设计任何东西之前先厘清业务目标，明确真正的约束条件（数据、连通性、数据驻留），确定一个最小可行版本，把准确率-成本-延迟的权衡说出来，最后说明系统会如何失效以及你会如何发现失效。这一轮考察的是在模糊中建立秩序的能力，而不是最优架构。
FDE 案例研究轮会给你一个没有规格说明的模糊客户问题，并要求你把它变成一个方案。这是整个面试流程的标志性环节，据报道通过率最低，约 40%，权重最高，接近决策权重的 30%。这也是优秀程序员最常被拒的环节，几乎总是因为他们在理解业务目标之前就开始设计系统。破局之道是一个可以边说边执行的拆解框架：厘清目标、明确约束、划定最小首版范围、说出你接受的权衡，并规划系统失效时的应对。本文将讲解这个框架以及让候选人折戟的失败模式。
这一轮真正考察的是什么
面试官并不是在评判你是否达到了他们心中预设的架构。他们评判的是你能否在无人提示的情况下为混乱建立秩序。客户交给 FDE 的永远是一团乱麻和一个截止日期，而不是一张清晰的工单，所以这一轮模拟的正是这种情境，并观察你的思考过程。
这就是为什么一个设计能力稍弱但具备敏锐范围界定直觉的候选人，往往能胜过一个一上来就画框图和箭头的更强设计者。评分标准大致是“候选人是否对模糊问题进行了结构化拆解并为其选择辩护”。以下所有内容都服务于这一点。
第一步：先厘清业务目标
在谈任何架构之前，先弄清楚客户真正想达成什么，用他们自己的话来说。一家物流公司说“我们想对货运数据使用 AI”，他们可能想预测延迟发货、解释延迟原因，或者从运营层面减少延迟。这是三个不同的系统。为错误的目标做设计，即使设计再优雅也是直接失败。
询问三个月后成功是什么样子，以及他们会如何衡量。如果你说不出客户关心的指标，你就是在盲目的状态下做设计。这是区分通过与失败最关键的一步，而它只需要两个问题。
步骤 2：把约束条件明确说出来
一旦目标清晰，在确定方案之前，先找出那些会改变系统形态的约束条件。对 FDE 来说最重要的三个约束，客户往往不会主动提及：
- 数据： 有哪些数据、归谁所有、新鲜程度如何、脏到什么程度。“他们仓库里的每日批量数据”和“实时事件流”会导向完全不同的架构。
- 连通性： 你的服务能否访问互联网，还是处于一个没有出站流量的私有 VPC 中？模型是否必须本地部署，因为数据不能离开客户环境？
- 数据驻留与合规： 数据在法律上可以存放在哪里？受监管的客户可能禁止将记录发送到第三方 API，这会排除掉显而易见的托管方案。
主动说出这些约束，说明你以前部署过系统。行为与客户问题专门训练这种主动暴露约束条件、而不是想当然地忽略它的直觉。
步骤 3：定义 MVP，并说明你不会构建什么
现在确定一个能在几周内交付价值的最小初始版本，并明确说出你刻意推迟构建的内容。FDE 靠交付一个能运行的小东西来赢得信任，而不是在第一天就设计最终的平台。
针对延迟发货案例，一个强有力的 MVP 可能是一份每日报告，基于简单的规则基线标记有风险的发货，并由人工审核这些标记。要说明你暂时不构建实时模型、自定义 UI 或自动改道功能，以及原因：这些风险更高，你希望先获得信号，确认简单版本确实能推动指标。第二分钟就伸手去拿微调模型，是最常见的过度设计信号。
步骤 4：说明准确性、成本和延迟之间的权衡
每个真实系统都要在这三者之间做取舍，这一轮考察的是你是否有意识地做出决策。要说明你在优化什么、放弃了什么。
以延迟发货系统为例：每日批处理便宜且简单，但无法捕捉今天下午出问题的发货；流式系统能捕捉到，但成本更高，还会增加运维负担。如果客户每天早上审核标记，那么每日批处理就是正确的选择，并且你要明确说出来。系统设计题集正是围绕这种约束优先的风格构建的，网络态势和预算对架构的影响比原始吞吐量更大。
步骤 5：规划故障模式
最后，说明系统会如何出故障，以及你如何得知。这是面试官等待的绿灯信号，因为它表明你运行过生产环境中的系统，而不仅仅是做过设计。
供报告参考：当数据源延迟或格式损坏时会发生什么，当模型把所有内容都标记或什么都不标记时，当下个季度源 schema 静默变更时。说明你会如何检测每一种情况——一个新鲜度检查、一个针对标记率漂移的告警、一个行数合理性门控——因为在实际工作中，值班的电话是你接的。主动说出这些内容，往往比设计本身更能提升评分。
在时间压力下整合起来
你不会有时间澄清所有事情，所以要澄清那两三个会改变系统形态的问题，然后对其余部分做出明确、可辩护的假设并继续推进。把澄清阶段限定在两三分钟内，这样你还有时间做设计。最糟糕的结果是候选人澄清了十分钟却什么都没构建出来。
练习时，拿一个一句话的题目（“帮助一家医院减少爽约的预约”），在计时器下把完整框架大声讲出来。先从必知问题开始，然后在范围界定环节深入行为与客户问题集，在架构环节深入系统设计问题。关于这一轮在整个面试流程中的位置，FDE 面试流程指南梳理了每个阶段。
核心要点
- 在画任何架构之前，先澄清业务目标及其成功指标；为错误的目标做设计，即使再优雅也会失败。
- 大声说出数据、连通性和数据驻留方面的约束，因为它们会改变系统的形态，而客户很少会主动提及。
- 承诺一个最小化的第一版，并明确说出你刻意暂不构建的内容。
- 有意识地做出准确率-成本-延迟的权衡，最后说出失败模式以及你会如何检测它们。
把它转化为 offer。练习这套内容对应的真实面试题和概念：
常见问题
因为没有规格说明，也没有可以死磕的标准答案。据反馈，这一轮的通过率约为 40%，权重约占决策的 30%，分别是整个流程中最低和最高的。很强的程序员也会在这一轮失败，因为他们还没澄清业务目标就开始做架构。
只有在你先与更简单的基线做了对比论证之后才可以用。在前两分钟就伸手要模型，最能暴露出候选人在解决他们希望自己遇到的问题。先说出启发式或规则基线，然后说明 ML 系统能带来什么、代价是什么。
把前三分之一的时间花在大声澄清和界定范围上。面试官在考察你能否在混乱中建立秩序，所以沉默会被解读为瞎猜。说出你的假设、验证它们，然后再开始画系统。
然后明确说出一个假设，解释为什么它是合理的默认值，然后继续推进。“我会假设数据每天落到他们的数据仓库里，因为这种规模的物流公司几乎都有数据仓库；如果是流式数据请提醒我。”在不确定性下做决策，正是被考察的能力。
讨论 (5)
区分通过与失败的关键一步：在动手设计架构之前，先用客户的语言问清楚成功是什么样子。“三个月后，他们怎么知道这件事成功了？”如果你回答不了这个问题，你就是在盲目设计，面试官一眼就能看出来。
我总是时间不够用。我花十分钟澄清问题，结果什么都没设计出来。我该如何在界定范围和实际展示设计之间取得平衡？
给时间设限。用两到三分钟提出精准的澄清问题，然后大声说出你选择的 MVP 并围绕它进行设计。你不需要澄清所有事情，只需要澄清那两三个会改变系统形态的问题，其余的做出站得住脚的假设即可。
这里有一个被低估的要点：主动指出失效模式是一个加分信号。当候选人在没有被问到的情况下就说“这里会怎么出问题，以及我会如何发现它”，这表明他们真正在生产环境中运行过系统，而不只是在白板上画过设计。
附议“先定基线”的原则。我见过候选人在一轮表现很好的面试中失分，就因为为一个 SQL 查询加阈值就能解决的问题提出了微调模型方案。面试官在一定程度上就是在考察你会不会拿着客户的钱过度建设。