中国与美国 FDE 现状与实践深度研究

AI 落地最后一公里：中美 FDE 正在走向两种不同的工程范式

AI 模型越来越强，但企业真正把 AI 用起来，仍然很难。

今天的大模型已经可以写代码、分析文档、调用工具，甚至独立执行一部分复杂任务。但当我们把它放到真实企业里，会马上遇到另外一套问题：

数据在哪里？

谁允许调用这些数据？

现有 ERP、MES、CRM、OA 怎么接？

业务流程到底是怎么运行的？

模型输出错了由谁负责？

效率究竟提升了多少？

最后又由谁来验收？

也正是在这个背景下，一个并不算新的职位重新成为 AI 行业的热点：

FDE（Forward Deployed Engineer，前线部署工程师）。

Palantir 很早就在使用 Forward Deployed Software Engineer 这种组织模式，而最近几年，OpenAI、Scale AI、Cohere 等 AI 公司也开始越来越重视类似团队。

有意思的是，中国其实也存在大量承担类似工作的团队，只不过我们通常不叫 FDE，而叫：

解决方案架构师、实施工程师、驻场研发、行业专家、算法工程师、技术服务专家、交付工程师……

所以我最近一直在思考一个问题：

中国和美国实际上正在形成两种不同的 FDE 路线。

美国更强调“工程师深入客户，然后把经验重新带回产品”。

中国则更擅长“工程师深入复杂现场，把项目真正落下来”。

那么，未来哪一种模式更有竞争力？

一、FDE 到底是什么？

很多人第一次听到 FDE，会把它理解成“驻场程序员”。

其实二者差别很大。

一个普通驻场开发的典型工作方式可能是：

客户提出需求 → 开发实现 → 测试 → 验收 → 项目结束。

而成熟的 FDE 更接近：

业务现场 → 发现真正的问题 → 抽象问题 → 获取数据 → 快速开发 → 进入生产 → 验证业务效果 → 总结共性 → 反馈产品。

因此，我更愿意把 FDE 理解成：

被部署到客户问题现场的产品工程师。

真正重要的并不是“驻场”两个字，而是三个能力同时存在：

第一，能够深入理解业务。

不是只听产品经理转述需求，而是直接观察业务怎么运行。

第二，能够真正动手实现。

不是只写 PPT 或方案，而是能写代码、接 API（Application Programming Interface，应用程序编程接口）、处理数据、搭 Agent（智能体）、调模型，并最终把系统上线。

第三，对结果负责。

不仅要问：

“功能是不是做完了？”

还要问：

“客户到底有没有用？”

“效率究竟有没有提升？”

“这个经验能不能变成下一位客户可以直接复用的产品能力？”

如果只有驻场和写代码，更接近定制开发。

如果只有业务沟通，更接近解决方案顾问。

只有形成：

现场 → 工程 → 生产 → 产品

这样的闭环，我认为才是 AI 时代真正有价值的 FDE。

二、一个成熟的 FDE 团队，最重要的角色有哪些？

很多人会认为 FDE 团队只有两类人：

一类负责去一线了解需求。

另一类负责回来开发。

实际项目通常复杂得多。

我认为至少需要下面几个核心角色。

其中，我认为最容易被忽略的是最后一类：

客户自己的业务专家。

比如一个制造项目中，真正知道某种异常意味着什么的人，可能不是客户 CIO（Chief Information Officer，首席信息官），也不是厂商算法工程师。

可能就是一位在这个车间工作了十几年的工艺工程师。

AI 可以发现相关性。

FDE 可以构建系统。

但很多时候，只有现场专家才能告诉你：

这个结果从业务上到底有没有意义。

三、FDE 到底怎么工作？

我认为比较典型的 FDE 生命周期可以拆成八步：

现场调研 → 问题抽象 → 数据接入 → 快速原型 → AI 或 Agent 集成 → PoC 验证 → 生产上线 → ROI 验收。

这里面的重点不是开发，而是前两步。

1. FDE 首先要进入现场

以制造业为例。

如果项目目标是优化某条产线，FDE 不应该第一天就坐进会议室讨论系统功能。

更好的做法是：

直接跟着车间人员走一遍流程。

观察操作员做什么。

观察数据从哪里产生。

观察等待发生在哪里。

观察为什么某一步必须人工判断。

观察系统和现实流程之间到底有什么差异。

很多真正重要的问题，从数据库里看不出来。

例如一个生产环节理论 SOP（Standard Operating Procedure，标准作业程序）只有 6 个步骤，但真正跟着操作人员走一遍之后，可能会发现实际存在 15 个动作。

