什么是 FDE（前沿部署工程师）？

首先，他是一名工程师，所以你本质上是在做数据科学、数据工程、软件工程。你和数据打交道，和技术打交道。而「前沿部署」这一部分，对我个人来说才是有意思的部分——它意味着你直接在客户的系统上工作。你不在实验室里干活。你面对的是真实的问题。

他是企业里的这样一个人：主要任务是让技术真正跑起来、解决问题、达成我们想要的结果。所以，与那种可能在做某个产品、只求让技术能运行的标准工程师不同，前沿部署工程师的首要目标并不是让方案「能跑」；而是触达做这件事的合适的人，并以另一种方式达成某种结果。我觉得「前沿部署」这个说法大概来自它的军事含义，但更核心的是——他们被嵌进了公司内部。

对我来说，前沿部署工程师不只是那种能把软件套到业务问题上、或者塞进公司现有业务流程里的人。更进一步说，他是能与客户手把手地合作，去搞清楚如何把业务流程连同软件、技术和工具一起改造，创造出一套全新工作方式的人。这是一套独特的能力组合，需要大量创造力，也需要一个相当「通才」的工具箱。

咨询顾问的传统含义，其激励大概更多围绕一份建议，或者说拿出一份行动计划。比如：「这是我们的建议，这是我们要走的方向。」而前沿部署工程师，更多是去落地某项技术——它改变你做事的方式，并对某个具体的工作流产生更直接的影响。

FDE 与咨询顾问的一个区别在于：作为工程师，你必须在客户的系统里工作并开发出一个产品，所以你会在那里留下这个产品。而 FDE 与软件开发者的区别在于：开发者要建的产品是预先定义好的；前沿部署工程师则像咨询顾问一样，需要先理解问题，并与客户讨论解决方案应该长什么样。

如今这两个角色正在大幅融合，前沿部署工程师和咨询顾问正在变成同一个角色。你不能只是进去交付一些洞察然后走人。你必须与客户一起工作，解剖业务问题，找出该和哪些人合作，推动技术落地，重构流程。我不把它看作两个角色。我认为，一个真正优秀的咨询顾问，就是一个真正优秀的 FDE。

我做这份工作 20 年了，我承认，FDE 这个说法本身也许有点像个流行词。然而它的概念比以往任何时候都更切题，因为新的 LLM 本身并不足够。关键在于把它们裁剪到眼前的问题上，并确保你从中拿到业务影响。否则，你只是为了 AI 而实施 AI。你会看到 token 消耗不断上升，但看不到任何利润层面的影响。这就是为什么「FDE 真正把问题解决掉」如此重要。

我认为人们现在谈论它比以往任何时候都多，对量子黑（QuantumBlack，麦肯锡的 AI 部门）的需求也比以往任何时候都高。那是我见过的这类人才最长的等候名单，部分原因是客户真的看到了它的价值。我们能够真正做到「在客户所在之处」与他们相遇。采用带来的收益和客户体验是天文数字级的。

三年前，所有人都在装企业级 AI 平台。但随后他们意识到并没有从中获得价值，人们也不用它们。所以今天，我的客户意识到：如果我们能端到端地重构一整个业务域，彻底重新想象一个业务流程，那才会带来真正的采用。

让技术做点对公司、对我们的客户有用的、有生产力的好事——这个核心问题并不新鲜。新鲜的是，AI 把很多这类问题放大了。我们有更多技术工具去解决更多问题，但它们并不是开箱即用、打包好的。客户会推出一款新的 AI 工具，然后指望影响自己发生，而事实并非如此。

从个人影响，到团队影响，再到全组织范围的影响——这个跃迁不会自动发生，因为你需要协作。仅仅因为我能把问题中的某一部分做得更快，并不意味着我们已经想清楚了如何更高效地开会、或者如何更快地沟通。

AI 正在两个方面改变这份工作。一是你开发软件的方式——用智能体式 AI（agentic AI）和智能体工程来写代码。我写的代码比 20 年前少了；AI 替你做。你需要更多地去思考规格说明，也就是你想让 AI 做什么。

另一方面是最终产品本身正在变成 AI。所以你在构建的是智能体式 AI 系统，而不只是几年前那样的机器学习系统。

以前，我们会配一个由许多计算机工程师或数据科学家组成的团队；但以今天的技术——AI、分析、软件工程——这些都在真正地民主化。今天量子黑的业务分析师，几乎像是在当 AI 的管理者。两年前的管理者，现在则像总监一样，带着一群各自带团队的人。

AI 在某种程度上改变了「部署技术」这件事的样子。以前是在客户那里部署更多预打包软件，也许做一点定制，或者以某些方式做配置。AI 稍有不同，因为它在某些方面是一个通用工具。但你得把几样东西拼起来：

你通常需要一个模型，但你也需要一个数据层，以及对组织的一些理解。你需要搭一个约束框架（harness），确保它按你预期的方式行为。而且你通常需要改变工作流，让人们做不一样的事，才能拿到全部价值。

