万字长文 | FDE的前世今生，AI越强，企业为什么越需要人去一线

本文来自微信公众号： Agent陌晨 ，作者：陌晨，原文标题：《万字长文 | FDE的前世今生，AI越强，企业为什么越需要人去一线》

大家好，我是陌晨。

一名FDE跟着团队去见客户，对方看了一圈，觉得来的人背景太杂，最后给他安排了一个方便理解的身份，产品经理。另一名做企业AI服务的创业者，晚上独自留在客户公司的会议室。员工准备锁门，顺口问他属于哪个部门。他想了一会儿，说自己算外包。

这两件事来自数字生命卡兹克对几位FDE从业者的采访。[1]一个被介绍成产品经理，一个主动认领外包身份。两个人做的活却很接近，他们进入客户公司，理解业务，搭AI应用，连接系统，再想办法让项目进入日常工作。

FDE这个缩写火起来以后，这群人终于有了一个统一些的称呼。中文常把Forward Deployed Engineer译成前线部署工程师，也有人译成前沿部署工程师。名字很新，工作现场却带着浓重的旧味道。需求含糊，系统封闭，员工防备，老板催进度，项目出了问题还得有人留下来处理。听起来像售前、产品经理、实施顾问、程序员和客户成功一起挤进了同一张工牌。

争论也从这里开始。有人把FDE称为AI时代最值钱的岗位，有人觉得它只是实施工程师换了一个更贵的英文名。转型课程也已经出现，仿佛学会几个Agent框架，再背一套需求访谈模板，就能拿到传闻中的高薪。

我把两份行业报告、两篇从业者采访、Palantir与OpenAI的公开材料放在一起看，发现大家争的经常是职位名称，企业面对的却是同一个难题。模型已经很强了，为什么仍然进不了日常工作。

FDE的内核可以压成一句话。它接住从模糊问题到生产结果的责任，再让一次项目的经验回到产品。客户看前半句，厂商的商业模式看后半句。

沿着这条线回头看，FDE的前世才会变得清楚。

01FDE出现以前，企业已经养过很多翻译技术的人

大型计算机刚进入企业时，机器昂贵，操作复杂，管理者也很难把业务要求直接交给程序员。系统分析员由此成为早期企业计算中的重要角色。他们要跟会计、生产和管理部门谈，弄清一家公司怎样处理订单、核算成本、安排库存，再把这些工作转成计算机能够执行的程序与数据结构。这类人很少只写代码。他们需要看懂业务，也要知道机器做得到哪里。企业说「把库存管起来」，系统分析员得继续追问，库存怎么算，谁有权修改，退货怎样处理，月底对不上账找谁。

今天回头看，系统分析员承担了FDE的一部分功能。两者没有一条可以直接画出来的职业血缘，面对的问题却很相似。企业购买了一种强大的通用技术，组织内部没人知道该怎样把它变成稳定流程，于是需要一群站在业务与技术之间的人。后来，企业软件逐渐成熟。这组工作被拆进更多岗位。咨询顾问负责诊断问题，售前架构师负责解释方案，实施团队负责安装和配置，系统集成商连接旧系统，产品经理整理需求，客户成功团队推动使用。分工让大型项目更容易管理，也留下了一串交接。

客户说一句需求，销售记下来，售前写进方案，项目经理再交给开发。开发发现接口根本没有开放，问题沿原路返回。等消息重新走到客户那里，业务已经换了一种说法。每个人都完成了自己那一段，项目仍然可能没有一个能用的结果。

FDE的功能祖先一直存在，只是长期散落在几份工作里。

这个职业后来在Palantir被重新组合。它背后的原因也很实际。Palantir最早面对的情报与政府客户，工作流程很难从公开资料里学会，客户也无法给一家新公司写出完整需求。

工程师只能进去。

02Palantir把产品研发搬到客户问题旁边

YC采访Bob McGrew时，他谈到Palantir刚进入情报行业的那几年。McGrew后来做过OpenAI首席研究官。公司早期拿着演示去见客户，对方的反馈很直接，演示和他们的工作没什么关系。[5]团队没有等客户写一份正式需求文档。他们继续问哪里不对，需要怎样修改。工程师一边听，一边做出下一版。产品由此在真实任务里长出来。这套做法与常见的软件增长路线有冲突。

