趋势推动
客户现在问的问题，已经很少停留在“你们产品有没有这个功能”。尤其在 AI、安全、数据平台、Agent 这类场景里，客户更关心：能不能接进现有SOC平台，如何评判误报漏报，AI的分析结论置信度如何，大模型的幻觉问题如何缓解，现有的安全运营流程能不能做出skill接入，效果怎么量化。
客户需要的已经不再是一次次产品讲解和demo演示，是今天能不能帮他把误报率压下来，把真正的攻击链挑出来。
技术演示已经不能解决流程、责任、数据和组织协同这些真实问题。甚至产线已经验证可用的用例，切换到客户真实环境，跑出来的效果也不一定能完全复现，除了模型本身的差异之外，还有数据、工具、接口、流程等一系列运行环境的差异。
作为在客户现场的一线售前，这个时候往往是乏力的。客户反馈的需求场景是真实存在的，产品目前的能力又无法满足，那如何连接这两端的断层，怎么找到切入点，能够把项目再往前推起走。
此时的售前，已经不能只看产品、讲产品、测产品，还需看产品如何在客户场景中落地。
需要诊断：客户说的"研判得对不对"背后，到底是规则库覆盖不全，提示词写的不完善，还是数据源本身就缺失关键日志。
需要设计：提供关联补充哪些数据，可以提供给AI Agent进行推理分析，给出切实可信的证据依据，而不是白皮书里的理想架构。
需要验证：产品在客户环境里能不能真的稳定运行，而不是POC环境里跑得漂亮。
此时的售前，实际上已经越过了"讲产品"和"卖方案"的边界，站到了"解决问题"的位置上。被逼之下，如果真的用AI Agent跑通了这个场景用例，那么他就不仅仅是个售前了，就已经是名初级的Forward Deployed Engineer，前线部署工程师。
* *
什么是FDE
FDE（Forward Deployed Engineer），即"前沿部署工程师"或"前线部署工程师"，源自 Palantir 最早设立的驻场交付工程师岗位。
岗位定位
不是单纯的售前、实施、外包或客户成功中的任何一个角色，而是把这四类角色的职能融合在一起：产品经理的终点是"功能上线"，售前的终点是"签单"，实施外包的终点是"验收"，客户成功的终点是"续费"——这些角色的终点，正是 FDE 的起点。FDE 不设能力边界，直接对客户的转化结果和人效负责，通常按结果付费。
组织上，很多公司都把 FDE 设为独立部门，不隶属于产品、工程或销售任一部门。
Palantir 早期的 FDE 分为三类角色：Echo（偏行业专家咨询、客户沟通）和Delta（偏落地开发、工程实现），第三个角色是Dev（核心研发工程师），当 Echo 和 Delta 在前线攻坚，为单个客户跑通了业务闭环（内部称为铺设“碎石路”）后，留守总部的 Dev 会提取这些定制化方案中的共性规律，将其抽象并沉淀为标准化的通用平台能力（修筑“柏油马路”），从而不断反哺核心产品线。当时没有 AI 加持，工程师需要身兼多能，是极稀缺的"六边形战士"，起源于军方项目的驻场模式。
FDE 这个概念本身早于 AI 存在，只是 2024–2026 年 Agent/AI 能力爆发后，现场工程师能以极短周期完成价值验证闭环，才让 FDE 模式迎来爆发式增长。
在当下的语境里，FDE 本质上是一种"熟练使用 AI 完成业务落地"的能力，而非一个固定岗位。
* *
区别与联系
售前与 FDE 前线部署工程师两者都面向客户，都需要理解业务需求，都要协调销售、产品、研发和交付团队，也都可能参与方案设计、技术验证和现场问题处理。尤其是在国内的软件和网络安全行业，许多资深售前实际上已经承担了大量超出传统售前边界的工作，因此很容易得出一个直观判断：FDE 不过是一个更偏技术、更会写代码、参与项目更深的售前。
但这也只是表面看起来如此。
如果从客户价值来看，售前主要负责发现需求、构建方案、证明价值和推动成交，解决的是“为什么应该买，以及这套产品原则上能不能解决问题”；而FDE 则进一步进入客户的真实业务与生产环境，负责把已经被证明“理论上可行”的东西，变成一个能够长期运行、可以被验收、能够产生业务结果的系统，解决的是“怎样才能让它在这个客户的真实环境中真正工作”。
因此，FDE 中的“前线部署”并不只是去客户现场安装系统。“前线”，意味着直接面对未经整理的真实问题，“部署”也不仅是安装和配置，还需将产品能力部署进客户真实的业务运行中并稳定运行起来。
表面上，客户说的是“我们希望用 AI 提升安全运营效率”。实际上，FDE需要思考，客户所谓的效率问题究竟来自告警数量太多、上下文数据不足、人工取证耗时，还是审批与协同流程缓慢；客户希望 AI 给出建议，还是希望 AI 可以直接调用工具执行处置；哪些动作允许自动执行，哪些动作必须由人工确认；错误判断的业务代价是什么；系统上线后通过什么指标证明它有效。
虽然售前也经常参与以上问题的讨论，但工作的终点却与FDE大有不同。
售前会进行需求调研、方案设计、产品演示、竞争分析、POC 测试和投标应答。售前最终要证明的是，厂商具备解决问题的能力，产品能够覆盖主要需求，方案在技术上是合理的，项目具有建设价值。
FDE 则不能停留在“具备能力”或者“测试通过”的层面，还要继续面对生产环境中的复杂性，并对系统能否稳定产生结果负责。POC 阶段可以选择一批质量较高、字段完整的样本，但生产环境中可能每天都会出现数据缺失、格式变化、接口超时和资产错配。演示阶段可以人工准备上下文信息，但实际运行时，系统必须自动从多个数据源中找到证据。
FDE 的成功则必须进一步表现为系统进入生产环境以后能够持续运行，客户的业务流程发生了真实改善，项目产生了可以被量化的结果，而且项目中的有效经验能够被沉淀下来，而不是每次面对新客户都从头开始。
这也是售前与 FDE 在“资产沉淀”上的根本区别。传统售前项目结束以后，可能留下方案文档、演示环境、测试报告和客户需求清单。这些成果对后续销售有价值，但多数仍属于知识性资产。FDE 更强调将项目经验沉淀为工程资产和产品资产，例如标准连接器、行业数据模型、工作流模板、评估数据集、自动化测试脚本、部署工具、权限策略、监控机制和失败处理框架。
例如，某银行客户要求 AI 安全运营平台在研判过程中同时查询主机安全平台、SOC、CMDB、身份系统和工单系统。对于单个项目而言，FDE 可以逐一完成接口对接。但如果每个银行项目都重新开发一遍，这种模式就无法规模化。成熟的 FDE 团队会继续抽象这些集成需求，形成统一的工具协议、数据标准和连接器框架，使后续项目只需要配置地址、认证信息和字段映射，而不需要重新编写全部代码。
此外，FDE 处在一种天然矛盾中。一方面，必须足够贴近客户，为客户解决具体问题；另一方面，又不能完全被客户牵引，演变为没有边界的定制开发团队。如果每一个客户提出的需求都被直接实现，产品会迅速碎片化，FDE 也会沦为高成本实施团队。优秀的 FDE 必须具备强烈的产品判断能力，能够区分哪些问题应该通过标准配置解决，哪些需要开发扩展，哪些值得进入核心产品，哪些需求应该明确拒绝。
从这个角度看，售前和 FDE 其实承担了两种不同形式的边界管理。
售前管理的是客户预期与产品能力之间的边界，要避免为了赢单而过度承诺，也要将复杂技术能力转化为客户能够理解的业务价值。FDE 管理的是客户个性化需求与产品长期演进之间的边界，既不能机械地坚持标准产品，也不能无限满足定制需求，而要在项目成功和产品可复制性之间找到平衡。
虽然从上面的讨论中可以看到，售前和FDE存在明显差异，但也会有很深刻的联系。
两者都不能只懂技术而不懂客户。客户通常不会用准确的技术语言描述真正问题，他们给出的需求可能只是表象。例如，客户提出“希望接入大模型”、“希望自动生成安全报告”，背后真正的问题可能是管理层无法了解运营效果、分析人员缺乏上下文、现有流程无法形成闭环。无论是售前还是 FDE，都需要穿透表面需求，识别客户真正希望改变的业务结果。
两者都需要具备跨角色沟通能力。在企业项目中，业务负责人关心价值和效率，技术负责人关心架构与稳定性，安全负责人关心风险与合规，采购部门关心价格和责任边界，一线使用人员关心系统是否增加工作量。售前需要在这些角色之间建立共同认知，FDE 则要进一步把这种共识落实为系统设计和运行机制。
此外，两者都需要很强的现场判断能力。客户项目中的信息很少是完整的，不同部门给出的描述甚至可能互相矛盾。售前要判断哪些需求是真需求，哪些只是竞争性指标，哪些承诺可能带来巨大交付风险。FDE 则要判断哪些现场问题源于产品缺陷，哪些源于数据质量，哪些属于组织流程，哪些应该通过工程方案解决，哪些必须要求客户改变现有机制。
售前与 FDE 最理想的关系不是互相替代，而是形成连续的客户价值链。售前负责在项目早期识别问题、建立价值共识、完成方案设计和关键假设验证。FDE 应当在商机中后期就适度介入，而不是等合同签订后才被动接手，可以提前评估数据可用性、系统集成难度、工程风险和生产约束，避免售前方案与真实现场之间出现巨大落差。
进入落地阶段后，FDE 应当成为产品、研发和客户技术团队之间的主要工程接口。售前仍然可以参与关键沟通，帮助维持客户预期和价值目标，但不应继续承担全部生产问题。项目运行稳定以后，FDE 再将共性能力交还产品团队，将日常运营交给客户成功、实施或售后团队，同时把形成的案例和资产反馈给售前，用于后续市场复制。
这条链路可以理解为：售前让项目值得开始，FDE 让项目真正成功，产品研发让这种成功能够规模化复制。售前负责把客户需求转化为一个可购买的方案，FDE 把方案转化为一个可运行的系统，产品团队再把现场形成的有效机制转化为标准产品能力。
* *
成为FDE
从职业能力角度看，售前向 FDE 转型并不意味着放弃原有优势，而是在原有客户理解和方案能力上补齐工程闭环。
售前通常已经具备需求发现、方案表达、跨部门协调和客户沟通能力，这些恰恰是许多纯研发人员转型 FDE 时最缺乏的能力。研发人员可能能够快速完成代码开发，却不一定擅长从模糊表述中识别真正需求，也不一定能够在客户压力、商业目标和技术边界之间做判断。
只是，售前更需要补充的主要是更深入的软件工程、数据工程、系统集成和生产运营能力。需要能够理解 API、数据库、消息队列、权限模型、异步任务和异常处理，而不只是知道产品提供了哪些接口；需要能够建立测试集、回归机制和验收标准，而不只是完成一次 POC；需要关注系统运行后的延迟、成本、稳定性和可观测性，而不只是演示结果；还需要培养将客户需求抽象为通用能力的产品思维。
就目前而言，AI Agent、企业级生成式 AI、决策智能系统和 AI 安全运营平台通常更需要 FDE。因为这类产品的价值高度依赖客户自己的数据、工具、流程和组织机制。厂商无法在产品研发阶段提前完成所有集成，也无法仅靠标准安装流程解决全部问题。客户购买的不是一个完全封闭的标准软件，而是标准产品能力与现场工程能力的组合。
另外，一个组织不能只把售前改名为 FDE，就认为已经建立了 FDE 能力。真正的 FDE 体系需要相应的组织条件：
首先，FDE 必须能够直接与产品和研发团队协作，而不是只能通过需求流程间接沟通。其次，FDE 需要拥有一定的工程开发权限和环境访问能力。还有，FDE 的考核不能只看合同金额，而应关注上线时间、使用深度、业务结果、客户扩展和资产复用。最后，组织必须允许 FDE 将一部分时间投入共性抽象，而不是要求其全部时间都服务于当前项目。
* *
总结一下，售前和 FDE 的区别可以归结为四个问题。
第一，谁对生产结果负责。
第二，谁有权改变系统或开发扩展。
第三，谁需要长期进入客户真实环境。
第四，谁负责将一次性项目经验沉淀为可复用的产品资产。只
售前站在产品与市场之间，将技术能力转化为客户能够理解和购买的价值；FDE 站在产品与客户生产现场之间，将已经被购买的价值转化为可以运行和验证的结果。
售前证明产品能够解决问题，FDE 确保问题在真实环境中被解决。
售前的优秀表现可以带来一个合同，FDE 的优秀表现则可以带来一个真正成功的客户、一个可复制的行业方案，以及下一代产品能力。
* *
附录：
https://github.com/pierpaolo28/Awesome-FDE-Roadmap
https://www.forwarddeployedengineer.site/