其中大量动作根本没有进入信息系统。

这就是所谓的：

隐性流程。

而隐性流程往往正是 AI 最有价值的地方。

四、“带着录音设备去现场，晚上让 AI 分析”是不是 FDE 的典型工作方式？

这个方法我认为非常有意思。

例如：

白天 FDE 进入车间。

跟着班组长、工艺工程师和操作人员走完整个流程。

经过客户许可后记录访谈、会议或者现场说明。

晚上利用 AI 对当天材料进行处理：

语音转文字。

整理流程节点。

提取问题。

发现重复劳动。

生成待确认假设。

形成第二天需要继续验证的问题。

第二天再回现场验证。

这样实际上形成了一个很快的循环：

观察 → AI 整理 → 提出假设 → 第二天验证 → 更新方案。

这种方法非常符合 FDE 的工作逻辑。

但需要特别说明：

我目前没有看到足够公开资料证明“FDE 普遍带录音笔进入车间”已经成为行业标准流程。

因此更准确的说法应该是：

这是非常适合 AI 时代 FDE 的一种现场研究方法，而不是所有 FDE 团队都在执行的标准动作。

而且进入真正生产环境之后，还必须考虑数据安全问题。

例如：

生产工艺可能属于商业秘密。

员工声音可能涉及个人信息。

屏幕可能出现客户信息。

会议内容可能涉及财务和采购信息。

因此正确的流程应该是：

客户授权 → 明确记录范围 → 数据脱敏 → 指定存储环境 → 明确保留周期 → 再使用 AI 处理。

FDE 的价值来自“进入现场”。

但进入现场并不意味着可以无限制采集现场数据。

五、FDE 真正应该对接客户里的哪些人？

这是我认为很多 AI 项目最容易犯错的地方。

项目失败很多时候不是技术不行，而是：

找错人了。

例如制造业 AI 项目，如果 FDE 只和 IT 部门沟通，很可能出现：

技术上做出来了，但业务部门根本不用。

如果只和车间沟通，又可能出现：

方案很好，但信息安全、数据权限和系统接口根本无法通过。

所以成熟项目至少需要建立几类关键关系。

这里面我尤其认同一个概念：

责任共同体。

也就是说，不能变成：

厂商负责开发，客户负责配合。

而应该形成：

客户对业务结果负责，FDE 对技术结果负责，双方共同对最终价值负责。

例如一个产线良率优化项目。

车间主任不能只负责“给数据”。

FDE 也不能只负责“模型准确率”。

双方真正共同负责的应该是：

最终良率有没有提升。

这时候，双方目标才真正一致。

六、FDE 怎么让客户满意？关键其实在“怎么验收”

我认为 FDE 项目大致存在两种完全不同的验收方式。

第一类：目标明确型项目

这种项目在签合同之前就已经知道要做什么。

例如：

实现某个系统。

完成某些接口。

支持某些业务流程。

达到约定性能。

完成上线。

这种情况下，本质上还是传统软件工程验收。

常见指标包括：

功能完成率。

测试通过率。

严重缺陷数量。

系统可用性。

接口性能。

数据完整率。

安全测试结果。

用户验收结果。

最终按照合同和 SOW（Statement of Work，工作说明书）完成验收。

这种项目最重要的是：

不要在执行过程中无限扩展范围。

第二类：探索型项目

AI 项目最有意思的恰恰是第二种。

客户往往只知道：

“这里效率好像比较低。”

“这里人工很多。”

“这里每天需要大量重复分析。”

但是客户自己也不知道：

到底能优化多少？

甚至不知道：

AI 能不能解决。

这时候如果一开始就要求客户给出完整需求文档，实际上是不现实的。

FDE 的职责就发生了变化。

首先不是实现需求。

而是：

发现值得解决的问题。

典型流程应该变成：

业务假设 → 建立 Baseline → PoC（Proof of Concept，概念验证）→ 小范围 Pilot（试点）→ 测量真实效果 → 决定扩大、调整还是停止。

这里最重要的词是：

Baseline，也就是基线。

七、为什么很多 AI 项目最后说不清“效率提升了多少”？

因为很多团队上线之后才开始想：

怎么证明价值？

这时候往往已经晚了。

例如我们要做一个 AI 工单助手。

上线以后发现平均工单处理时间是 20 分钟。

这个数字到底好不好？

不知道。

因为我们不知道以前是多少。

正确的方法是在项目开始之前记录：

