中国五类企业的 FDE 团队全景：同一个岗位，五种生意，五条职业路线

QUOTE

如果你正在做 FDE，真正该问的不是“这个岗位火不火”，而是：同一个缩写，在这家公司到底要交付什么。

过去几个月，中国企业的 FDE 信号明显密了起来。

零一万物把“战略咨询＋FDE 共创”写进企业 AI 落地模式；北森年报明确采用 FDE 交付，公司官网称已组建 300 余人的团队；软通动力把“AI Factory＋FDE”写进 2025 年年报；中远海控提出用 FDE 人才培养建设业务与技术融合的 AI 研发队伍；阿里云则直接公布 FDE 在固废、石化、煤化工、钢铁和建材生产链路中的项目。

智慧芽也已经成立 FDE 团队。公开侧可以看到，公司官方新闻明确提出以 FDE 推动 AI 嵌入组织创新工作流；公开岗位则把工作写得很具体：理解客户在知识产权、研发创新与战略情报中的流程，配置和部署 Agent、Skills、报表与自动化，再把客户特定需求转成标准产品能力。

这批公司看起来都在招 FDE，实际上需要的是五种不同的人。

有人要把通用模型送进生产，有人要把专家脑中的判断教给 AI，有人要把咨询方案写成能运行的系统，有人要改造自己公司的流程，还有人要让机器人在粉尘、光照和设备公差面前依然保持职业素养。

岗位名只有三个字母，工作内容却足以开一家百货商场。

做了一年多 FDE 后，我越来越不愿意只看岗位名称判断一支团队。我通常先问四件事：它服务谁的业务状态，能动哪些生产权限，怎样证明结果，离场后留下什么。

如果这四个问题没有答案，FDE 往往只是把组织里没人完整负责的工作，集中交给了几个比较能扛的人。

本文不做一份“国内 FDE 公司大全”。公开招聘会消失，组织名称会变化，私域团队更无法穷尽。本文要回答的是一个对从业者更有用的问题：

五类中国企业为什么需要 FDE，它们已经在做什么服务，未来又会把这个岗位带向哪里？

本文看点

01

五类公司与真实服务

02

三个生产小场景

03

岗位趋势与选择问题

01

DEFINITION

先定口径：什么才算真正的 FDE

FDE 很容易被两种统计方式毁掉。

第一种，是把解决方案、售前、实施、驻场开发、客户成功和 AI 培训全部装进来。这样一夜之间遍地都是 FDE，仿佛给鱼香肉丝改名“川味蛋白质解决方案”，它就突然进入了高科技行业。

第二种，是只认岗位名称里完整写着 Forward Deployed Engineer 的人。这样又会漏掉大量已经在做同构工作的团队。

我采用四项检验。一支队伍至少应覆盖其中三项，才进入本文的核心样本：

深入外部客户或内部业务现场，理解真实工作流；

能直接搭 Agent、写生产代码、接数据和系统，并推动上线；

对采用、稳定性、效果或业务结果承担端到端责任；

把现场规律沉淀为评测、组件、方法、产品能力或业务自持机制。

Palantir 对两类工程师有一个经典区分：传统软件工程师更像“一个能力服务很多客户”，FDE 更像“一个客户调用很多能力”。

到了中国，我认为还要再补半句：FDE 不只要把能力送到现场，还要把现场送回产品。

否则每做完一个客户，只多出一套没人敢升级的代码、三个永久驻场群和一句“这块得问老王”。项目也许交了，机制并没有长出来。

老王很重要，但老王不是平台。

为了避免后面变成五段公司介绍，我会用同一套六维账本拆每一类 FDE：

商业瓶颈： 企业为什么不能只靠标准产品、实施或咨询解决；

交付对象： FDE 最终改变的是哪个业务状态，而不只是做了什么功能；

组织单元： 一支可运行的小队里，FDE 需要和哪些角色共同负责；

生产权限： 它能读什么、能写什么，哪一步必须由业务 Owner 确认；

验收指标： 怎样区分 Demo、有限生产和规模化采用；

复用资产： 项目结束后，什么必须离开个人电脑，进入产品或平台。

这套账本也是本文最核心的作者视角：判断一支 FDE 团队，不看它做过多少 Demo，要看它改变了什么状态、承担了什么失败代价。

02

PLATFORM

第一类：模型、云与通用 AI 平台

它们正在卖什么服务

这类企业拥有模型、算力和开发平台，却离客户业务结果最远。它们成立 FDE，不是为了把客服做得更热情，而是为了把模型能力、客户数据、真实流程和生产责任接成一条链。

