FDE · BUSINESS TRANSLATION

我做了一年多FDE，发现AI项目最难的根本不是技术

客户说出来的是明线，真正决定AI能不能落地的，往往藏在那条暗线里。

最近，FDE这个岗位一下子火了。OpenAI的招聘页面上，从旧金山、纽约、西雅图，到伦敦、东京、新加坡，都能看到Forward Deployed Engineer的职位。

我看到这些讨论时，感觉还挺奇妙。因为大家最近才开始给这份工作起名字，而我已经在企业现场干了一年多。

这一年多，我给央企、外贸、连锁餐饮和出海企业交付过AI项目。从第一次开需求会，到拆业务、整理资料、搭系统、培训员工，再到项目上线后的反复调整，我几乎把FDE这条路从头到尾走了一遍。

所以我很确定，这个岗位会越来越值钱。但真正值钱的地方，跟很多人理解的不太一样。它不在于你能写多少代码，也不在于你一晚上能搭多少个Agent。

技术当然重要，官方岗位说明甚至明确要求FDE能够参与生产级代码和完整系统交付。可技术更像门票，真正拉开差距的是另一种能力，你能不能钻进一家企业，把客户自己都说不清楚的问题挖出来，再翻译成AI可以执行的工作。

我把这件事分成两条线。客户说出口的是明线，真正决定项目成败的是暗线。

先说结论

客户说出口的是明线，真正决定AI能不能落地的，往往藏在那条暗线里。

01

WHAT IS FDE

FDE干的不是技术外包，而是把AI送进业务现场

FDE的全称是Forward Deployed Engineer。这个名字听起来很技术，简单理解，就是不只坐在模型公司里研究能力，而是直接进入客户的业务现场，和客户一起把AI做成能运行的系统。

OpenAI对这个岗位的描述很完整。FDE要负责需求发现、技术范围界定、系统设计、开发和生产上线，还要用真实采用率、工作流影响和评测反馈来衡量结果。代码只占其中一部分，前面要听懂业务，后面还要推动真正使用。

所以我不太愿意把FDE理解成一个更高级的程序员，也不觉得它只是售前、顾问或者项目经理换了一个新名字。它站在业务和技术中间，两边的话都要听懂，两边的责任也都躲不开。

客户说想要一个智能体，你不能只问用哪个模型。你还得知道谁会使用、资料从哪里来、什么情况算答对、出了错谁负责、接进原有系统以后会不会有人真的打开。FDE交付的不是一个演示，而是一项可以持续运行的工作。

02

THE BRIGHT LINE

客户说出口的需求，通常只是明线

这一年多，我听过很多企业表达AI需求。想做知识库，想搭智能客服，想让AI写内容，想让员工学会豆包和DeepSeek，想把周报、表格和客户资料自动处理。

这些话都没有错，只是它们经常已经带着一个现成答案。客户还没有把真正的问题讲清楚，就先决定了要做知识库、智能体或者自动化。FDE如果照着这句话直接开工，很容易把客户的方案当成客户的需求。

我把这类能在会议上直接说出来、也能写进项目清单里的东西叫做明线。它有名称、有交付物，看起来很清楚，双方也最容易围绕它讨论功能、时间和价格。

麻烦就出在这里。明线越具体，项目团队越容易产生一种错觉，觉得需求已经清楚了。于是大家开始选模型、画架构、搭页面，等到系统做出来才发现，员工不用、数据不对、结果没人敢签字。

很多AI项目不是做不出来，而是从一开始就做错了问题。

KEY POINT

很多AI项目不是做不出来，而是从一开始就做错了问题。

03

THE DARK LINE

真正决定项目成败的，是藏在下面的暗线

明线下面，通常还压着一条暗线。它不是客户故意不说，而是很多业务规则已经变成了习惯，连客户自己都很难一次讲清楚。

客户说想做知识库，明线是把资料放进去，让员工可以提问。暗线可能是同一件事不同部门有三个版本，也可能是关键经验只在几个老员工脑子里，管理者真正担心的是人一离开，经验也跟着消失。

客户说想做智能客服，明线是让AI自动回复。暗线可能是售后、销售和运营的口径从来没有统一，遇到退款、投诉和特殊客户时，谁有权决定也没有写进任何流程。AI一旦接手，只会把原来的混乱放大。

客户说想让AI写内容，明线是提高产量。暗线可能是企业连内容到底写给谁、产品凭什么被选择、哪些表达不能出现都没有确定。此时让AI一天生成一百篇，只是更快地产出一百篇没人负责的内容。

暗线藏在企业真正害怕的结果里，藏在异常情况里，藏在老员工的一句「这个要看情况」，也藏在部门之间默认但没有写出来的责任边界里。大家都懂，AI不懂。

所以FDE真正值钱的，不是听见客户要什么，而是继续往下追，他为什么现在要做，最怕什么，谁在判断，什么结果才算真的解决。

