Kevin Bai 谈 FDE：客户买下平台之后，谁来交付结果

原始资料：《Forward Deployed Engineering 101》

发布频道：AI Engineer。活动：AI Engineer World's Fair 2026。演讲者：Kevin Bai，演讲时任 Anthropic Applied AI 团队技术人员。YouTube 视频发布于 2026-07-28，时长 00:17:48。

本文依据视频英文自动字幕整理，并结合主办方演讲页面核对名称与背景。商业数字和行业判断保留演讲者的陈述边界。

一家企业买下了技术平台，员工仍然不知道该用它解决什么问题。数据接进来了，工具也齐了，业务成果却还隔着一段工程工作。

Kevin Bai 用这个缺口解释 FDE，也就是 Forward Deployed Engineering，前线部署工程。工程师深入客户业务，在自家平台上做出客户真正用得上的应用和流程。

Bai 曾在 Palantir 工作，后来成为 Rippling 的首位 FDE 成员。他在演讲中回忆，这支团队在一年左右增长到约 25 人，这段经历也能在他的个人介绍中找到。如今他在 Anthropic 的 Applied AI 团队工作，但这场演讲讨论的是 FDE 的通用工作方式。

他的核心判断很明确：只有把客户交付建立在可复用的平台上，FDE 才有机会随着业务一起扩大。 客户越来越多，留下的系统也越来越多，维护责任会一直跟着团队。

客户付钱之后，还差一段工程工作

Bai 从 Palantir Foundry 的作用讲起：组织数据，让它们对应真实业务，再在上面构建应用。

他用仓库举例。企业需要知道哪个仓库是什么、有哪些相关数据，随后才能围绕仓库开展工作。Palantir 的 Ontology 文档进一步把这套结构描述为对象、属性、关系和操作。把它理解成业务对象的共同语言，比把它当成几张整理过的数据表更接近用途。

但数据结构清楚了，客户的生意未必就变好了。

消费品企业的负责人关心货架陈列和销售效率。数据怎样组织，是支撑这些目标的技术工作。平台供应商如果只交付工具，客户还得培训员工、学习平台、安排开发，然后才能开始获得价值。

FDE 把其中一段责任接了过来：理解客户经营中的问题，利用平台做出解决方案，让软件能力与业务结果连接起来。

Bai 所说的客户购买结果，描述的是这套交付逻辑。演讲没有给出按效果计费的合同条款，也没有承诺某个业务指标必然提高。

先判断买家能否自己用好产品

在 Bai 的买家与产品分析里，技术复杂度只是其中一个变量，还要看谁来消化它。

GitHub、Datadog 可以很复杂，但它们面对的技术负责人和工程师，通常有能力理解并使用这些工具。学习技术工具，本来就是这群人的工作组成部分。

Rippling、Jira、Slack 则被他放在另一种常见使用情境里：客户主要通过配置使用已有功能。这类产品也可能复杂，但用户通常不需要先从零开发一套应用。这里讨论的是购买和使用方式，并不表示这些产品没有扩展或开发能力。

FDE 要处理的是两端不匹配的情况：供应商卖的是需要继续开发的技术平台，买家却缺少完成这段开发的能力。

Bai 提到，Google、Meta 和模型实验室有很强的工程团队；一家油气行业的大企业，未必拥有同样的工程配置。平台的功能再丰富，也不能假定每个客户都能自己把它用好。

于是，供应商提供熟悉平台的工程师，与客户一起解决问题。客户不必为了使用这款平台，单独承担招聘、培养和留住这批工程师的全部工作。

大合同背后，也有一笔维护账

Bai 用一组合同金额的比较，说明这种交付方式可能承载的商业价值。

他在这里把 ACV 明确解释为平均合同金额，列出的数值是：

• Palantir：约四百万美元。
• ServiceNow：约一百二十万美元。
• Workday：约六十万美元。

他还称，其他上市 SaaS 公司没有一家超过五十万美元。

这组数字需要连同限定条件一起读。他谈 Palantir 时说的是自己上次查看的数字，对 Workday 的数值也带着记忆上的不确定。演讲没有提供统计日期、样本和统一口径，因此它们只能作为他在台上的引用，不能直接当成当前市场排名，也不能换算成年收入或证明 FDE 单独造成了这些差异。

比金额更值得顺着往下算的，是每份合同留下的维护工作。