零一万物公开的服务包括 AI 转型咨询、业务本体构建、FDE 现场共创和闭环运营；阿里云的公开样本覆盖工业大模型、智能体、工艺优化与控制平台；火山方舟、BytePlus 等岗位还明确要求建立评测、可观测性，并把共性问题带回平台。

所以这类 FDE 交付的通常不是一个聊天窗口，而是：

问题定义：

哪个业务状态值得改变，怎样才算成功；

数据与系统接入：

哪些数据可信，Agent 可以调用哪些工具；

原型到生产：

评测、观测、权限、成本、稳定性与上线；

产品反馈：

哪些连接器、模板和评测能力应该进入平台。

六维专业账本：平台 FDE 的任务不是“把模型送过去”

商业瓶颈：

模型和云资源是通用能力，客户购买的却是特定流程的结果。中间缺少问题定义、数据接入、系统集成、评测和采用责任。

交付对象：

从“模型 API 可调用”推进到“某个业务任务在生产中稳定完成”，并让使用量、采用率和产品反馈形成闭环。

组织单元：

更合理的是战略客户 Pod：FDE 负责问题与业务架构，FDSWE 或应用工程师负责生产实现，平台、安全和客户业务 Owner 共同参与。

生产权限：

FDE 可以配置模型、工具和工作流，接入获批数据；涉及改变客户业务状态或工业控制时，应按风险分级，由客户 Owner 保留最终授权。

验收指标：

我会看首次生产上线时间、目标用户采用率、任务成功率与人工覆盖率、延迟和稳定性、单位任务成本，以及多少现场能力被平台复用。

复用资产：

评测集、可观测性、连接器、参考架构、业务对象模型、权限模板和故障处理手册。

这些指标是我的管理建议，不是上述公司公开披露的统一 KPI。

平台型 FDE 还有一个容易被忽略的双向责任：向前，它要把模型能力翻译成业务动作；向后，它要判断现场问题究竟应该产品化、交给伙伴，还是明确停止定制。

如果所有需求都被接受，FDE 会成为高价人肉中间件；如果所有差异都被推回客户，FDE 又会退化成会写代码的产品说明书。

专业性恰恰体现在第三种选择：把高频差异变成平台能力，把低频差异留在配置层，把不产生持续价值的需求挡在范围之外。

深入场景一：垃圾焚烧炉温波动，不是让大模型“自由发挥”

阿里云公开了一处足够具体的现场：绿色动力武汉生产基地的固废焚烧链路。

按照公司披露，当系统检测到炉温波动或蒸汽稳定性不足时，智能体会关联历史数据与基准值，分析偏差并生成处置建议；运控人员通过自然语言确认后，再由工业控制平台下发指令，调节推料速度、风量等参数。

这是一个比“AI 帮助企业降本增效”有价值得多的小场景。它把 FDE 的真正工作暴露得很完整：

炉温、蒸汽稳定性和历史工况要先形成可用的数据契约；

模型输出必须落到可执行的工艺变量；

运控人员要有确认权，而不是被一段漂亮的解释绕过；

指令必须有范围限制、异常阻断与恢复路径；

新策略要经过影子运行、对照评测，再逐步扩大权限。

第 2、3 项来自公开案例中的控制变量与人工确认逻辑；第 1、4、5 项是我从生产交付视角提出的验收要求，不是阿里云公开披露的项目细节。

在工业现场，“人类确认”是责任接口，不是 AI 不够先进。

如果一个 Agent 可以直接改风量，却没人说得清它在什么条件下必须停手，这不叫闭环，叫把事故报告提前写成了自动化脚本。

我的判断：平台型 FDE 会“小队化”，不会无限驻场化

这类团队会继续增长，但组织会明显分层：FDE 负责问题与业务架构，FDSWE 或应用工程师负责生产实现，平台与安全团队负责评测、观测、连接器和权限底座。

战略客户仍会由小而强的 Pod 深度共创，规模覆盖则交给伙伴和标准能力。因为如果每卖一份模型调用，都附送三名长期驻场工程师，收入曲线可能像云，成本结构却会越来越像工程承包。

因此，这一类团队的负责人不应只统计 POC 数量，还要同时看“账户采用”和“平台回收”。前者证明客户真的在用，后者证明公司没有用更多工程师线性购买增长。

这类 FDE 最值得积累的，不是又会一个模型 API，而是把模糊业务问题编译成生产系统的能力。

03

VERTICAL SaaS

第二类：垂直 SaaS 与行业软件

它们正在卖什么服务

