对 FDE 的三个误读
作者：吴穹
本文首发于 Agilean 微信公众号
公众号原题：《FDE 火了，但很多人把这三件事搞错了》
导语
最近，FDE 正在成为国内 AI 行业的新热词。
给客户安装大模型一体机的叫 FDE，配置知识库和智能体的叫 FDE，把 WorkBuddy 导入客户现场的也叫 FDE。过去叫实施顾问、解决方案工程师、驻场开发的岗位，似乎只要进入客户现场，就都可以换上 FDE 的新名字。
FDE 的关键不是驻场，而是让业务现场进入产品研发闭环
但如果 FDE 只是换了一个更时髦的名称，它并不能解决国内软件行业长期存在的问题：总部维护一套基础源码，客户来了就复制一份，然后派人到现场不断修改。项目交付了，产品却没有变得更好；客户越来越多，版本也越来越多，最后所有收入都被交付和维护成本吞噬。
Palantir 的 FDE 模式不是这样。它真正有价值的地方，不是把工程师派到客户身边，而是把客户现场纳入产品研发过程：团队在现场发现真实问题，快速构建解决方案，再把经过验证的共性能力带回核心产品。
FDE 的核心不是“人在现场”，而是“让现场成为产品研发的一部分”。
过去，这套模式在国内很难大规模成立。它需要足够成熟的平台产品、高密度的复合型人才，还需要企业愿意为持续创造的价值付费。国内大量软件公司依靠项目收入生存，产品团队和交付团队彼此割裂，现场成果也很难回到产品主线。
AI 的出现正在改变其中一个关键变量：软件研发和知识转换的成本。它让小团队能够更快理解业务、形成原型、完成开发，也让现场经验转化为产品能力的成本显著下降。FDE 在国内因此第一次具备了更广泛的可行性。
但在讨论怎么培养 FDE 之前，我们需要先澄清三个误解。
误解一：到现场安装产品，就是 FDE
现在国内最常见的 FDE，是所谓的“最后一公里交付人员”。他们进入客户现场，安装软件、部署模型、连接系统、导入数据、配置智能体，再对用户进行培训。
这些工作都很重要，但它们首先属于实施、部署、运维和客户成功。仅仅把一个已经完成的产品安装到客户现场，并不构成 FDE。
传统实施人员面对的是一套边界相对确定的产品。他们的任务，是让产品在客户环境中正确运行。即使客户提出新的需求，通常也是先记录下来，再转交总部评估。实施工作的终点往往是系统上线或者项目验收。
FDE 不同。FDE 带到现场的，不是一套不可改变的成品，而是一个能够继续演进的产品基础。他不仅要让产品运行起来，还要在真实业务中发现产品尚未解决的问题，快速修改和验证，并把现场形成的共性能力带回统一产品。
安装产品的人解决“怎样交付”，FDE 还要回答“产品应该变成什么”。
因此，判断一个现场岗位是不是 FDE，不能只看他有没有进入客户现场，而要看他有没有进入产品闭环：现场发现的问题是否进入产品路线图？形成的能力是否回到统一代码库？下一个客户能否直接复用？产品是否因为这次交付而完成了一次进化？
如果现场团队只是在客户版本上持续修改，项目结束后留下一个独立分支，那么无论使用了多少 AI、派出了多少工程师，本质上仍然是传统驻场开发。
这也是 FDE 在国内落地时必须正视的现实。国内企业软件很难完全脱离项目制，不同客户的流程、数据、系统、权限和监管要求差异巨大，期待用一套开箱即用的标准产品解决所有问题并不现实。
因此，国内 FDE 的出路不是消灭项目制，而是建立产品化的项目制。
产品化的项目制允许客户存在个性化需求，但不能让每个项目都变成一套新产品。客户特有的能力可以留在项目层，具有行业共性的能力则必须回到产品层。传统项目以验收为终点，产品化项目则把上线视为获得真实反馈的开始。传统项目从基础源码复制一个新版本，产品化项目则从统一产品出发，通过配置、扩展和标准接口完成适配。
每完成一次交付，团队都应该回答一个问题：这次现场工作，是否让下一次交付变得更快、更好、更便宜？
如果答案是否定的，那么企业只是完成了一个项目，并没有增强产品。
AI 为产品化的项目制提供了新的可能。过去，现场团队即使发现了产品问题，也可能没有能力完成修改；总部团队虽然有工程能力，却不理解现场语境。AI 扩大了现场人员的技术半径，使他们能够更快读懂代码、连接系统、构建原型和验证方案，也降低了总部吸收现场成果的成本。
但 AI 也可能把企业带向相反的方向。它既能加速产品化，也能更快地制造定制代码。如果组织机制没有改变，过去两个月生成一个客户分支，现在可能两周就能生成一个，最后留下的仍然是一地技术债。
AI 降低了写代码的成本，却不会自动提高产品化的能力。
所以，FDE 的第一个门槛不是有没有现场工程师，而是有没有真正的产品。真正的 FDE，必须带着产品进入现场，并且有能力改变产品。
误解二：FDE 是一个无所不能的人
第二个误解，是把 FDE 想象成一个超级个体：既懂行业和客户，又能做产品经理；既能开发前后端，又能处理数据、模型、部署和组织关系。
AI 确实提高了个人能力。一个工程师借助 AI，可以覆盖过去需要多人协作的范围。但这并不意味着企业可以把所有责任都压缩到一个岗位上。
FDE 首先是一种团队能力，其次才是一个岗位名称。
Palantir 当前用 Echo、Delta 和 Dev 描述三种互补角色。Echo 深入客户业务，理解组织如何真正运行，找到最值得解决的问题，并通过快速原型让模糊需求变得可验证。Delta，也就是 Forward Deployed Software Engineer，负责把经过验证的问题转化为能够进入生产环境的系统，解决数据、接口、权限、性能和可靠性问题。Dev 则站在核心产品一侧，把不同现场反复出现的能力抽象为通用平台。
如果用我们提出的 AI Native 研发团队五角色模型来理解，Echo 更接近 Prototyper：它缩短了从模糊问题到可验证方案的距离；Delta 和 Dev 则覆盖 Productizer 的不同阶段：Delta 把原型变成客户现场可用的生产系统，Dev 再把验证成功的方案沉淀为可服务更多场景的产品能力。在这套模型中，另外三个角色——Challenger、Beautifier 和 Grower——分别补足质量挑战、体验精修与价值增长，使现场发现、产品构建和真实使用反馈能够形成更完整的 AI Native 研发闭环。
这里需要区分职位定义和组织模式。按照 Palantir 的严格职位口径，Delta/FDSE 是具体的前线部署工程师，Echo 的正式职位是 Deployment Strategist。但从 Forward Deployed Engineering 的完整过程看，真正产生效果的不是一个孤立的 Delta，而是 Echo、Delta 与 Dev 共同构成的闭环。
Echo 防止团队把错误的问题做得很漂亮，Delta 防止团队只留下漂亮的 Demo，Dev 防止团队在每个客户那里重复发明轮子。
这意味着，企业要建设 FDE 能力，不能只靠招聘或者培训一批名为 FDE 的人。一个人即使掌握了业务分析、提示工程、智能体开发和系统集成，如果他无法调用产品团队，不能推动现场成果进入产品主线，也无法影响产品路线图，就很难形成真正的 FDE 闭环。
组织真正需要建立的，是一套 AI Native 的岗位体系和研发机制。有人深入现场发现问题，有人快速构建原型，有人把原型做成可靠的生产系统，也有人负责把项目能力沉淀为平台产品。一个人可以跨越多个角色，但这些责任不能在组织中消失。
AI 的价值，是降低角色之间协作和转换的成本。业务型人才可以更快做出原型，工程师可以更快理解陌生行业，产品团队可以更容易消化现场代码。它让一个小队能够覆盖过去需要一个大型项目组才能覆盖的范围，却不意味着一个人可以替代整个组织。
AI 提升的是小队的能力密度，而不是证明一个人可以成为一支队伍。
如果一家企业只是把原来的实施工程师集中培训，再把岗位名称改成 FDE，却没有同步改变产品管理、研发流程、代码治理和考核机制，那么它培养出来的只会是一批能力更强的项目人员，不会形成真正的 FDE 组织。
误解三：FDE 一定是乙方派到甲方的人
第三个误解，是认为 FDE 天然属于软件厂商，是乙方为了把产品卖给甲方而设置的现场岗位。
这种理解很容易让 FDE 与高端实施、解决方案咨询或者驻场开发画上等号。但 FDE 的本质并不由甲乙方身份决定，而是由它在价值闭环中的位置决定。
只要一个团队能够进入业务现场、理解真实问题、快速构建方案，并把经过验证的能力沉淀为可复用产品，它就在从事 Forward Deployed Engineering。按照这个标准，甲方内部同样可以拥有 FDE，而且在国内环境中，甲方内部的 FDE 可能更有发展潜力。
大型银行、制造企业、能源企业和集团公司拥有大量复杂而独特的业务场景。这些场景涉及内部流程、历史系统、权限结构、监管要求和大量隐性知识。外部厂商可以提供平台和技术，却很难在短时间内真正理解一个组织如何运行。
甲方内部的科技人员天然更接近业务、数据和用户。如果他们能够走出科技部门，进入真实业务一线，与业务人员共同发现问题、验证方案并持续迭代，就可以形成企业内部的 FDE 小队。
传统企业内部其实也存在一种隐性的甲乙方关系：业务部门提需求，科技部门接需求，双方通过需求文档、项目排期、预算和验收进行协作。虽然没有跨越企业边界，但依然存在很高的信息损耗。业务很难一次说清真正的问题，科技拿到的往往已经是一个预设的解决方案。等到系统交付时，团队才发现需求已经变化，或者最初解决的根本不是关键问题。
内部 FDE 的作用，就是缩短这条需求链路。科技人员不再坐在后方等待业务提交需求，而是进入业务现场，与业务人员一起观察流程、定义问题、构建原型并验证价值。
传统内部甲乙方以需求为交易对象，内部 FDE 则以业务结果为共同目标。
公开资料显示，上海银行已经引入“业技融合（FDE）”工作模式，让 AI 工程师直达业务一线，与业务人员共建智能应用，形成“业务提出问题、现场快速验证、持续迭代优化”的过程。在其公布的基金交易文件解析场景中，单个文件解析时间被压缩到十秒级，批量处理效率较人工提升了 80% 以上。
这个案例值得关注，不只是因为一家银行使用了 FDE 这个名称，而是因为它展示了另一条路径：FDE 不一定是外部软件公司派驻客户的团队，也可以是甲方内部连接业务与科技的机制。
甲方内部推进 FDE 还有一个重要优势：组织边界内的交易成本通常更低。内部工程师可以更持续地接触用户、数据、流程和历史系统，也更容易进行多轮、小步试错。很多价值尚不明确、需求尚不清晰的场景，难以支撑一次正式的外部采购，却非常适合由内部小队先快速验证。场景得到证明以后，再引入外部厂商的平台和工程资源，也能减少采购和建设的盲目性。
当然，内部交易成本低并不是天然成立。部门墙、预算机制、项目考核和需求排期，同样可能让内部协作变得非常昂贵。如果只是让科技人员去业务部门驻场，却不给小队实验权限，也没有企业级产品和统一工程治理，内部 FDE 仍然会退化成一个项目组。
甲方内部 FDE 的“产品”也不一定需要对外销售。它可以是一套企业级平台、一组可复用组件、一个数据产品、一套智能体能力，或者一条标准业务流程。判断它是否完成产品化的标准仍然相同：一个场景中形成的能力，能否被其他部门、其他分支机构和其他业务流程重复使用。
未来更可行的形态，可能不是乙方 FDE 单独进入甲方现场，而是甲乙双方共同组成混编小队。乙方带来平台、工程方法和跨客户经验，甲方带来业务知识、内部数据和组织推动力，双方共同完成场景发现、原型验证、生产建设和能力沉淀。
对于乙方，沉淀的结果应进入能够服务更多客户的通用产品；对于甲方，沉淀的结果应进入能够服务更多内部场景的企业级平台。双方沉淀的边界不同，但遵循的是同一套产品化逻辑。
FDE 不分甲方和乙方，只区分有没有形成从现场价值到产品进化的闭环。
结语：FDE 不是新岗位，而是新的研发闭环
国内并不缺少进入客户现场的人，真正缺少的是把现场经验变成产品的人；国内也不缺少能够完成一个项目的团队，真正缺少的是让每一个项目持续增强产品的机制。
AI 改变了软件开发的成本结构，提高了团队的能力密度，也让业务知识、原型和生产系统之间的距离显著缩短。过去只有 Palantir 这类高客单价、高人才密度的软件公司才能承担的现场研发模式，现在开始具备更广泛的可行性。
但机会并不来自把所有现场岗位改名为 FDE。
真正的 FDE，必须带着产品进入现场，也必须有能力把现场成果带回产品；它不是一个人的全能表演，而是一支 AI Native 小队的协同；它不只属于乙方，也可以成为甲方内部连接科技与业务的重要力量。
对乙方软件公司而言，FDE 的出路是把传统项目制改造成产品化的项目制，让每一次客户交付都推动产品进化；对甲方企业而言，则是利用内部业务距离更近、协作成本更低的优势，在科技部门与业务部门之间建立内部 FDE 小队，让科技从被动接收需求转向与业务共同发现问题、共同研发产品。
FDE 在国内的真正出路，不是把传统驻场交付包装成一个新概念，而是借助 AI 重建技术与业务的协作关系。它可以发生在软件公司与客户之间，也可以发生在企业内部的科技与业务之间。它真正要打破的不是甲乙方边界，而是需求提出者与产品建设者之间的距离。
无论发生在企业边界之外还是之内，FDE 的本质都只有一个：把业务现场变成产品研发的前沿。
参考资料
- Palantir, Careers: Echos, Deltas, and Devs. https://www.palantir.com/careers/
- Palantir, Students and Early Talent. https://www.palantir.com/careers/students-and-early-talent/
- 上海市国有资产监督管理委员会：《上海银行以 AI 实践和数字化转型赋能创新发展》，2026-07-21。https://www.gzw.sh.gov.cn/shgzw_zxzx_gqdt/20260721/6919aa86859644519432b694b6452590.html
- Agilean 微信公众号：《从字节调整QA岗位说起：AI Native团队的五角色模型》；官网版本见《AI Native研发岗位模型：五种新角色与组织责任重构》。