稀饭

FDE 是什么:人工智能时代最抢手的岗位——是什么、有什么要求、该怎么做

企业 AI 项目 95% 阵亡,岗位需求却一年涨七倍。前沿部署工程师(FDE)是什么、需要什么能力、如何沿着「找对问题→赢得客户→激活部署→守住续约→扩大收入→规模化复制」的完整旅程落地——借范冰《FDE 从零入门指南》全解析。

  • AI
  • FDE
  • 前沿部署工程师
  • Palantir
  • 职业
  • 开源项目

前面的几篇,我们聊的都是给编码代理装技能的项目——Superpowers、ECC、graphify, 核心都围绕一个命题:让 AI 自己把活干好。 今天这篇换一个角度,聊一个人的岗位——这个岗位被很多人说是 "人工智能时代最抢手的工作"。

它就是 FDE(Forward Deployed Engineer,前沿/前线部署工程师)。 中文社区最系统的入门读物,是《增长黑客》作者范冰(XDash)刚刚开源的一本书——《FDE 前沿部署工程师:从零入门指南》,上线一周就拿下 3000+ star。 这篇就借这本书的框架,回答三个问题:它是什么、有什么要求、该怎么做。

一、它是什么:一个岗位,一年涨了七倍

先讲两个放在一起看的数据。麻省理工学院 NANDA 实验室 2025 年发布 《生成式人工智能的鸿沟》(The GenAI Divide) 报告:过去三年,全球企业在生成式 AI 上烧了 三四百亿美元,其中 95% 的项目没有产生任何可衡量的财务回报。 几乎同时,硅谷招聘网站上一个岗位的发布量一年涨了七倍—— OpenAI 在招,Anthropic 在招,YC 里一百多家创业公司都在招。

一边是企业 AI 项目 95% 的阵亡率,一边是岗位需求一年暴涨七倍。 把两条新闻摆在一起,答案不难猜:模型已经不稀缺了, 能把模型塞进客户真实业务里的人,才稀缺。

这个岗位就是 FDE,而它最早是从 Palantir(彼得·蒂尔 2003 年创办的情报数据分析公司) 长出来的。书中有一段经典描述:造软件的地方,和价值产生的地方,不在一个地方—— 墙这边,需求被工单、纪要、周报层层转述,每转述一次就失真一层;墙那边,客户的真实工作流 藏在没人写进文档的表格里、口耳相传的惯例里、"这事得问老王"的隐性知识里。 Palantir 的答案很朴素:不翻墙了,把人送过去。

FDE 就是那个"被送过去的人":驻在客户现场,把模型塞进客户真实业务里的工程师。

需要注意,"前沿部署"这个名字源自 Palantir 的情报背景——把分析能力部署到离情报源最近的地方。 今天它的含义是:把 AI 能力部署到离客户真实业务最近的地方。 它是工程师,但不是纯粹的写代码的工程师;它也做售前,但不是靠嘴的售前; 它懂产品,又身处服务一线。用一句话概括:FDE 是"工程师 × 售前 × 产品"三者合一的角色。

这个角色为什么在 AI 时代爆发?因为 AI 项目失败的原因几乎不在技术。 报告归纳出的五大路障——员工不愿用、担心模型质量、糟糕的体验、缺高管支持、变革管理难—— 全部发生在"问题定义"和"组织现实"层面,而不是"模型不够聪明"。 换句话说:企业缺的不是模型,是有人把工具塞进车间真实的流程里。这正是 FDE 干的活。

二、有什么要求:不是一个"更卷的程序员"