04

FIVE QUESTIONS

暗线不是靠猜，要靠五个问题挖出来

挖暗线不是坐在会议室里展示自己多懂行业，也不是听两句话就替客户下结论。最有效的办法，反而是回到真实工作，跟着一次任务从头走到尾。

我现在面对一个AI需求，通常会连续问五个问题。现在这项工作到底由谁完成，最耗时间和最容易出错的地方在哪里，如果没有解决公司最担心发生什么，老员工靠什么判断对错，AI做完以后又由谁按照什么标准验收。

第一个问题帮你找到真实岗位，第二个问题找到流程卡点，第三个问题找到业务风险，第四个问题挖出专家经验，第五个问题决定AI能不能上线。这五个问题问完，客户最开始那句话往往会变成另一项完全不同的任务。

想做知识库，可能会变成统一产品口径和权限。想做智能客服，可能会变成先整理异常处理规则。想做内容自动化，可能会变成先确定客户、卖点和审核标准。

这一步很慢，也没有搭出一个漂亮界面那么容易被展示。但我自己的感受是，项目后面能不能少返工，员工会不会抵触，管理者敢不敢把真实业务交给AI，往往在这里已经决定了一大半。

客户给你的通常是一个答案，FDE要重新找到那个问题。

KEY POINT

客户给你的通常是一个答案，FDE要重新找到那个问题。

05

TRANSLATION

从暗线到AI，中间要完成四次翻译

暗线挖出来还不够。它仍然是一堆业务语言、经验判断和风险担忧，AI不能直接拿去执行。FDE接下来要做的，是把这堆东西连续翻译四次。

第一次，把客户的表达翻译成业务目标。不是做一个知识库，而是让新人可以在十分钟内找到统一答案。不是做自动周报，而是让负责人每天都能看到异常，而且数据来源可以追溯。

第二次，把业务目标翻译成判断规则。AI要读什么资料，遇到哪些情况必须拒绝，哪些结果需要引用来源，哪些异常必须转给人，谁有权修改规则，都要被写清楚。

第三次，把判断规则翻译成工作流程。这个时候才轮到选择Kimi、Claude、GPT或者国产模型，再决定用知识库、Agent、工作流还是现有系统接口来完成。技术终于有了一个明确位置，而不是被请来猜客户心思。

第四次，把工作流程翻译成验收结果。节省了多少时间，错误少了多少，员工有没有真的使用，人工复核还剩多少，出现问题能不能找到责任和原始依据。没有验收，所谓落地就很容易停在演示阶段。

从明线走到暗线，再从暗线走到规则、流程和验收，这才是一套完整的FDE工作。Agent只是流程里的一块，业务翻译才是把整条链路接起来的东西。

06

THE REAL VALUE

技术是门票，业务翻译才是壁垒

这话听起来可能会让一些技术人员不舒服。FDE当然需要技术，不会系统设计、不懂模型边界、写不出可靠代码，很难把一个复杂项目真正送进生产环境。OpenAI的招聘要求也明确写着生产级开发、系统交付和客户协作能力。

但模型会继续变强，写代码和搭Agent的门槛也会继续下降。以前需要一个团队做几周的原型，现在一个人配合Codex可能几天就能做出来。工具越强，单纯把功能搭出来越难成为长期壁垒。

真正不容易被压缩的，是你能不能听懂一个组织怎么工作，能不能让老板、业务、技术和一线员工把同一件事说清楚，能不能把那些模糊经验变成一套可执行、可复核、有人负责的规则。

我一直觉得，AI落地像一个1，后面跟着一串0。模型是0，工具是0，Agent也是0。把业务暗线挖出来并翻译清楚的人，才是前面的那个1。

没有这个1，后面的0越多，项目看起来越热闹，返工也可能越多。有了这个1，模型选型、知识库、智能体和自动化才开始共同指向一个真实结果。

KEY POINT

把业务暗线挖出来并翻译清楚的人，才是前面的那个1。

07

START HERE

想做FDE，先别急着再学一个新工具

如果你也想进入FDE这个方向，我不会劝你放下技术。技术基础依然重要，只是别把所有时间都花在追最新模型、背产品功能和复制工作流模板上。

找一段真实业务，完整地跟一次。看看资料怎么进来，谁做判断，谁接收结果，遇到例外怎么办，做错以后谁承担代价。再试着把这项工作写成一张任务说明，包含输入、规则、权限、输出和验收。

如果你是企业管理者，也可以从同一个动作开始。下次有人说公司需要一个知识库、智能体或者AI助手，先别急着问价格，继续追问一句，我们真正害怕发生的事情是什么。

那句话后面，往往就是暗线。也是AI真正应该进入业务的位置。

我做了一年多FDE，最大的感受并不是技术不重要，而是技术终于足够强以后，企业再也不能把业务没想清楚这件事推给工具。模型越强，真正懂业务、会翻译的人，反而越值钱。