一家SaaS公司通常希望找到足够统一的需求，然后让大量客户使用同一款产品。每增加一个客户，交付成本最好接近于零。客户提出太多个性要求，产品就会分叉，利润也会被服务成本吃掉。Palantir服务的客户很难被压进同一套标准流程。情报、国防、金融和工业客户处理的数据不同，权限不同，错误后果也不同。公司若给每位客户单独做一套软件，很快会变成项目公司。若坚持只卖标准功能，产品又进不了核心工作。

Palantir选择建设一套可配置的平台，再让工程师进入客户环境完成最后一段适配。FDE从现场看到的问题回到产品团队，产品团队判断哪些能力值得提供给更多客户。McGrew把这项工作拆成Echo与Delta两类角色。Echo熟悉行业和客户，负责找出值得解决的问题。Delta拥有较强工程能力，负责快速做出可运行的系统。早期一人可能同时承担两边，项目变大以后通常需要分工。[5]Ontology在这套模式里很重要。

同一个业务对象，在不同系统里可能有不同名称。客户编号、用户ID和主体编码可能指向同一类人。订单也可能散在ERP、Excel和业务人员的聊天记录里。Ontology把这些字段重新映射成业务能理解的对象、关系、权限和动作。[10]Palantir的关键动作是把这趟往返固定下来。

FDE把产品带到现场，也把现场带回产品。

现场代码可以丢掉，学到的结构要留下来。这件事决定了FDE与普通定制开发的分界。

Bob McGrew在2025年发过一句很短的判断。一支FDE团队若没有参与产品发现，拿到的只是披着亮片的服务收入。[6]2026年，Palantir首席技术官Shyam Sankar又把话说得更重。他认为FDE首先是一种产品策略，评价这套组织要看它发现了什么新产品。[7]

一支前线团队完成多少项目并不稀奇。第十个客户能否少走前九个客户走过的弯路，才决定这家公司在卖产品还是卖人。

Palantir长期被质疑像咨询公司，原因也在这里。前线投入很重，第一批项目甚至可能亏钱。只要产品持续吸收现场经验，同类项目所需的人力会下降，公司就能逐渐获得软件公司的经济模型。

这个条件很苛刻。

前线人员愿不愿意整理经验，产品团队会不会采用，管理层是否允许短期项目为长期产品让路，任何一个环节断掉，FDE都会变成一群收费昂贵的救火队员。所以，Palantir把FDE做出来以后，市场并没有立刻集体学习。大多数软件公司还有一条更轻松的路。

03SaaS最繁荣的时候，工程师被要求离客户远一点

过去二十年，软件行业最受欢迎的故事是标准化。做一套产品，放进云端，客户开通账号就能使用。产品团队收集需求，按统一路线安排开发。实施工作越少，毛利越好。客户数量增长时，公司无需同比增加工程师。这种模式适合财务、协作、人力资源和客户管理等已经形成通用规则的场景。企业愿意调整一部分流程来适应软件，厂商也能用配置覆盖多数差异。

工程师长期驻在单个客户那里，反而会被视为危险信号。客户随口提出的需求容易扰乱产品安排，现场写出的代码难以维护，收入也可能越来越依赖人天。FDE因此长期集中在少数领域。客户数量有限，单笔合同足够大，业务问题高度复杂，错误又很昂贵，这几项条件必须同时出现。普通SaaS公司没有必要复制。云计算进一步强化了标准产品的优势。企业采购算力、数据库和软件服务，厂商提供文档与接口。解决方案架构师帮助客户设计，实施伙伴完成接入，产品研发继续留在总部。

到了大模型时代，这条分工突然变得不够用了。企业买到的模型很通用，工作环境却极其具体。模型会写一封不错的邮件，不知道这家公司哪些客户需要优先回复。它能分析一份合同，不知道旧版本条款已经失效。它会调用工具，也不会自动知道谁有权批准退款。过去的软件要求企业把流程整理好，再填进固定页面。大模型接受自然语言，很多尚未整理的流程也能开始尝试自动化。企业因此把更多模糊问题拿了出来。工具能力扩大了，待解决的问题也跟着扩大。这次回摆算不上历史倒车。

