FDE：前沿部署工程师，AI 交付的新范式
从 Palantir 到 OpenAI：FDE 角色的起源、为什么 AI 落地特别需要它、与驻场外包的本质区别。
角色起源：从 Palantir 走出的实践
前沿部署工程师（Forward-Deployed Engineer, FDE）这个词由数据分析公司 Palantir 发扬光大。它的做法一度显得「重」得不合常理：把最优秀的工程师直接派到客户现场——政府机构、金融机构、工厂——与客户的分析师并肩工作，从真实的业务问题出发搭建系统，而不是坐在总部等需求文档。这套模式让 Palantir 在最难标准化的领域完成了交付，也让 FDE 成为一种被验证过的组织实践。
2025 年以来，随着 AI 公司大量招聘同类角色，FDE 成为 AI 行业的热门岗位之一，OpenAI 等公司公开谈论这一角色在其企业交付中的价值。角色的流行不是偶然——它恰好回应了 AI 落地最棘手的那道鸿沟。
为什么 AI 落地特别需要 FDE
大语言模型（Large Language Model, LLM）的能力上限很高，但能力与真实场景之间隔着一条巨大的鸿沟：模型会写代码、会总结文档，但客户的真实问题从来不是「帮我总结」，而是「这个审批流程为什么每周卡三次」「这批工单里哪些其实是同一个故障」。
这些问题无法通过需求文档完整传递。信息分散在现场人员的脑子里、聊天记录里、只跑一次的脚本里；等写成 PRD，上下文已经失真。传统的「产品经理收集需求 → 总部研发 → 发布」链条，在 AI 落地场景中失效率极高——因为没人能在事先说清楚模型在这个具体流程里到底能干什么、会在哪里出错。唯一可靠的办法，是把工程师放到现场，让ta亲眼看到问题发生的那一刻。
FDE 的一天
一名 FDE 的日常大致是这样的：上午在客户运营团队旁边观察一线员工怎么用现有系统，记下三个没人写进需求的手工环节；中午与客户的技术负责人对齐数据权限的边界；下午写一个快速原型，把模型的输出接入客户真实的工单流，当天让一线员工试用并收集反馈；晚上把现场发现整理成简报，同步给总部的产品团队——「这个问题可能在其他客户那里也存在，值得做成产品能力」。
关键词是当天。FDE 的工作节奏以「现场反馈周期」为单位，而不是以「版本发布周期」为单位。这也解释了为什么 FDE 必须是工程师而不是顾问：没有写代码、改代码、当天部署的能力，现场观察就只能停留在报告层面。
与「驻场外包」的本质区别
「把工程师放到客户现场」听起来很像传统的驻场外包或定制开发，但两者有一个决定性差异：经验是否回流。
- 驻场外包：现场问题在现场解决，方案留在客户那儿，交付团队的资产是个别工程师的经验，换个项目就清零。
- FDE：现场问题在现场解决，但解决方案与洞察会被抽象、沉淀，回流为公司的产品能力——下一个客户遇到的同类问题，直接用产品化模块解决。
Palantir 的很多产品能力正是这样从客户现场「长」出来的。FDE 模式因此是一种双向流动：产品能力流向现场，现场经验回流产品。这也是它能持续 scaling、而外包模式边际成本不降的根本原因。
小结
FDE 是 AI 时代「从现场出发做产品」的组织化表达。它承认一个朴素的事实：模型能力与真实需求之间的翻译工作，无法坐在办公室完成；同时它坚持另一个原则：现场的经验必须回流，否则就只是一件成本高昂的外包。对 AI 供应商和采购方而言，理解这一点比理解任何单项技术都重要。