FDE，作为当前最受关注且充满神秘色彩的AI职位之一，其热度源自多家知名企业提供月薪高达3万至5万元的岗位，在小红书上相关讨论和求职经验分享层出不穷。
根据招聘数据平台FDE Pulse的统计，海外公开薪资的FDE职位，年薪中位数约为20万美元，折合人民币约134万元。
（这些数字背后都是实打实的收入）
而神秘之处在于，我采访了6位FDE从业者，发现他们的工作内容似乎各不相同……
FDE的全称是Forward Deployed Engineer，中文译为前线（前沿）部署工程师。
顾名思义，这类工程师被派驻到客户现场：既负责软件部署，也协助解决客户的实际业务难题。
如今，这一概念已从硅谷蔓延至国内市场。
海外，Anthropic宣布投入1亿美元，计划在2027年底前培养1万名FDE工程师；OpenAI也携40亿美元投资，成立专注部署的公司；AWS则斥资10亿美元组建FDE部门，将数千名工程师派往客户身边。
国内企业同样跟进，许多大厂已发布FDE职位。Kimi宣布联合多家IT服务商共建FDE团队；腾讯云推出号称行业首个的FDE工程师认证，并招募FDE合作伙伴。
与此同时，独立开发者也开始涌现，凭借个人能力接单，为企业实施AI转型。
但话说回来，派遣工程师到客户现场的做法，在互联网时代早有先例。
部署工程师、实施顾问、解决方案工程师、售后工程师……这些角色从事的工作类似，甚至一度被视为“苦差事”。
那为何到了AI时代，它突然变得炙手可热？这个传统岗位，究竟发生了哪些变化？
在经典的FDE模式中，常涉及两个不同角色：Echo和Delta。
Echo负责理解业务需求、沟通方案和设计；Delta则负责编写代码、整合数据，将方案落地实施。两者在前线协作，共同满足客户需求。
后方还有一群Dev（普通工程师），负责开发标准化平台。
Delta和Dev的区别可概括为：Dev追求“一个能力，服务众多客户”，而Delta则聚焦“一个客户，解决诸多问题”。
值得一提的是，国内FDE的部分招聘岗位也开始标注Echo或Delta方向，这种情况在两个月前还未出现。
前线工作很大程度上围绕Ontology（本体）展开。
简单来说，Ontology是一张能被软件和AI调用的“业务地图”：涵盖企业内的员工、部门、订单及其关联关系，以及各自允许的操作权限。
FDE需要将散落在不同系统、流程和员工经验中的信息整合进这张地图，并在此基础上开发应用、解决问题。
当这一模式引入中国后，衍生出多种变体。
到了AI时代，驻场工作的重心也发生转变：企业自身难以明确AI的应用场景，FDE需先帮助客户确定方向。
李开复领导的零一万物便是一个典型案例。
零一万物全面转向企业AI，其路径是：先接触企业高层，再派驻前线部署工程师进场，梳理企业的Ontology，最终沉淀为产品和平台。早期一个项目需派出5名FDE驻场，并配备5人的后端团队。
李开复认为，其产品虽已产品化并采用订阅制，“但并非即插即用”。建立一家公司的Ontology需要一至三个月，“公司的数据库、角色和流程必须完善，客户才能获得理想结果”。
在其他公司中，也有人从事类似工作，例如Layla和Sonic。
Layla在一家SaaS公司担任FDE，但她的职位头衔仍是产品经理。
△AI生成
自2025年三四月起，她开始真正参与客户项目。客户均为万人以上的上市公司，涉及连锁门店和制造业，她每次驻场一至两个月。
起初，没人称这项工作为FDE。后来这一模式流行起来，她深入了解后，“才发现，诶，好像是一回事”。
她的工作流程如下：
第一步，进场了解业务，从采购、市场、财务、IT等多个角色中理清客户真实需求；
第二步，提出方案，搭建demo快速验证；
第三步，验证通过后，交由公司原有的交付团队上线；
最后，将可复用的能力抽象出来，迭代回公司的产品中。
这基本是经典的FDE工作流程，也是目前企业或独立FDE开发的常规模式。
Layla认为，FDE的观察和经验，“最终仍需沉淀到标准产品中”。
另一位企业FDE——Sonic，则负责审核类AI项目，如财税审核和广告物料审核。
△AI生成
同样从2025年起，他的团队开始研究FDE。在他看来，FDE的关键环节之一是梳理Ontology。
他举例说：如果企业想开发一个组织管理方面的AI助手，需先梳理企业有多少部门、部门间的关系；除了关系，还有属性，如员工的职级和薪资。
只有将这些抽象成Agent可理解的结构，它才能更准确地回答问题，而非胡乱猜测。
这一过程相当耗时，因为FDE常遇到上下游历史数据不完整、旧系统无开放接口等问题，导致项目推进困难。
但Sonic认为，这一步无法跳过：“如果质量足够高，效果会很好，后续交付质量主要取决于前面的Ontology质量。”
为做好这些工作，Layla和Sonic都需常驻客户现场。
Sonic看来，驻场不仅为了解需求，还要先统一业务方对AI的认知：明确什么能做、什么不能做，双方在相同语境下，才能讨论后续痛点和方案。
而来自硅谷公司Baseten的程天舒却告诉我，他们的FDE基本不驻场。
△AI生成
Baseten是一家AI推理云公司，客户将模型部署在其平台上，他们负责让模型运行更快、更稳定、更经济。
他们接触的客户几乎都是工程师，需求具体明确。例如，原本调用OpenAI的API，现想换成开源模型，需确定选择哪个模型、如何部署、如何达到预期速度和成本。
FDE会与客户开会，了解技术需求，再搭建prototype验证方案。问题可能涉及云基础设施、模型推理优化、训练或产品体验，不同方向由不同专长的FDE负责。
对他们而言，这种沟通基本可在线上完成。
原因在于，Baseten提供的是面向开发者的标准化产品，只负责客户业务中的一段明确链路。定制化程度不高，也无需深入客户组织肌理解业务问题。
“我们的产品与客户自身业务逻辑耦合度不高。”程天舒说。
在公司之外，还有一批“游击队”正在迅速壮大：他们不属于任何有产品的公司，自己找客户、自己接单，为企业实施AI转型。
这本身也是AI带来的变化：过去定制一套系统，需一个团队做几个月；如今代码几乎免费，一个人也能接单交付。
这一市场目前非常野生。号称“全网第一FDE”的Lawted告诉我，他称之为土FDE。
大厂FDE主要推广自家产品，而土FDE面向“土老板”，使用OpenAI或Gemini都行，没有销售任务，“你要什么，我就给什么”。
我接触了一位名叫Zaniel的FDE，聊完后发现，他的路子非常野……
他是一名斯坦福在读博士，今年4月开始独自接企业AI项目。
银行、律所、煤化工、月子中心、家政中介、建筑企业……五个多月下来，他已做了几十个项目，全部由他一人交付。
有趣的是，做了这么多场景后，他的工作重点已从“为客户开发AI系统和工具”转变为“教企业员工如何使用AI”。
△AI生成
例如，他的第一个客户是一家银行，几名员工每天需从数据系统中导出大量数据，汇总成报表给领导。
他最初制作了一个自动生成器，数据拖进去，一键生成报表。
但工具很快无人使用。因为报表规则每天变化，导出的表格格式也不统一，写死的程序“用几天就崩溃了”。
后来他发现，无需新软件，直接教员工将脱敏数据交给通用AI汇总，并将高频流程整理成Skill，连接到现有数据系统。
这样一来，员工真正用起来了。
Zaniel告诉我，至少在白领工作中，大部分问题可通过一个通用Agent、加上大量Skill和对现有系统的连接解决，“无需开发其他新软件”。
另一位独立接单的FDE，软萌孜神也描述了类似情况。
她曾为一家外贸公司做FDE，与老板讨论如何提高员工AI使用率——最终结论是，采购WorkBuddy即可。
△AI生成
她负责培训员工使用WorkBuddy，并为WorkBuddy打通集团内部现有系统。
这些“游击队”式的土FDE，在为企业改造过程中发现，很多时候无需开发新产品或系统，他们的业务模式也开始偏向咨询服务。
Zaniel与企业的合作有两种模式：项目制和顾问制，且顾问制越来越多。
所谓顾问，就是教员工如何使用AI工具。每当新工具出现，便帮企业思考业务如何跟进；若需求不大，他也会顺手完成，包含在顾问服务中。
他将这种角色称为企业外部的“CAIO”（首席AI官）。
而Lawted也觉得，自己的业务开始变得像一家咨询公司。
他运营着一个名为HA7CH的FDE社群，通过举办线下交流会和黑客松，撮合需要AI改造的企业与独立接单的FDE签订订单。
△AI生成
流程是：企业提交需求，他从报名者中挑选一两名选手。选手进厂48小时，梳理工作流、制作demo，打动老板便当场签单，后续交付由选手负责。
办了几期后，Lawted越来越觉得FDE“非常像咨询”：企业往往只知想用AI，却说不清问题所在，FDE需先进入现场完成诊断，再制定方案。
在他看来，咨询顾问甚至比程序员更适合转行做FDE，只需补充vibe coding能力，“vibe coding其实不难”。
看到这里，你大概也会发现，FDE的工作中，编写代码和开发的时间并不多，与人沟通反而占了大多数。
几位从业者都告诉我，他们沟通需求的时间占七成以上，开发大约只占三成。
而与客户员工产生摩擦、打不开接口权限等困难，也往往发生在这个过程中。
在推动WorkBuddy接入企业内部系统的过程中，软萌孜神经常需与采购、IT、ERP产品经理和外部工程师反复沟通。有些系统没有现成接口，还得推动企业自行开发。
一个多月过去，仍有不少API未开放。她说，第二天自己还要继续与IT部门交涉。
不过，她也不认为是员工故意阻挠。“没有人刻意给你使绊。”只是每个人都有自己的任务，AI改造在对方那里未必有高优先级。
△AI生成
拿不到权限，有时只是流程问题。
但AI带来的阻力，还有更微妙的一层：过去部署一套软件，很少直接影响到谁的位置；AI不同，它可能改变一个团队原本的工作。
有家企业想开发一套覆盖几十个业务模块的AI系统。Zaniel估算，自己三四个月就能完成，但客户要求他以顾问身份与IT团队合作。
尽管签了保密协议，对方仍不愿开放代码库，却时常让他远程排查问题。
Zaniel也建议，部分模块直接使用通用Agent即可，没必要全部自研。
领导回了一句：“你都用WorkBuddy了，那他们干啥呢？”
……听完我只能说，这太真实了。
不过，Zaniel也并不简单地将此归结为客户“不配合”。客户可能有保密要求、既有的供应商关系，也可能只是不同部门各有顾虑。
“对于企业，换一种工作方式的代价，常常比换一个工具大得多。”他说。
另一个常被讨论的问题是：FDE究竟是不是外包？
至少在Baseten，答案是否定的。
程天舒告诉我，他们的FDE与普通工程师一样，招聘标准、面试流程完全相同，同样拿固定薪资和股票，不靠提成。
FDE提供的服务也不单独收费。即使搭出原型，只要客户最后未使用Baseten的云平台，就不需付费。
对他们来说，FDE服务于自家产品：帮客户用起来，再将现场反馈带回改进产品。
△AI生成
在企业中的Layla和Sonic也认为，将经验沉淀回产品、进行复用，是FDE与外包的重要区别。
Layla表示，过去区分外包，看的就是它“不会做自己的产品，不会沉淀自己的能力”。
“如果我们也不沉淀自己的能力，不做自己的产品，每个项目都从零开始，别人说是外包，也无法反驳。”
Sonic很直接地告诉我，传统外包做不了FDE。“不信可以找外包试试。”
作为FDE，他们会将项目里可复用的模块，按场景沉淀到评测和迭代平台上，再搭建Skill Hub、Agent Hub，组里的FDE都在上面做评测和优化。
效果是，在一个垂直领域里，第一个场景从接入到上线大约需一个月；后续同类场景可能一两天就能完成。
“做得越久，速度越快。”速度快意味着会议更少、沟通成本更低，“业务会觉得整个过程很轻，钱花得值”。
听起来，只要能将经验沉淀下来、复用到下一家，FDE就与外包划清了界限。
本来到这里，我已基本被前面几位嘉宾说服，但Zaniel又刷新了我的认知。
大家通常想象的复用，是先做出一套半标准化软件，到下一家客户，“把规则调一调，即可直接部署”。
Zaniel并不否认Skill、代码和行业经验可以复用。但他质疑：这些积累，究竟能让下一次完整交付便宜多少？
过去做一套企业软件，开发可能要花90块，给每家客户适配只需10块。软件做一次、卖给多家，前面那90块就能被逐步摊薄。这是传统软件公司的生意逻辑。
AI改变了这个公式。现在开发只需1块，适配还是10块。
△AI生成
例如，给一个客户做了客户管理系统，下一个客户也要，那还不如直接重新做一套，“因为AI现在做一个软件出来太快了”。
当然，代码可以复用，Skill和行业知识也能积累。但每进入一家新企业，FDE仍需重新理解需求、连接系统、处理权限，再推动不同部门接受新的工作方式。
这部分投入，并不会随代码成本一起降低。
软件越来越容易复制，这门生意能否复制，却是另一个问题。
访谈到最后，我几乎问了每个人同一个问题：
FDE会一直存在吗？
程天舒认为，FDE这个岗位的最终目的，“就是要将FDE给取消掉”。
需要FDE出手的地方，说明产品与客户需求之间还有差距；产品做得足够好，客户自己就能搞定，也就不再需要FDE了。
在他看来，FDE更适合产品不成熟的早期公司。成熟的公司其实不太需要这个职位，它更像是公司打磨产品过程中“一个过渡性职能”。
但他也承认，AI发展太快，“你昨天做的产品，今天就赶不上了”。只要市场还在变，这个差距就会一直存在，所以这个目标“可以逐渐靠近，但永远无法抵达”。
Zaniel的看法则是：FDE要做的事，在AI之前就一直有人在做，以前叫管理咨询，也叫IT外包，只是这个词最近才火起来。
“至于这个词火不火，这就是一个互联网的传播学问题了。”
事实上，他和软萌孜神都不太在意自己是不是FDE。对外这么说，只是因为大家熟悉这个词。
“其实我不是特别喜欢别人说我是FDE，但又不得不这样。因为现在市场上，你必须跟客户说AI FDE，大家才会关注。”软萌孜神说。
她更愿意称自己为创业者，目标是用AI改造外贸，“让中国供应链再次伟大”。
FDE三个字母，已被赋予了过于丰富的含义。
软件开发、咨询服务、员工培训、系统对接、社群撮合……这些看似不同的工种，通通可以与FDE相关