前沿部署工程 101：把平台卖成结果

当客户买了一个强大的平台，却不知道怎么把它变成业务价值——这时候，就需要前沿部署工程师出场了。

整理自 Kevin Bai 在 AI Engineer 的演讲 · 2026

Anthropic 工程师的演讲《 Forward Deployed Engineering 101》，是我看过的对 FDE 讲的最清楚的一期视频。

前沿部署工程（Forward Deployed Engineering，简称 FDE），是将复杂平台与实际业务成果连接起来的一种工程组织方式。但这门生意能不能跑通，取决于两个关键前提：底层是否有可复用的共享基础组件，以及客户定制化工作和核心产品开发之间是否有清晰的边界。

Kevin Bai 结合自己在 Palantir、Rippling 以及 Anthropic 应用 AI 团队的工作经验，做了一次系统性的分享。他在 Rippling 是首位 FDE 团队成员，该团队一年内就扩张到了 25 人左右。以下是演讲的核心内容。

1. 整理好的数据能为企业带来什么

以 Palantir 的 Foundry 平台为例。它的核心作用是将企业数据集中起来，创建一个"本体"（Ontology），并提供一个构建应用的基础平台。

所谓"本体"，可以用一个仓库的例子来理解：企业得到的是所有仓库数据的"唯一事实来源"，远超一堆相互脱节的数据表。数据被赋予了实际的业务含义——变成了人们可以直接理解和操作的概念。

但即便如此，买家仍然有理由追问：把数据整理成这样，到底能给我的业务带来什么？一个平台能否成功，取决于客户能否真正用好它。这就带来了一个购买价格之外的"采用成本"：员工必须先学会使用平台，然后才能在上面开发出有用的应用。供应商卖出的是一种"能力"，但如何把这种能力变成价值，难题留给了客户。

FDE 的核心，就是将软件和工程服务结合起来，打包成一个"结果"卖给客户。 FDE 工程师会深入学习客户的具体业务，然后直接在平台上为他们量身打造解决方案。客户买到的是软件和工程服务的结合体——一个可交付的结果。

比如，一家消费品包装公司可能希望自家商品在超市货架上占据更好的位置，或者想提高销售额。为了实现这些最终结果，如何组织数据就成了至关重要的底层实施细节。

2. 让产品的复杂度与买家相匹配

Bai 用一个二维矩阵来解释产品采用的难题：你卖的是什么产品？谁来买它？单纯的产品复杂度并不一定需要引入 FDE。真正关键的是，客户是否有能力消化这种复杂度。

真正触发 FDE 需求的，是第三种情况——你正在把一个技术要求极高的平台，卖给一个非技术的买家。

这种"错位感"恰好解释了 Palantir 的市场空间。像 Google、Meta 以及各大 AI 实验室，他们本身就拥有大量能开发内部应用的工程师。但一家财富 500 强的石油天然气公司，可能根本没有这么深厚的软件工程实力——毕竟他们的管道里流淌的是石油，跟数据处理无关。

FDE 刚好填补了这条鸿沟。它直接为客户提供优秀的工程师，客户无需自己去招聘、管理或留住这些人。Bai 把这种细致入微的关注比作高级餐厅里的服务员：了解客户需要什么，本身就是交付服务的一部分。

3. 交付业务结果背后的商业价值

为了说明这种模式的商业吸引力，Bai 对比了财富 500 强企业在各大上市 SaaS 公司上的花费，用 ACV（Average Contract Value，平均合同价值）来衡量：

这些只是 Bai 提供的参考数字，没有说明具体的测量日期或计算方法，主要是为了说明该模式在商业上的竞争力。他还提到，相对于 Palantir 仅有几千名员工的规模，其估值高得令人惊讶。

4. 扩展设计合作关系，避免反复造轮子

FDE 的运作模式，非常像初创公司早期的"设计合作伙伴"（Design Partnership）机制：客户负责提供关于痛点的业务背景，公司投入时间、技术和工程力量去构建解决方案。FDE 是把这种模式搬到了大型企业级项目中，让它成为一种长期战略。

