PS：
AITutor 来了。每个人的 AI 原生学习伙伴，全网首发，点击预约。
2026 年了，AI 智能体的概念已经火到无人不知。但大家有没有发现一个很扎心的现象：很多客户花大价钱买了强大的平台，最后却扔在那里吃灰，根本不知道怎么把它变成实实在在的业务价值。最近我看了一场 Anthropic 工程师 Kevin Bai 在 AI Engineer 大会上的演讲，主题叫《Forward Deployed Engineering 101》。说实话，这是我看过的把 FDE 讲得最清楚的一次分享。Kevin Bai 先后在 Palantir、Rippling 和 Anthropic 应用 AI 团队干过，他还是 Rippling 首位 FDE 团队成员，这个团队一年内就扩张到了 25 人左右。可以说，他是真正在第一线把这个模式跑通过的人。所谓前沿部署工程（Forward Deployed Engineering，简称 FDE），本质上是把复杂平台和实际业务成果连接起来的一种工程组织方式。但这门生意能不能跑通，取决于两个关键前提：第一，底层有没有可复用的共享基础组件；第二，客户定制化工作和核心产品开发之间有没有清晰的边界。今天这篇干货，我就带大家把这场演讲的核心内容一次性吃透，全文共 8 个部分，建议收藏慢慢看。PS：
FDE 工程更多案例深入免费学习去这里：
1.打开 AITutor 新一代 AI 原生学习伙伴：www.aiaitutor.com 2.在首页输入"FDE” 就能看到更详细更丰富案例。3.包含了图文、视频、播客、闪卡、代码、测验等9种学习模态。
一、整理好的数据，到底能为企业带来什么
要理解 FDE，得先理解平台卖给客户的到底是什么。以 Palantir 的 Foundry 平台为例。它的核心作用是把企业数据集中起来，创建一个「本体」（Ontology），并提供一个构建应用的基础平台。「本体」这个词听起来很玄乎，其实用一个仓库的例子就能讲明白：企业得到的不是所有仓库数据的简单堆砌，而是一个「唯一事实来源」。数据在这里被赋予了实际的业务含义，变成了人们可以直接理解和操作的概念，远超一堆相互脱节的数据表。但即便如此，买家仍然有理由追问一句：把数据整理成这样，到底能给我的业务带来什么？这就引出了一个关键概念：采用成本。一个平台能否成功，取决于客户能不能真正用好它。员工必须先学会使用平台，然后才能在上面开发出有用的应用。供应商卖出的是一种「能力」，但如何把这种能力变成价值，难题却留给了客户。FDE 的核心，就是把软件和工程服务结合起来，打包成一个「结果」卖给客户。FDE 工程师会深入学习客户的具体业务，然后直接在平台上为他们量身打造解决方案。客户买到的不是裸软件，而是软件加工程服务的结合体，一个可交付的结果。举个例子，一家消费品包装公司可能希望自家商品在超市货架上占据更好的位置，或者想提高销售额。为了实现这些最终结果，如何组织数据就成了至关重要的底层实施细节。这就是 FDE 工程师要干的活。二、什么时候需要 FDE？让产品复杂度与买家相匹配
Kevin Bai 用一个二维矩阵来解释产品采用的难题，我觉得非常经典，直接上表：提供的产品 | 买家或用户 | 如何处理复杂度 |
|---|
技术产品（GitHub / Datadog） | 技术买家（CTO / 工程师） | 自行学习并操作 |
可配置工具（Rippling / Slack） | 非技术用户（业务人员） | 自行配置 |
复杂技术平台（需要定制开发） | 非技术买家（财富 500 强） | FDE 工程师构建解决方案 |
看明白了吗？单纯的产品复杂度并不一定需要引入 FDE，真正关键的是客户是否有能力消化这种复杂度。真正触发 FDE 需求的，是第三种情况：你正在把一个技术要求极高的平台，卖给一个非技术的买家。这种「错位感」恰好解释了 Palantir 的市场空间。像 Google、Meta 以及各大 AI 实验室，本身就拥有大量能开发内部应用的工程师。但一家财富 500 强的石油天然气公司，可能根本没有这么深厚的软件工程实力，毕竟人家的管道里流淌的是石油，跟数据处理八竿子打不着。FDE 刚好填补了这条鸿沟。它直接为客户提供优秀的工程师，客户无需自己去招聘、管理或留住这些人。Kevin Bai 把这种细致入微的关注比作高级餐厅里的服务员：了解客户需要什么，本身就是交付服务的一部分。这个比喻很妙，客户要的不是后厨的菜刀和灶台，而是端上桌的那道菜。三、交付业务结果，背后的商业价值有多大
为了说明这种模式的商业吸引力，Kevin Bai 对比了财富 500 强企业在各大上市 SaaS 公司上的花费，用 ACV（Average Contract Value，平均合同价值）来衡量：公司 | 平均合同价值（ACV） |
|---|
Palantir | 400 万美元 |
ServiceNow | 120 万美元 |
Workday | 约 60 万美元 |
其余所有上市 SaaS 公司 | 均不超过 50 万美元 |
差距是不是非常夸张？Palantir 的客单价是普通 SaaS 公司的 8 倍以上。这里我要严谨地补充一句：这些只是 Kevin Bai 提供的参考数字，没有说明具体的测量日期或计算方法，主要是为了说明该模式在商业上的竞争力。他还提到，相对于 Palantir 仅有几千名员工的规模，其估值高得令人惊讶。四、共享基础组件：避免反复造轮子的生命线
要理解 FDE 怎么赚钱，先得看懂它的运作模式从哪来。FDE 的运作模式，其实一点都不新鲜，它非常像初创公司早期的「设计合作伙伴」（Design Partnership）机制。做过 ToB 创业的同学对这个套路一定不陌生：公司刚起步、产品还没打磨好的时候，会找几家种子客户深度绑定。客户负责提供关于痛点的业务背景，把「我到底哪里疼」讲清楚；公司则投入时间、技术和工程力量，贴身为客户构建解决方案。作为交换，客户拿到抢先体验和深度定制，公司拿到最真实的场景反馈，双方各取所需。这套机制在初创阶段简直完美，但它天然是「一次性」的：服务完三五家种子客户，公司就要把经验抽象成标准产品，然后头也不回地走向规模化。而 FDE 干的是一件更激进的事：它把这种贴身共建的模式原封不动地搬进了大型企业级项目，并且不是用一两次就收手，而是固化成一种长期战略。几十家、上百家财富 500 强客户，每一家都配工程师贴身服务。听到这里，工程师出身的读者应该已经嗅到危险的气息了。没错，这种模式有一个最大的挑战：代码维护。大家顺着这个逻辑推演一下，如果为每个客户都从零开始单独构建一套应用，会发生什么？第一年，你有 5 个客户，5 套定制系统，问题不大，每套都有人记得来龙去脉。第三年，你有 30 个客户，30 套系统开始陆续出 bug，而当年写代码的人已经换了一波。第五年，你坐拥上百个客户，同时也坐拥上百个互不相同的代码仓库。每一次平台升级、每一个安全补丁，都要在上百个仓库里分别适配一遍。Kevin Bai 打了个非常形象的比方：想象一下要被迫去熟悉 55 个完全不同的代码仓库，那绝对是一场灾难。每套系统的数据模型、接口约定、依赖版本都不一样，工程师的大量时间不是花在创造价值上，而是花在读懂前任留下的迷宫上。如果真变成那样，公司就沦为了外包开发工作室：收入看似在涨，但每接一单都要线性增加人手，毛利被维护成本吃得干干净净，规模化也就无从谈起。让企业级设计合作关系可持续维护的秘诀，就在于「共享基础组件」。这句话翻译成大白话：客户要的那 40% 定制可以千差万别，但底下 60% 的地基必须是同一套。FDE 工程师接到新需求时，不是打开一个空白工程从零写代码，而是直接把平台已有的各项能力像搭积木一样，组装成满足客户需求的解决方案。数据模型是现成的，本体定义是现成的，权限体系、工作流引擎、可视化组件也全是现成的，工程师只需要在最上层做业务编排和少量定制开发。这样一来，所有定制化工作都稳稳地建立在一个拥有良好支持的地基之上。平台团队修好一个 bug，所有客户同时受益；平台升级一次新能力，所有方案原地进化。维护成本从「乘以客户数」变成了「除以客户数」，这就是 FDE 和外包最本质的区别。反过来，如果没有这个地基，每一个项目都会陷入重复造轮子的泥潭：客户 A 要的报表引擎，客户 B 也想要，但你只能再写一遍；客户 C 的权限需求跟 A 几乎一模一样，对不起，代码不互通，还是得重写。高昂的维护成本会一点点吞噬掉公司的利润，最后账面上有收入，口袋里没有利润。所以我在这里划个重点：FDE 的护城河从来不是「工程师多能打」，而是「平台沉淀有多厚」。前者是人力生意，后者才是复利生意。这也是为什么下一节的两道关卡里，「有没有底层平台」会成为一个硬门槛。五、设立 FDE 团队前的两道关卡
看到 400 万美元的 ACV，很多老板可能已经开始盘算了：这买卖划算，要不我们也组个 FDE 团队抄作业？先别急，我必须泼一盆冷水。FDE 是重资产、重人力、重承诺的走向市场策略，一旦上错车，烧掉的是真金白银的工程师编制和宝贵的战略窗口期。采用 FDE 模式必须有真正的业务驱动力，而不是看到 Palantir 赚钱就眼红。Kevin Bai 提出了两道检验标准，建议所有心动的团队逐条对照自查，过了这两关再动手也不迟。
关卡一：公司真的需要这种走向市场的策略吗
这道关卡检验的是供需关系。你需要确认一个前提：你们是否正在把一个技术极其复杂的产品，卖给一个非技术的买家。
判断标准其实很朴素，问自己三个问题就够了。
第一，我的买家是谁？是懂技术的 CTO 和工程师，还是完全不懂代码的业务负责人？
第二，产品开箱之后，买家靠自己能跑通吗？是翻翻文档就能上手，还是必须有人钻进业务里陪着做定制开发？
第三，如果没人帮，买家会不会买了用不起来，最后续约失败、口碑受损？
如果答案指向「买家非技术、产品极复杂、自己玩不转」，那么恭喜你，供需错位成立，FDE 值得认真考虑。反过来，如果没有这种错位，FDE 大概率不适合你。对于技术买家，通过开发者关系（DevRel）团队沟通就够了，写写好文档、办好黑客松、维护好社区，人家自己就能把产品玩出花来，没必要兴师动众地派工程师驻场。
我补一句：关卡一的本质是在问这笔钱该不该花。FDE 工程师的薪资和机会成本都极高，把他们投给一个本来就能自助的客户，是最奢侈的浪费。
关卡二：你们有底层平台吗？或者有决心去建一个吗
这道关卡检验的是家底。工程师在为客户解决问题时，底层必须有共享的基础组件托着。
我知道，「工程师直接为公司赚取收入」这个愿景实在太诱人了：每个 FDE 工程师背后都挂着几百万美元的合同，财务报表看起来美如画。但请务必记住上一节的推演，这并不意味着他们开发出来的东西就不需要花钱维护。交付的那一刻不是终点，而是维护的起点。客户要用五年十年，这期间的每一次升级、每一个 bug，都得有人接着。
没有平台托底的 FDE，每一笔收入都在暗中标好了维护的价格，最后就是披着工程师外衣的外包团队，规模越大，陷得越深。
所以这一关要回答的不是「有没有」，而是「敢不敢」：眼下没有平台不要紧，关键是公司有没有决心投入时间和资源去建一个，并且接受它在短期内只投入不产出的现实。平台是 FDE 的入场券，没票还要硬闯，闯进去的不是金矿，是泥潭。
2026 年的新变化：AI 让供需错位更加严重
站在 2026 年回看，AI 的爆发让这两道关卡变得更加应景。
先看供给端的变化：编写代码和开发复杂的定制软件比以前容易多了，AI 编程工具把开发效率拉高了一个数量级，为保险、法律等各个领域开发 AI 智能体，已经从高精尖工程变成了常规操作。
再看需求端的变化：Kevin Bai 的判断是，随着平台越来越具备智能体特性，它们会变得更容易定制，但同时也意味着越来越多的客户会面对那些他们根本不懂背后原理的强大产品。以前客户至少还能看懂软件在干什么，现在面对一个会自主规划、调用工具的智能体平台，大多数业务买家连「它为什么这么做」都无从问起。
这就形成了一个微妙的悖论：造软件越来越容易，用好软件却越来越难。供给端的能力在民主化，需求端的理解力鸿沟却在加深，供需错位不但没有消失，反而被 AI 进一步放大了。
而软件开发变得容易，并不意味着客户就自动拥有了实现商业价值所需的能力。供应商如果把「能不能用好产品」完全甩给客户，结果只会是产品躺在账号里吃灰，续约率难看，口碑翻车，进军高端市场自然也就无从谈起。
所以我的判断是：AI 时代不是 FDE 的终点，恰恰是 FDE 需求大爆发的起点。谁先想明白这一点，谁就能先卡住位置。
六、基础组件到底该封装到什么程度
落地实施时的第一个问题来了：共享的基础组件，颗粒度应该有多细？Kevin Bai 建议的底线是：至少要避免「每次都从头定义数据模型」。除此之外，合适的复用程度完全取决于具体用例。策略 | 适用场景 | 参考比例 |
|---|
重量级应用底座 | 特定行业，高度垂直 | 约 60% 预构建 + 40% 定制 |
细颗粒度搭积木 | 需要灵活配置和工具组合 | 轻量积木自由组装 |
这里有个绝佳的类比：AWS 就是「宽泛基础组件」的教科书案例。一个工程团队本来可以自己买服务器机架、连网、维护，但 AWS 直接把这些工作接管了。DynamoDB 提供了现成的数据库能力，团队完全不需要自己发明一个数据库。AWS 的客户群体极其庞大，这解释了为什么通用积木对他们来说如此有用。相反，如果你的客户群体非常窄，把更多应用逻辑直接写进基础组件里，也完全合理。封装程度没有标准答案，匹配客户结构才是王道。七、团队协作与跨公司合作：知识必须共享
关于团队协作，Kevin Bai 鼓励在一个项目上配置多名 FDE 工程师。道理很简单：客户的项目不能全指望一个人把所有上下文信息都装在脑子里。万一这位工程师休假了，团队里的其他人必须依然能理解并继续支持。这就是工程团队的「防单点故障」设计。至于跨公司合作（比如 AWS 和 Palantir 的工程师在同一个项目中并肩作战），Kevin Bai 把它比作「承包商」之间的关系：首先要明确谁占据主导地位，谁是总包、谁是分包。这提供了一种思考工作关系的框架，至于管理供应商之间摩擦的详细流程，则需要各方自行制定。八、让一线实战经验反哺平台
最后一个问题，也是最考验架构功力的问题：当收到一个修改需求时，代码到底该写在哪里？是平台里，还是客户的具体方案里？Kevin Bai 给出的核心标准是「通用性」，同样上表说清楚：修改内容 | 长期归宿 |
|---|
仅针对某一个客户的独特需求 | 该客户的具体实施代码库 |
不止一个客户能用得上的能力 | 共享的底层平台 |
早期的 FDE 团队手头可能只有寥寥无几的基础组件，这很正常。这时，一线的实战工作就成了一种探索手段：FDE 工程师就像前方的侦察兵，直面客户难题，识别出具有通用性的能力，帮助公司发现还能开发哪些新产品和服务。一线打下来的每一颗子弹，都应该变成平台军火库里的新武器。最后说说人才画像。Kevin Bai 对 FDE 工程师的定义是：面向客户的软件工程师。应聘者必须跨过团队在软件工程能力上的招聘门槛，同时还必须是公司能放心派去直面客户的人。这两项要求缺一不可：足够懂客户才能挖出真正的问题，足够强的工程能力才能亲手把解决方案做出来。九、一句话总结
FDE 的本质，是把软件平台和工程服务打包成「结果」卖给客户：用共享基础组件保证规模化，用两道关卡过滤伪需求，用一线实战反哺平台进化。在 AI 智能体大爆发的 2026 年，平台越来越强，客户却越来越「看不懂」。谁能帮客户把强大的能力变成真金白银的业务结果，谁就能吃到高端市场最大的那块蛋糕。Palantir 的 400 万美元客单价，就是最好的证明。参考资料：Kevin Bai 在 AI Engineer 大会的演讲《Forward Deployed Engineering 101》（youtube.com/watch?v=KwhgfwOSToQ）。演讲者背景：Anthropic 应用 AI 团队，前 Rippling 首位 FDE 成员，前 Palantir 工程师。送个福利：
新一代 AI 原生学习伙伴 AITutor「www.aiaitutor.com」，重构学习方式，AI 驱动个性化精准成长，体系化学习+真实案例，塑造 AI 实战能力。快来免费体验吧。
PS：AITutor 来了。每个人的 AI 原生学习伙伴，全网首发，点击预约。
十、加我微信
扫码加我👇有很多不方便公开发公众号的我会直接分享在朋友圈，欢迎你扫码加我个人微信来看👇
加星标★，不错过每一次更新！
⬇戳”阅读原文“，立即体验 AITutor
