企业 AI 要赚钱，第一个岗位先招谁？OpenAI 前首席研究官给答案

企业做 AI，最怕什么？

不是技术不成熟，不是市场不接受， 而是：工具上线了，却没人用。

Bob McGrew，ChatGPT 的主要开发者、OpenAI 前首席研究官，对此有深刻洞察。 他主导过 GPT-4、O1 等关键模型的研发，如今他的建议是：

不是先建平台，不是先招架构师，要先找到能快速交付结果的人。

他指的不是产品经理，也不是顾问，

而是一个新兴的、正在被 YC 百家公司疯抢的角色：

FDE——前部署工程师

2025 年 9 月 8 日，McGrew 在 YC 的 Lightcone 节目上完整讲透了这个岗位， 他还同步在 X（原 Twitter）上发文强调自己的核心方法论：

“先把无法规模化的事情，变成可规模化的模式（Doing things that don’t scale — at scale）。”

这句话很简单：不是先搭技术，而是先搭人和流程。

Claude、Castle、Palantir这些成功案例，背后都有这样的“落地专家”。

在这个节点，我们必须重新问一句：

企业 AI 要赚钱，第一步到底该怎么走？

 为什么不是 CTO，不是产品总监，而是这个从未出现在组织架构中的新岗位？

第一节｜不是顾问，不是销售：FDE 到底是谁？

这个岗位，名字叫 FDE，听起来像技术岗位，但又不是工程师。

它的全称是 “前部署工程师（Forward Deployed Engineer）”。 Bob McGrew 一句话说透了：

“FDE 不是给你做演示，也不是陪你讲需求。他是直接进现场，和客户一起把问题解决掉。”

✅  FDE 不是工程师？

如果你把 FDE 想成顾问，那就错了。

顾问是站在边上，出一套方案，让别人去执行。 而 FDE，是直接动手的人，把软件改成能用的人。

McGrew 强调，FDE 不搞形式。他说：

“我们在 Palantir 一开始就发现，去找传统做政府销售的人，根本没用。他们会说：‘我可以请你吃饭，带你见客户，但不会动手改产品。’”

FDE 也不是普通工程师。

工程师在办公室画架构图，FDE 进驻客户现场，当场解决前所未见的问题。

Bob McGrew 用一个场景来说明：

“客户的问题通常是全新的、前所未见的挑战。FDE的价值就在于：别人觉得不可能，他们能让它成为可能。”

而且 FDE 要在短时间内把 demo 变成能交付的产品。原型粗糙没关系，但结果得能用。

不是要做十年不出 bug 的代码，而是能在三个月内上线，真实解决客户问题的代码。

✅  FDE 到底在干什么？

McGrew 举了一个例子：

他在 Palantir 做情报系统时，客户一开始根本不愿意讲真实需求。因为是情报部门，信息保密。

于是他们带了一个基础 demo 去，结果客户说这和我们的工作完全无关。但下一句就变了：

“客户说：‘如果你能把这个地方改掉，再换个视图，我们也许能用上。’”

于是 FDE 当场记下反馈，一晚上改好，再带回来。

这是完整的现场迭代过程：传统做产品，是销售讲完客户意见，工程师在总部写代码；FDE 是直接让工程师坐在客户边上，听他说，马上改。

那么，FDE 和产品经理又有什么区别？McGrew 的话很直接：

产品经理是站在用户身边理解流程，FDE 是直接把流程改掉。

而且好的 FDE 会持续深入。解决了第一个问题后，继续找新的切入点，有时候价值比最初预想的还高。

这是全面渗透客户业务的过程。

这节不是讲“FDE 的定义”，而是在回答一个更具体的问题：

“你在做 AI 产品时，谁是真正能拿下客户的关键角色？”

第二节｜为什么 AI 公司都在抢 FDE？

FDE 模式解决的核心问题是：复杂企业场景下，技术和业务之间的“最后一公里”。

McGrew 用一个形象比喻概括了这个模式：

FDE 在前面铺石子路，产品团队再把它修成高速公路。

这种分工让 Palantir 能够同时解决个性化需求和规模化复制的矛盾。

