FDE 手册框架

前沿部署工程师的三种角色类型

前沿部署工程师角色通常分为三类：AI 应用与 Agent 密集型、集成与部署密集型，以及平台与基础设施密集型。

大多数角色是混合型的，但通常有一类决定了面试中最深入考察的方向。在决定学习什么之前，先确定这一类。

1. AI 应用与 Agent 密集型

AI / Agent

  • 典型工作
  • RAG、Agent、工具调用、评测、防护栏以及生产环境调试
  • 面试深度
  • LLM 系统行为、可靠性、评估与安全自动化
  • JD 信号
  • agents · RAG · evals · tool calling

2. 集成与部署密集型

集成

  • 典型工作
  • API、Webhook、身份验证、客户工作流与快速交付
  • 面试深度
  • 需求分析、系统集成、故障处理与实际权衡
  • JD 信号
  • deployment · APIs · implementation · solutions

3. 平台与基础设施密集型

平台 / 基础设施

  • 典型工作
  • 推理、服务化、分布式系统、吞吐量、延迟与可靠性
  • 面试深度
  • 后端深度、规模化、并发、缓存与故障域
  • JD 信号
  • inference · serving · performance · infrastructure

我们用当前的招聘数据验证了这一框架。请阅读我们的100 份在招 FDE 职位描述分析。

关于 FDE 面试，首先要知道的是：并不存在单一的 FDE 面试。

“前沿部署工程师”如今被用来指代几种差异相当大的工作。有些公司想要能构建生产级 AI Agent 的工程师。有些想要能坐在客户身边、集成混乱系统并快速交付的强力全栈工程师。还有些公司将 FDE 用于围绕推理、数据或开发者平台的高技术含量基础设施工作。

如果你为错误的角色版本做准备，可能会花大量时间学习错误的内容。

前沿部署工程师面试流程

大多数 FDE 面试流程将常规软件工程与面向客户的判断力相结合。顺序因公司而异，但候选人应预期大致包含以下环节：

  • 招聘人员或招聘经理初筛 — 动机、角色匹配度，以及你交付过真实系统的证据。
  • 编码 — 算法、API、JSON 转换、SQL、调试，或一个小型实用服务。
  • 系统设计 — 围绕真实客户工作流进行设计，包括约束条件和故障处理。
  • 技术深度 — AI 系统、集成、数据平台或基础设施，取决于公司。
  • 客户案例或现场演示 — 澄清一个模糊的需求，规划一个有用的第一版范围，并沟通权衡取舍。
  • 项目深挖与行为面试 — 所有权、生产事故、难缠的利益相关方、上线推广以及可衡量的影响。

在准备之前，先阅读职位描述，确定哪两个阶段可能权重最大。AI 应用公司可能会深入考察 Agent 和评测；数据平台公司则可能强调 SQL、分布式系统和技术演示。

常见的 FDE 面试问题

这些问题考察的是该职位背后的核心能力，而不是某个特定公司的冷知识：

  • 你如何把一个模糊的客户需求转化为范围明确的首个部署？
  • 设计客户 CRM 与你的产品之间可靠的同步机制。
  • 当 webhook 被重复投递或乱序到达时会发生什么？
  • 什么时候你会选择 RAG、确定性工作流，或 AI Agent？
  • 你如何在上线前后评估一个 AI 工作流？
  • 设计一个能够安全执行高影响外部操作的工具调用 Agent。
  • 讲讲你亲自诊断并解决过的一次生产事故。
  • 描述一个项目，其中最初的技术方案并不是正确的客户解决方案。
  • 当外部依赖可能失败时，你会如何进行现场技术演示？
  • 哪些运营和业务指标能够证明一次部署是成功的？

优秀的回答从用户、工作流、约束条件和成功标准出发。它们会明确说明失败处理方式，并区分模型决策的部分与应用控制的部分。

FDE 面试准备清单

  • 将该职位归类为偏 AI 应用、偏集成，还是偏平台。
  • 每周练习一道常规编程题和一道实用的 API 或数据转换题。
  • 排练系统设计，涵盖认证、重试、幂等性、队列、可观测性和上线推广。
  • 准备两个项目故事，展现模糊性、所有权、生产环境工作、失败经历和可衡量的影响。
  • 构建一个与职位相关、深入到可以讨论权衡取舍的项目，而不是多个浅层的演示。
  • 在提出架构方案之前，先练习一次客户需求挖掘对话。
  • 准备好关于公司用户、部署模式和成功定义的问题。

使用 30 天 FDE 学习计划 将这份清单转化为每日日程，或从 FDE 编程练习、系统设计 和 AI 模拟面试官 开始。

我发现将 FDE 角色分为三大类型很有用。

类型一：偏 AI 应用和 Agent 的 FDE

这是随着生成式 AI 兴起而增长最快的类别。

这份工作通常不是训练基础模型，而是围绕它们构建应用，并让这些应用为真实客户可靠地运行。

