FDE火了，企业会把钥匙交给外人吗？

文 | Techmo

最近这段时间，FDE突然成了AI行业的热门缩写。

5月，OpenAI宣布成立一家专门帮助企业部署AI的公司，并计划收购应用AI咨询公司Tomoro，后者约150名工程师和部署专家将加入。新公司获得超过40亿美元初始投资，麦肯锡、贝恩和凯捷也在参与者之列。OpenAI的公告发布后，国内的云计算、ERP和软件服务企业也密集谈论FDE。

8月底，明略科技在中期业绩中披露，公司已有约30%的交付人员转型为FDE，并将推动普联软件的FDE模式转型；中远海控准备培养自己的FDE，软通动力、金蝶、致远互联则把FDE写进产品交付体系。

打开招聘软件，阿里，字节，蚂蚁集团，Minimax，商汤等一众大厂也纷纷挂出FDE岗位招贤纳士。

一个在Palantir存在了二十多年的概念，为什么等到大模型出现才大规模走红？

这个岗位通常被译为“前沿部署工程师”或“前线部署工程师”。名字新鲜，工作场景却似曾相识：进入客户现场，理解需求，接入数据，修改系统，再陪着客户把项目跑起来。咨询顾问、解决方案架构师和驻场开发过去也做过类似的事。

FDE是不是新职业，反而没有那么重要。企业押注的是另一件事：能否把依赖个人经验的驻场交付，变成可以不断复用的软件能力。

资本市场买的不是职位名称

Palantir把FDE视为一种产品开发方法。工程师靠近客户正在处理的问题，再将现场发现带回核心研发团队，公司把这个过程形容为软件研发中的“人类反向传播”。Palantir官方文档显示，这套方法从公司早期一直延续至今。

近两年，随着Palantir估值上升，外界开始用FDE重新解释这家公司的增长。FDE能够解释的是，为什么一家需要工程师深入客户现场的软件公司，仍可能保有软件生意的高毛利率。

General Mills的供应链项目提供了一个样本。这家食品企业在北美连接着4000家供应商和200多座工厂，每年处理约120万份订单。按照Palantir公布的客户案例，双方接入200张主数据和运营数据表，建立供应链决策系统ELF。它每天检查约3000份订单，提供约400条调整建议，其中超过70%被工作人员接受；General Mills称，这套系统每天节省约4万美元。

系统必须同时理解订单、运力、产能、成本和业务约束，还要知道什么建议可以执行，什么决定必须交给人。顾问可以提出优化方向，传统实施工程师可以把数据库接起来，FDE则要把模糊问题变成生产系统，再用采用率和业务指标判断系统是否有效。

三类岗位没有天然分界，差别主要在责任的终点。顾问通常交付建议，驻场工程师对约定范围内的上线和运维负责，FDE还要把现场问题带回供应商的核心产品。只在客户处写一次性代码、下一次交付仍从头开始，这份工作依旧是定制开发。

国内公司押注交付效率

国内玩家的打法差异化也很明显。

明略科技在尝试改造原有交付队伍。公司上半年约30%的交付人员转型为FDE，并表示将推动普联软件团队，转型成为面向央国企的FDE。过去，项目经验留在顾问或实施人员手中；现在，公司试图把经验写成Skill和Agent，让下一次交付少依赖人。

软通动力提出“AI Factory+行业经验+FDE”，从咨询、模型部署、智能体开发一直做到持续运营。致远互联则把FDE定义为深入现场完成数据治理和定制功能开发，再把业务痛点反馈给内部团队。前者来自大型IT服务商，后者来自协同管理软件厂商，都想给传统交付增加产品反馈这一环。

这也提示了一个风险：FDE正在成为宽泛的商业标签。谁都可以把售前、实施和外包团队改名为FDE。判断它是不是新模式，不妨问三个问题：工程师是否写生产代码，是否对实际采用负责，单个客户的经验是否进入标准产品。缺少最后一项，再豪华的岗位名称也改变不了项目制生意。

