FDE 是什么，不是什么

定义，出自招人的公司

先从雇主说起，因为只有他们把这份工作白纸黑字写了下来。下面的内容，可以当作雇主要求什么的一手证据来读；至于工作实际怎么做，它只算 T4 证据：一份招聘启事描述的，是一家公司希望招人来做的那份工作。

OpenAI 于 2026 年 9 月 11 日发布的旧金山招聘启事，是单份启事里说得最清楚的。FDE“与我们最具战略意义的客户一起，主导前沿模型在生产环境中复杂的端到端部署”，受聘者“将负责需求挖掘、技术范围界定、系统设计、构建和生产上线”。成功的衡量标准是“生产环境中的采用、可衡量的工作流程影响，以及能改变产品和模型路线图的、由评测驱动的反馈”（OpenAI，FDE – 旧金山；T4）。把这份清单当作一个顺序来读，从找到问题一直到运行系统。三条成功标准里没有一条是“上线了一个功能”或“签下了一单”；三条都只有在客户真正用上这个系统之后才成立。

Anthropic 于 2026 年 10 月 14 日发布的Staff 级 FDE 招聘启事，用一句话说出了同样的意思：“客户请你来，是让你主导，而不只是实施：你决定应该构建什么，然后确保它被构建好。”同一份启事要求 FDE“交付客户能够自己运维的生产系统”，并“移交客户能够运行的系统”（Anthropic，Staff 级前线部署工程师；T4）。这就给出了这份工作的两端。在前端，FDE 决定构建什么。在后端，客户不靠 FDE 也能运行它。

这些招聘启事里最有用的一句话，是一句否定句。OpenAI 于 2026 年 8 月 6 日发布的医疗健康 FDE 招聘启事，要求受聘者“端到端地负责技术方案，从客户需求挖掘和工作流程范围界定，到架构、亲手实施、评测、生产部署、采用和交接”。接着又补了一句：“这个角色负责技术方案；不要求负责商务关系或高层关系”（OpenAI，FDE 医疗健康 – 西雅图；T4）。

本章用的就是这句话划出的界线。对结果负责，不等于对客户关系负责。客户经理负责商务关系：合同、续约和价格。FDE 负责的是这个东西在客户的业务里能不能用。两者在发起人那里交汇，它们可以由不同的人承担，FDE 也并不因此就不算 FDE。FDE 不能交出去的，是从问题到运行中的系统之间的任何一个阶段。

所以，用本书的话来说，定义如下。FDE 在需求挖掘、范围界定、构建、上线和交接的全过程中对客户的结果负责，并把写代码作为实现它的手段。拿掉前端，你得到的是一个按吩咐干活的人。拿掉后端，你得到的是一个在东西能用之前就离开的人。拿掉代码，你得到的是一个顾问。这些都是真实存在、往往薪酬不错的工作。但没有一个是这份工作。

五个阶段加一个闭环：每个阶段的“负责”意味着什么

“负责”是招聘启事里被滥用得最厉害的词，所以要把它钉死。在每个阶段，负责意味着握有一项决定，而不是出席别人做决定的那场会议。

• 需求挖掘。由你决定问题是什么。客户的需求是一个假设，而 FDE 是拿真实工作流程去检验它的那个人。如果问题到你手上时已经定好了，写在一张工单上，那你就不负责需求挖掘。怎么做，见“需求挖掘”一章。
• 范围。你和签字的人一起商定成功指标、它的阈值和“暂不做”清单。如果数字由别人定，而你被要求去达到它，那你就不负责范围。见“划定范围与首个成果”。
• 构建。你在客户的环境里写生产代码，并做架构上的决定。设计好之后交给合作伙伴或客户团队去构建，是另一份工作，下文会讲到。
• 上线。你要一直待到它在真实流量上对照约定的阈值运行起来，经过安全审查，也经过评测爬坡。在演示时离开，是保住头衔、同时不再对结果负责的最简单方式。
• 交接。由你决定客户的团队什么时候能在没有你的情况下运行它，并且你要证明这一点。“上线与交接”把它称为一项由客户的运维人员在你不在场时通过的验收测试。