垂直软件公司通常已经有产品、有客户、有行业数据。真正卡住 AI 的，是每家企业脑子里的规则并不一样。

北森给出的公开定义非常直接：FDE 要把客户独有的岗位模型、用人标准、评价逻辑和组织语言转成 AI 可理解的结构化知识。具体服务包括岗位模型定制、评估标准本地化，以及把 AI 面试官、AI 人才官、排班等 Agent 接进审批、决策和异常处理流程。

智慧芽则把这件事放进研发创新和知识产权工作流。

公司公开的 Eureka 服务覆盖技术问答、技术预研、TRIZ 方案探索、可行性分析、技术交底书、查新检索、FTO、材料筛选、生物医药情报和战略洞察；FDE 的公开职责包括配置与部署 Agent 工作流、Skills、报表和自动化，支持测试迭代，并把可复用需求转成标准能力。

公开案例中，用友智石开的研发云与 PLM Cloud 已与智慧芽 Eureka 近 10 个 Agent 集成，服务范围覆盖技术洞察、方案探索、配方优化和专利布局。该案例说明的是产品与工作流已经发生真实连接；公开资料没有说每一项集成都由 FDE 完成，不能把两者强行画等号。

北森、智慧芽、帆软和毕至智能看起来分属 HR、研发/IP、数据分析和招聘科技，背后的问题却相同：

垂直软件的 AI 交付对象，正在从“功能配置”变成“专业判断”。

六维专业账本：行业知识不是一批文档，而是一套决策机制

商业瓶颈：

产品已经覆盖标准流程，但每家客户的术语、规则、例外和专家判断不同，通用 Agent 无法自动获得组织语境。

交付对象：

不是“知识库建完”，而是让一个专业判断进入真实流程，并被专家接受、修正、追溯和持续维护。

组织单元：

行业专家负责判断边界，FDE 负责把边界写进数据、工具和工作流，产品团队回收共性，客户业务或专业 Owner 负责最终结果。

生产权限：

HR 数据、未公开发明、研发资料和专利判断都具有敏感性。FDE 需要设计最小可见范围、草稿与正式状态、专家复核和审计留痕。

验收指标：

我会按场景选择专家复核通过率、关键遗漏率、人工退回原因、目标流程覆盖率、活跃采用、首次价值时间，以及模板和评测的跨客户复用率。

复用资产：

行业本体、术语映射、黄金评测集、规则和例外库、流程模板、专家纠错样本、证据引用与版本机制。

这里要特别区分“行业相同”和“风险相同”。

北森处理的是岗位模型、评价标准和人才流程，风险集中在偏差、解释与组织公平；智慧芽进入研发和知识产权流程，风险更集中在未公开技术信息、证据可追溯、专业复核和正式法律动作的边界。它们都属于垂直软件 FDE，但不能用同一套准确率和审批流验收。

这也是垂直型 FDE 比普通实施更难的地方：实施可以问“配置是否完成”，FDE 必须继续问“这套判断是谁的、错了由谁发现、规则变化后由谁维护”。

深入场景二：一份技术交底书，真正难的不是生成文字

把场景缩小到一个研发工程师刚产生技术想法的下午。

工程师上传技术描述、图纸或实验材料，希望系统形成技术交底书。公开产品能力可以帮助梳理发明点、检索相关专利、生成初稿；但企业真正要上线的并不是“会写文档的按钮”，而是一条研发与 IP 协作流程。

站在 FDE 角度，我会继续追问：

要点

谁可以查看尚未公开的发明内容？

要点

AI 引用的专利与文献能否逐条回溯？

要点

哪些字段必须由研发工程师确认，哪些结论必须由 IP 负责人复核？

要点

初稿怎样进入评审、退回、补充和版本留痕？

要点

系统能否生成草稿，但不能越过业务 Owner 自动进入正式申请？

这五个问题决定了产品是在“帮忙写字”，还是真的进入企业技术成果形成的责任链。

这里最专业的动作往往看起来最不科幻：给草稿加状态、给证据加来源、给高风险动作加确认、给错误留回滚。发布会上它们很少站 C 位，出了问题却总能迅速获得麦克风。

我的判断：垂直型 FDE 最容易规模化，也最容易变成高配实施

北森官网称团队已超过 300 人，年报披露 AI Family 合同额、客户数和渗透率均快速增长。这些数字能证明公司正在规模化商业化，不能证明增长全部由 FDE 带来，更不能当作独立验证的客户 ROI。

