FDE不是驻场开发， Palantir如何把项目变成产品？

 一个客户项目交付了，下一个客户来了，团队却还要重新接数据、梳理权限、搭建流程。项目越做越多，为什么产品能力没有同步积累？

理解 Palantir 的 FDE 模式，可以从这个问题开始。它的关键在于，让工程师在现场发现的问题持续进入核心产品，使一次客户交付成为后续项目可以复用的能力。

FDE 是 Forward Deployed Engineer 的缩写，常译为“前沿部署工程师”。如今，OpenAI、Anthropic 的招聘页面上都能找到相关岗位。[6][7] 大模型让通用能力更容易获得，企业仍要解决数据、权限、流程和生产稳定性的问题。FDE 因而值得重新讨论：工程师深入客户之后，怎样让现场投入留下长期的产品价值？

Palantir 成立于 2003 年，最初为美国情报机构开发反恐调查和行动软件。它的第一款核心平台 Gotham，服务于国防与情报分析人员。[1]

这类场景很难先写好需求，再按功能清单交付。数据分散在不同系统里，格式、可信度和访问权限各不相同；软件还要适应保密网络、本地数据中心，甚至断网环境。

“整合情报数据”“发现潜在关联”可以写进需求文档，却不足以指导开发。分析员怎样判断一条信息是否可信？哪些字段会改变决定？结果以什么方式呈现，才能进入实际行动？答案往往藏在日常操作、例外情况和组织分工里。

Palantir 的上市文件提到，FDE 曾进入阿富汗的军事基地和美国中西部的工厂，在部署软件的同时理解用户的困难。[1]

现场工作的价值，首先是补全产品定义中缺失的知识。工程师需要弄清楚用户如何判断、如何行动，才能决定软件应提供什么能力，以及怎样才算解决了问题。

以一家希望减少停机的工厂为例。设备数据在哪里，维修记录是否可靠，停机究竟由零件、排班还是供应链导致，都需要逐一查清。

即使模型已经能够给出风险分数，工作也没有结束。预警交给谁？负责人能否据此调整检修计划？如果预警从未改变任何决定，系统上线就不等于业务改善。

FDE 要沿着这条链工作：理解目标，接入真实数据，构建分析或应用，把结果放进工作流，再观察它是否改变了决策。Palantir 的职位说明也强调，小团队需要从首次客户沟通到产品交付端到端负责。[5]

这要求工程师把现场判断不断落实为可运行的软件，并根据实际使用调整方案。但业务结果改善，也只是完成了当前客户的任务。要进一步形成产品积累，还需要回答：这次解决问题的经验，怎样被其他团队和客户用起来？

项目型团队也能解决复杂问题。困难往往出现在交付之后：客户离不开熟悉现场的那几个人，其他团队却很难直接用上他们积累的经验。

有人写了专用接口，有人记住了权限例外，还有人知道某个指标真正代表什么。系统能够运行，知识却分散在人、文档和客户专属代码里。另一支团队接到相似项目时，还要重新理解、重新开发。

Palantir 值得研究的地方，是它把现场工程师纳入了产品研发的反馈机制。

其 2020 年上市文件披露，软件工程师会在现场与产品开发职能之间轮换；现场工程师被视为研发体系的延伸，他们发现的改进会被系统性地纳入 Gotham 和 Foundry。[1]

Palantir 的架构文档把这套方法比喻为“人类版的反向传播”：工程师靠近真实问题，与核心研发一起持续消化反馈、发布新能力。[2] 对应到组织运作，就是现场发现不足，研发提炼共性，再用更多客户的实际使用检验这些改进。

不过，客户需求不会自动变成产品能力。团队仍要作出判断：哪些是单个客户的特殊规则，适合留在配置或应用层；哪些问题会反复出现，值得进一步抽象为核心平台能力。

如果每个需求都新增一条长期维护的专属分支，客户越多，维护负担也可能越重。有效的知识回流，需要把现场经验转化为其他客户能够使用、研发团队能够持续维护的能力。

工厂关注设备与工单，航空公司关注飞机与航班，医院关注床位与病人。它们的业务对象和流程不同，却经常需要回答相似的问题：数据怎样接进来，对象怎样关联，谁有权操作，判断怎样触发行动。

这些反复出现的工程问题，为平台复用提供了基础。结合 Palantir 的架构文档，可以把相关能力整理为六类。[2][3]

其中，Ontology（本体）把数据、业务对象、逻辑、动作和安全策略组织到同一套业务表示中。[2] 工程师可以围绕“工厂”“订单”“设备”等对象构建系统，定义对象之间的关系、可执行的操作及其约束。

这样一来，团队可以围绕业务对象及其行为组织应用，不必每次都从孤立的数据表和接口开始设计。但“设备”怎样定义，谁可以修改它的状态，哪些动作需要审批，仍要回到客户的实际业务中确定。

共同的建模机制可以复用，具体的业务判断仍需分别完成。

Palantir 在上市文件中举过一个例子：最初用于处理油气井流式时序数据的能力，后来被用于改善一级方程式赛车速度、提高机队利用率和汽车生产线的质量控制。[1] 跨行业延续的是底层数据处理能力，各行业的目标、约束和决策逻辑仍有差异。

从产品分工看，Foundry 承担数据管理、逻辑、Ontology 和工作流等能力，Apollo 管理部署与持续交付，AIP 提供大模型接入、Agent 与自动化开发等能力。[3] 这些平台共同承接现场反复出现的需求。