企业不会把整串钥匙交出去

FDE越接近真实业务，权限矛盾越难回避。

工程师只看到一份脱敏订单表，可以很快做出原型。要让系统参与每天的排产和运输调整，他还得理解供应商等级、客户优先级、违约成本和异常审批。最有价值的信息往往不在数据库里，而在业务人员处理例外的习惯中。

国内已经出现了这种现场。2026年8月，阳光智维与金蝶启动统一智能平台项目，先从合同、票据和投标文件审核入手。按照金蝶披露的方案，外部团队将进场整理审核规则、样本和知识，建立“AI初审、人工复核”的流程。虽然尚无公开结果证明效率已经提高，但它展示了FDE需要接触的内容：票据只是表层，真正要写进系统的是红线条款、审批责任和历史判断。

企业不该因为对方叫FDE就开放全部系统。外部团队需要的是完成特定任务所需的最小信息：开发与生产环境隔离，敏感字段分级，账号按项目授权，代码合并由内部审批，操作留下日志，项目结束后回收权限。

技术只能限制成员能看什么，无法回答企业为什么愿意让你看的问题。外部团队可能接触成本结构、客户关系和未公开的经营规则，保密协议无法完全消除知识外溢风险。反过来，如果企业只提供层层过滤的材料，FDE又容易停在演示阶段，做出一个看起来聪明、实际无法接管业务的应用。

深度FDE项目先要解决信任问题。成熟企业必须保留内部的数据负责人、业务负责人和安全团队。外部FDE可以进入被授权的房间，开哪扇门、怎样解释业务规则、系统能否上线，决定权仍在企业内部。

内部FDE与外部FDE，谁会留下

甲方也在建立自己的FDE队伍。除了上文我们看到的诸多大厂FDE内部团队招聘信息，中远海控表示，将以FDE人才培养为抓手，建设业务与技术结合的内部AI研发团队。对于拥有复杂航运网络的大企业，这个选择不难理解。外部工程师熟悉模型和平台，内部人员更清楚哪些数据口径不能混用、哪个审批环节不能绕开，也知道一个看似低效的流程为何一直保留。

内外部FDE会合作，也会竞争。新模型和首批高风险场景需要外部经验；场景进入日常运营后，内部团队必须接管权限、评测和修改能力。供应商不愿交接，客户会担心被锁定；企业把所有工作收回内部，又可能失去跨项目的技术视野。

检验合作是否健康，可以看一个反常识指标：后续项目需要的外部人力是否减少。第一套系统需要十个人驻场，第二套仍从数据清洗重新做起，第三套还依赖同一批人救火，FDE就没有形成软件杠杆，只是按人天收费的项目生意。

最好的FDE项目，应该允许FDE离场

外部FDE见过更多模型失败的方式，也更了解产品接下来可能获得什么能力。这种视角可以帮企业少做几个没有生产价值的演示项目。但他无法替企业决定哪些错误可以接受、哪个部门应当让出权力，以及自动化失败后由谁负责。AI转型牵涉预算、责任和利益调整，代码只能处理其中一部分。

我们认为，外部FDE会长期存在，因为模型和工具还在变化。但在一项具体业务中，FDE不应成为永久岗位。项目成熟后，日常运营要回到内部团队，常见需求要进入标准产品，低阶的数据转换和故障排查还会逐渐被AI接管。Palantir已经推出能够操作Foundry、管理代码库和修改数据转换的“AI FDE”，人类FDE的工作将更多转向业务判断、权限协调和异常处理。

一个FDE项目真正完成，可以看三个结果：外部工程师离开后系统仍在使用，内部团队能够独立修改，供应商服务下一位客户时不必从头再来。

如果驻场队伍越来越大、合作期限越来越长、客户离开这批人就无法运行，那么AI行业只是给传统外包换了一个更昂贵的名字。