早期系统分析员靠近业务，是因为计算机很难使用。SaaS后来把大量规则预先写进页面、字段和权限，企业学会按软件的方式工作，厂商才能把工程师留在总部。Agent改变了这个分工。它接受自然语言，也能跨系统调用工具。那些从未写进制度的简称、例外和默认做法，忽然都可能影响一次执行。Agent一旦开始改数据、发消息和触发审批，厂商便无法把最后一段工作全部交给文档和培训。

软件史在这里转了一个弯。规则稳定，产品可以远离单个客户。规则还在形成，技术又开始替人行动，工程师就得回到问题旁边。FDE站在这个弯道上。

04AI越强，FDE短期内越忙

很多人判断，模型继续进步以后，企业只要购买一套Agent平台，FDE这类中间角色很快会消失。眼前的项目给出了另一种信号。代码生成让原型变快。过去需要一个开发团队做几周的应用，现在一名工程师可能几天就能搭出第一版。企业看到演示以后，会自然地把更多任务交进来。客服可以做，合同审核能不能做。报表可以生成，审批能不能一起完成。任务从回答问题走向修改数据，风险也跟着上升。

一段文案写得差，人可以删掉。一个Agent拿着错误权限修改了客户价格，问题已经进入业务系统。模型在十步任务的第三步走偏，后面七步可能执行得很勤快，结果仍然不能用。生产环境因此需要评估、日志、权限、回退和人工接管。数据从哪里来，哪条规则当前有效，系统怎样识别异常，这些工作无法靠一次漂亮回答解决。技术之外还有采用。

OpenAI前线部署工程负责人Colin Jarvis在访谈中谈到Morgan Stanley的项目。团队大约用六到八周解决主要技术问题，随后又花了约四个月试点、收集评估数据并调整，才让财富顾问建立使用信心。Jarvis披露的最终采用率与使用数据来自公司案例，不能当成独立审计结果。它仍然说明时间花在了哪里，能跑起来只是前半程，让专业人员敢在工作里使用还要更久。[9]

2026年5月，OpenAI宣布成立Deployment Company，把前线部署单独组织起来。公开说明把FDE的工作写得很具体，他们进入企业，与管理层、运营人员和一线团队共同挑选问题，连接数据与工具，再交付能够测量结果的生产系统。[4]

同月的一场公开讨论里，OpenAI、Ramp、Nominal与Dataland的从业者给出了一组很有意思的解释。模型和AI编程工具降低了软件生产成本，原来不值得开发的细分流程开始具备经济性。工程师少写了一些重复代码，却要进入更深的业务问题。[8]这就是第一条反共识。

模型能力提高，FDE处理的技术杂活会减少。企业敢于自动化的工作也会变多，前线问题发现、结果验收和责任设计随之变重。

长期看，平台会接走大量标准工作。短期看，每一次能力提升都会打开一批企业过去没想过要改的流程。技术供给跑得越快，组织采用的缺口越明显，FDE吃到的正是这段时间差。岗位一热，边界也就开始变得模糊。

05判断一个岗位是否属于FDE，看四件事

FDE热起来以后，职位名称迅速膨胀。AI解决方案工程师、大模型交付工程师、Agent架构师、AI实施顾问和客户工程师，都可能承担相似工作。反过来，一个职位即使写着FDE，也可能只负责演示、培训和工单。

《2027中国FDE人才与企业AI落地实践报告》选取九个中国公开职位做职责观察。研究团队把其中两个归为核心FDE，六个归为相邻岗位，一个作为非FDE对照。样本来自定向检索，无法代表全国岗位比例，它的价值在于提供了一套判断方法。[4]

第一件事是结果责任。FDE要对系统能否上线、用户是否采用和业务结果是否改善承担责任。售前通常负责方案与赢单，实施顾问负责约定范围内的上线，客户成功关注活跃与续费。几类岗位都重要，承担的终点不同。

第二件事是生产工程。FDE需要直接构建、测试和维护系统。只会写方案、配置页面或协调资源，工程责任还不完整。企业AI进入生产以后，数据接口、身份权限、版本变化和故障处理都躲不开。

第三件事是持续共创。这里的「前线」指接近真实工作。Palantir纽约一则FDSE职位把客户现场出差写成按需最多25%，同时要求工程师与客户并肩工作并推动端到端执行。[4]物理驻场时长由此失去了判断力。远程团队若能持续看到用户怎样工作，也可能承担FDE职责。

