从项目到产品：FDE模式如何让客户交付转化为可复用能力

每交付一个客户项目，团队就要重新接入数据、梳理权限、搭建流程。当客户数量持续增长时，产品的核心能力却没有同步积累，反而陷入项目越多、人力越紧的困境。这种现象在企业服务领域普遍存在，Palantir的前沿部署工程师模式却提供了一种不同的思路。Forward Deployed Engineer，简称FDE，并非简单的驻场开发或技术支持。其本质在于让工程师深入客户现场，发现的问题能够持续进入核心产品架构，使一次交付成为后续项目可以复用的能力。如今大模型让通用能力更容易获得，企业仍需解决数据接入、权限管理、业务流程和生产稳定性等具体问题。理解FDE如何运作，对正在推进AI落地的企业具有重要的参考价值。

需求文档之外的关键知识

在复杂的业务场景中，很多关键信息无法提前写入需求文档。以情报分析和国防场景为例，数据分散在不同系统中，格式、可信度和访问权限各不相同，软件还需要适应本地数据中心甚至断网环境。「整合数据」「发现关联」这些目标可以写进需求，却不足以指导具体开发。分析人员如何判断一条信息的可信度？哪些字段会改变最终决策？结果以什么方式呈现才能进入实际行动？这些答案往往藏在日常操作、例外情况和组织分工里。FDE的核心价值，首先是补全产品定义中缺失的现场知识。工程师需要弄清楚用户如何判断、如何行动，才能决定软件应该提供什么能力，以及怎样才算真正解决问题。

从系统上线到业务结果落地

即使模型已经能够给出风险预警或分析建议，工作也远未结束。预警应该交给谁？负责人能否据此调整检修计划？如果预警从未改变任何业务决策，系统上线就不等于业务改善。FDE需要沿着完整的价值链工作：理解业务目标，接入真实数据，构建分析或应用，把结果嵌入工作流，再观察它是否真正改变了决策。这要求工程师把现场判断不断落实为可运行的软件，并根据实际使用情况持续调整方案。但完成当前客户的任务只是第一步，更关键的问题是：这次解决问题的经验，怎样才能被其他团队和客户直接使用？

现场经验向核心产品的回流路径

项目型团队也能解决复杂问题，真正的困难往往出现在交付之后。客户离不开熟悉现场的那几个人，其他团队却很难直接用上他们积累的经验。有人写了专用接口，有人记住了权限例外，还有人知道某个指标真正代表什么。系统能够运行，知识却分散在人、文档和客户专属代码里。Palantir的做法是将现场工程师纳入产品研发的反馈机制。软件工程师会在现场与产品开发职能之间轮换，现场工程师被视为研发体系的延伸，他们发现的改进会被系统性地纳入核心平台。这套方法被Palantir架构文档比喻为「人类版的反向传播」：工程师靠近真实问题，与核心研发一起持续消化反馈、发布新能力。但客户需求不会自动变成产品能力，团队仍需作出判断——哪些是单个客户的特殊规则，适合留在配置层；哪些问题会反复出现，值得抽象为核心平台能力。

跨客户复用的平台能力分层

不同行业的客户关注点各异，工厂关注设备与工单，航空公司关注飞机与航班，医院关注床位与病人。但这些场景经常需要回答相似的问题：数据怎样接进来，对象怎样关联，谁有权操作，判断怎样触发行动。这些反复出现的工程问题为平台复用提供了基础。通过分析Palantir的架构文档，相关平台能力可分为六类：数据接入与转换能力、细粒度权限与审计治理、业务对象建模机制、规则与应用开发能力、工作流与行动接口、跨环境的部署与交付能力。其中Ontology本体把数据、业务对象、逻辑、动作和安全策略组织到同一套业务表示中，工程师可以围绕「工厂」「订单」「设备」等对象构建系统，定义对象之间的关系和可执行操作。这样团队可以围绕业务对象组织应用，不必每次都从孤立的数据表开始设计。平台本身应吸收部署、接数和升级中的重复劳动，使客户数增加后相应投入不再按原来的比例增长。

FDE的价值，既要在当次业务结果中验证，也要在后续项目中减少的重复投入中验证。大模型让通用能力更容易获得后，把它嵌入具体业务并持续验证结果的工作变得更加突出。但新增一个岗位名称无法代替两部分核心工作：现场解决问题的能力，以及把共性问题带回产品的机制。客户问题解决之后，产品留下了什么，才是企业学习这套模式时需要追问到底的事。