7月28日，在 AI Engineer World's Fair 2026 上，Anthropic applied AI 团队的 Kevin Bai 做了一场前置部署工程（FDE，Forward Deployed Engineering）的入门讲座。加入 Anthropic 前，他是 Rippling FDE 团队的第一名成员，团队一年内扩展到 25 人规模；在 Rippling 之前，他在 Palantir 工作过。讲座回答的是一个老问题：产品复杂、买家却不技术时，怎么把它卖出去、让客户用起来。在 agent 时代，这个问题落到了更多公司头上。Kevin 把 Palantir 的那套打法拆成了一条完整链条。
卖平台的人，卖的是「结果」
Kevin 的讲述从 Palantir 的 Foundry 切入。Foundry 把企业散落的数据收拢到一处、做成「本体」。用他的话说，是把数据变成业务里的「专有名词」：仓库从散落的几张表，变成一个公认的、唯一的数据来源，应用搭建在本体之上。
卖技术的人在这里会撞上一个尴尬。行业领袖关心的不是数据怎么摆放，而是业务结果：快消品公司要的是货架排面、销售吞吐，数据如何组织对他们只是实现细节。另一个麻烦在于，平台卖出去只是开始。员工学会使用、能在上面建东西，前提是客户投入培训。买完之后，价值怎么实现，落在了客户自己身上。
Kevin 给出的答案是换一种卖法。客户买的不是软件，不是某个人的时间，而是一个「结果」：供方派懂业务、懂平台的人过去，理解客户要解决什么，在平台上把方案建出来、交付能用的东西。他把这个模式比作创业早期的「设计合伙」：客户出场景，供方出技术和人力，双方把方案打磨出来。Palantir 的做法，是把这种早期模式搬进了大企业。
需要 FDE 的，只有一种错配
FDE 不是每家公司的选项。Kevin 画了一个 2×2：一条轴是产品复不复杂，另一条轴是买家懂不懂技术。GitHub、Datadog 卖的是复杂产品，但买家是 CTO、CIO 和工程师，用户自己能消化复杂度；Rippling、Jira、Slack 的买家不技术，但产品可配置、不需要在上面开发。第三种情形是唯一需要 FDE 的：产品复杂到需要定制开发，买家却不技术。
为什么会落进这一格，Palantir 的客户结构给出了线索。Google、Meta 这些大厂自己有工程团队，需要什么应用自己建；油气、制造这类世界 500 强没有这种工程深度，用 Kevin 的话说，他们的「管道」里流的是实物、不是数据。把应用平台卖给这样的客户，买完和能用之间隔着一道鸿沟，FDE 填的是这道鸿沟：客户不必自己招人、培训和留人，供方把训练有素的工程师「借」过去。
这套打法的商业结果，Kevin 引用了一组按平均合同金额排出的数据：Palantir 400 万美元居首，ServiceNow 120 万，Workday 60 万，除此之外的上市 SaaS 公司没有一家超过 50 万美元。这组数字需要打折看。它是 Kevin 在讲座中的口述，没有给出统计口径和日期，Workday 那个数字他标注凭记忆。讲座的官方修订稿提醒，ACV 在这里指 average contract value（平均合同金额），有别于常见的 annual contract value（年度合同价值），不能当作可比的财务基准。它支撑的是讲者的论证，而不是一份行业排名。
分界线在平台，不在人头
把 FDE 理解成「每个客户定制一套」是头号陷阱。Kevin 的判断明确：给每个客户从零写代码，那开的不是 FDE 部门，是外包公司。外包是正当生意，但它不是这套模式。分界线在于平台：FDE 在一组 primitives（可复用基础组件）上做组装，而不是重复造轮子。
不做平台化会付出什么代价，Kevin 说得具体。每个客户一套从零建的系统，意味着工程师要维护一堆彼此无关的代码，Kevin 用「没人想学 55 个代码仓库」来形容这种处境。维护成本吃掉利润，工程团队留不住人。共享组件的作用，是把客户专属的部分压在一个已被支撑的地基之上，让定制保持可控。
动手之前先过两道闸
想清楚要不要做，Kevin 给了两道闸门。第一道是需不需要：业务里是否存在「必须把一个技术上复杂的东西卖给非技术买家」的场景。没有这种错配，FDE 不是对症的选择。他区分了「想要」和「需要」：追赶时髦想做 FDE 是一回事，业务真的卡在这个错配上是另一回事。第二道是有没有平台，或者愿不愿意投资建一个。工程师能直接带来收入，这个诱惑不小，但如果他们不在共享组件上构建，维护负担会压垮团队。
错配不成立时，他给了两条替代路径：买方是技术人的，把资源投到开发者关系（DevRel）；走传统 SaaS 路子的，用销售驱动（SLG）。
落地时的几个取舍
复用组件该做到多细，Kevin 的答案是看情况。有的行业平台可以把应用做到六成预制、剩下四成定制；有的行业需要细粒度工具，接近成品的组件会限制发挥空间。他用 AWS 举例：团队可以自购服务器、自己维护，但 AWS 提供 DynamoDB 这类现成能力，是因为它要覆盖极宽的客户群。客群集中的平台，组件可以做得贴近具体场景。六成预制是他举的例子，不是推荐目标。
改动落在哪里，边界按可泛化性划。单一客户的定制留在客户侧；能覆盖更多客户的能力，长期收进平台。FDE 团队初期组件不多是正常的，Kevin 把这个阶段的价值看作「侦察」：在客户现场发现问题、找出哪些能力可以泛化，把这些信号带回给产品。
协作方式上，他鼓励同一项目放多个 FDE，避免单点故障。一个人掌握全部上下文的风险是，他休假时项目会停摆。被问到两家公司的 FDE 同做一个项目时，他认为这种合作存在，关键是厘清具体项目里谁承担「承包商」角色。
FDE 该招什么样的人，Kevin 给的定义是一句话：一个客户面对面的软件工程师。门槛有两条：一是按软件工程师的标准招，二是敢把人放到客户面前。前者保证他能把方案建出来，后者保证他能把问题问到位。
agent 时代，「客户不会用」变成普遍问题
Palantir 进入市场是在 2004 或 2005 年前后，这个年份 Kevin 标注凭记忆。被问到这 20 年什么变了，他的回答不是「世界发现了这套打法的好」，而是软件做生意的方式本身变了。AI 让写代码、做可定制软件变得容易，平台普遍 agent 化、随之普遍可定制化。结果之一是，客户理解产品能做什么的门槛变高了。
他给出的判断是一个假设：平台可定制程度提高，产品成败落在客户的实施能力上，往上走市场或横向扩张的阻力变大。容易构建不等于客户有能力把价值用出来。这是 Kevin 的个人假设，并非行业共识。这场讲座交付的是一套可以对照自家业务检查的框架：错配成不成立，平台在不在。
AI 速览