人工平均处理时间。

每天处理量。

首次解决率。

升级人工比例。

错误率。

客户满意度。

然后上线以后，在相同口径下再测一次。

例如：

上线前平均 40 分钟。

上线后平均 25 分钟。

人工升级率从 30% 降到 18%。

那么价值才可以被证明。

进一步还要考虑：

是不是因为最近业务量下降了？

是不是因为换了一批更有经验的员工？

是不是因为同时更新了另外一个系统？

所以成熟 FDE 项目还需要做：

对照组。

分批上线。

Shadow Mode。

A/B Testing（A/B 测试）。

时间窗口对比。

业务归因。

只有这样：

“效率提高 30%”才不是一句 PPT 上的话。

八、FDE 应该关注哪些验收指标？

不能只看模型准确率。

至少应该同时看四层指标。

模型层

例如：

准确率。

召回率。

误报率。

漏报率。

任务成功率。

系统层

例如：

延迟。

可用性。

故障率。

数据完整性。

权限和安全。

使用层

例如：

多少员工真正使用。

WAU（Weekly Active Users，周活跃用户）。

工作流覆盖率。

人工接管比例。

业务层

例如：

人工工时减少多少。

吞吐量提高多少。

良率提高多少。

停机时间降低多少。

工单解决速度提高多少。

成本降低多少。

最终 ROI（Return on Investment，投资回报率）是多少。

我认为真正成熟的 FDE 项目一定会从：

模型指标

逐渐走向：

业务指标。

因为客户最终购买的从来不是一个 95% 准确率的模型。

客户真正购买的是：

更高效率、更低成本、更好质量或者更多收入。

九、美国 FDE：从 Palantir 到 AI 公司重新流行

美国 FDE 很大程度上与 Palantir 有关。

Palantir 很早就建立了 Forward Deployed Software Engineer 这样的角色。

这些工程师并不是简单部署软件。

而是直接进入客户业务环境。

理解问题。

整合数据。

开发解决方案。

最终让 Palantir 的平台真正解决业务问题。

到了大模型时代，这种模式突然变得更加重要。

原因其实非常简单。

过去卖 SaaS（Software as a Service，软件即服务），很多时候可以告诉客户：

这是我的标准产品。

你按照我的流程使用。

但是 Agent 时代不一样。

一个企业 AI Agent 要真正工作，很可能需要连接：

CRM。

ERP。

内部知识库。

邮件。

Slack 或企业微信。

权限系统。

审批流程。

内部 API。

甚至生产设备。

这意味着：

模型能力越强，最后一公里反而越复杂。

因此 OpenAI 已经正式设立 Forward Deployed Engineering 团队，并在法律、医疗、政府等方向招聘 FDE。

OpenAI 对这一岗位的描述非常值得注意。

FDE 位于：

客户交付与核心平台开发的交叉位置。

也就是说，它既不是普通售前，也不是传统外包实施。

FDE 要参与：

Discovery。

Technical Scoping。

System Design。

Build。

Production Rollout。

也就是：

发现问题 → 确定技术范围 → 系统设计 → 开发 → 生产部署。

更重要的是：

客户现场出现的问题还需要重新反馈给产品和模型团队。

这就是美国 FDE 模式一个非常关键的特点：

现场不是产品研发的终点，而是产品研发的信息来源。

十、为什么美国 AI 公司突然如此重视 FDE？

核心原因是：

AI 产品越来越通用，但企业问题越来越具体。

同一个模型可以服务银行、制造企业、医院和律师事务所。

但是四个行业的数据、权限、流程和风险要求完全不同。

所以 AI 公司需要一群人站在：

模型和真实业务之间。

过去这个位置可能由咨询公司、系统集成商或者客户 IT 团队承担。

现在越来越多 AI 公司开始自己建立这样的能力。

因为谁掌握客户现场，谁就更容易知道：

模型到底哪里不够好。

产品到底缺什么能力。

客户为什么没有使用。

Agent 为什么在 Demo 里很好，在生产环境却失败。

因此 FDE 实际上已经不仅是“交付团队”。

它正在成为：

AI 产品公司的前线研发组织。

十一、美国 FDE 和传统售前、咨询、实施有什么区别？

我认为最关键的区别不是岗位名称，而是权限。

传统售前通常负责：

解释产品。

设计方案。

Demo。

PoC。

支持签单。

传统实施通常负责：

配置。

集成。

培训。

上线。

咨询公司通常负责：

研究问题。

设计流程。

提供方法论。