典型的工作可能包括：

  • RAG
  • Agent 和工具调用
  • 结构化输出
  • 评测
  • 追踪与可观测性
  • 提示词与上下文设计
  • 防护栏
  • 生产环境调试

想象一个客户想要一个内部支持 Agent，能够回答问题、查询账户信息并执行某些操作。

原型很容易做。

真正的工作在那之后才开始。

模型应该接收哪些信息？它可以访问哪些工具？哪些操作需要审批？你怎么知道它是否选择了正确的工具？当检索给出糟糕的上下文时会发生什么？如果一个错误答案出现在四次工具调用之后，你该如何调试？

这正是这位 FDE 所处理的那类问题。

公司通常看重什么

你应该能够构建普通的软件，但同时也需要理解 LLM 系统在生产环境中的行为。

重要的不只是“RAG”或“Agent”这些概念本身。你应该能够推理：

  • 系统为什么会失败
  • 你会衡量什么
  • 你会追踪什么
  • 哪些部分应该是确定性的，而不是交给模型处理
  • 你会如何降低模型不良行为的影响范围

适合这一类别的优秀项目是一个真实的 AI 工作流，具备用户、工具、状态、失败处理、评测和可观测性。

只有一次模型调用的聊天机器人通常不足以让你有太多可谈的内容。

类型 2：以集成和部署为主的 FDE

这更接近前沿部署工程的最初理念。

你与客户紧密合作，理解他们想要实现的目标，然后在他们的环境中构建实现这一目标所需的软件。

客户可能已经有 CRM、计费系统、数据仓库、内部 API、身份提供商，以及一堆靠电子表格和手工操作维系的流程。

你的工作不是重新设计整个公司。

你的工作是让你的产品在那个现实中运转起来。

典型的工作包括：

  • API
  • Webhook
  • 身份验证
  • 数据转换
  • 客户专属工作流
  • 后端或全栈开发
  • 快速原型
  • 生产环境部署
  • 调试集成问题

假设一个客户希望将 Salesforce 中的记录在你的产品中创建对应的对象。

这听起来很简单，直到你开始提出真正的问题。

什么才是唯一事实来源？你如何在系统之间映射记录？如果 Salesforce 发送了两次相同的 Webhook 怎么办？如果你的 API 调用成功了，但 Salesforce 在接收响应之前超时了怎么办？当一个系统宕机两小时会发生什么？

这些细节就是这份工作的内容。

公司通常看重什么

这种类型的 FDE 奖励那些能够在客户对话和具体实现之间自如切换的工程师。

你需要足够的系统设计知识来处理分布式状态和故障，但同时也需要务实的判断力。

复杂的架构并不自动等于更好。

通常最有力的答案是那个能处理重要故障场景、并且可以快速上线的最简单系统。

对于这一类，我会重点准备以下内容：

  • API 和 HTTP
  • Webhook
  • 重试
  • 幂等性
  • 队列
  • 身份验证
  • 数据建模
  • 外部 ID
  • 对账
  • 可观测性

我还会练习把模糊的客户需求转化为具体的需求。

类型三：偏平台和基础设施的 FDE

第三类更接近后端、基础设施或机器学习系统工程。

这类岗位常见于销售基础设施产品的公司：模型服务、AI 网关、数据平台、向量系统、可观测性工具、数据库或开发者基础设施。

客户可能仍然是工作的核心，但技术问题更偏底层。

典型的工作可能涉及：

  • 推理
  • 模型路由
  • 分布式系统
  • 数据管道
  • 并发
  • 缓存
  • 可观测性
  • 吞吐量
  • 延迟
  • 可靠性
  • 成本优化

客户可能有多个模型运行在不同的供应商上，希望获得更低的延迟和更好的可靠性。

这时对话的重点不再是提示词设计，而是路由、降级行为、缓存、吞吐量、故障处理和成本。

公司通常看重什么

对于这类岗位，传统的后端和系统设计准备要重要得多。

你应该能够熟练地思考以下问题：

  • 规模
  • 队列
  • 存储
  • 并发
  • 缓存
  • 一致性
  • 负载
  • 故障域
  • 延迟
  • 可靠性

你可能仍会遇到面向客户的场景，但技术门槛通常比典型的应用型 FDE 岗位更深。

大多数 FDE 岗位都是混合型的

这些类别并不是泾渭分明的框框。

很多当前的 FDE 岗位介于类型一和类型二之间。

例如，你可能要构建一个 AI Agent，把它连接到客户的 CRM 和内部 API，部署到他们的环境中，然后监控它的表现。

这既需要 AI 应用知识，也需要常规的集成工程能力。

还有一些岗位结合了类型二和类型三：你与企业客户紧密合作，但产品本身偏基础设施。

这种分类的目的并不是给岗位贴上完美的标签。

而是回答一个问题：