智慧芽成立 FDE 团队，则代表另一个清晰趋势：当行业软件从“交付工具”走向“交付成果”，FDE 会成为数据、Agent、专家方法和客户工作流之间的编排层。

这类团队的分水岭非常简单：

要点

客户知识沉淀成行业本体、评测样本、流程模板和产品能力，FDE 就是产品飞轮；

要点

客户知识沉淀成私有 Prompt、特殊代码和只有原作者懂的规则，FDE 就是高配实施。

从经营上看，它还需要一条“双账本”：客户账本记录采用、质量与结果，产品账本记录哪些现场知识已经进入标准能力。如果只看续费不看产品回收，团队可能在增长中积累不可升级的分叉版本；如果只看产品标准化不看客户结果，又会得到一套内部很优雅、现场没人使用的架构。

未来更成熟的组织会把 FDE 与“客户模型运营”分开：FDE 负责第一次把专业流程做进生产，后续规则更新、评测维护和采用运营由长期角色承接。否则所有客户变化都会重新召回最稀缺的工程师。

资产会复利，例外也会。前者进入产品路线图，后者进入凌晨两点的群聊。

04

SERVICES

第三类：IT 服务、咨询与系统集成

它们正在卖什么服务

这类公司最熟悉客户现场，也最受传统人天模式挤压。

软通动力 2025 年年报称，公司构建“AI Factory＋FDE”模式，以咨询定义高价值场景、FDE 敏捷交付落地，服务链覆盖业务咨询、产品实施、技术底座和持续运营。年报还称，FDE 咨询实施一体化模式已经在农牧等行业落地。

天云融创的公开岗位把服务写成场景勘测、流程拆解、Agent 交付、上下文工程、评测和交付资产；飞享数据公开岗位更偏培训、需求拆解和轻量 POC；和君咨询也开始招聘 FDE。

这些样本说明，IT 服务业正在把原来分散在咨询顾问、架构师、开发、项目经理和运维之间的工作，重新包装成更短的结果闭环。

包装不是坏事。把六个人的责任重新设计成一个 Pod，可能提高效率；把六个人的活原封不动塞给一个人，只会提高体检频率。

六维专业账本：服务型 FDE 首先是一种项目经济学

商业瓶颈：

客户要的是业务结果，传统合同却按人天、功能和里程碑管理，咨询、开发、上线与运营之间容易各自完成、整体失败。

交付对象：

把一份战略判断转成可运行的系统，再通过运营数据证明它是否改善了约定状态，而不是交完功能清单就离开。

组织单元：

行业顾问定义价值与范围，FDE 串起需求、工程和采用，平台工程师提供交付底座，客户 Owner、IT 和风控共同验收。

生产权限：

外部团队的访问应当临时、分级、可审计；客户保留生产批准和高风险动作，交付结束后撤销账户、密钥与写权限。

验收指标：

除了时间、预算和功能，我会看价值基线、变更请求率、生产缺陷逃逸、人工接管、客户自持率、维护成本和交付资产复用率。

复用资产：

行业场景包、连接器、交付 Harness、回归评测、SLA 与变更模板、运行手册、客户培训和退出清单。

这里最关键的专业变化发生在合同，而不只发生在代码。

结果型交付必须在开工前写清业务基线、数据口径、可控变量、外部依赖和变更机制。否则“对结果负责”很容易变成一句边界无限、证据有限的口号：客户认为你承诺了经营改善，交付团队认为自己只承诺了系统上线，双方直到验收会才发现使用的是不同版本的中文。

服务型 FDE 可以扩大责任闭环，但不能吞掉客户的业务责任，也不能替合同吸收无限范围。

深入场景三：港口集卡混合调度，验收的不是一张新大屏

软通动力年报披露，公司与某大型 ICT 企业打造了港口智能水平调度方案，实现港口集卡混合调度突破。公开资料没有说明这个项目是否由 FDE 模式交付，因此它不能被写成“FDE 成功案例”；但它非常适合说明服务型 FDE 面对的真实问题。

如果我负责这个场景的验收，我不会先问大屏颜色，而会问五个更麻烦的问题：

船期、堆场、车辆与任务状态分别来自哪个权威系统；

调度建议怎样处理设备故障、临时插单和优先级变化；

调度员何时可以覆盖系统建议，覆盖原因是否留痕；

新策略上线后，用等待时间、空驶、吞吐还是安全事件评估；

当数据延迟或模型异常时，系统怎样回到可用的人工规则。

这些是我的交付检查框架，不是年报披露的项目配置。

服务型 FDE 的价值，不是替客户多做一版方案，而是把“方案—系统—运营—复盘”压进同一条执行链。

