FDE 工程师就是承担这项工作的一类人。它的全称是 Forward Deployed Engineer，通常译为“前线部署工程师”。
他们深入客户的业务，与客户一起找到值得解决的问题，设计和开发方案，持续推进到实际使用。
说简单也简单：先搞清楚业务怎么跑，再用自己的 AI 知识，想办法让 AI 接进去，承担合适的工作。
复杂之处在于，这句话包含了好几种判断：客户真正需要什么，AI 能做到哪一步，现有系统怎么配合，以及做出来以后怎样才算有用。理解了这条主线，FDE 的职责、工作方法和这两年受到关注的原因，也就连起来了。
FDE 的工作，从客户的业务问题开始
FDE 在这一轮大模型热潮之前就已经存在。Palantir 在 2020 年发布的工程师访谈里，介绍过一种很直观的分工：产品研发通常围绕一项能力，让多个客户都能使用；FDE 则围绕一个客户的问题，组合和实现多项能力，与最终使用者一起把方案做出来。
Palantir 工程师访谈
两种工作的起点不同。产品研发要找共性，考虑一个功能怎样适用于更多人；FDE 先面对一家具体企业，理解它的工作习惯、数据条件和业务目标，再决定怎样使用平台里的能力。
这也解释了为什么 FDE 需要接近业务一线。客户的需求往往还没有整理成完整的软件说明。业务人员知道哪里难做，却未必知道技术上有哪些选择；工程师知道平台能做什么，却需要有人讲清楚，哪些问题值得花力气解决。
Kevin Bai 在《Forward Deployed Engineering 101》中谈过这种落差。他在演讲时任职于 Anthropic 的应用 AI 团队，此前在 Palantir 工作，并参与建立 Rippling 的 FDE 团队。他的解释是：客户买到一个强大的平台后，还需要把它变成业务结果；FDE 就参与承担这部分工作。
Kevin Bai 的《Forward Deployed Engineering 101》演讲封面。来源：AI Engineer。
所以，FDE 的技术工作和业务工作很难完全分开。选错问题，代码写得再好也可能没人用；理解了问题，却没有能力把系统做出来，同样无法交付。
它与解决方案、实施、咨询、产品经理等岗位都有交集。判断一个岗位是否具有 FDE 的特点，可以看它的责任是否贯穿需求发现、工程实现和实际使用，以及现场经验能否回到产品里。仅凭职位名称，很难看出这些区别。
为什么 AI 越来越强，企业仍然需要 FDE
2026 年 5 月，OpenAI 宣布成立 OpenAI Deployment Company，明确提出让 FDE 与客户的业务负责人和一线团队合作，选择优先流程，连接数据、工具及业务系统，并完成部署。Anthropic 的官方 FDE 岗位也要求工程师进入客户环境，构建能投入实际使用的应用。
这些动作背后，是企业对 AI 的期待正在扩大。
OpenAI 在 2026 年 8 月的企业使用观察中，将这种变化概括为从辅助走向执行：人们开始让 AI 使用工具、处理资料并完成工作。
摩根士丹利案例中的 AI 助手使用与访谈画面。来源：OpenAI。
我的理解是，这让企业同时遇到了三件需要解决的事。
首先，能做的事情多了，选择反而更重要。 同一个模型可以用来整理资料、辅助销售、编写代码。企业需要判断，哪一项最接近自己的业务目标，哪里有足够好的条件，哪里即使做出来也不会产生多少价值。模型能力本身无法替企业作出这些选择。
其次，AI 要干活，就得进入已有的工作流程。 一份内容生成得不错，只能说明它在这个任务上有潜力。实际使用还涉及资料从哪里来、结果交给谁、下一步在哪个系统继续处理。员工原本的工作安排也要随之调整。只要这些连接没有完成，员工就仍需在工具之间来回搬运，独自承担核对和收尾。
最后，企业需要有依据地相信它。 一个人偶尔使用 AI，可以随时判断答案是否合适；一个团队把某段工作交给 AI，就要共同确定质量要求，知道哪些结果需要复核，出现问题时如何处理。工程师必须把这些要求做到系统和协作方式里。
因此，模型能力的进步与 FDE 的工作可以同时增加：前者扩大了可以尝试的范围，后者负责在具体企业中判断怎样尝试、怎样验证、怎样持续使用。
FDE 具体做什么？沿着一条责任链看
OpenAI 的 FDE 岗位说明要求 FDE 工程师必须具备需求发现、范围确定、系统设计与开发等一系列能力，一直负责到生产部署，并以实际采用、流程影响和反馈来衡量工作。
把这些职责放到一个项目中，可以理解为四件前后相接的事。
先把问题选准。 “提高效率”还不足以开始开发。FDE 要理解业务现在怎样完成，主要困难在哪里，谁最受影响，以及改善之后能产生什么价值。这一步的结果，是与客户共同确定一个值得推进、范围清楚的问题。
接着把问题变成方案。 需要什么资料，哪些步骤适合 AI，哪些工作继续由现有软件或人来完成，都要作出选择。这里需要工程能力，也需要取舍能力：第一版应该做到什么程度，哪些复杂功能可以后置，怎样尽快验证最关键的假设。
然后陪着使用者把方案用起来。 系统做出来以后，要进入实际任务，观察结果是否可靠、操作是否顺手，以及有没有把负担转移给其他人。发现问题后，可能要改模型用法，也可能要改界面、数据处理或业务安排。FDE 要沿着问题继续处理，直到这段工作能够稳定进行。
最后把经验带回产品和团队。 一个项目会暴露平台缺什么，也会验证哪些做法可行。客户专有的需求需要妥善维护，有共性的能力则可以形成工具、组件或方法，让后续项目直接使用。这样，项目交付也在帮助产品成长。
这四件事连在一起，才能解释 FDE 为什么要同时懂业务和技术。它需要在整个过程中不断作判断，并为判断之后的结果负责。
业内怎样做：两个项目，看到两种关键判断
摩根士丹利：让专业人员参与建立信任
摩根士丹利的财富管理顾问需要从公司积累的大量研究资料中找到信息。它与 OpenAI 合作建设内部助手，帮助顾问检索和理解这些知识。
摩根士丹利客户案例中的交流画面。来源：OpenAI。
这个项目有一项很重要的做法：让顾问参与评价 AI 的回答，与工程团队一起改进检索和输出，并持续用测试检查系统表现。业务专家参与定义“什么样的答案够好”，使技术迭代有了明确方向。
Colin Jarvis 在以 OpenAI FDE 负责人身份参加的《Trust. Product. Impact.》访谈中回忆，团队大约用了六至八周解决主要技术难题，此后又花了约四个月与顾问一起试用、评估和改进系统，让顾问逐渐信任并使用它。（所以其实更能证明，不是企业买一个所谓的“AI产品”就代表着接入 AI 、进行智能化转型了，其实把 AI 接入现有工作流是一项复杂的工作。）
专业人员看实际结果，指出问题，工程团队修正，再让他们验证。使用者因此能够判断系统的能力，工程师也能知道下一步该改哪里。
“应用能回答问题”不是项目终点。
对 FDE 来说，使用者能否在自己的工作中用得上，才是真正的交付责任。
欧洲半导体客户：先看业务，再决定 AI 接手多深
Colin 还谈到一家未具名的欧洲半导体公司。团队先进入客户现场，了解各个业务环节，再选择芯片验证工作，也就是通过测试检查设计是否按预期工作。AI 起初协助分析测试失败的原因，得到工程师信任后，再逐步尝试修改相关代码，并运行测试检查结果。
Colin Jarvis 的《Trust. Product. Impact.》访谈封面。来源：Altimeter。
这里有两个相连的方法。先了解整段业务，才能判断在哪个环节投入最有意义；先让 AI 承担较有限的职责，才有机会在真实任务中观察能力，再决定是否扩大范围。
这种推进方式也给客户留下了学习和调整的空间。双方可以根据已经发生的结果讨论下一步：哪些工作足够可靠，哪些仍需要工程师介入，增加自动化之前还缺什么条件。项目方向因此有了证据，而不只依赖最初的设想。
FDE 的价值，落在业务真正用起来的地方
回到开头那句话：先搞清楚业务怎么跑，再想办法让 AI 接进去做。
前半句要求工程师认真理解已有的工作，后半句要求他拿出能运行、能验证、有人愿意使用的方案。做完一个项目，还要把其中可复用的经验留下来。
摩根士丹利客户案例中的会议画面。来源：OpenAI。
这类投入尤其适合有业务价值、需求尚需共同探索的问题。
Kevin Bai 在另一篇公开分享中，也强调要有选择地部署 FDE，把它用在价值高且存在不确定性的问题上。
对于已经能用成熟工具解决的需求，直接采用工具就很好；需要 FDE 时，则应给工程师接触真实使用者、理解流程和推动改进的条件。
当一家企业开始组建 FDE 团队，问题还会进一步扩大：怎样配置人才，怎样让项目经验进入产品，以及怎样承担不断增加的交付和维护工作。
下篇结合腾讯研究院的观察，继续讨论这套团队和业务怎样运转。
以上就是这次的侦察。
如果对你有用，顺手点个赞 +「♥️」。
想第一时间收到前线情报，关注「硅基斥候S01」。我们，下次侦察见。