而优秀 FDE 则把这些能力压缩在一个非常小的团队里。

同时增加一个关键能力：

可以直接写生产代码。

所以 FDE 更像：

软件工程师 + 产品经理 + 解决方案架构师 + 行业顾问。

当然，一个人不一定真的承担所有工作。

但一个 FDE 小队通常需要拥有这些完整能力。

十二、中国有没有 FDE？

有类似工作。

但不能简单说：

“中国已经大量存在正式 FDE 岗位。”

目前中国更准确的描述应该是：

FDE 的功能大量存在，但岗位名称尚未统一。

比如：

驻场研发。

解决方案架构师。

行业解决方案专家。

实施顾问。

交付工程师。

算法工程师。

数据工程师。

云技术服务专家。

这些岗位中有一部分实际上已经在承担 FDE 类型的任务。

所以讨论中国 FDE 时，我认为应该区分：

“岗位名字是不是 FDE”

和：

“组织是不是按照 FDE 的方式工作”。

后者更加重要。

十三、中国为什么天然适合发展 FDE？

一个非常重要的原因就是：

中国拥有非常高密度的真实产业现场。

汽车。

新能源。

光伏。

锂电。

钢铁。

化工。

消费电子。

物流。

装备制造。

大量 AI 问题都不是单纯在电脑屏幕里解决的。

而是在真实生产环境中解决。

例如：

钢板缺陷检测。

电池良率预测。

设备预测性维护。

生产参数优化。

排产调度。

能源优化。

这些场景有一个共同特点：

仅仅调用模型 API 是远远不够的。

工程师还需要理解：

设备。

工艺。

传感器。

PLC（Programmable Logic Controller，可编程逻辑控制器）。

MES（Manufacturing Execution System，制造执行系统）。

质量体系。

生产节拍。

现场安全。

中国近年来大量工业 AI 项目，其实已经体现出这种“类 FDE”模式。

例如阿里云工业大脑曾公开展示协鑫光伏、中策橡胶等案例。

其核心不是单纯训练一个模型，而是：

生产数据 → 工艺理解 → 算法分析 → 现场验证 → 改变生产结果。

这和 FDE 的逻辑已经非常接近。

十四、中国 FDE 最大的风险：重新变成“高级驻场外包”

这也是我认为中国未来发展 FDE 最需要警惕的一件事。

很多项目的模式是：

客户提出需求。

厂商驻场。

大量定制开发。

项目验收。

团队撤场。

然后下一个客户重新开发。

这种模式虽然也可以赚到钱，但它本质上依然属于：

项目制。

FDE 真正应该形成的循环是：

现场问题 → 快速实现 → 生产验证 → 提炼共性 → 产品化 → 下一个客户直接复用。

举一个简单例子。

假设第一个制造客户要求：

把 SAP、MES 和设备数据统一起来。

FDE 为客户做了一套连接器。

到了第二个客户，如果还是重新写一遍，那么这只是项目经验。

如果第二个客户已经可以直接使用标准 Connector（连接器），那么第一个项目才真正提升了产品能力。

所以衡量 FDE 是否成功，我认为有一个非常有意思的指标：

前十个客户遇到的问题，有多少到了第二十个客户那里已经不需要 FDE 手工解决？

这个指标甚至比：

“一年完成多少项目”

更加重要。

十五、一个典型制造业 FDE 项目可能是什么样？

假设一家工厂希望利用 AI 优化质量检测。

第一周。

FDE 不急着训练模型。

先进入现场。

跟着质检员走流程。

了解：

缺陷是什么。

什么缺陷最严重。

目前怎么判断。

每天检查多少件产品。

一次检查花多少时间。

哪些缺陷最容易漏掉。

第二阶段。

开始处理数据。

接入相机。

生产批次。

质量系统。

设备数据。

建立标注规范。

第三阶段。

快速训练和验证模型。

但这个时候 AI 不直接控制生产。

先进入 Shadow Mode：

AI 给出判断。

人工继续正常工作。

双方结果进行比较。

第四阶段。

当效果稳定以后，再把 AI 接入真实工作站。

第五阶段。

开始测量真正业务价值。

例如：

人工检查量下降多少？

漏检是否下降？

每小时检测数量增加多少？

质量成本下降多少？

最后才进行正式验收。

这就是 FDE 和“做一个 AI Demo”之间最大的区别。

十六、再看一个企业知识场景

比如一家企业每天有大量内部技术支持问题。

传统做法可能是：

用户提问 → 客服收集信息 → 查询知识库 → 找工程师 → 建 Jira → 等待回复。