然后是那个闭环。FDE 在现场学到的东西会回到产品里。OpenAI 要求它的 FDE“把行之有效的模式沉淀为别人可以使用的工具、操作手册或构建模块”（旧金山招聘启事，T4）。Decagon 于 2026 年 7 月 31 日发布的战略部署工程负责人一职，职责是“决定 Decagon 应该构建什么，把它交付出去，并把它产品化，让每个客户受益，而不只是这一个”（Decagon；T4）。这个闭环不是交付的第六个阶段。它是让这次交付值得供应商花钱的原因，而“反哺产品”一章论证，正是它把 FDE 和外包工程师区分开来。把它留在清单上。

为什么非要写代码？因为代码是决定被证明对或错的地方。顾问可以推荐只提建议（不执行）的路由、一条在模型之外的确定性规则，以及一个只读身份。FDE 则必须让这些选择经受住客户的数据、基础设施和审查者的考验，并在这个过程中发现哪些选择是错的。Salesforce 的 FDE 总监 Sarah Khalid 把写代码称为“入场券”，其副总裁 Ruth Hickin 则把 FDE 形容为“黑客、客户价值和专业服务人员的结合体”（Salesforce，2026 年 3 月；T4，公司描述自己的团队）。代码不定义这个角色，但没有它你就上不了场。就连 OpenAI 的旧金山招聘启事，也没有它的概述那么绝对：一条要求 FDE“构建全栈系统”，另一条则是“当进展或清晰度取决于此时，直接在代码里动手”。检验标准不是写代码花了多少小时，而是在关键时刻，生产代码是由你来写，还是由别人照着你的设计来写。

有一个说法比其他任何说法流传得都广：FDE 就是“创业公司 CTO”。Palantir 的前线部署软件工程师招聘启事写道：“作为 FDSE，你的职责与创业公司 CTO 类似：你将在几乎无人监督的小团队中工作，端到端地负责高风险项目的执行”（Palantir，FDSE – 美国政府；T4）。Pragmatic Engineer 引用过它的一个版本（Orosz，2025 年 8 月；T3），Decagon 的启事则让它的负责人“像每一单的创始 CTO 那样”运作。对待这个说法，要像本书对待回声数字那样：一家公司的自我描述，被重复到听起来像一项发现。它很好地概括了这份工作的负责范围，却很难指导你的日常。创业公司 CTO 选择市场。FDE 则在别人的公司里、在别人的约束下工作，并且打算离开。

一个头衔，好几种工作

头衔已经不能告诉你眼前是哪一种工作了。有三类证据表明这一点，但每一类都比看上去更弱。

招聘启事分成三种。Bloomberry 分析了约 1,000 份 FDE 招聘启事，数据由招聘数据公司 Revealera 提供，并把它们分为三类（Bloomberry，2025 年 11 月，2026 年 1 月更新；T2）：

• “构建型 FDE”，占 60%：嵌入客户、在生产环境中构建、部署和维护系统的软件工程师，“70% 到 90% 的时间在写代码”。
• “销售工程师+”，占 30%：“一个换了名字的解决方案工程师或销售工程师岗位”，会把工作移交给实施团队，并被标注为“背销售指标”（文章在这一点上前后不一，别处又说这些岗位都不背销售指标）。
• “内部工具构建者”，占 10%：“一个 GTM 工程师或 RevOps 岗位，根本就不该被叫作‘前线部署工程师’”。

这个结论要谨慎看待：这是一位分析者自己的分类，文章没有说明分类规则，没有第二位评审，也没有做一致性检验。这个划分说得通，但它不是测量。它真正能确立的是：带着这个头衔的岗位里，有相当一部分把构建、上线阶段或外部客户整个丢掉了。

同一家公司会用“工程师”指代不同的工作。Anthropic 于 2026 年 9 月 28 日在伦敦发布的“应用 AI 工程师（企业）”招聘启事，要带企业客户“从第一次谈话开始，经过技术评估、价值验证和采购，直到决定构建”。接着是：“一旦他们做出决定，你要帮他们的系统集成合作伙伴做好交付准备，商定目标架构以及什么样算好，并在整个部署过程中作为客户在 Claude 方面的技术顾问保持紧密联系，而由合作伙伴来构建”（Anthropic，应用 AI 工程师（企业）；T4）。这是对另一份工作的诚实描述：按本章的检验，构建归别人。问题出在那些把界线弄模糊的启事上，而不是像这样把界线画清楚的启事。