第四件事是产品反馈。项目里重复出现的问题要进入平台、工具、评估集或产品安排。团队给客户交付一套能用的系统，只完成了当期任务。下一位客户依然从零开始，公司就没有获得产品收益。

这四件事连成一条责任链。前线接住问题，工程把它送进生产，结果决定项目有没有价值，产品反馈让下一次少走弯路。不同公司会调整四项工作的比重，几条共识已经相当稳定。

FDE也没有固定编制。十几人的创业公司里，创始人和早期工程师常会一起承担这段工作。客户增多以后，一个人很难同时守住行业判断、系统工程、评估与长期运营，职责自然会拆进一支小队。[5]岗位变化落在责任怎样连接，工牌数量排在后面。

解决方案架构师更靠近售前，实施工程师更关注按范围上线，系统集成商处理接口，咨询顾问交付诊断和建议，客户成功推动使用。FDE跨过这些边界，对一段完整工作负责。招聘难就难在这段责任跨度。

一名纯研发工程师可能不愿处理反复变化的需求。一名咨询顾问能够迅速理解业务，未必能在生产环境里调试代码。一个人同时做到技术、业务和客户沟通已经很难，再要求他理解成本、产品取舍与组织关系，招聘画像很容易变成不存在的六边形战士。成熟团队会让业务负责人、应用工程师、数据与评估人员、安全运营人员共同承担结果，FDE负责把这些责任接起来。

判断FDE，别看他坐在哪里，去看四项责任有没有连起来，生产结果、工程实现、用户共创、产品回流。

把这条责任链放进一个项目，它会变成一条从需求到生产的路线。

06一项企业AI项目，到底怎样走进生产

企业最常见的开场很短。

「我们想做一个AI助手。」

这句话无法直接开发。助手服务谁，处理什么任务，当前过程花多久，失败会造成什么损失，都没有答案。FDE先去观察员工从哪里拿资料，在哪个页面复制数据，遇到例外会问谁。流程图上可能只有五步，真实工作里还藏着权限、口头约定和多年形成的习惯。访谈中的一位从业者说得很直接，客户若能准确描述自己要什么，可能也不会来找FDE。[1]

客户通常能够判断做出来的东西哪里不对，却很难提前写出完整规格。FDE先做一个范围有限的版本，让模糊意见落到可以修改的东西上。PoC在这里负责降低不确定性，模型能否处理真实样本，数据接口能否接通，错误是否能被发现，员工愿不愿意使用，单次运行要花多少钱。

很多项目把PoC当成汇报成果。团队挑几条干净数据，准备固定问题，再让领导看一次流畅演示。会议结束，项目已经「成功」。等系统接入日常任务，脏数据、异常路径和权限审批一起出现。

演示追求最好的一次，生产系统要接住最差的那些次。PoC的价值在于暴露问题，拿它当结业证书，项目通常活不到生产。

原型之后要建立评估。团队从真实任务里整理样本，写清什么结果算合格，哪些错误必须拦住。模型、提示词、知识库和工具发生变化，旧任务还要重新测试。代码有单元测试，企业工作却很少有现成答案。一份合同摘要可以语言通顺，关键责任却漏了一条。客服回复符合话术，也可能给错退款范围。业务人员必须参与，因为FDE无法独自决定什么叫做对。

进入有限生产以后，系统还得处理身份与权限。谁可以读取客户资料，Agent能否修改业务数据，一次允许处理多少金额，哪种情况必须交给人。MCP等协议降低了连接工具的成本，也扩大了授权范围。接口接通以后，信任不会自动出现。

日志和回退也要提前设计。系统做过哪些判断，调用过什么资料，失败以后怎样恢复。企业若只能看到最后一段回答，事故发生时便无法重建过程。随后才轮到采用。登录人数很高，无法证明工作已经改变。员工可能打开系统试过几次，随后继续使用原来的Excel。也可能为了完成管理层要求，多做一遍AI流程，再手工核对一遍，工作量反而增加。

衡量价值时，节省时间也不能直接换算成利润。一名员工每天省下半小时，公司没有减少人力，也没有增加产出，这半小时仍然只是潜在收益。团队要继续看处理量、错误率、周期、收入或风险有没有变化。

项目走到最后，还要决定经验去哪里。高频接口可以做成连接器，重复任务可以整理成Skill，典型错误进入评估集，通用控制进入平台。高度个性的部分留在客户环境里，由后续运营团队维护。价值太低或风险过高的项目应当停止。

