企业什么时候才真的需要 FDE？组建 FDE 团队前，需要先通过两道闸门...

在企业软件里，一个反复出现的难题是：厂商交付了强大的底层平台，客户付费之后，却依然不知道怎样把平台能力变成实际业务结果。以 Palantir Foundry 为例，它能集中数据、构建本体（ontology），把底层数据变成仓库等业务对象，并在其上开发应用。但企业负责人仍会追问：「这对我的实际业务有什么用？」如果只卖技术，厂商就把理解问题、学习平台和构建应用的责任留给了客户。

前线部署工程师（Forward Deployed Engineer，简称 FDE）试图填补的，正是平台能力与业务结果之间的这段距离。Kevin Bai 现任职于 Anthropic；他在 AI Engineer World's Fair 的《FDE 101》演讲中，围绕什么是 FDE、企业为什么需要它，以及为什么他判断 AI 时代会让更多公司采用它展开。此前他曾在 Palantir 从事相关工作，并作为首位成员加入 Rippling 的 FDE 团队，帮助团队在一年内扩展至约 25 人。这份材料最值得读的地方，是它给出了两项很具体的判断：什么样的产品与买家组合真的需要 FDE，以及什么样的平台基础能防止它滑向开发外包。

客户买的应当是结果，而不是一套等待学习的平台

如果只卖平台，客户不仅要为软件付费，还要再投入人力学习平台，才可能构建出有用的应用。FDE 把平台与工程服务合在一起：工程师先理解客户的业务，再在平台上组装解决方案。客户购买的不再只是软件，也不是单纯购买某个人的工时，而是一个能够运转的业务结果。在这种方式里，常规做法是厂商卖出平台后，由客户承担学习和实施；FDE 则把理解业务、在平台上构建方案和交付结果放进客户购买的整体服务里。因此，FDE 不是成交后才派来补救的实施人员，而是产品销售和交付方式的一部分。

以快消品（CPG）企业为例，业务方关心的是商品能否进入更多货架、销售额能否提高；数据如何组织只是实现细节。FDE 的任务，是理解这些业务需求，再用已经存在的平台能力把方案构建出来。

这种协作方式并不陌生。B2B 创业早期，团队和客户常常都还没完全弄清产品最终是什么、客户究竟在买什么。客户提供自己的真实问题，团队投入时间、资源与技术共同构建方案，并在过程中找到客户真正愿意付费的产品形态，也就是产品市场契合（PMF）。FDE 可以理解为把这种「设计伙伴关系」（Design Partnership）延续到企业客户的长期交付中，而不是只在创业的最初 18 个月这样做。

一张 ACV 图，能说明什么、不能说明什么

客单价（ACV）是一个客户一年向厂商支付的金额。这组数字不是为所有公司划出统一的投入门槛，而是显示 Palantir 的单客户收入与其他大型企业软件公司相差多大。