职位族告诉你雇主以为自己买的是什么。中国市场让这一点一目了然，因为大雇主把这个角色归在不同的地方。爱范儿的 APPSO 栏目（2026 年 8 月 29 日由 36氪转载）报道，腾讯的三个前线部署工程师（FDE）岗位放在产品职位族下，要求三到五年经验。字节跳动给这个岗位起名为“AI FDE 工程师”，没有中文译名，归在研发之下，横跨飞书、火山引擎和数据平台。但字节跳动的 FDE 实习岗位，却放在“销售-销售支持”之下（爱范儿/APPSO，经 36氪；T3，一位记者解读招聘网站）。一个头衔，三个职位族，有时就在同一家公司里。要判断你将按谁的指标被考核，看招聘启事所属的部门比看头衔更靠谱。中国的薪酬和更广泛的市场情况，放在第 IV 部分讲 FDE 在哪里工作的那一章。

雇主也会用别的头衔指代同样的工作：应用 AI 工程师、智能体部署工程师、部署策略师、前线部署金融工程师。有些公司把不写代码的搭档角色单独命名：2026 年 10 月 17 日查阅的 Palantir 招聘页面上，部署策略师岗位和前线部署软件工程师岗位并列。错误是双向的。有些挂着 FDE 头衔的岗位并不是 FDE 工作，有些 FDE 工作也并不叫这个名字。在招聘网站上按头衔搜索，会在两个方向上都误导你。

这些都不能告诉你，做这些岗位的人每周实际怎么度过。没有研究跟踪 FDE 走完一次次交付，并记录他们负责哪些阶段。现有证据只是雇主写下来的东西：足以说明头衔靠不住，却不足以说明一份工作有多常与它的招聘启事相符。

相邻角色，按它们负责什么来看

看清 FDE 最清楚的办法，是把它和两侧的工作放在一起对比。咨询公司 Tryolabs 的 CEO Alan Descoins 给出了一个两句话的检验。“顾问做一轮需求挖掘，交给你一份战略，然后在写下一行代码之前离开。”“外包工程师严格按工单构建，但不会告诉你工单写错了，也不会留下来看有没有人在用”（Tryolabs，2026 年 6 月；T4，一家公司描述自己所在的领域）。顾问负责前端，不负责后端。外包工程师负责构建，不负责前端，并在后端之前离开。FDE 必须两端都负责。

下面的对照表把这个检验扩展到最常与 FDE 混淆的五个角色。它是本书依据本章引用的招聘启事和来源做出的归纳，不是一项测得的发现。把每一行当作这份工作的典型形态来读。任何一份具体的启事都可能不同，这正是 1.7 节那份清单的用处。

要用这张表去读一份招聘启事，就找出启事给受聘者分配职责的最后一个阶段，以及它在那里用的动词。如果职责止于“技术赢单”或签约，这是销售工程师的工作。如果止于“架构”或“建议”，这是架构师的工作。如果止于一份建议或一张路线图，这是顾问的工作。如果系统从不离开雇主自己的产品，这是应用 AI 工程师的工作。只有职责一路贯穿“上线”直到“移交”的启事，描述的才是第一行。

从这张表里能得出两点。第一，每一个相邻角色都是正当的工作。FDE 并不更高级；它要为一件其他角色都不负责的事担责：供应商离开之后，系统在客户的业务里能不能用。

第二，应用 AI 工程师在技能上离 FDE 最近，在处境上却离得最远。技术工作几乎完全相同。对于这一半的工作，本 wiki 的智能体评测页面已经讲过。应用 AI 工程师不必做的，是在另一家公司的政治里找到问题、在自己控制不了的基础设施上工作，以及设计自己的退场。这三件事就是本书大部分内容所讲的东西。

质疑者说对了一部分

对这个角色有三种严肃的批评。所有权检验能解释每一种，而不是把它们一笔抹掉。

“这就是换了个标签的 AI 工程。”Paden Gayle 关于这个角色的 O'Reilly 图书正处于抢先版阶段，他认为“很多被贴上 FDE 标签的内容，其实是换了名字的 AI 工程”。他划界的方式和本章差不多：在他的描述里，“一名工程师负责需求挖掘、范围界定、构建、部署、验证和客户关系”（O'Reilly 直播活动页面；T4，作者描述自己的课程）。他说得对。以 FDE 为名流传的东西，大多教的是构建，也就是 FDE 与所有 AI 工程师共有的那一个阶段；这正是本书为什么把技术栈链接到 wiki，而把篇幅花在构建两侧。有一处分歧：Gayle 把客户关系放在这个角色之内。OpenAI 的医疗健康启事则明确把商务关系排除在外。本书站在 OpenAI 一边：FDE 必须掌握与发起人之间的工作关系，但这单生意属于销售。