一项成熟的FDE项目会留下系统，也会留下证据。它能说明哪里有效，哪里失败，下一次怎样少花一点时间。

腾讯研究院的行业观察把这段路分成场景识别、原型、试点、生产和扩展几个阶段。进入生产以后，真实数据、异常、测试集、权限、审计、监控、回滚与培训才会同时出现。[3]这套分段并非行业标准，它至少提醒采购方，看到Demo距离结束还很远。

如果把整个过程压成三页项目检查表，第一页记录业务基线与错误成本，防止团队只看模型表现。第二页写清权限、评估、日志和回退，它决定系统敢不敢进入生产。第三页最容易被忘记，里面要写本次形成了哪些连接器、评估集和通用组件，下一次究竟能少做什么。

业务基线回答值不值得做，生产控制回答敢不敢上线。复用清单决定这支团队会不会越做越轻。

技术路线到这里才算完整。系统一旦碰到真实组织，另一类问题才刚开始。

07管理层请进来的人，为什么会被一线挡在门外

技术责任补上以后，组织责任才露出来。中国FDE的现实，比职位说明书复杂。数字生命卡兹克的采访里，一位从业者把第一次进入企业形容成掉进充满敌意的环境。老板欢迎他，员工却会把外部团队理解成前来优化岗位的人。[1]这种防备很合理。管理层看到一份效率方案，员工先承担迁移成本。他要学习工具，整理历史数据，解释自己多年形成的工作习惯，还要担心解释得太清楚以后，岗位会不会被削减。

AI项目的第一版通常也不好用。管理层已经听过发布会上的能力，容易把模型上限当成当前系统的稳定水平。工具没有减掉多少工作，新的指标和期待先压到员工身上。员工当然会回到熟悉的办法。部门负责人还可能失去一部分控制。过去，流程细节掌握在少数人手里。谁知道数据在哪，谁理解例外，谁就拥有解释权。FDE把规则写进系统，很多个人经验开始变得可见。项目会提高效率，也会改变一些人在组织中的位置。

FDE带进公司的既有代码，也有一套新的风险与解释权分配。一线员工往往先感受到后者。

外部团队很难靠一场培训解决这些问题。

一线员工需要知道系统会拿走哪些任务，自己的判断留在哪里，发生错误由谁负责。管理层也要接受AI能力有限，不能把所有失败继续压给员工。采访中的从业者采用过一种更稳的办法。他先找少数愿意尝试的员工，在原有工作旁边做小范围对照。结果对员工有用，防备才会下降。[1]这类做法经常被归入沟通能力。沟通两个字显得太轻。FDE处理的是风险如何分配。

老板承担采购风险，技术团队承担系统风险，一线人员承担操作风险。外部FDE若只向管理层汇报，项目很容易把最后一份风险留给使用者。这也是很多PoC停住的原因。管理层已经认可，IT完成接口，一线人员却没有参与规则和评估。系统被宣布上线，工作仍沿着旧流程运行。

企业AI项目很少被一句反对意见杀死。它更常死在所有人都口头支持，却没人愿意把自己的工作交进去。

FDE需要的授权因此很微妙。他要获得足够高层支持，才能推动数据、接口和跨部门协作。又要与一线保持足够近，避免把管理层愿望误写成日常需求。站得太靠上，会变成老板派来的监督者。站得太靠下，又可能困在局部需求里，做出一套没人愿意维护的工具。这份工作最难的地方，也许正是同时对两边说坏消息。告诉老板，AI暂时做不到他想要的效果。告诉员工，原有流程确实需要改变。再把双方都能接受的一小段先做出来。这部分工作很难写进一份统一的职位说明，国内市场的岗位和报价也因此格外混乱。

08中国FDE当前有生意，还没有统一行业

国内企业早就有承担相似职责的人。云厂商的解决方案架构师、AI公司的交付工程师、行业顾问和驻场开发，都可能在做FDE型工作。职位名称直到最近才开始集中出现。这会造成两个错觉。一边看公开招聘，直接以FDE命名的岗位不算多，容易得出国内没有需求。另一边把所有AI交付岗位都算成FDE，又会迅速得到一个很大的市场。两种算法都不可靠。

