我目前的工作要去到客户现场，和客户现场沟通、现场开发，和传统的研发有很大的差别，这是在学习美国公司 Palantir 的 FDE 交付模式

这篇博客记录我对 FDE 模式的实践和思考

首先简单介绍一下 FDE 模式，如果对这种模式有所了解，可以直接看文尾我对 FDE 的思考：点击跳转

FDE 模式简介

FDE（Front Deployed Engineer） 是 Palantir 独创的一种工程师角色和交付模式。它不是传统 SaaS 公司的远程标准化部署，而是让工程师直接进驻客户现场，与客户团队并肩作战，快速配置 Palantir 平台（Gotham、Foundry、AIP 等）来解决客户最复杂、最棘手的业务问题。目标是交付真实业务成果，而非仅仅提供软件或咨询服务

起源

这种模式起源于 Palantir 早期服务美国情报机构、国防等高度保密且需求极度差异化的场景，客户环境极端复杂（碎片化数据、严格合规、遗留系统、高安全要求），传统“卖软件让客户自己适配”的模式完全失效，由于客户难以远程清晰描述需求，Palantir 创新性地让工程师驻场，现场共创、迭代、交付

FDE 的价值在于替客户”发现需求”，然后当场用 Foundry 把解决方案搭出来。这相当于把咨询公司的问题定义能力和一家产品公司的技术杠杆合并

核心团队模式：Dev ｜ FDE（Echo & Delta）

Dev：在总部构建可复用、面向多客户的平台能力

• 当前 Palantir 的平台有 Gotham、Foundry、AIP

FDE：在客户现场交付业务成果，通常采用 Echo & Delta 搭配：

• Echo：偏业务/产品策略，像 PM（Product Manager）。负责现场需求挖掘、痛点翻译、客户关系维护、定义高价值问题。常由领域专家（退役军官、医疗专家等）担任

• Delta：纯技术执行者，高级软件工程师。负责快速原型构建、数据集成、平台配置、部署上线

Dev, FDE 两者紧密协同，形成“现场探索->总部抽象”的闭环：现场定制化实践->提炼为通用平台能力，避免陷入“纯服务陷阱”，同时反哺产品迭代

FDE 模式的优势

• 极高毛利率与可扩展性：前期 FDE 成本很高（顶尖人才 + 驻场），但平台成熟后，新客户边际成本大幅下降，最终形成“软件 + 深度集成”的高毛利结构

• 极高客户留存与扩展：因为深度嵌入客户核心运营流程，形成“操作依赖”，切换成本极高。客户不是买软件，而是把 Palantir 变成自己决策系统的一部分

• 最真实的 PMF 实验室：现场暴露的真实失败模式、边缘案例、政治因素，是任何总部产品团队都无法模拟的。Palantir 的产品迭代速度和贴合度由此而来

• AI 时代特别吃香：当前大模型能力爆炸，但企业真正落地面临“最后一公里”难题：数据集成、遗留系统、安全合规、工作流适配、变更管理等。FDE 模式正是解决这些“现实世界摩擦”的最佳方案

我对 FDE 模式的实践和思考

我司的 FDE 模式，类似 Palantir FDE 的运作模式，但是目前没有 Dev 团队，也就是没有平台能力，现场的 Echo 和 Delta 团队基本和 Palantir 的描述一致：一波人负责和客户紧密联络，另一波人负责完成项目构建

我属于 Delta 团队，目前的工作模式就和 Indie-Hacker 或者创业公司一样，利用各种能用到的技术（包括内部产品、开源组件）去完成客户的需求，不限制技术栈，以解决问题为导向

以下记录我的一些思考：

平台能力的重要性

Palantir 的 FDE 实际上是基于 Palantir 的平台做定制开发，抽取定制开发中的公共能力沉淀为产品能力，而我司并没有这样的平台，所以定制开发成了无限自由度的定制开发

这种开发在实践中有很大问题：

• 没有平台，后续的生产部署和运维存在很大问题：我们给客户开发的方案更多的偏售前的方案，倾向于跑通，而很难完全考虑清楚后续真正生产如何交付，这存在很大隐患
• 没有平台，很多基本的问题不太好解决：当前项目上最大的问题恰恰是基本的问题——客户有没有相应的数据、相应的数据从哪里来如何集成，这些基本的问题都很难确认，哪怕是数字化、信息化建设比较好的公司，也存在这个问题，更别说不重视数字化、信息化建设的公司了
• 没有平台，沉淀不了公共能力，复用难度大：这个不用多说，这也是定制化软件和产品软件的区别。目前我司的复用方法是以人为维度的复用——一个项目做成了，把人抽到下一个项目进行复制，这也是一种复制的模式，但效率极低

