OKFDE｜FDE 到底是什么？为什么工程师要走进客户现场【Insights #002】

OKFDE · Forward Deployed Engineering · Insights #002

01 / FDE

这个听起来像特种部队的岗位，到底在干什么？

FDE，全称 Forward Deployed Engineer（前线部署工程师）。

第一次听到这个词的人，脑海里往往会浮现出一个画面：一个背着双肩包的黑客工程师，从直升机索降到客户公司的大楼天台，十指翻飞黑进内网，拯救世界。

真实的画风通常朴素得多。

他坐在客户公司一张借来的工位上，一边看着控制台里跳出来的超时报错，一边听旁边的业务主管抱怨："你们这个东西，今天早上又把折扣算错了。"

这个名字在 Palantir 存在了十几年。当时大家觉得，只有做军工、情报、大反恐项目的硬核公司才需要这种"前线特工"。

结果到了大模型时代，它突然在 OpenAI、Anthropic、Scale AI 的招聘主页上成片出现。

更诡异的是它的 Job Description。以 OpenAI 的通用 FDE 为例，岗位职责一口气串联了：

传统 IT 人士看完直接陷入沉默。Discovery 是咨询顾问和产品经理的活；架构与构建属于研发工程；上线实施有专门的实施团队；客户用不用、ROI 高不高，那通常又落到客户成功团队。

OpenAI 几乎是面带微笑地，把这四五个部门的 KPI，全部塞进了一个人的背包里。

普通的工程师对"代码写完了"负责；FDE 对"从模糊的问题，一直走到业务结果发生"负责。

02 / SCOPE

一个 FDE 到底从哪里接手，管到哪里？

我们拿企业里最常见的"订单审核太慢"来举例。

如果走传统企业的研发交付链路，通常是这样的风景：

1. 客户 CEO 对销售说："我们订单审核太慢了，每个月被投诉，能不能用 AI 搞一下？"

2. 销售记在小本子上："客户痛点：提高订单流转效率。"

3. 解决方案架构师出了份 60 页的 PPT，画满了天花乱坠的微服务和流水线。

4. 产品经理把它拆解成一张张标准的 Jira 工单。

最后，经过四轮交接和无数封邮件转发，工单排期三个月，安详地躺在了研发小哥的看板上。

Ticket #3821: Add approval API

研发小哥没有任何过错。他按时交付了 API，单元测试覆盖率 99%，Swagger 文档齐齐整整，准时关单打卡下班。

六个月后，客户在复盘会上冷冷地问了一句。

"所以，我的订单审核，到底快了多少？"

会议室死一般安静。

因为谁也不知道，审核卡住的地方到底是缺一个接口，还是遇到折扣超过 15% 的时候，系统必须等李总手写签名；而李总每个月有三周都在外出差。

传统模式与 FDE 模式的差异可以画得很简单。

FDE 不会等着接那张被嚼烂的 Ticket。他第一天就会坐到审核员旁边，看他到底怎么点鼠标、遇到特殊情况问谁、为什么系统里的备注和实际批复永远对不上。

搞清楚真实问题后，他自己画架构，自己敲核心代码，自己陪着客户通宵上线。系统上线了，工作才刚刚到半场。他还要坐在客户工位边上，亲眼看着那个干了八年的审核老员工，把原来的 Excel 关掉，真正用起了这个新系统。

代码合入主干不能算交付，客户把新工作流跑顺了才算。

03 / ROLES

它和售前、实施、AI Engineer 到底有什么区别？

在科技圈，大家最擅长的事情之一就是发明新职位。有人会问，这不就是售前顾问（Solutions Engineer）或者驻场实施工程师（Implementation Engineer）换了个时髦的马甲吗？

名字可以随便起，但责任边界骗不了人。我们不妨看看这些角色在项目濒临翻车时，通常会把球踢给谁。

这张表并不是为了拉踩谁。在现实中，顶尖的 SE 会写一手好代码，优秀的 AI 工程师也会直接跟客户开会。

但 FDE 最独特的气质在于，他的责任半径极长，长到没有退路。

过去在职能切分非常细的团队里，你可以心安理得地顺手把烂摊子转给下一个人。"这是环境问题"、"这是业务理解问题"、"这是模型泛化问题"。而在 FDE 的世界里，只要这个问题阻碍了明天系统在真实业务里转起来，它就自动变成了 FDE 的 P0 任务。

04 / CONTEXT

为什么大模型时代，突然极度渴望这种"全能打手"？

在传统的 SaaS 时代，"Build once, sell many times"是所有人的信仰。你做个飞书或 Salesforce，只要用户按照你的按钮去点，系统就能稳稳运行。

但 Enterprise AI 完全是另一套丛林法则。

当一个 AI Agent 没把任务跑通，远方的工程师大概率会下意识去调 Prompt、换 Embedding 模型，或者抱怨模型又产生了幻觉。

只有坐在现场的 FDE 才会发现：

• Agent 报错真的因为它不够聪明吗，还是说它压根没有访问采购数据库只读备份的权限；

• 销售 CRM 里的“线索状态”字段，销售团队为了省事已经六个月没填过了；

• 业务方在宣讲 PPT 里画出来的五步极简审批，到了现场翻开抽屉，才发现实际上藏着九步人工对账和两个微信私聊确认。

更致命的惨剧往往是，技术团队熬了三个月通宵，模型调得无比惊艳，上线那天业务负责人看了一眼，淡淡地说："这块业务我们下个季度要砍掉。"

这些隐秘的暗礁，在项目开始前写进任何 PRD 都很困难。如果工程师坐在离现场三千公里的总部工位上，每一次试错都要经过三层人的邮件传递、情绪过滤和失真解释。