“这就是换了个好听头衔的 IT 外包。”2026 年 3 月，Gergely Orosz 报道说，他与一些接了 FDE 岗位后感到失望的工程师聊过。其中一人说：“这份 FDE 工作就是典型的 IT 外包思维”，以及“我四周后就辞职了”。Orosz 对这类抱怨的概括是，这样的 FDE 除了集成产品团队造好的东西之外，没做多少“软件工程”，并且“不会回馈到平台里”（The Pragmatic Engineer，2026 年 3 月；T4，通讯转述的两则轶事）。这只是两个人，不是一项调查。但这个抱怨说得很准，而所有权检验正好能预测它。一个没有产品闭环、对问题没有发言权的角色，是外包工程师的工作。这些工程师失望的不是 FDE 这份工作；他们得到的是一份丢掉了让它成为 FDE 工作的那些阶段的工作。Orosz 更早的文章已经把界线画在了同一个地方：“区别归根结底在于，FDE 与客户一起工作，同时也为公司所卖的产品做贡献”（Pragmatic Engineer，2025 年 8 月；T3）。

同一篇文章经由《华尔街日报》引用了 Betts Recruiting 的 Patrick Kellenberger 的话：“人人都想要他们，但市场上可能只有 10% 的人想做这个角色”（T4，一位招聘顾问的估计，经过两次转述）。把 10% 当作一个印象，而不是一个数字。但论点成立：许多能胜任这份工作的工程师不想要出差、不确定性或面对客户的工作，他们说不也没有错。

“它正在滑向咨询。”2026 年，OpenAI 和 Anthropic 各自成立了一家由私募股权资金支持的独立部署公司。最不客气的解读是：服务收入太诱人，于是供应商们建起了品牌更好听的咨询公司。所有权检验给出一个更窄、可以核实的解读。部署公司仍然可以做 FDE 式的交付，但前提是现场工作仍在反哺某个产品。一旦停止，里面的工程师就是会写代码的顾问，而上面那些失望的受聘者描述的，正是那份工作的滋味。“起源与经济账”给出了带日期的事实和两种解读。对求职者来说，实际要点很简短：如果 offer 来自一家部署公司，下面清单的第 6 行就是要最先问的那一行。

质疑者错在一些人由此得出的结论：这个角色是炒作，终将退回到它的相邻角色里去。一个能干的模型与客户结果之间的距离是真实存在的，它由误读的问题、够不着的数据、没规划的审查、没商定的数字和没人负责的系统构成，总得有人对它负责。质疑者表明的是，许多挂着这个头衔的工作并没有负起这个责任。他们并没有表明这段距离不存在。

合成案例：谁会丢掉什么

第 II 部分跟随一次交付，发生在一家区域性保险公司，从第一次销售电话一直到复盘。下面把这次交付放到各个相邻角色手里重演一遍，看看每一种丢弃会付出什么代价。

FDE 并不是单枪匹马。客户经理掌握合同，负责人谈判条款，理赔总监对阈值负责。对结果负责并不意味着包揽每一项任务。它意味着从问题到运行中的系统之间，没有一个阶段是无人负责的。第 II 部分的每一章，从“交付开始之前”到“当交付失败时”，讲的都是一个否则就会漏掉的地方。

模板：“这是一份 FDE 工作吗？”

投递之前拿一份真实的招聘启事跑一遍，拿到 offer 时再跑一遍。它读启事的方式和本章一样：按阶段读，每个回答都引用原文。每一行标 Y（启事明确这么说）、N（启事说的是相反的情况）或 ?（启事没提）。“?”不算不合格。它是第一轮面试要问的问题。

IS THIS AN FDE JOB?                 post: ____________  date: ______
Quote the post for every answer. Y = says so, N = says not, ? = silent

OWNERSHIP, DISCOVERY TO HANDOFF                          Y / N / ?
 1 Discovery: does the role find the problem, or get it   [ ]
   handed over on a ticket?  quote: ________________________
 2 Scope: does it agree scope and success criteria with   [ ]
   the customer?             quote: ________________________
 3 Build: does it write production code itself, or        [ ]
   design for a partner to build?  quote: __________________
 4 Production: does it stay until the system runs on      [ ]
   real traffic?             quote: ________________________
 5 Handoff: is "the customer runs it without you" named   [ ]
   as the end state?         quote: ________________________
 6 Loop: does field work feed the product, by a named     [ ]
   channel?                  quote: ________________________