公开薪资同样容易误导。月薪区间从9000元到8万元。最高区间来自一个被归为非FDE的算法岗位。少量头部职位无法代表市场平均水平。[4]定焦One采访的五位从业者，把这种分层写得更直观。[2]有人是公司第一位专职FDE，拿的仍然是产品经理薪资。有人以实习生身份工作，日薪200元，忙时每周接近50小时。也有创业者接触年营收过亿元的客户，获客、驻场、交付和维护全部自己承担，收入离网上传闻很远。

这些采访不能替代大样本薪酬调查。它们至少打破了「挂上FDE就自动高薪」的想象。项目市场更加混乱。同一类企业AI需求，有团队报价19万元，也有人报价2000元。双方交付的东西可能完全不同。一个交演示，一个交生产系统。一个做完培训离开，另一个还要负责接口、维护和故障。[1]

客户最容易比较价格与速度，稳定性、权限和后续责任很难在签约前看见。低报价者可能没有算返工与维护，高报价者也未必拥有更好的方法。行业缺少共同验收标准，劣币和昂贵包装都能找到空间。独立FDE还要解决信任。定焦One的采访对象在四座城市组织过线下交流。他观察到，不少人的第一单来自亲友或过去的人脉。[2]企业把经营数据和系统权限交给陌生小团队，本来就要承担风险。没有品牌、案例和长期运维能力，技术再好也很难进门。

大厂FDE拥有公司产品、合同和安全团队做背书。个人FDE可能在两个月内做出系统，却回答不了一个简单问题，出现故障以后，谁能提供持续支持。所以中国市场会同时出现三种形态。模型和平台公司组建内部FDE团队，服务少数战略客户。大型企业建立自己的AI落地小队，由业务、数据和工程人员承担类似职责。垂直服务团队则围绕某个行业做高密度项目，再尝试把重复部分做成产品。

三种形态都有机会，也都有各自的退化方向。原厂团队可能成为售前赠品，企业内部团队可能变成工单部门，服务团队最容易陷入按人天收费。名称还会继续乱一段时间。

中国市场先发生的会是工作方式变化，岗位名称统一可能永远不会来。

09高薪属于少数能承担高价值结果的人

海外FDE职位的薪资很醒目。Palantir、OpenAI和部分AI原生公司公开职位给出的基础年薪，已经进入美国高级工程岗位的区间。有些职位还包含股权与奖金。[4]这笔钱买的很少是「懂AI又会聊天」。企业把高价值流程交给FDE，一次错误可能影响客户、资金或合规。候选人需要能写生产代码，理解分布式系统与数据，还要面对高管和一线用户。项目范围持续变化，他仍要判断什么值得做，什么应当停止。

高薪也依赖公司的商业条件。客户合同足够大，平台有足够复用能力，前线投入才撑得住。把美国头部公司的薪酬数字搬到国内中小企业服务市场，中间少算了客单价、毛利和持续采购能力。国内市场会快速分层。强FDE处理复杂生产系统，进入高价值行业，也参与产品决策。相邻岗位负责部署、配置、培训和常规集成。个人与小团队服务中小企业，收入取决于获客、交付边界和维护成本。同一个缩写下面，可能同时放着高级工程岗位、实施工作和自由职业项目。讨论平均薪资的意义很有限。

职业风险也很清楚。FDE每天解决客户眼前的问题，很容易变得很宽，却没有一项足够深。沟通越来越熟，工程判断没有同步增长。项目一个接一个，个人经验留在脑子里，离开当前客户以后很难证明自己做出了什么产品。更稳的职业资产是一份可以核验的记录。原来怎样工作，系统改了什么，错误怎样处理，结果由谁确认，哪些部分在第二个项目中继续使用。个人能否拿到长期溢价，最终还要看他所在的团队能不能把项目变成产品。

市场愿意给结果责任溢价，不会长期给一个新缩写溢价。

10最好的FDE会逐渐减少自己的存在感

FDE公司最容易爱上服务收入。客户愿意付钱，团队继续加人，项目规模不断扩大。收入增长看起来很好，产品却没有变得更容易使用。每签一个客户就需要增加一批工程师，公司仍然靠出售时间增长。OpenAI、Ramp、Nominal与Dataland的公开讨论多次碰到这个问题。[8]客户也可能对FDE产生依赖。团队在现场待了十二个月，所有异常都由他们处理。人数一撤，系统就停。客户购买的是这几个人，平台没有获得独立价值。组织归属会把这道难题放大。