FDE 的做法不会只是做一个聊天机器人。

首先应该观察整个工作流。

然后发现：

真正浪费时间的可能不是回答问题。

而是：

信息收集。

问题分类。

内部知识查询。

寻找负责人。

创建工单。

所以真正解决方案可能变成：

用户仍然在原来的 Slack 中提问。

AI 自动收集上下文。

查询历史文档。

判断问题类别。

调用内部系统。

必要时自动创建 Jira。

最后再由工程师处理真正复杂的问题。

这时候 AI 改变的就不是：

“回答问题的方式”。

而是：

整个业务工作流。

我认为这也是 FDE 最核心的价值：

不是把 AI 放进业务，而是借助 AI 重新设计业务。

十七、中美 FDE 最大的差异

把目前公开案例和两边企业软件的发展路径放在一起，我认为可以做一个比较。

如果用一句话概括：

中国更擅长把工程师送到复杂现场，美国领先团队更擅长把现场经验重新带回产品。

当然，这只是当前阶段的整体观察。

并不意味着所有中国企业或者美国企业都符合这个模型。

十八、我更看好的不是“中式 FDE”或者“美式 FDE”

如果一定让我判断未来，我反而认为最终很可能出现第三种模式。

也就是：

中国式现场能力 + 美国式工程授权 + 产品飞轮 + 可量化评测 + 客户能力转移。

中国最大的优势是：

真实产业场景足够多。

但如果每一个场景永远依赖大量工程师重复定制，就很难形成软件规模效应。

美国模式最大的优势是：

现场知识可以快速进入产品 Roadmap。

但如果过度相信标准产品和通用 Agent，又可能低估复杂产业现场中的工艺、组织和安全问题。

所以真正成熟的 FDE 应该同时解决两个问题。

第一个问题：

能不能走得足够深？

真正进入业务现场。

第二个问题：

能不能走得出来？

把某个客户的特殊经验重新抽象成产品能力。

如果只能进去，出不来，就会变成外包。

如果只想产品化，不愿意进去，就很容易做出没有人真正使用的 Demo。

十九、AI 时代，FDE 可能会成为一类非常重要的人才

以前软件工程师最重要的是：

把需求变成代码。

未来一部分工程师可能需要进一步变成：

把现实问题变成可以被软件和 AI 解决的问题。

这要求工程师同时拥有：

技术能力。

业务理解。

沟通能力。

产品判断。

数据意识。

AI 能力。

现场执行力。

这也是为什么我认为 FDE 值得长期关注。

模型能力越强，很多纯编码工作可能越来越自动化。

但另外一种能力反而会越来越稀缺：

知道到底应该解决什么问题。

二十、最后留一个问题

目前来看：

中国拥有大量复杂、真实、高密度的产业现场。

美国正在形成更成熟的 FDE 工程组织和产品反馈机制。

一边更接近现场。

一边更强调产品飞轮。

未来很可能并不是谁完全取代谁，而是两种模式逐渐融合。

所以我也想把这个问题留给大家：

你觉得中国式还是美国式 FDE 更有前景？ 你所在的公司有没有类似 FDE、驻场 AI、行业解决方案或者 AI 落地团队？ 有没有真正让你印象深刻的案例？ 欢迎在评论区分享。

我目前更倾向于一个判断：

未来最高价值的 FDE，不是最擅长“救火”的工程师。

而是：

解决一次问题之后，能够让同一种问题以后尽可能不再需要人工救火的人。

这可能才是 Forward Deployed 真正值得保留的意义。

参考资料

1. Palantir：A Day in the Life of a Palantir Forward Deployed Software Engineer。
2. OpenAI Careers：Forward Deployed Engineer。
3. OpenAI Careers：Forward Deployed Engineer，Legal。
4. Scale AI Careers：Forward Deployed Engineer，GenAI。
5. Cohere：Why Forward-Deployed Engineers Should Build Capability, Not Dependency。
6. Cohere 与 CoreWeave 企业 AI 落地案例。
7. NIST（National Institute of Standards and Technology，美国国家标准与技术研究院）：AI Risk Management Framework 相关资料。
8. 国家数据局：《“人工智能+制造”专项行动实施意见》。
9. 国家数据局：《关于推进行业高质量数据集建设行动的实施方案》。
10. 中国信息通信研究院：工业算网与工业人工智能融合发展相关研究。
11. 阿里云 ET 工业大脑公开案例。
12. 华为云工业智能与智能质检公开案例。