这也是它与传统咨询最大的差别。PPT 可以在第 38 页宣布闭环，生产系统通常会要求你把闭环的 API、Owner 和告警电话都写出来。

我的判断：这类团队增长最快，也最容易稀释 FDE

Agent 会继续压缩方案初稿、接口脚手架、测试、文档和部分运维劳动，服务企业必须从“卖投入”转向“卖结果”。因此，FDE Pod 会快速增长。

同时，改名也会很快。售前可以改名 FDE，驻场开发可以改名 FDE，实施团队开完一次 Agent 培训，也可能在周一完成全员物种升级。

判断真假，不看英文缩写，看四项权力：生产代码权、产品反馈权、评测与回滚责任、明确退出条件。

与平台公司不同，服务企业未必有一个外部软件产品可以承接现场反馈。它更应该把经验送回自己的“交付工厂”：行业数据模型、评测基线、连接器、部署模板、合同边界和运维机制。只要下一单仍从空白文档和新建群聊开始，AI Factory 还只是一个很有工业气质的会议室名字。

我预计这类组织会进一步拆成“Build”和“Run”两套责任：前者由 FDE Pod 完成首次生产，后者由托管运营或客户团队长期维护。把两者混在一起，骨干会被旧项目告警持续召回，新项目永远缺最有经验的人。

没有这些，FDE 可能只是咨询顾问穿上了工程马甲；有了这些，一次项目才可能变成下一次不用重做的能力。

05

INTERNAL FDE

第四类：企业内部 AI 转型团队

它们正在卖什么服务

这类团队不对外卖服务，客户就在同一栋楼里。

影石创新的公开岗位面向市场、销售、客服、供应链和财务等内部场景，从 Demo、POC 一直推进到生产。湃方科技的岗位要求深入各业务部门，完成知识库与 RAG、内部 API 和数据库接入、工作流编排、生产部署、监控告警、用户培训，并沉淀内部 Agent 组件与工具链。

中远海控则在年报中提出，2026 年将以 FDE 专业化人才培养为抓手，建设业务与技术深度融合的 AI 研发队伍。这里必须保留“将”字：这是公开计划，不是已经验收的组织成果。

这类公开证据主要是岗位设计和建设计划，不是已披露的客户案例。文章如果把一份招聘 JD 写成成功故事，就像看见健身房办卡记录，直接宣布对方已经有八块腹肌——鼓励性很强，证据性不够。

六维专业账本：内部 FDE 不是免费的外部供应商

商业瓶颈：

中央 AI 平台能提供模型和工具，却没有足够业务上下文与部门授权；业务部门知道流程，但缺少把规则工程化的能力。

交付对象：

改变一个内部流程的周期、质量或决策状态，并让业务团队接管，而不是把“上线了多少个 Agent”写进季度海报。

组织单元：

更稳妥的是 Hub-and-Spoke：中央平台提供模型、安全和工程标准，FDE 嵌入业务小队，业务产品 Owner 承担结果，风险与数据负责人参与放权。

生产权限：

使用企业身份、服务账户、最小权限和变更窗口；FDE 可以实现自动化，但不能自行取得业务审批权、付款权或对外承诺权。

验收指标：

我会先建立旧流程基线，再看周期时间、异常率、人工接管、目标用户采用、旧步骤是否真正退出，以及业务团队能否独立处理常见问题。

复用资产：

内部业务对象模型、数据契约、权限矩阵、评测集、共用工具、变更记录、运行手册和交接材料。

内部团队最容易掉进“需求排队”的陷阱。各部门发现中央有一群既懂 AI 又肯沟通的人，需求会像节假日前的高速入口一样迅速汇合。

因此内部 FDE 需要一套场景准入机制。我会优先评估业务价值、发生频率、数据就绪度、流程 Owner、错误可逆性和复用潜力；缺少 Owner、没有基线、失败不可逆却又不愿设置人工确认的需求，不应因为高层在群里发了一个“尽快”就直接开工。

内部 FDE 的稀缺资源不是开发时间，而是带着授权进入流程、又能按时退出流程的组织位置。

我的判断：内部 FDE 的核心不是技术，而是授权

中央 AI 团队通常懂模型、平台与安全，却未必知道销售怎样判断商机、供应链如何处理异常、财务在哪一步必须人工签字。业务部门最懂规则，却没有能力把规则变成数据契约、工具权限和评测样本。

内部 FDE 正好站在这条缝里，但不能独占业务责任。