腾讯研究院的行业观察提到，FDE放在销售、交付或产品体系里，会分别受到签单、按期验收和通用产品路线的拉扯。[3]销售需要尽快拿下客户，前线容易变成免费Demo团队。交付追求范围与进度，团队会倾向于把问题做完，却没有时间整理共性。产品团队擅长抽象，距离现场太远时又可能抽错。

一支健康的FDE团队需要同时记两本账。一本写客户结果，系统上线没有，谁在使用，错误和业务指标怎样变化。另一本写产品回报，哪些接口、评估方法和控制措施在第二个项目继续使用。只算签单和验收，团队迟早滑向人天生意。只算组件数量，团队又会把第一个客户的习惯包装成行业标准。两本账一起看，前线投入才有机会变成软件杠杆。

客户结果决定这一单值不值，产品回报决定下一单能不能更轻。

结果很好，复用很差，公司可能做成一家优秀的服务商。复用很好，客户没有结果，团队可能在制造没人要的平台。两边需要一起成立。

Colin Jarvis在公开访谈里讲过一条具体的产品过程。OpenAI团队先在Klarna客服项目中处理大量政策与工具，再把其中一套方法用于更复杂的T-Mobile场景。内部框架后来开源为Swarm，相关经验又进入Agents SDK等产品。[9]这是厂商一方的叙述，无法证明每一步都由单个项目直接推动。它展示了FDE想实现的方向。客户问题先得到解决，重复结构随后进入更多人能使用的产品。产品化也不能太早。

团队只做过一个客户，就急着把定制代码包装成行业平台，通常只是给一次性方案换了名字。相反，等十个项目全部做完再整理，代码和流程可能早已分叉。FDE与产品团队要持续判断，哪些内容留作客户配置，哪些能进入通用组件。价值太低或风险太高的需求，应当拒绝。这会带来第二条反共识。

优秀FDE并不追求永久驻场。他要把重复工作交给产品，把运营能力交给客户，再去解决下一批仍然模糊的问题。

岗位数量很难证明团队成绩。公司招了多少FDE，只能说明前线需求很多。一个稳定产品能力能支撑多少项目，下一次交付快了多少，更能说明组织有没有学会。FDE公司也不能靠永久扩编证明规模。第一单可以重投入，因为团队还在发现共性。第二单和第三单若仍用同样的人数与时间，说明学习没有进入产品。客户扩容可以增加收入，单位交付成本也要下降，否则Land and Expand只剩一条销售口号。

11FDE不会消失，它会被拆回整个组织

模型继续进步以后，FDE的工作会发生分化。写简单脚本、接标准接口和搭普通知识库，会被Agent平台吸收。低风险流程由业务人员用自然语言自己配置，也会减少一部分实施需求。剩下的问题更难。系统开始影响资金、客户权益和关键运营以后，企业需要更严格的评估与审计。模型能调用更多工具以后，权限与故障范围扩大。AI进入医疗、制造和金融等行业，领域知识也无法由一名通用工程师临时补齐。

个人英雄式FDE会逐渐减少。小队里会出现业务专家、应用工程师、评估人员与安全运营角色。一个人仍可能负责主要接口，结果由团队共同承担。职位名称也会继续分散。有人叫大模型交付工程师，有人叫Applied AI Engineer，也有人留在解决方案架构师和产品工程师岗位。企业内部的AI落地办公室可能完全不用FDE这个词，工作方式却高度相似。FDE作为热门职业存在多久，很难预测。它承担的几项责任会长期留下。

有人要靠近真实工作，找出值得解决的问题。有人要把模型放进生产系统，处理失败与权限。还要有人把项目经验送回产品，避免下一次从零开始。这些责任过去被分散，AI暂时把它们重新压到FDE身上。等平台成熟，组织会再次拆分，只是交接方式会变。未来的产品经理需要更懂系统边界，工程师要更习惯接触用户，客户成功要能看懂生产数据。业务负责人也不能只提需求，他要参与基线、评估和风险决定。FDE由此暴露出一段行业过渡期里的组织缺口。缺口很大，岗位才会火。

FDE可能从职位表上消失，前线发现、生产责任和产品回流却会渗进更多岗位。

岗位以后怎样拆还没有答案，企业眼下要做的判断可以先落地。