✅  不是公司特别，而是场景变了

Palantir 之所以会走这条路，是因为它做的客户非常复杂：

• 国家安全局、反恐指挥、执法系统……
• 每个组织不一样，每个流程也不一样，根本没有标准产品能直接拿来用

Bob McGrew 认为：AI Agent 现在的处境，和 Palantir 当时一模一样。

“你以为你做的是一个通用代理工具，但每家企业的流程、工具、数据权限，全都不一样。没有谁能买回去就能上线。”

这就和传统 SaaS 完全不同了。SaaS 产品靠的是“流程标准化”：

• 每个公司发工资的方式差不多，做财务报表的步骤也差不多
• 所以 SaaS 公司做了一个统一的模版，只要设置好账户，大家都能用

但 AI Agent不是。

它是个全新物种，不像 SaaS 有成熟流程可复制。没有谁知道 AI Agent 应该长什么样。

在这种情况下，如果只是等客户自主使用，很难产生实际效果。

✅  不是服务转型，而是产品落地路径改了

很多人一听“FDE”，会以为这就是服务岗，是“陪伴式运营”或者“定制开发”。

McGrew直接否认了这个说法：

“FDE 并不是让产品去配合客户，而是通过客户，把真正通用的需求提炼出来。”

举个例子：

某 AI 公司给银行做风控系统，第一家银行要检测信用卡欺诈，第二家要识别洗钱行为，第三家要防范内部违规...每家需求都不同。

如果每次都定制开发，永远做不完。

但 FDE 发现，这些需求本质上都是“识别异常行为模式”，于是产品团队抽象出通用的异常检测框架，一套系统解决所有问题。

这就是 FDE 模式的关键价值：彻底改变产品落地路径。

✅  今天的 AI 代理公司，为什么更需要 FDE？

现在超过 100 家 YC 创业公司都在招聘 FDE，三年前这个岗位还几乎没人听说。

为什么突然爆发？

因为 AI 公司发现，Agent 落地的关键是接入真实的业务流程。但这些流程在哪里？

不是谁都能讲清楚流程，很多客户连自己为什么这样做都说不出来。你得人到现场去看，去跟，才能找到真正的切入口。

这就是为什么 OpenAI、Anthropic、Claude 背后的团队越来越强调： Agent 不只是能力，而是行动的结果。

技术已经准备好了，但世界的采用速度还没跟上。

企业需要的不是更强的模型或更高的准确率，而是一个能接得上流程、跑得出结果的人。

这个人就是 FDE。

第三节｜FDE 怎么让 AI 项目赚起来？

如果说 FDE 的第一个角色是“让 AI 能落地”，那第二个角色，就是 “让企业能开大单”。

你可以把 FDE 理解成“结果负责人”——他卖的不是功能，而是结果。

在 SaaS 模式里，公司卖的是“许可”“模块”“席位”。但在 AI agent 的世界里，客户只愿意为结果付钱。

✅  怎么赚钱的逻辑变了：从“卖软件”到“交结果”

传统 SaaS 怎么赚钱？靠规模。

一个功能打磨完，复制给一百家公司。合同不大，但能复制。

AI agent不一样：

• 每个客户的问题都不同
• 过程复杂、流程多变、数据乱糟糟
• 如果你想快速复制，大概率复制不了

McGrew 给的答案是：

“不要追求快速复制，而要深入解决问题。你卖的不是产品本身，而是已经验证的解决方案。”

FDE 在客户那里，不是为了安装产品，而是为了承接具体问题并交付结果。

这就解释了为什么 FDE 模式的商业逻辑很特殊：初期部署时可能亏钱，但随着时间推移，提供的结果越来越有价值，成本反而下降。

这个过程分三个阶段：

1. 最开始，FDE 去现场，花很多时间解决第一个问题，成本高；
2. 接着，客户开始依赖 AI 工具，反馈也更精准，需求更聚焦；
3. 最后，FDE 不用再改太多东西，产品已经能适配更多客户场景，利润开始上来。

✅  真实案例：怎么从“试点”干到“大单”？

McGrew 提到过几个 AI 代理创业公司的真实例子，比如 Castle 和 Happy Robot：