FDE 最大的不可替代性，就是把这个信息链路压缩到很短。他能同时看见系统在底层是怎么崩的，也能转头问清业务老油条为什么非要这么干。

离现场近，是为了少丢哪怕一点关乎项目成败的 Context。

05 / CAPABILITY

什么样的“怪胎”，能做好 FDE？

翻开各家顶尖公司的 FDE 招聘 JD，你会看到一张足以让普通程序员头晕目眩的技能清单。从 Python、全栈开发，到分布式系统、云基建，再到 Prompt Engineering、Fine-tuning、Agent 评测……

但这些依然只是硬指标。OpenAI 在 Government FDE 的 JD 里写过一句极具画面感的话："当项目陷入模糊或推进变慢时，能直接挽起袖子切入代码。"

客户跑过来说："我们想用 AI 颠覆现有客服流程。"

普通的开发者可能立刻开始选模型、拉框架。成熟的 FDE 会端着咖啡坐下来，像个老刑警一样顺藤摸瓜，一路盘问直到把这句宏大的愿景，拆成几个很快就能跑通验证的局部工作流。

既愿意随时打开 IDE 敲核心代码，也愿意推开会议室的门直面各种人类的扯皮。

TALENT MODEL / 六维能力画像

为什么不能只看写代码的能力？

只看刷 LeetCode 和算法水平，你根本猜不到一个人被空投到客户现场时会发生什么。代码写得再优雅，如果碰到企业内网的 Active Directory 权限和十几年前的古董 ERP 就手足无措，交付依然会瞬间爆死在现场。

为了让这个复合画像可讨论、可衡量，我们拆解出了 FDE 的六维能力模型。

• Engineering（工程能力）  自己动手写代码、排查线上最恶心 Bug 的硬实力。

• AI & Data（模型与数据）  懂模型边界、Prompt、Tool Calling 和评测系统，不盲信宣传。

• Enterprise Integration（企业集成）  能钻进陈年 API、古怪权限和各种内网魔改系统里把路修通。

• Product Sense（产品嗅觉）  能在一团乱麻的需求中判断先做什么。

• Business Domain（行业常识）  听得懂行业语言，也知道客户的业务怎么运转。

• Delivery & Communication（交付与推进）  能让相关团队达成共识，并对上线结果跟到底。

雷达图不是用来简单算总分的，它更适合拿来做项目配置和短板判断。

如果一个 FDE 的平均分达到 6.5，但 Enterprise Integration 明显断层，让他单枪匹马去接一个大集团的私有化 SAP 集成，风险依然很高。

成熟的 FDE 不要求六个维度全满分。更现实的要求，是核心工程交付、系统集成和客户结果责任上不能出现致命断层。

（对了，请持续关注我们，人才评估工具我们后续也会上线）

(｡•̀ᴗ-)✧

06 / PRODUCT

警惕"服务陷阱"：FDE 的价值，到底如何流回产品？

FDE 模式有一味致命的"毒药"。

因为 FDE 离客户太近，技术又好，人又靠谱，客户提什么奇葩需求，他顺手就能写个脚本填平。

客户 A 的数据库字符集奇怪？写个Patch。客户B的审批流有14种分支？写个 Special Connector。

一年过去了，客户被伺候得很舒服，销售提成拿满，但公司的代码库里会长出一个连上帝看了都要摇头的怪物。

Customer A / Special Integration / v7 / final / really_final
utils_do_not_touch_or_everything_dies.py

恭喜你，你的高科技 AI 团队，成功蜕变成了一家昂贵的高级定制外包公司。

所以，优秀的 FDE 团队在项目收尾时，会反复问一句。

"做完这家，我们到底给下一个客户沉淀了什么？"

OpenAI 在招聘 Healthcare 和 Government FDE 时，明确要求工程师把现场经验沉淀为参考架构、系统组件和 Playbook。

第 1 个客户可能需要从地基打起。第 10 个客户应该能复用前 9 个项目留下的能力套件。到了第 50 个客户，这套工作流甚至应该直接长成标品功能，不再需要 FDE 全程肉搏。

如果经验只留在现场，这更接近技术驻场外包；经验持续流回产品底座，Forward Deployed Engineering 才开始形成复利。

尾声 / FIELD NOTES

既能听见炮火，也能把弹壳带回兵工厂

理解 FDE 这个角色，不需要背诵时髦的硅谷术语。

他就是那个既能顶着前线刺鼻的硝烟，坐在客户工位上陪着业务人员改工作流，又能半夜回到代码编辑器里重构架构的人。

当所有人都在争论参数规模、Benchmark 跑分和绚丽的 PPT 时，他只盯住最现实、也最冷酷的一件事。

"这个东西，明天早上 9:00，客户到底能不能真正用起来？"

能把这个问题一路追到底的人，就是今天我们所说的 FDE。

NEXT / 下一篇

我们将深入剖析真实企业交付现场的“静默拒绝”、隐藏流程与人性博弈。

关于 OKFDE

我们关注 FDE，更关注 AI 真正落地之后发生的真实事件。

如果你也关注AI，关注产业，欢迎与我们建联。

参考资料

• OpenAI Careers｜Forward Deployed Engineer (FDE), SF

• OpenAI Careers｜Forward Deployed Engineer (FDE), Healthcare

• OpenAI Careers｜Forward Deployed Engineer, Gov

• Anthropic Careers｜Applied AI / Forward Deployed Engineer

• Scale AI Careers｜Forward Deployed Engineer, Gen AI