很多人第一反应是"FDE 是不是就是更全能、更能吃苦的程序员?" 书里给的答案要微妙得多。把全书对 FDE 能力的描述拆开,大概是下面这几条:

  1. 技术上是"全栈通吃"的工程师,但不以写码为重心—— FDE 什么都要会一点:接数据、写集成、改配置、调模型、看指标。 但它的重心不在"写漂亮代码",而在"让系统在客户环境里真正被用起来"。
  2. 极强的业务翻译能力——把客户"客服主管每周一花三小时手动汇总工单" 这种模糊痛点,翻译成可量化、可交付的问题。 书里给了个锋利标准(来自 Palantir 前高管麦格鲁):去解决 CEO 最关心的五个问题之一——只有这个量级的问题, 才够力碾过企业内部的官僚阻力。
  3. 能跟客户上上下下打交道——不是沟通能力好的工程师, 而是能在"客户高管面前讲数字、在客户一线员工旁边改配置"之间自如切换的人。
  4. 能忍受混乱与驻场——书里引用前 Palantir FDE 的自述: 成本、混乱与倦怠是真实账本;招聘网站上 Palantir FDE 的薪酬福利 4.0 分(满分 5), 工作生活平衡却只有 2.8 分,高频抱怨是工作节奏被打断。常年一半时间出差的团队,倦怠率显著更高。
  5. 把"失败"当成原材料——FDE 的现场交付,失败不是意外,是必然。 Palantir 把接受失败写进制度:试点就当风险投资来打,多数会死,死完必须复盘。 复盘的唯一规则是"对事不对人"——一旦复盘与绩效挂钩,人们就会开始修饰失败。
  6. 最难的一条:反直觉的谦逊——书里反复强调 "去他的可泛化性"(先解决眼前这个客户的问题,而不是急着做一个放之四海而皆准的方案)。 对很多工程师来说,不追求完美方案、不追求通用架构,是最反本能的一件事。

顺带澄清一个常见误解:有人说 FDE 就是"换了个名字的售前"。 区别在结果导向:售前签完单就交棒,而 FDE 要一直跟到 "系统真的被用起来、客户真的愿意续约"。书里给了一句很狠的话—— 判断你是不是在做 FDE,而不是在做外包,就看一件事:你的定制工作量,是不是随着客户数在递减。

三、怎么做:一场真实交付的完整旅程

书的主体框架,是沿着一次真实交付的完整旅程展开的: 找对问题 → 赢得客户 → 激活部署 → 守住续约 → 扩大收入 → 规模化复制。 每一步都值得单独一篇,这里给你一条浓缩的地图。

1. 解决正确的问题(第 2 章)

这是全书的第一性原理:写第一行代码之前,先确保你在解决正确的问题。书里提出了一个叫 PSF(Problem-Solution Fit,问题与方案的契合) 的概念, 和互联网的 PMF(Product-Market Fit)对应,但视角反过来了—— PMF 问"我的产品有没有市场要",PSF 问"客户这个具体的问题,值不值得、能不能被我们解决"。

一个企业客户内部可能有几百个"AI 能做点什么"的机会点,但真正值得做的必须同时过三关:

  • 痛点检验——是不是某个具体的人的具体痛点? "提升客服效率"不是痛点,是方向;"客服主管每周一早上要花三小时, 从四个系统里手动汇总上周的升级工单"才是痛点。
  • 经济性检验——解决这个问题值多少钱? 算不清楚账的项目,做了也活不过下一个预算季。
  • 转化检验——验证项目能不能进入付费部署? 书里提到 Palantir 把 PoC 转化率从早期的 5%~10%,提升到了约 75%。

书里还有一个扎心的对照:与外部专业供应商合作的项目,成功率约为内部自建的三倍。为什么?因为按结果收钱的人,定义错问题的代价是自己买单。

2. 赢得客户(第 3 章)

核心是筛选"灯塔客户":不按合同金额排,而按两个维度排—— 这个客户的灯塔价值(行业信号强度)和学习价值(能沉淀多少可复用能力)。两个维度都高的客户,可以、也应该倒贴资源优先做; 两个维度都不高的大合同反而最危险——钱看着多,却把精英团队套牢半年。

同时要警惕"需求蝗虫":预算充足、需求旺盛,但会吸干你团队、却不产生任何复利的客户。 判断标准是三个——需求与公司战略明显偏离;把 FDE 当廉价外包按人头使唤; 内部政治消耗巨大,主要工作变成帮某个部门证明另一个部门错了。

3. 激活部署(第 4 章)