这场面试会在哪里深入考察？

这应该决定你如何准备。

如何从职位描述中识别岗位类型

最容易判断的信号是 JD 中的措辞。

如果你反复看到：

agent、RAG、评测、LLM 工作流、工具调用、提示词工程

那么这个岗位很可能偏向类型一。

如果你看到：

客户部署、集成、实施、API、原型设计、解决方案

那么它很可能偏向 Type 2。

如果你看到：

推理、基础设施、分布式系统、服务化、性能、吞吐量

那么它很可能偏向 Type 3。

同时也要看这家公司实际卖的是什么。

AI 应用公司的 FDE 和模型服务基础设施公司的 FDE 可能头衔相同，但面试内容完全不同。

一旦你知道自己面试的是哪种类型，剩下的准备工作就会容易得多。

FDE 到底做什么？

从宏观层面来看，FDE 仍然是一名软件工程师。

不同之处在于，你通常离问题更近，离客户也更近。

你得到的可能不是一个完全明确的需求，而是从这样的起点开始：

“我们想把这个工作流程自动化。”

然后你需要弄清楚这到底意味着什么、涉及哪些系统、应该先构建什么，以及如何把它推向生产环境。

这就是为什么 FDE 面试考察的内容往往不只是编码。

他们想看到证据，证明你能够应对模糊性、快速构建、做出合理的权衡，并在第一个版本上线后持续跟进。

面试流程通常是什么样的

各公司组织面试流程的方式不同，但大多数面试都会涵盖以下环节的某种版本：

  • 编码
  • 系统设计
  • AI 或技术深度
  • 客户问题解决
  • 项目深挖或行为面试

权重分配在很大程度上取决于 FDE 角色的类型。

编码

有些公司使用常规的 SWE 编码轮次。

另一些公司则使用更贴近实际的任务：API、数据转换、SQL、调试，或构建一个小型服务。

我仍然会练习基础算法，但对于 FDE 角色，我还会确保自己能够熟练处理 JSON、HTTP、API、SQL 和异步工作流。

系统设计

FDE 的系统设计往往从真实的工作流程出发，而不是一个泛泛的产品。

你可能会被要求同步两个系统、自动化一个支持流程，或者围绕客户现有的数据构建某些东西。

重要的习惯是：在设计架构之前先理解工作流程。

对于 Type 2 角色，预计会有更多关于集成和故障处理的问题。

对于 Type 3 角色，预计会有更深入的分布式系统问题。

AI 和 GenAI

这一点对 Type 1 角色最为重要。

你应该了解何时使用直接生成、RAG、工具或 AI Agent，并且能够谈论评测、可观测性、故障模式和防护机制。

面试通常更关心你能否运营一个 AI 系统，而不是你是否了解最新的框架。

客户案例

客户案例通常从一个刻意模糊的请求开始。

例如：

“我们想用 AI 来自动化客户支持。”

不要直接跳到架构设计。

先问清楚用户是谁、他们现在怎么做、哪些环节昂贵或缓慢、有哪些数据、哪些内容适合安全地自动化、以及成功会是什么样子。

目标是展示你能够找到初始请求背后的真正问题。

练习面向客户的案例

项目深挖与行为面试

准备两三个你非常熟悉的项目。

你应该能够解释哪些地方不明确、你个人负责了什么、为什么做出某些决策、出了什么问题、系统如何上线到生产环境、以及你如何确认它有效。

常见问题包括：

讲讲你从头到尾构建过的东西。
讲讲你把一个模糊的需求变成可用解决方案的经历。
你第一次做错了什么？
讲讲你不得不调试的一个生产环境问题。

FDE 面试官非常看重主人翁意识，因为这份工作给你的结构化程度往往低于普通的产品工程岗位。

建立你的行为面试故事库

你应该构建什么来准备？

如果你的目标是类型 1，构建一个真实的 AI 工作流，而不是多个演示。

为它配备真实的工具、持久化、错误处理、追踪，以及一个小型评测集。

如果你的目标是类型 2，构建一个真实系统之间的集成。处理 webhook、重试、重复事件、故障和对账。

如果你的目标是类型 3，构建一个迫使你思考基础设施的东西：并发、队列、缓存、吞吐量或可靠性。

项目不需要很大。

它需要让你有真实的工程决策可以谈论。

我会如何准备

我会把准备分成四个方面：

编程 — 足够通过常规筛选的算法能力，加上实际的 API 和数据处理工作。

系统设计 — 核心系统设计，额外关注集成和故障模式。

岗位相关的深度 — 类型 1 侧重 AI 系统，类型 2 侧重部署和集成，类型 3 侧重基础设施。

项目故事 — 两三个能体现主人翁意识、模糊性、生产环境工作和可衡量成果的例子。

最重要的一步在所有这些之前：

弄清楚公司实际招聘的是哪种 FDE。

一旦明确了这一点，准备工作就会更有针对性。