FDE 工作的典型第一周或初始阶段，通常是坐在正在执行某项任务的人旁边。假设我们有一个做供应链计划的团队：他们拿到一堆数据，已有系统在跑，正在做决策——是否要给船只或卡车改道，以确保正确的东西出现在仓库里。

FDE 做的，就是把自己塞进那个团队，试着理解谁在做决策、什么才真正带来差别、哪些数据是重要的。真正把自己沉浸进去理解这件事怎么运转，因为其中很多东西可能从来没有被很好地文档化。

很难描述一个典型的 FDE 工作，因为它真的取决于项目类型。始终不变的是：从定义问题开始——我们想解决什么——然后找到数据。这意味着要识别客户环境中数据所在的核心系统，再决定如何把数据取出来，放进比如云基础设施里。这更多是数据工程的部分。

到某个时点，你还会加入软件工程组件或前端工程组件，因为你最终想建一个真正的工具。然后就是迭代——因为你需要不断向客户演示你建的东西、拿到反馈，甚至可能从头再来。

这份工作更聚焦于业务问题。我们如何界定范围？我们如何知道什么会带来业务影响？FDE 在早期的工作时间里，大部分都在界定问题、解剖业务本身、和人待在一起、搞清楚价值在哪里，等等。

我的一位客户是一家工业企业，产品复杂，供应链很专业。由于地缘政治形势，他们的产品需求正在成倍上升，是此前交付量的很多倍。他们需要一套为其供应链量身定做的东西：能带来可见性——他们是否在正确的时间拥有正确的零件；能给出行动顺序；能驱动责任落实；还能做复杂分析。

周二我们被要求做出这个能力，周四我们就让它跑起来了。这个我们基本用一天半建出来的工具，过去要几百人花很多年才能建出来。

FDE 必须能够做判断。咨询顾问可能会识别问题、定义最佳方案应该长什么样。但作为 FDE，你应该决定的是什么是最佳方法论。什么才是合用？生成式 AI 是最好的工具吗？是智能体式 AI 吗？还是机器学习？或者只是一个非常简单的回归？工具有多先进并不重要，重要的是它有没有产生影响。

现在的焦点在智能体式 AI 系统上。比如，我们都知道和呼叫中心打交道可以有多烦。我们基本上把一家公用事业公司的呼叫中心「智能体化」了。解决那个问题相当有意思：确保智能体始终有正确的答案、不会产生幻觉、并且客户真的会喜欢。那是一个真实可以拨打的呼叫中心，智能体会在你穿过这段呼叫中心旅程时提供支持。

常常很讽刺的是，可以说更难的那部分是人的一面。人们并不总是对变化或新事物持开放态度。这有时甚至比让技术真正跑起来更棘手。

我想一个有意思的例子最近来自一位客户。我们正在改造他们开发软件的方式，让他们更多使用智能体。这位客户最有经验的软件开发者之一参加了智能体培训，然后回到工作岗位。他开始使用智能体，但它们不工作。因为他是一位真正有经验、有资历的工程师，他把智能体那部分放到一边，打开 IDE，自己把代码修好了。但智能体那条路就走偏了。

下一次，他可能连试都不会再试用 AI 和智能体来做这件事。有时候，如果你手下的人在自己擅长的事情上真的非常强，做出这种改变反而更难。

你必须用真实的数据、在真实的系统里解决问题，并确保本该使用它的人喜欢这个方案、而且真的在用。这是获得业务影响的唯一途径。

我们有一位客户反对智能体工程或智能体编程。他很明确地告诉我们：「我不太信任这东西。我不喜欢 AI。」我们花了一个半小时教他一些 AI 的基本原理，以及如何把它应用到他必须在 24 小时内解决的一个具体问题上。

下一周，他进来说：「我把我的 token 全用完了。」他还请我们教他整个团队如何使用 AI，让他们成为自己的前沿部署工程师。

如果你像我一样，是个「外向的极客」；如果你喜欢教别人；如果你不仅喜欢机房，也喜欢和人交谈——我认为那就是 FDE 的完美画像。它是机房里的编码、向人解释你做了什么、收集反馈、然后再来一遍，这种组合的完美体现。这就是这份工作的美妙之处。

你需要有点像「多项目运动员」，或者说像个双语者、三语者。我的意思是，这不一定关乎多门语言；你只需要在技术上有足够的深度。某种程度上你得是工程师，也就是你理解一个技术系统如何运作。

但如果你只有技术，却无法把「决策是如何做出的」、以及正在发生的那些非正式连接挖掘出来，去为客户解决问题，你就不会很擅长解决问题。那需要多得多的与人相处的经验：能很好地沟通、问对问题、有共情力。

我认为这是几件不同事情的组合。一是真正的内容知识与内容专长。第二是很好的人际能力——交付业务影响、做咨询，这都是一项「人的运动」。最后是技术能力，是的，但更重要的技能是快速学习的能力。

我认为最好的 FDE，是那些能极具创造力、或者能为从未存在过的东西跳出框架思考的人。而这份工作的很大一部分，是激励客户。