因此，定制仍然有必要，关键是判断它应放在架构的哪一层。反复出现的部分可以继续抽象，客户独有的业务规则则保留在相应的配置或应用中，避免每个项目都形成一套独立维护的系统。

FDE 的现场投入并不便宜。如果每签下一个客户，就必须永久增加一支工程团队，公司仍很难摆脱收入与交付人力同步增长的关系。

所以，客户数增加，还不足以证明这套模式已经形成规模效应。

Palantir 在 2020 年上市文件中，用 Acquire、Expand、Scale 描述客户关系的发展。[1] 理解这套框架，需要观察平台使用扩展之后，投入与收入的关系如何变化。

Acquire：先证明价值。通常从短期试点开始，客户支付较低费用，甚至免费试用。Palantir 承担前期投入，验证平台能否解决一个足够重要的问题。

Expand：让平台进入更多业务。团队继续识别主要难题，接入更多数据、流程和部门。这个阶段的工程投入仍可能很大，单点应用逐渐成为日常运营的一部分。

Scale：检验相对投入是否下降。随着客户使用成熟，供应商继续提供运维与支持，但相关投入成本相对于收入下降。平台复用，以及客户逐步具备自主扩展能力，为降低对交付团队的依赖提供了条件。

需要注意，这三个阶段有明确的统计口径：上市文件按客户收入和贡献利润率划分阶段，并指出客户未必依次经历每一阶段。[1] 签下大单或进入更多部门，本身不能证明已经实现规模化。

客户能否自主，是另一项需要检查的证据。Palantir 的 Foundry 采用指南将成熟状态描述为“基本自给”：日常运营和新的建设由客户内部团队负责，Palantir 工程师主要在新用例突破或顾问支持时介入。[4]

这意味着，FDE 深入现场之后，还应帮助客户逐渐具备独立使用和扩展平台的能力。在已有场景中，如果日常运维和新需求始终离不开原班人马，就需要检查知识是否充分进入产品、文档和客户团队。

平台本身也应吸收部署、接数和升级中的重复劳动。Palantir 的 2020 年上市文件提供了三组历史数据：[1]

• 从 2019 年第二季度到 2020 年第二季度，客户开始在平台上使用数据的平均时间降至 14 天，不到原先的五分之一。
• ERP 数据映射并开始构建应用的流程，从 2019 年第二季度部分情形下最长 45 天，改善到 2020 年第二季度最快 4 天。这是不同情形的时间描述，并非平均值比较。
• 同期，工程师跨安装环境可管理的软件升级次数，从平均每周约 2 万次增至超过 4.1 万次。这是整体管理能力，不是单名工程师的工作量。

这些是公司当时披露的数据，不能直接作为今天所有项目的交付承诺。它们提供的观察方向是：重复工作是否进入产品和基础设施，进而减少部署与管理所需的时间和资源。

对其他企业而言，也应在需求复杂度和质量要求相近时，比较新项目的重复开发、部署时间及后续支持需求。规模化需要证明的，是业务扩展之后，相应投入不再按原来的比例增长。

大模型让生成、总结和编程等通用能力更容易获得，却没有替企业完成业务系统建设。

模型该读取哪些内部数据，权限如何继承？结果怎样进入审批、排产或客服流程？错误由谁发现，人在哪一步接管？这些问题直接影响系统是否可用，也决定了一次演示能否成为持续运行的生产系统。

我们据此理解 AI 公司对 FDE 的重视：通用能力更容易获得后，把它嵌入具体业务并持续验证结果的工作更加突出。不过，招聘页面能够证明岗位存在，不能证明相关公司已经建立了与 Palantir 相同的产品回流机制。[6][7]

仍以减少停机为例，AI 可以帮助读取维修记录、归纳故障原因、提出检修建议。但谁能查看哪些记录，什么条件下允许生成工单，哪些建议必须人工批准，都需要进入系统设计。

其中，数据连接、权限继承、评估、异常处理和人工接管，有可能沉淀为可复用能力；某条产线的维修规则，则可能需要留在客户应用层。如果每个项目都从头拼接模型、接口和流程，交付速度即使提高，产品也未必随之积累。

学习 FDE，需要同时建立现场解决问题的能力，以及把共性问题带回产品的机制。前者让一个项目交付成功，后者让更多项目能够共享这次投入。新增一个岗位名称，无法代替这两部分工作。

对企业管理者和技术负责人，判断 FDE 是否有效，最直接的方法是拿出一个真实项目查证据。

现场发现了什么？哪些改进进入了产品？谁已经复用？客户能否接手？下面四问，可以把讨论落到具体工作上。

某一项缺少证据，就能指向具体的改进位置。现场意见进不了产品路线，需要检查反馈与决策机制；复用停留在文档里，需要检查是否形成可维护的共享能力；客户始终无法接手，则需要检查平台易用性和知识转移是否到位。

还可以进一步把第一个和第二个同类项目放在一起：到底少做了什么？

答案应落到具体模块、工程工时、部署周期或支持需求上。比较时必须控制项目范围和质量要求，不能把少做功能当成效率提升。

回看 Palantir，难以复制的部分，是把不同客户和行业里的经验持续带回同一套产品架构，同时控制定制化造成的分裂。这需要现场团队影响产品决策，也需要核心研发作出取舍，并持续维护提炼出的通用能力。

FDE 的价值，既要在这一次的业务结果中验证，也要在下一次减少的重复投入中验证。客户的问题解决之后，产品留下了什么，才是企业学习这套模式时需要追问到底的事。