Bai 把 FDE 比作扩大到企业客户的设计伙伴合作。创业公司早期常与客户共同探索：客户提供业务背景，团队投入工程和技术，一起找出有用的产品。

这类合作可以带来深入的客户理解。但每来一家客户就从头写一套系统，团队很快会被不同代码、不同需求和不同故障拖住。

他的答案是共享平台。工程师利用已有的基础能力，组合出客户需要的应用和工作流。平台承担可以重复使用的部分，交付团队处理具体业务中的差异。

复用能减少重复建设，维护责任仍然存在。 Bai 特别强调，即便平台已经相当扎实，客户系统也会带来持续的维护负担。

启动 FDE 前，先回答两个问题

Bai 给准备组建团队的公司提出了两个前提。

第一个问题是：公司的业务是否确实需要把复杂技术卖给非技术买家？

如果买家本来就会开发，开发者关系和开发者社区可能更适合解决采用问题。若产品属于成熟、可配置的 SaaS，传统销售团队也可能足够。FDE 的热度，不能替代对客户使用障碍的判断。

第二个问题是：公司是否已经有平台，或者愿意投入资源建设平台？

一支能直接带来收入的工程团队很有吸引力。但每个人都从头做项目，新增收入也会不断带来新的维护义务。团队需要共同的基础能力，让客户交付的经验有机会积累下来。

这并不要求公司在接触客户前，就把平台做得无所不包。Bai 在后面的问答中允许另一种起点：先有有限的基础能力，再从现场工作中发现下一批值得共建的功能。

真正需要明确的是，公司是否愿意同时承担客户交付和平台建设这两份工作。

平台应该做到多细，取决于客户差异

现场有人问，可复用的基础能力应该有多细？做到数据库这一层，还是接近一个完整应用？

Bai 没有给统一的粒度标准。他举了一个假设：某些行业里，应用可以提前完成 60%，客户再定制剩下的 40%。其他场景则需要更细的工具和配置能力。

这里的 60% 和 40% 是说明差异的例子，不能拿来当作平台复用率的目标。

他借 AWS 说明共享基础能力的价值。工程师可以使用 DynamoDB 这样的数据库服务，把精力放在上层应用。面对很广泛的客户需求，平台提供相对通用的基础构件就有意义。

若客户处在同一个较窄的业务场景，平台则有机会提前完成更多应用层工作。基础能力究竟做到哪一层，需要由用户群和需求差异来决定。

客户现场的经验，怎样回到产品里

关于FDE 与平台团队的分工，Bai 给出的方向是：只有某个客户需要的东西，可以留在这个客户的方案里；能够通用的能力，长期应当进入共享平台。

这里需要保留长期两个字。客户提出需求，并不自动代表核心产品应该立即增加一个功能。FDE 的现场工作也承担探索作用：发现哪些需求值得反复解决，再帮助平台长出新的能力。

人员之间的知识传递同样重要。在讨论协作方式时，Bai 起初把问题理解为同一项目里多名 FDE 的合作。他支持这种安排，因为客户系统的知识若只掌握在一个人手里，这个人休假就可能让团队无法接手。

提问者随后澄清，问的是来自不同公司的团队合作。Bai 的回答转向承包商或合作伙伴关系：首先需要明确双方在项目里的关系，以及谁承担承包方的角色。这段回答没有提出一套通用的跨公司协作流程。

最后，招聘 FDE 的标准被他压缩得很直接：这个人应当达到团队招聘软件工程师的标准，同时也值得被信任，可以直接面对客户。

写代码的能力和与客户合作的能力，需要出现在同一个人身上。

AI 让代码更容易写，交付仍然需要人负责

Bai 在讨论 AI 带来的变化时提出了一个个人假设：软件更容易生成，也更容易按客户需要定制，销售和交付软件的方式因此正在改变。

保险、法律等领域都在出现智能体产品。可定制能力越强，供应商越需要面对同一个现实问题：客户是否知道怎样把这些能力放进自己的业务？

如果供应商把产品成败完全交给客户的实施能力，就可能在争取更大客户、进入更多行业时遇到困难。这是 Bai 对市场变化的判断，不能据此断言每家 AI 公司都需要 FDE。

把他的几条建议放在一起，交付的重点就更清楚了：理解客户的问题，把系统做出来，让团队能够继续维护，再把反复出现的需求沉淀成共享能力。

代码生成得更快之后，客户能否持续用好软件，仍然需要有人负责。