"上线"不等于"激活"。企业部署有一个"首日魔咒":系统上线了,但没人用。 书里给出的一套打法很精彩:

  • 寄生在用户已有的界面里——用户在主战场工作,你的系统就该出现在哪: 他在表格里工作,你就做表格插件;他在邮件里审批,你就让审批在邮件里完成。 要求用户登录一个新系统,等于在你和他之间加了一道每天都要翻的墙。
  • 用 AI 打 AI 的集成战争——没有接口的老系统,用浏览器智能体模拟人去取数; 字段映射、格式转换、接口文档解读,大量交给模型处理。
  • 交付工作本身自动化——把环境搭建、权限配置、监控接入打包成 一键式 IaC;把主流企业系统做成可复用的连接器;用检查清单把"依赖个人经验" 变成"依赖组织记忆"。Sierra 从启动到上线最快的不到两周,Palantir 把销售周期 从九个月压到几周——不是靠加班,是靠把昨天的交付变成今天的脚手架。
  • 变革管理:让客户组织为你站台——书里的 Lyft × Anthropic 案例: 双方共建产品、Lyft 优先测试新能力、Anthropic 为 Lyft 工程师提供培训三件套, 结果客服平均解决时长降了 87%。

4. 守住续约(第 5 章)

激活让项目活过第一年,续约决定能不能长期活下去。 书里强调的是设计"健康分":把使用、价值、关系、商业四类信号合成一个评分, 每周全量巡视,跌破警戒线就自动触发干预流程。单点依赖是要警惕的—— 客户组织里只有一个"关键支持者",他走了,项目就可能死。

5. 扩大收入(第 6 章)

核心是按结果收费:客户得到什么,就为什么付钱。 以及存量深耕——从一个部门扩展到一张大网。书里还讲了一个很聪明的做法: 用 AI 交付 AI 部署的活,让"现场反哺产品"——当一万个人在问同一个功能, 它就该被排进产品优先级。

6. 规模化复制(第 7 章)

这是 FDE 模式与"高级外包"之间的最后一道防线。书里给了一个三级杠杆模型:

  1. 一级杠杆·知识复制——把"怎么做"写成打法手册、检查清单、培训材料, 把对个人经验的依赖变成对组织记忆的依赖(新人上手从一年压到三个月);
  2. 二级杠杆·组件复制——把"做过的"变成"能直接用的": 集成连接器、评估框架、部署模板、行业数据模型;
  3. 三级杠杆·产品复制——把"反复出现的定制"抽象成平台标准能力, 从此这个需求不再需要任何工程师到场。这一级改变的是整个生意的成本结构。

麦格鲁那句"砾石路与高速公路"说的就是这个递进:FDE 修砾石路(解决眼前问题), 组件团队铺碎石路基(让下一辆车好走),平台团队浇高速公路(从此人人可通行)。如果不把现场学习转化为产品资产,你得到的只是一堆定制项目——恭喜,你重新发明了咨询公司。

四、它跟"给 AI 装技能"那几篇的关系

前面几篇的 Superpowers、ECC,本质是在回答同一个问题的两个侧面:让 AI 代理成为更可靠的工程师——纪律、体系、团队、品味。 而 FDE 回答的是另一侧:让工程师成为更懂客户业务的人。

有意思的是,这两条线正在合流:当 AI 能把"写代码"这件事做得越来越好的时候, "人的价值"就越来越往"理解真实业务、搞定组织现实"的方向迁移。 前几篇是"AI 时代工程师的工具箱",这篇是"AI 时代工程师的位置在哪里"。 对做个人 IP、想走"技术 + 商业"路线的你来说,FDE 可能是值得认真看一眼的方向。

我的收获

  1. AI 落地的瓶颈不在模型,在"人"——95% 的阵亡率、五大路障没有一条是技术问题。 这解释了为什么 FDE 会暴涨:模型越强,能把模型塞进真实业务的人越值钱。
  2. PSF 先于 PMF——先确认"客户这个具体问题值不值得解决", 再谈"产品有没有市场"。对企业 AI 项目,问题定义比方案炫技重要得多。
  3. 交付即投资,不是成本——Palantir 把试点烧掉的钱记在研发账上: 每一次实施首先是构建与学习的机会,其次才是生意。这种"复利思维" 是 FDE 模式能跑赢传统外包的根本。
  4. "被送过去的人"是全书的灵魂——软件行业的墙永远在那里, 与其发明更多翻墙的梯子,不如承认:有些价值只能靠"人在现场"来交付。 这句话对做内容、做产品、做服务的你,同样适用。

这本书在GitHub 免费公开,完整目录从自序到附录 C 全都可以在线阅读。 如果你也想弄清楚"人工智能到底怎么在企业里落地",这是目前中文圈最系统的一份资料—— 顺手给它点个 star,也算是对作者坚持开源的感谢。