SIGNALS THAT SHIFT THE READING
 7 Pay shape: base, or a base/variable split? ____________
 8 Team or job family: product / R&D / GTM / sales? _______
 9 Code: required, or "a plus"? __________________________
10 Who else is named alongside (AE, CSM, partner, PM)? ____

READING (take the first rule that matches)
 Mostly ? ............................ ask lines 1, 3 and 5 first
 N on 4-5 and a variable split ....... sales engineer, rebranded
 N on 3, or line 9 says "a plus" ..... strategist or architect:
                                       owns the problem, not the code
 N on 1-2 (problem arrives decided) .. contractor or delivery engineer
 N on 6 .............................. services; ask what happens to
                                       what you learn in the field
 1-6 all Y and code required ......... an FDE job, whatever the title

IF A LINE IS ?, ASK
 1 "Who decided what to build on your last engagement?"
 3 "Whose name is on the production commits?"
 4 "Where were you when it went live, and for how long?"
 5 "Who was running it three months after you left?"
 6 "Name one product change that came from the field."

下面是填好的版本，用的是一份因为难以归类而特意挑出的真实招聘启事：Harvey 于 2026 年 10 月 6 日在纽约发布的“前线部署金融工程师（并购基金）”（Harvey；T4，作为雇主要求什么来读）。

IS THIS AN FDE JOB?   post: Harvey, FD Finance Engineer, Buyout
                      date: published 2026-10-06, read 2026-10-17

OWNERSHIP, DISCOVERY TO HANDOFF                          Y / N / ?
 1 Discovery                                               [Y]
   "lead discovery, demos, pilots, trainings, onboarding,
   and custom builds alongside our AEs and CSMs"
 2 Scope                                                   [?]
   "running live pilots"; scope and success criteria
   are not mentioned
 3 Build                                                   [?]
   builds "workflows in the firm's own templates and
   formats"; "Python, SQL ... is a plus"
 4 Production                                              [Y]
   "throughout the pre-sales process and stay with
   them well past it"; continues "post-close"
 5 Handoff                                                 [?]
   no end state named; "value compounds after the
   first deal" suggests the role stays on
 6 Loop                                                    [Y]
   "bring deal-team feedback back into the product"

SIGNALS THAT SHIFT THE READING
 7 Pay shape: OTE with a "75/25 Split" (figures in box)
 8 Team: Finance Engineering, beside AEs and CSMs; the
   post names "the pre-sales process"
 9 Code: "a plus"; Excel, modelling and prompting required
10 Alongside: AEs, CSMs

READING
 Not mostly ?. Line 4 is Y, so the sales rule fails.
 Line 9 says "a plus": the strategist rule matches.
 Owns the outcome from discovery onward and feeds the
 product, but the means is configuring the product's
 workflows, not writing production code. The variable
 split and pre-sales work pull toward the deal.
 Verdict: a domain deployment role near the Deployment
 Strategist end. A real job; not an FDE in this
 book's sense. Ask: what does the variable pay for?

这个结论并不是批评。一位曾经做交易的专业人士，在 Harvey 的产品里为一家并购基金搭建尽调工作流程，并带着这家基金从试点走到日常使用，他负责的是一个真实的结果。清单揭示的是手段。代码只是“加分项”，所以这个角色和 Palantir 的部署策略师处在同一位置：负责问题和采用，站在工程师旁边，而不是作为其中一员。如果你想写生产系统，这份启事不适合你。如果你是想把交易工作变成产品的交易专业人士，它可能恰好合适。清单不替你做选择；它只是不让头衔替你做选择。把自己放到这份工作所看重的四类行为上去定位，是“技能地图”的主题。

使用时有两点提醒。第一，招聘启事是一种期望，不是一份合同。即使纸面上是 Y，也照样要在面试里问对应的问题，因为对方讲上一次真实交付的回答，是比启事更好的证据。去问将来会是你负责人的那个人，而不是招聘专员：负责人当时在场。第二，一份大部分是“?”的启事，通常意味着还没人想清楚。这给了你塑造这份工作的空间，也意味着它可能滑向当季指标更青睐的那个相邻角色。