我更看好“中央平台＋业务共建小队＋阶段性轮岗”：FDE 完成问题定义、第一版生产系统、评测、权限和交接；业务 Owner 对结果负责；平台团队接走共性能力；当业务可以自持，FDE 退出。

好的内部 FDE，不以“全公司永远需要我”为成功，而以“这个流程终于不再依赖我”为成功。

这会催生一条与外部 FDE 不同的职业路径：内部 FDE 更接近业务产品负责人、流程架构师和 AI 治理工程师的结合体。其价值不一定表现为直接收入，却会体现在跨部门流程是否被真正改写，以及中央平台能否从多个部门吸收共性。

管理上必须给这支队伍“双重归属”：工程标准归中央平台，业务优先级和结果归场景 Owner。只有技术汇报线，它容易做成平台布道；只有业务汇报线，它又容易长成部门定制开发。

否则企业会得到一个新的影子 IT 部门。业务说“AI 的事找 FDE”，技术说“业务规则问现场”，FDE 最后成为全公司最懂流程、最忙，也最不敢休假的人。

06

PHYSICAL AI

第五类：具身智能、机器人与工业现场

它们正在卖什么服务

软件 FDE 面对脏数据、旧系统和组织政治。物理世界 FDE 在此基础上，还会获得光照、粉尘、网络抖动、设备公差、安全围栏，以及一台偏偏只在周五晚上报错的机械臂。

大制科技官网已经明确把平台能力用于 FDE 工艺开发与现场系统集成，公开服务链包括任务定义、仿真验证、工位执行、PLC／IoT／MES 接入和样本回流，场景覆盖汽车与 3C 柔性装配、原料搬运与拆袋、配方称重、物料分拣等。逐际动力的公开岗位则涉及客户技术对接、数据采集工作流和具身算法落地。

这里的交付物不只是模型和界面，而是动作原子、工艺约束、设备兼容、现场数据、质量评估和安全边界。

对这种团队，我会把“回滚”问得特别具体：软件回滚可能是切回旧版本，物理系统回滚首先要回答设备怎样停止动作并回到安全状态。

按钮变灰不等于机械臂已经放下扳手。现实世界对 UI 的尊重一向比较有限。

六维专业账本：物理世界把“可回滚”变成了安全问题

商业瓶颈：

实验室能证明模型会做某项任务，客户购买的却是在特定设备、工艺节拍、物料波动和人员协作条件下持续完成任务。两者之间隔着现场工程、控制系统和安全责任。

交付对象：

不是“机器人动起来”，而是在安全包络内改变一个可度量的生产状态，例如完成一次抓取、装配、称重或分拣，并稳定达到约定的节拍、良率和可用性。

组织单元：

FDE 需要与工艺或控制工程师、机器人／应用算法工程师、现场可靠性人员、操作员和安全 Owner 共同交付。少了任何一方，系统都可能在演示时很聪明，在换班后突然开始重新认识世界。

生产权限：

必须区分建议、监督执行和自动控制三级权限；模型不能绕过 PLC、安全联锁、急停和工艺上限。版本、参数和动作范围的变更要有审批、窗口和可追溯记录。

验收指标：

我会同时看安全条件内的任务成功率、周期时间或良率、人工干预率、误停率、故障恢复时间、场景漂移和数据覆盖。仅仅“没有发生安全事故”不是充分指标——它也可能只是设备还没真正干活。

复用资产：

动作与工艺原子、工位模板、硬件兼容矩阵、失败分类、仿真与离线回放样本、标定规范、远程诊断、运行手册和安全恢复流程。

这些同样是我的上线与管理框架，不代表相关企业已经公开采用同一套指标。

物理 FDE 最容易被“端到端”三个字误导。端到端是系统责任视角，不等于让一个模型拥有从识别到执行的全部权限。安全 PLC、机械限位、急停和人工接管应该构成独立保护层；模型负责在允许范围内选择动作，保护层负责在模型失去判断时依然能说“不”。

我更认可五级放权路径：

仿真验证： 先覆盖正常工况、边界条件和故障注入；

离线回放： 用真实现场数据复现模型选择，不影响设备；

影子运行： 在线生成建议，但不执行，与人工决策对照；

监督执行： 操作员确认后执行，记录接管和拒绝原因；

有限自治： 只在明确工况与动作范围内自动执行，异常立即降级。

这条路径最重要的不是“最终一定走到第五级”，而是每一级都有进入条件、退出条件和恢复方案。对于低频高后果任务，长期停在监督执行反而可能是成熟，而不是落后。

物理 FDE 的上线单位不是一个模型版本，而是一组“模型＋设备＋工艺＋安全状态”。