这种模式最大的挑战是代码维护。如果为每个客户都从零开始单独构建一套应用，久而久之，公司就会积累大量杂乱无章的定制系统。Bai 打了个比方：想象一下要被迫去熟悉 55 个完全不同的代码仓库——那绝对是一场灾难。如果变成那样，公司就沦为了外包开发工作室。

让企业级设计合作关系可持续维护的秘诀，就在于"共享基础组件"。 FDE 工程师直接把平台已有的各项能力像搭积木一样，组装成满足客户需求的解决方案。所有定制化工作都稳稳地建立在一个拥有良好支持的地基之上。

如果没有这个地基，每一个项目都会陷入重复造轮子的泥潭，高昂的维护成本会吞噬掉公司的利润。

5. 设立 FDE 团队前的两道关卡

采用 FDE 模式必须有真正的业务驱动力。Bai 提出了两道检验标准：

关卡一：公司真的需要这种走向市场的策略吗？

广告

你需要确认一个前提：你们是否正在把一个技术极其复杂的产品，卖给一个非技术的买家。如果没有这种供需错位，FDE 大概率不适合。对于技术买家，通过开发者关系（DevRel）团队沟通就够了。

关卡二：你们有底层平台吗？或者有决心去建一个吗？

工程师在为客户解决问题时，底层必须有共享的基础组件。虽然"工程师直接为公司赚取收入"这个愿景很诱人，但这并不意味着他们开发出来的东西就不需要花钱维护。

AI 的爆发让这个问题变得更加普遍。站在 2026 年回看，编写代码和开发复杂的定制软件比以前容易多了，包括为保险、法律等各个领域开发 AI 智能体。Bai 的判断是：随着平台越来越具备智能体特性，它们会变得更容易定制，但同时也意味着越来越多的客户会面对那些他们不懂背后原理的强大产品。

软件开发变得容易，并不意味着客户就自动拥有了实现商业价值所需的能力。供应商如果把"能不能用好产品"完全甩给客户，进军高端市场就会变得非常困难。

6. 基础组件到底该封装到什么程度

落地实施时的第一个问题是：共享的基础组件，颗粒度应该有多细？Bai 建议底线是至少要避免"每次都从头定义数据模型"。除此之外，合适的复用程度完全取决于具体用例。

AWS 是"宽泛基础组件"的绝佳类比。一个工程团队本来可以自己买服务器机架、连网、维护，但 AWS 直接把这些工作接管了。DynamoDB 提供了现成的数据库能力，团队完全不需要自己发明一个数据库。AWS 的客户群体极其庞大，这解释了为什么通用积木对他们来说如此有用。相反，如果客户群体非常窄，把更多应用逻辑直接写进基础组件里，也完全合理。

7. 共享知识，厘清合作关系

关于团队协作，Bai 鼓励在一个项目上配置多名 FDE 工程师。客户的项目不能全指望一个人把所有上下文信息都装在脑子里——万一这位工程师休假了，团队里的其他人必须依然能理解并继续支持。

至于跨公司合作（比如 AWS 和 Palantir 的工程师在同一项目中），Bai 把它比作"承包商"之间的关系：首先要明确谁占据主导地位，谁是总包、谁是分包。这提供了一种思考工作关系的框架，至于管理供应商之间摩擦的详细流程，则需要各方自行制定。

8. 让一线实战经验反哺平台

当收到一个修改需求时，代码到底该写在哪里——是平台里，还是客户的具体方案里？Bai 认为核心标准在于"通用性"：

早期的 FDE 团队手头可能只有寥寥无几的基础组件。这时，一线的实战工作就成了一种探索手段——FDE 工程师就像前方的侦察兵：直面客户难题，识别出具有通用性的能力，帮助公司发现还能开发哪些新产品和服务。

Bai 对 FDE 工程师的定义是：面向客户的软件工程师。 应聘者必须跨过团队在软件工程能力上的招聘门槛，同时还必须是公司能放心派去直面客户的人。这两项要求缺一不可：足够懂客户才能挖出真正的问题，足够强的工程能力才能亲手把解决方案做出来。

来源：youtube.com/watch?v=KwhgfwOSToQ&t=16s&start=0

演讲者：Kevin Bai（Anthropic 应用 AI 团队 · 前 Rippling 首位 FDE · 前 Palantir）