12一家公司需不需要FDE，可以先做这个测试

企业采购FDE服务以前，先问四个问题。

第一问看问题本身。它是否直接影响收入、风险或关键运营，需求又是否仍然模糊。通用翻译、摘要和普通问答已经有成熟产品，直接购买软件更划算。问题价值不高，重FDE只会让交付变贵。

第二问看生产环境。数据是否分散在多个系统，权限和责任有没有跨过几个部门，错误发生后由谁接管。流程清楚、接口标准、内部工程团队完整，企业没有必要再增加一层角色。

第三问看组织投入。业务负责人愿不愿意花时间，一线员工能不能参与设计，数据与权限是否开放，项目失败以后是否允许停止。只有预算，没有这些条件，FDE进场也只能做演示。

第四问看复用空间。第一处场景跑通以后，同一套连接、评估和控制方法能不能进入其他部门或服务其他客户。每次部署都完全不同，团队卖的仍然是人天。重复结构足够多，前线投入才可能变成产品。

问题够重要、现场够复杂、组织愿意改、经验还能复用，四个条件叠在一起，FDE才比标准软件和普通实施更有价值。

招聘也可以沿着同一条责任链来验。先给候选人一个含糊业务问题，看他会不会追问用户、基线、错误成本与权限。随后让他做一个小系统，检查测试、日志、回退和维护。最后把场景换到第二个客户，问哪些部分还能继续用。

这三步分别在看问题发现、生产工程和复用判断，答案会比岗位名称诚实得多。

准备进入这个行业的人，可以把修改简历往后放。先找一个熟悉的流程，跟着真实使用者走完一遍，让AI参与一段有明确输入和结果的工作，再把失败记录下来。

作品集要写清问题、系统、结果与限制。没有上线，就写到PoC。没有财务收益，就别把节省时间换算成利润。某个流程仍靠人判断，也无需藏起来。FDE面对的正是这些没有被营销材料抹平的部分。

文章开头那两个人，一个被叫作产品经理，一个自称外包。他们的身份尴尬不会因为行业统一翻译而消失。更有用的判断来自项目结束以后。系统能否继续运行，员工是否愿意使用，产品有没有少一个缺口。下一位工程师进入相似客户时，是否还要从第一场需求会重新开始。

如果一支FDE团队九十天后离开，客户只剩几个人写过的代码，这还是一次项目。客户与产品都留下了继续工作的能力，这套模式才算站住。

FDE眼下很热，名称还会继续变化。

缩写会过气，责任不会。企业AI总要有人把「模型会做」推进到「业务做成」，还要让第二次做得更快。

13参考资料

1.

数字生命卡兹克，《那些被管理层请进公司，却不被一线员工接受的FDE们》https://mp.weixin.qq.com/s/qo5XYIt0ZVobqyeO5kio1g[1]

2.

定焦One，《第一批做FDE的人，离高薪差远了》，2026年8月，https://mp.weixin.qq.com/s/cvkN8JT_nEoNwVcfja1yUg[2]

3.

腾讯研究院，FDE模式行业观察报告，2026年7月。

4.

FDE中国社区，《2027中国FDE人才与企业AI落地实践报告》，对外传播版v1.0，2026年8月。

5.

Y Combinator，《The FDE Playbook for AI Startups with Bob McGrew》，https://www.youtube.com/watch?v=Zyw-YA0k3xo[3]

6.

Bob McGrew关于FDE与产品发现的公开讨论，https://x.com/bobmcgrewai/status/1882953398833856853[4]

7.

Shyam Sankar关于FDE产品策略的公开讨论，https://x.com/ssankar/status/2066223291749056601[5]

8.

South Park Commons，《The Future of Forward Deployed Engineering》，https://www.youtube.com/watch?v=hWuoH-ODDNc[6]

9.

Altimeter Capital，《Colin Jarvis，Head of Forward Deployed Engineering at OpenAI》，https://www.youtube.com/watch?v=cBD7_R-Cizg[7]

10.

Palantir AI FDE产品文档，https://www.palantir.com/docs/foundry/ai-fde/overview[8]

本内容由作者授权发布，观点仅代表作者本人，不代表虎嗅立场。如对本稿件有异议或投诉，请联系 tougao@huxiu.com。

本文来自虎嗅，原文链接：https://www.huxiu.com/article/4889923.html?f=wyxwapp