看你服务的客人有多杂
有的行业能先做好六成、现场调四成；有的场景得给很细的原料和工具。AWS 像一家超市：DynamoDB 这种现成数据库就像买来的盐，不用自己晒——因为它的客人极杂。
现实里做数据模型类平台，起码别让客户从零定义数据模型。
FDE 101 · 图解绘本AI Engineer World's Fair 2026 · 17 分钟演讲
上门做饭的工程师
有一种软件工程师，不在自己公司里写代码，而是被派到客户那里，用自家的平台替客户把事情做成。它叫 FDE（Forward Deployed Engineer，前线部署工程师）。下面用一个比喻把它讲清楚：上门厨师。
一句话：FDE ＝ 带着中央厨房备好的半成品，上门替客户把菜做好的工程师。
讲者 Kevin Bai · Anthropic 应用 AI 团队曾任 Rippling 首位 FDE（一年带到约 25 人）更早在 Palantir
01 / 11
先认识一个很厉害的厨房
Palantir 卖的平台叫 Foundry，像一个智能厨房：把你家乱糟糟的冰箱理得清清楚楚，每样东西贴上名字，还能直接拿来做菜。
动画：乱箱子 → 贴名字的罐子 → 下锅
现实里冰箱里的杂物 ＝ 公司散落各处的数据；贴上名字 ＝ 本体（Ontology），把“表1、表2、表3”变成“仓库、门店、货车”这样的名词；做菜 ＝ 在上面搭应用。
“数据是整齐了。可这对我的生意有什么用？”Kevin 设想的行业老板的第一反应
02 / 11
卖厨房？卖钟点？还是卖一桌菜？
同一个平台，有三种卖法。点一下，看客户最后吃没吃上。
- 厨师上门，先弄懂你想吃什么
- 带着中央厨房备好的半成品，现场做
- 你拿到的是一桌菜，而不是一堆锅碗瓢盆
客户买的是结果。Palantir 就是这么卖的：软件和工程师打包成一件东西。
现实里好比快消品老板要的是饮料“上架多、卖得快”；数据怎么整理，只是实现细节。
03 / 11
什么时候，非得派厨师上门？
看两件事：你卖的东西难不难用，买的人会不会做饭。四个格子里，只有一格需要上门。点格子看例子。
买的人会做饭懂技术
买的人不会做饭不懂技术
专业灶台得会做饭才能用
微波炉按按钮就行
演讲没讲这一格
Palantir 所在的格子。Foundry 是“搭应用的平台”，得在上面开发才出价值；它的客户却常常是没有软件团队的传统企业。
“软件工程师，大概是最不该面对客户的一群人——包括我自己。”Kevin 的自嘲。所以只有非派不可，才派。
现实里专业灶台 ＝ 很技术、要在上面开发的平台；微波炉 ＝ 复杂但“可配置”的工具；会不会做饭 ＝ 买家懂不懂技术。
04 / 11
大厂自己有厨师，油田没有
谷歌、Meta、AI 实验室里满是工程师，想要什么应用自己就能写。世界 500 强的油气公司呢？管道里流的是油，不是数据。
动画：一位厨师走进了没有厨师的公司
“我们借你几位很好的工程师”——他们早就精通平台，像高级餐厅的服务员，先弄清你要什么，再替你把问题解决、把软件搭出来。Kevin 自己打的比方
现实里Palantir 就是这样把平台卖进全球 500 强的。
05 / 11
这样卖，一位客户花多少钱？
Kevin 报了几家上市软件公司的“客单价”（ACV：平均每个客户在这家公司身上花多少钱）。小票越长，花得越多。
查看数据表
| 公司 | 平均合同额（美元） | 讲者的说法 |
|---|---|---|
| Palantir | 约 4,000,000 | 第一，“我上次查的时候” |
| ServiceNow | 约 1,200,000 | 第二 |
| Workday | 约 600,000 | “我想是” |
| 其余上市 SaaS | 均 < 500,000 | “没有一家突破 50 万” |
按口述数字算，Palantir 是第二名的 3.3 倍；而且员工只有几千人，估值却“高得离谱”。“离谱”是原话，Kevin 没给估值数字
口径Kevin 说的是“世界 500 强里的上市 SaaS 公司”，数字凭记忆（“我上次查的时候”“我想是”），没给统计时间和算法。只能看量级，不是严谨的横向对比。
06 / 11
其实就是“试菜”，只不过放大到了宴会
新店开张前，会请熟客试菜：客人讲口味，厨师出人出料，改到满意为止。Palantir 问：凭什么只有开业时才能这么干？
动画：一张小桌 → 整个宴会厅
谁说“设计合作”只能在创业初期做？为什么不能在大企业里规模化地做？Kevin 转述 Palantir 的核心主张
现实里试菜 ＝ 设计合作（design partnership）：客户提供问题和背景，你出时间、技术和资源，一起做出好方案。很多 B2B 创业公司靠它找到产品市场契合。FDE ＝ 把它放大到大企业。
07 / 11
可要是每一桌，都从种菜开始呢？
台下一定有人反驳：每位客户都定制一套，谁维护得过来？拖动滑块加客户，比比两种做法。
私厨作坊每位客户一片菜园
要打理的东西（示意）
中央厨房大家共用半成品
要打理的东西（示意）
“没人想去学 55 个代码仓。”——“你完全正确。”如果每个 FDE 都从零写，你拥有的不是 FDE 团队，而是一家外包作坊。Kevin 先替台下说出反对意见，再表示认同；他补充说作坊也挺赚钱，只是它不是 FDE
现实里菜园 ＝ 每家客户一套从零写的代码仓；中央厨房 ＝ 平台上的共用积木（shared primitives）。滑块和维护条是示意，不是演讲数据。Kevin 也强调：就算平台很扎实，维护负担依然不小。
08 / 11
想派厨师上门？先问自己两个问题
这是 Kevin 给所有想建 FDE 团队的人的建议。替你的公司答一下：
① 我是真的需要，还是只是想要？
检验标准：你是不是必须把一台“专业灶台”，卖给不会做饭的人？别因为它时髦就想要。
② 我有中央厨房吗？或者，愿意花钱建一个？
没有共用的半成品就上门，Kevin 的原话是：“你会过得很惨。”
可以开始招上门厨师
两道门都过了。招什么样的人？见第 10 页最后一问。
现实里DevRel ＝ 开发者关系，面向技术买家的打法；SLG ＝ 销售驱动增长（sales-led growth），传统 SaaS 的常见打法。Kevin 说这两条路都很好，只是不需要 FDE。
09 / 11
为什么现在人人都在谈？因为菜单变得无限长
Palantir 起步时（Kevin 记得是 2004、2005 年前后），做菜很难。如今 AI 让“做菜”变得很容易，人人都在做某某领域的 Agent。切换年代看看。
“保险、法律 Agent”是 Kevin 举的例子；灰条代表数不清的其他能力
现实里Kevin 的个人假设：几乎每个平台都变成了 agentic（智能体式）→ 几乎都能深度定制 → 客户根本不知道你到底能做什么。变的不是大家突然发现 FDE 好，而是软件生意本身变了。
如果把产品的成败交给客户自己的实施能力，不管想往上打大客户，还是横向、纵向扩张，都不会轻松。Kevin 原话的意译
10 / 11
台下的四个追问
现场问答里最有用的四问，照样用厨房来讲。
至少两位，别留单点故障
只有一个人知道全部情况，这个人一休假就完蛋，所以一个项目最好多派几位。两家公司的厨师同场（比如 AWS 和 Palantir 都派人）也有，就像请承包商：先说清谁是总承包。
独有的留下，通用的收回厨房
只对一位客户有意义的，留在那位客户那里；好几家都要的，长期都该沉淀进平台。刚起步时共用积木少也没关系——FDE 正好是侦察兵，替公司找到下一批值得做的产品。
一个面向客户的软件工程师
Kevin 留下的一句话：FDE 说到底，就是面向客户的软件工程师——够格进你的工程团队，你也放心带到客户面前。其余的，边做边摸索。
11 / 11
把比喻翻译回来
| 中央厨房 | 平台（例如 Palantir 的 Foundry） |
| 备好的半成品 | 平台上的共用积木（shared primitives） |
| 上门厨师 | FDE：面向客户的软件工程师 |
| 一桌好菜 | 客户真正要的业务结果 |
| 每桌都从种菜开始 | 外包作坊（dev shop）：每家一套从零写的代码 |
| 试菜 | 设计合作（design partnership） |
| 小票长度 | ACV：平均每个客户花多少钱 |
| 菜单无限长 | agentic 平台什么都能做，客户反而不知从何用起 |
FDE ＝ 带着中央厨房的半成品，上门替客户把菜做好的工程师。
前提有两个：你真的需要（复杂的东西 × 不懂技术的买家），而且你有中央厨房（平台）。少了第一个，别派；少了第二个，你开的只是外包作坊。