我的判断：物理 FDE 会最晚规模化，但专业壁垒最高

这一分支的公开团队样本仍少，不能写成已经成熟的主流范式。但随着工业智能体与具身智能进入真实工位，它会与应用算法、现场可靠性、数据闭环和安全工程逐步融合。

它的区域化交付会更重，驻场深度会更高，远程诊断、硬件兼容矩阵、仿真到现实评测和安全停机将成为核心资产。它的规模化速度可能慢于纯软件 FDE，因为复制的不是一段代码，而是代码与设备、工艺和现场责任的组合。

但一旦动作原子、工位模板、设备兼容和失败数据开始复用，壁垒也会比“再做一个 Agent 工作流”更厚。未来更成熟的企业，可能形成“中央产品与仿真平台＋区域 FDE 网络＋现场合作伙伴”的三层结构：中央团队回收共性能力，区域 FDE 处理高价值差异，合作伙伴承担标准安装与维护。

这里的经营指标不能只看项目收入，还要看“每新增一种设备或工艺，下一次交付减少了多少重新学习”。否则所谓平台化，只是把每个现场的独特困难都保存得更加数字化。

同时也要防止把传统安装调试直接改名 FDE。现场工程师同样重要，但如果岗位没有软件工程、数据评测、产品反馈和结果闭环，就不是本文讨论的 FDE。

职业没有高低，只有别让缩写替岗位加戏。

07

FIVE MODELS

五类企业，其实在购买五种 FDE

把案例放回商业模式，差异会更清楚。

模型、云与通用平台：

购买“价值转译器”，把前沿能力变成生产采用，再把现场问题送回平台。

垂直 SaaS 与行业软件：

购买“知识迁移器”，把专家判断变成行业本体、评测与可升级工作流。

IT 服务、咨询与集成商：

购买“结果交付单元”，把战略、工程和运营连成闭环。

企业内部 AI 团队：

购买“组织编译器”，把部门规则变成数据、权限、流程和责任。

具身智能与工业现场：

购买“现实适配器”，让模型在设备、人员和安全约束下稳定工作。

「同一个 FDE 名称背后，是五种商业问题、五套生产责任、五条职业路线。」

真正拉开职业差距的，是失败代价

这五类企业的差别，不只在客户是谁，更在于系统失败时，损失由什么构成：

要点

平台型 FDE 改变的是“模型能力到生产采用”的状态。失败通常表现为采用停滞、成本失控、稳定性不足，或者大客户定制吞掉平台路线。

要点

垂直型 FDE 改变的是“专家知识到流程判断”的状态。失败可能是一项专业判断遗漏、敏感数据越界、证据不可追溯，或者规则变化后无人维护。

要点

服务型 FDE 改变的是“项目里程碑到持续运营”的状态。失败可能是范围失控、项目亏损、系统无人接管，或者功能验收了，经营问题还在原地等电梯。

要点

内部型 FDE 改变的是“部门需求到组织流程”的状态。失败可能形成影子 IT、审批责任真空、旧流程与新 Agent 并行，以及所有问题最终都流向同一个群。

要点

物理型 FDE 改变的是“软件判断到设备动作”的状态。失败代价会进一步落到停机、质量、设备和人身安全，因此它的放权与回滚必须最保守。

这也解释了为什么五类团队不能使用同一张绩效表。平台团队数 POC，垂直团队数知识库条目，服务团队数人天，内部团队数 Agent，物理团队数实验室准确率，都可能得到一份看起来很努力、却无法证明生产价值的周报。

更有意义的问题是：这支队伍改变了什么状态，谁批准它改变，失败由谁承担，现场留下了什么资产，下一次是否可以更快、更安全地完成。

FDE 的专业度，最终由它能安全改变多重要的状态，以及能否把这种能力复制出去决定。

如果你正在选岗位，不妨少问一句“公司模型多大”，多问下面五句：

我最终要改变哪个业务状态，而不是交付哪个功能？

我能否接触生产代码、真实数据和业务 Owner？

谁拥有评测集，谁决定上线，谁可以回滚？

现场经验怎样进入产品路线图或内部平台？

项目什么时候算结束，FDE 什么时候应该离场？

这五个答案，通常比岗位名称和技术栈更能预测你一年后是在积累复利，还是积累微信群。

08

TRENDS

接下来三年，我对中国 FDE 的五个判断

一、岗位名会继续膨胀，岗位本身会开始拆分

