案例 · Palantir：FDE 的原点
本页你会看到：Palantir 怎样用「演示循环 + 现场工程师」把软件送进最难进的客户；FDE 这个名字和工作方式从哪来；Foundry、Airbus Skywise、ShipOS 这些标志性项目到底发生了什么；这套模式靠什么指标运转，代价与争议又在哪。
一句话：FDE 不是 Palantir 发明的一个岗位名称，而是它对「软件必须长在客户现场」这一事实的组织回答。
本页速览：一张案例画布
先把 Palantir 放进案例库的六格画布：
| 画布 | 内容 |
|---|---|
| 背景 | 2003 年创立，最早服务政府与国防客户：数据敏感、场景特殊、无法公开演示 |
| 问题 | 通用软件进不了现场：数据脏且不通、流程独一无二、客户不信任演示数据 |
| 做法 | 把工程师派到客户现场，用真实数据反复演示和修改；把重复出现的需求抽成平台能力 |
| 指标 | 合同额、净收入留存率（NRR）、人均营收、FDE 占工程师比例 |
| 可迁移经验 | 现场发现 → 窄场景验证 → 产品反哺；演示本身就是需求收集 |
| 口径与限制 | 大量细节来自回顾性报道与播客（C 级），部分数字待核；人力成本高，难以简单复制 |
下面的内容按「起源 → 方法 → 平台 → 客户现场 → 商业模型 → 争议」展开。
起源：一家必须去现场的公司
Palantir 创立于 2003 年，创始团队包括 Peter Thiel、Alex Karp、Stephen Cohen 等人，CIA 旗下的投资机构 In-Q-Tel 是其首投方（A/B，公开公司史）。它最早的客户在政府与国防领域：数据涉密、系统割裂、任务无法用标准软件描述。
这决定了两件事。第一，产品不能靠远程销售和标准演示推进，必须有人带工程师进到客户房间里，在客户的数据上把东西跑起来。第二，早期案例几乎不能公开：客户是谁、系统长什么样、效果如何，都不能写进官网。Palantir 神秘感的来源不是营销，而是客户性质——这也解释了为什么公司披露的财务数字可信度较高（A），而工作方式与管理细节多来自前员工回顾、播客和媒体特稿（B/C）。
演示循环：把「太糟了」变成需求
关于 Palantir 的工作方式，被引用最多的一个片段来自 Stephen Cohen。客户看完演示，直说「这东西太糟了」；Cohen 不辩护，而是问：「那你们希望它哪里不一样？」然后当场或很快改一版，再给客户看。
这个循环听起来朴素，却把它和两种常见做法区分开了：
- 咨询做法：先写几十页需求文档，几个月后再交付；客户看到成品时，业务已经变了。
- 外包做法：照合同清单实现功能，验收即结束；没人对「用了有没有用」负责。
演示循环的本质，是把客户的不满当作最高优先级的需求输入。它要求工程师在场、能改、改得快，也要求客户愿意在真实数据和真实流程上陪跑。这就是后来 FDE 工作方式的雏形：不靠说服，靠下一版；它对应的可执行流程是 六阶段交付法。
Sankar、第 13 号员工与「FDE」这个名字
把这种做法固化成岗位和方法的，是 Shyam Sankar。他是公司第 13 号员工，被认为是 FDE 模式与「Forward Deployed Engineer」这个命名的发明者之一，后来出任首席技术官（B，Colossus 杂志 2026-04-14；American Optimist 播客 2026-05-08）。
命名本身值得停一下。「Forward Deployed」借自军事术语，指前推到前线部署；它强调的不是「支持」，而是位置：工程师不在总部等工单，而是在离问题最近的地方，拥有临时决策权，对结果负责。这个词后来被 OpenAI、Anthropic、Databricks 以及火山引擎、安永等组织沿用（见 AI 原生公司 与 中国现场），说明它抓住了真实的结构性缺口。
代价也是真的。据 Colossus 2026-04-14 的回顾，2007 年前后一个代号 COIC 的项目上，团队连续两周每天工作约 19 小时，有人把电话绑在头上随时接听（C，细节待核）。本书引用它，不是把它当榜样，而是提醒你：FDE 模式的高交付强度是有历史原型的，不应被浪漫化。任何把「去现场」讲成热血故事、却不谈可持续性的说法，都值得警惕。
保密室与两种文化
前员工回忆里有「保密室」：早期政府项目在封闭空间交付，团队与外界隔离，靠极短反馈循环推进（C，Colossus）。另有一个被戏称为「桑卡尔炸弹」的细节：Sankar 会在机场咖啡馆当面批评同事的邮件与会议文化（C，Ted Mabrey 回忆）。
两个细节照出早期文化的两面：极短的反馈链和极高的人际强度。前者可迁移：减少层级、当面说清、当天闭环；后者要谨慎，不必学「用羞辱推动进度」。
Foundry：客户现场长出来的平台
Palantir 现在的核心平台 Foundry，不是先在实验室设计好、再找客户验证的。据 Challenges 杂志 2019-03 与 theforwarddeployed.io 的梳理，它的能力是在苏黎世、休斯顿、圣保罗、图卢兹、巴库等一个个客户现场长出来的：工程师先为某个客户解决一个具体问题，再把重复出现的模式抽象成平台功能（B/C）。
最典型的例子是从伊拉克、阿富汗战场需求演化出的地图工具：一线需要在地图上处理路边炸弹相关事件，这类需求反复出现，最后变成平台的标准能力（B/C，公开 Palantir 史）。
这正是全书「砾石路与高速公路」比喻的原始版本：先在现场铺一条能走的砾石路，再把反复被走过的路径修成平台的高速公路。判断一家公司是在做 FDE 还是驻场外包，一个实用标准就是看它有没有这条「现场 → 平台」的回流通道。
| 现场问题 | 被抽象成什么 | 后来在哪 |
|---|---|---|
| 战场事件的地图化处理 | 地图与事件关联能力 | 平台标准功能 |
| 航空发动机燃油泵故障定位 | 跨系统数据关联与根因分析 | Airbus Skywise |
| 船厂排产与供应链协同 | 排产、物料与进度的统一视图 | 美国海军 ShipOS |
表中前三列是作者归纳（D），不是 Palantir 官方口径；目的是帮你看清「现场能力如何变成产品」。
Airbus 与 Skywise：两周定位一个两年的问题
Palantir 最常被引用的客户案例是 Airbus。据 Challenges 杂志 2019-03 及 Palantir、空客的公开资料：A380 的一个燃油泵问题拖了两年没有定位，Palantir 的团队进场后，两周内找到了问题所在；有报道称这帮助保住了约 400 亿美元的订单（B，订单数字待核）。后续双方共建的航空数据平台 Skywise，覆盖上万架飞机、约五万名用户（B，数字待核）。
这个案例的价值不在于「AI 多神」，而在于它展示了 FDE 型交付的三个要素：
- 跨系统取数：问题往往不在单个系统里，而在多个系统之间；
- 现场知识：工程师必须听懂飞机工程师在说什么，才能构造正确的关联；
- 短反馈：两周内给出可验证的结论，而不是半年后交一份报告。
指标选择练习：只报「处理多少 TB 数据」，说明还没找到业务指标；报「定位从两年到两周」，才是业务结果。
ShipOS 与美国海军：把「天」压成「分钟」
公共部门是 Palantir 的另一条主线。据 USNI News、Defense One、The Register 等媒体 2025-12 前后的报道（B）：美国海军的 ShipOS 项目合同金额约 4.48 亿美元；在电船公司（Electric Boat），原本约 160 小时的工作被压缩到 10 分钟；在朴茨茅斯船厂，原本需要几周的流程缩短到约 1 小时。
多家独立媒体报了同一组事实，可信度尚可；但口径是项目方在特定环节的对比，不是整个船厂的生产率提升，也不代表其他船厂能复现。此外，Palantir 与美国陆军之间也有框架性合作安排，本书未取得可公开引用的合同金额与范围，相关细节标为「待核」。
公共部门案例对 FDE 的启示很直接：采购周期长、合规要求高、数据不能出域，但一旦跑通，替换成本极高，续约与扩展空间也大。中国读者可以把这一点与中国现场里的私有化、项目制采购对照着看。
商业模型与指标：FDE 如何变成一门生意
FDE 模式能不能成立，最终要看单位经济学。Palantir 公开财报给了几个关键数字：
| 指标 | 数字 | 口径 |
|---|---|---|
| 2025 年第四季度合同额 | 42.6 亿美元 | 公司财报新闻稿（A） |
| 净收入留存率（NRR） | 139% | 公司财报新闻稿（A） |
| 现金 | 72 亿美元 | 公司财报新闻稿（A） |
| 2025 全年营收 | 约 44.8 亿美元 | 公司财报新闻稿（A） |
| 员工数 | 4,429 人 | 公司披露（A） |
| 人均营收 | 约 100 万美元 | 据上述两项算术（D） |
| 2026 年第一季度营收增速 | 同比 +85% | 公司财报（A） |
| FDE 与工程师占比 | 2016 年前，FDE 人数一度超过平台工程师；一半以上工程师在全球客户现场 | 公开资料汇总（C；口径是工程师，不是全体员工） |
三种读法。第一，NRR 139% 说明客户在续约时花得更多——交付物进入了客户的日常运转，而不是一次性项目。第二，人均营收约 100 万美元很高，但要看构成：收入里既有软件订阅，也有交付与服务（作者归纳），把「人均营收高」当成「FDE 模式很轻」是误读。第三，FDE 是昂贵的人力：据 SaaStr 2025-08 引述的从业者估算，单个部署的年交付成本约 7.5 万美元起，一个满负荷 FDE 通常只服务 3-5 个客户（C/D，第三方估算）。这解释了 Palantir 为什么一定要把现场能力平台化：只有把重复劳动变成产品，才可能在高人力成本下保持增长。这条逻辑对中国的 AI 服务公司同样成立。
Project Frontline：把部署变成培养机制
据 Project Frontline 设计者 2026-02-05 的一手介绍，250 多名工程师进入真实部署轮岗，校友后来散布在 OpenAI、xAI、Anduril 等公司（C，单一来源）。这条信息的价值在于它揭示了一种培养路径：FDE 能力主要不是课堂里学会的，而是在真实客户、真实数据、真实压力下练出来的。这也解释了 Palantir 的面试风格传闻：拆解刻意模糊的真实问题，几乎不写代码，按纯软件工程师准备的候选人反而容易失手（C，Glassdoor 聚合与面试指南，待核）。准备转岗时，练「拿到模糊描述后怎么问出约束、定义可验证的下一步」，比刷算法题更接近考察点（框架见第 9 章）。
局限与争议：这套模式不能被神话
- 不可验证：客户多为政府与大型企业，案例细节无法公开复核，公开材料以回顾性报道为主，大量细节只能标 C 或待核。
- 成本与规模化：FDE 是重人力模式。华尔街日报 2026 年的评论认为，FDE 更像咨询而非软件，嵌入式人才太贵，规模化仍是悬案（C，付费墙文章，仅作框架级引用）；另有分析师个人观点认为，到 2028 年 70% 的企业会放弃 FDE 主导的智能体方案（C，CIO.com 2026-05-06 引述，非 Gartner 正式报告）。
- 「可泛化性」的反思：前 Palantir 员工 Nabeel Qureshi 在 2024-10 的回顾中有一句被广泛引用的话——「去他的可泛化性」；他估计数据问题里九成五是接入、清洗与关联（C，原文待核）。这既说明 FDE 的价值在脏活里，也说明这种能力很难标准化复制。
- 交付强度：保密室式的长期高强度工作不可持续，也不该成为招聘话术。
- 被误读为驻场外包：外界常把 FDE 等同于「派几个人到客户那里写代码」。两者最关键的区别是：FDE 对业务结果负责，并把现场经验回流成产品；驻场外包按人天和合同清单交付。
本章小结
- 演示循环、保密室、Foundry 的现场演化，共同构成「现场发现 → 窄场景验证 → 产品反哺」的原始样本。
- 商业上，FDE 是昂贵的人力入口，真正撑起增长的是把现场能力平台化后的订阅与扩展。
- 这套模式可学的是机制（反馈速度、结果负责、产品回流），不可学的是强度。
给读者的 5 条启示
- 先让客户在真实数据上看到差别，再谈需求。 演示不是销售环节，是最高效的需求收集方式。
- 把「现场」当产品路线图的来源，而不是成本中心。 每做完一个客户，问自己：哪一个动作会被下一个客户重复？
- 区分「去前线」与「驻场支持」。 前者有决策权、背结果、能反哺产品；后者只交工时。
- 面试与培养都围绕「拆模糊问题」。 练提问，比背答案有用。
- 学模式，不学强度。 保密室式的 19 小时是历史细节（待核），不是职业标准。