Castle 是一家做语音 AI 的公司，帮美国几家大银行处理抵押贷款电话

• 一开始只能做少数几个场景，但交付结果非常准，客户满意
• 后来客户主动追加合同金额，把整个流程都交给它做

另一个是 Happy Robot，也是做语音代理的，主要服务物流公司，比如 DHL：

• 他们和客户定合同，不是按功能收钱，而是按“成功通话数量”收费
• 客户越用越顺，越能看到省下的人力，就越愿意追加预算

这两个例子都说明了一点：

FDE 并不是成本中心，而是拉动收入的起点。

✅  客户信得过，合同才拉得动

很多人误解 AI 销售最大的门槛是功能不够，其实真正的门槛是：客户信任。

McGrew 说：

“企业客户往往经历过很多失败项目，他们甚至不信你能干成。 所以你要先跑出第一个结果，让他们信了你，后面的才好谈。”

这就是为什么FDE必须是能现场交付的人，必须在两三个月内把流程完整跑通，交出实实在在的成果。有了这个成果，客户才会真正信任，才有下一份大合同的可能。

只要你交付的结果越来越有价值，客户的预算就会主动跟着你走。

第四节｜谁能做 FDE，产品怎么配合？

说到底，FDE 是让 AI 落地的第一人。

可不是所有人都能做这事。

Bob McGrew 在对话中说得非常清楚：FDE 不是找“聪明人”，而是找“能扛事的人”。

✅  什么样的人能做 FDE？

McGrew 在 Palantir 内部把 FDE 分成两类角色：

• Echo 团队：嵌入客户现场，理解需求，找到落地场景
• Delta 团队：快速写出能跑的产品原型，现场部署，交付结果

Echo 团队最好有行业背景，比如退役军官、医疗专家，但更重要的是，他们得是“叛逆者”——熟悉行业流程，但知道原来的做法不够好，来拆掉旧流程、建新路径的人。

Delta 团队是工程背景，但和普通工程师不一样。不要找追求完美架构的人，要找能快速写代码、接受版本重写、面对流程变化的人。重点是先交付，代码可能很丑，但得能用。

这两类人，本质上就像“项目型创始人”：面对未知能开路，有压力能扛住，有方向感也能跟客户对话。

✅ 产品团队和FDE怎么互相配合 ？

McGrew 讲得非常坦率：

“我们面试了很多传统大厂的产品经理，他们都很优秀，但不习惯从多个客户需求中抽象出通用解决方案。”

举个例子：

有客户说，我要查“人”，下一个客户说我要查“船”，再一个说我要查“账户”。

那产品该怎么设计？

McGrew 给出的回答是别为每个客户定制，而是抽象出：

“人、船、账户虽然不同，但都有共同点：都有基本信息，都会跟其他东西产生联系。把这个共同的底层逻辑设计好，一套系统就能处理所有类型的数据。”

这就是 Palantir 著名的“本体（ontology）”设计来源。不是 FDE 提出了抽象，而是产品团队从 FDE 的踩坑里提炼出来的。

但在实际配合中，产品和 FDE 之间也有冲突。产品团队经常觉得自己开发的工具“非常好用”，结果现场的 FDE 不愿意用。

解决方式是什么？

“派产品团队去现场，陪着 FDE 一起用工具、一起改进。”

这就是 FDE 模式的核心：先跑出结果，再抽象成通用能力。

产品团队的角色不是闭门造车，而是将现场验证的解决方案规模化。

结语｜FDE，不是岗位，是路径

FDE 是现实倒逼的产物。你想要结果，就得有人先迈出第一步。

正如 McGrew 所说：

模型能力已经进步飞快了，但企业部署还远远跟不上。

不是工具不够强，不是模型还差点，而是企业没人能落地。你缺的是那个能让 AI 融入现实流程、交付第一个成果的人。

FDE 做的事，就是把“不确定的机会”变成“可重复的流程”。它是结果的起点，是增长的前线。

企业想用好 AI，别先问模型行不行，应该先问一句：

“我们有没有这样一个人？”

一个能在客户现场把路铺出来的人。起点，总要有人先走。