FDE、FDSWE、部署负责人、应用架构师、评测工程师、平台工程师和行业专家会逐渐分开。早期团队可以一人多岗，规模化后不能再期待同一个人既谈董事会战略、又写全栈、再背生产告警。

如果一份 JD 同时要求你懂行业销售、Kubernetes、财务 ROI 和高管沟通，还能全年出差，它描述的可能不是岗位，而是一份组织愿望清单。

二、最大人才来源不是应届生，而是存量角色重组

解决方案架构师、产品经理、交付工程师、数据工程师、行业专家和企业数字化团队，会成为 FDE 的主要供给。上海、山东的培训项目与北京政策已释放出这个信号。

但转型不是在原岗位后面加三个字母。真正的门槛是：从讲清功能走到写进生产，再从写进生产走到敢为权限、评测和回滚签字。

三、项目资产会成为团队真正的毛利表

成熟团队会强制回收业务对象模型、数据契约、评测集、权限模板、连接器、异常手册和退出方案。

下一次交付能否更快，是判断 FDE 团队有没有产品飞轮的最诚实指标。

如果客户越多，例外越多，骨干越不敢休假，业务规模增长只是把技术债从单间搬进了写字楼。

四、外部 FDE 与内部 FDE 会正式分家

外部 FDE 对客户采用、续约和产品反馈负责；内部 FDE 对流程改造、组织采用和能力交接负责。两者技能相似，权力结构不同。

客户从“另一家公司”变成“楼上那个部门”，并不会自动让需求更清楚，只会让电梯偶遇更频繁。

五、治理会从加分项变成主干能力

国家网信办等部门发布的智能体实施意见已明确提出决策权限、用户最终决策权、行为可追溯，以及异常发现、干预、阻断和恢复。

这意味着 FDE 不能只回答“能不能跑”，还要回答：谁授权，谁维护评测，哪些动作必须确认，异常怎样升级，谁能停机，数据和状态如何恢复。

当 Agent 能发邮件、改状态、下指令时，“它挺聪明的”不再是一句完整的验收意见。家长夸孩子可以这样，生产系统不行。

09

DECISION

企业到底该不该成立 FDE 团队

不是每家公司都需要一支叫 FDE 的队伍。

如果产品高度标准化、客户几乎无需集成、业务结果与产品使用之间距离很短，成熟的产品工程、实施和客户成功体系可能更经济。

但如果下面六个问题有四个以上回答“是”，企业就值得认真考虑 FDE：

客户或业务必须接入多套系统、私有数据与复杂权限；

Demo 到稳定生产之间经常卡在组织、数据或流程，而不是模型；

高价值项目需要工程师与业务 Owner 连续共创；

现场差异无法只靠配置和文档解决；

项目经验必须持续反哺产品或内部平台；

上线后需要长期评测、观测、异常处理和变更治理。

成立团队前，我还会要求管理层写清五件事：

向谁汇报：

夹在销售和研发之间却没有明确 Owner，团队会长期活在优先级拔河里。

什么叫成功：

上线、采用、稳定、自持还是业务指标改善，答案不同，行为就不同。

哪些东西必须产品化：

没有回收机制，现场经验只会沉在个人电脑和群聊里。

谁对高风险动作负责：

FDE 可以设计系统，不能成为业务责任的最终替身。

什么时候必须离场：

没有退出条件的“前置部署”，最后通常只剩“永久前置”。

∞

THE END

结语：别只选择一个岗位，要选择它背后的生产责任

中国 FDE 最值得关注的变化，不是又多了几个招聘页面，而是它已经进入公司战略、上市公司年报、客户工作流、人才培养和产业政策。

这意味着企业 AI 的竞争重点正在移动。

以前大家比较谁的模型更强、参数更多、Demo 更快；接下来会越来越多地比较谁能进入真实流程、守住权限边界、持续维护评测、完成组织采用，并把一次成功变成下一次不用从头再来。

FDE 这个名字可能继续流行，也可能被拆成十几个更准确的岗位。名字并不重要。

真正重要的是，企业开始为“模型到结果之间那段没人完整负责的路”建立组织。

「我的判断是：未来三年，中国不会收敛出一种标准 FDE；会长出五类更成熟的前置部署机制。」

好的团队会把现场变成产品，把项目变成资产，把客户或业务变成能够自持的 Owner。

差的团队会把所有模糊需求、跨部门矛盾和线上事故塞给几个能干的人，再给他们一个听起来很像特种部队的英文缩写。

两种团队都可能很忙。

只有一种会越来越值钱。

本文由 JOTO AI 智库从已授权的 53AI 知识库同步。

原始来源：53AI FDE 知识库