强客户关系和大客户是跑通 FDE 模式的关键

有博主分析，Palantir 能采用 FDE 模式的关键是 Peter Theil 在美国强大的政商关系

这种说法我非常认可。会发现这种模式开始的前期，非常需要和客户紧密配合，如果客户高层不重视，很容易就只派一个“接口人”来配合一下，实际上就是应付一下，这样的“接口人”对业务不熟悉、对痛点不理解，最终可能导致交付出的东西价值有限，最后用不上，也就达成不了 Palantir 那种加强用户粘性的做法

并且服务的企业中也有军工、国企，保密性要求很高，并不是所有的企业他们都能够信任，一定需要足够强大的品牌背书和足够铁的客户关系

所以强客户关系非常重要，没有很好的客户关系，客户内部的信息就很难良好传递，最终交付的东西也很难说解决了真正的问题

除了客户关系以外，大客户是另一个要素，因为一般的小客户信息化建设弱、人员素质较低，加上这种模式一般要求比较高昂的费用，小客户一般负担不起也很难做深入

在这两点上，我司应该是占有很大优势的，是适合去跑这个模式的公司

Vibe Coding 对这种模式的利好

Vibe Coding 使得现场交付的速度大大加快，我们可以根据客户沟通情况快速做出原型和客户对齐，确定是否满足客户要求，再根据客户反馈进行快速迭代修改（现场一般两三天就能出一个版本）

这样，就能最大程度上确保我们做出的就是客户需要的软件

在 Vibe Coding 没有那么成熟的时候，很难想象还能靠这样的方式来交付软件

“以客户为中心”解决问题的思维和导向

在产品管理中，一句很常说的话就是：客户要的不是软件，而是解决问题。解决问题的思维也是工程师最重要的思维之一

在现场以 FDE 交付中，解决客户的问题也是最重要的思维：

• 客户不一定明白软件怎么开发，但他一定明白他的痛点，你的软件能不能帮他解决痛点问题是他最关心的
• 你帮客户解决的问题多了，客户关系自然就好了，客户粘性自然就增加了

FDE 模式锻炼了什么能力

我觉得 FDE 开发模式是比较锻炼人的，相比研发里接需求、做需求的模式，有更大的能力成长

主要的能力提升在：

• 快速原型 Prototyping 的能力：在研发体系里，不同的需求往往是相似的，代码也基本围绕已有代码库进行修改，不会有很大的变化，也不会接触太多新技术。这种情况反而原型能力会有所欠缺，FDE 的模式下，交付有点类似大学里做创新作业（大作业）的模式——功能实现是第一，再结合研发学到的工程能力和工程思维，以及 Vibe Coding 能力，对快速原型能力有很大的提升
• 客户面和非技术人员交流的能力：在研发，基本都是和开发、测试进行沟通，语言也相对偏技术；而在客户现场，参与交流的基本上是客户的非技术人员（一般是业务专家），要将非技术人员的痛点、问题转化为软件，首先要理解他们的问题，这很锻炼和非技术人员的交流能力

我司在这种模式的实践上存在的其它问题

• 层级组织的问题：层级组织导致现场团队需要分出精力去汇报，影响现场交付效率，甚至有时会因为汇报影响交付方案。或许应该设立一种机制让现场团队只为现场客户负责

• 和部门墙问题：大公司组织划分容易导致部门墙，而最终形成协作上的不顺畅

• 团队分工问题：在 Vibe Coding 时代，AI 的执行力是人无法比拟的，传统的团队分工出于公平的目的给每个人分一点活，最后再进行合并，这种团队分工方式在总体上是影响团队效率（人和人之间存在等活的问题）和最终效果（合并可能会合出问题；并不是每个人都熟悉业务，中间弱的环节会导致最终效果差）。可以预见，小而精的团队是 Vibe Coding 时代战斗力更强的团队

• 人员素质问题：一些不善用 AI 的人，现场经验较弱的人容易成为团队效率的瓶颈。可以通过团队分工方式规避

• #FDE