把 FDE 送进企业之后：谁救火，谁背责，谁赚钱？
“我觉得 80% 的程序员不会喜欢这样的工作，因为它确实意味着长时间出差。”神策数据联合创始人兼 CTO 曹犟在谈到 FDE 时说道。
“现场”是 FDE 价值的根源，但这种工作方式一点也不性感。为了在神策内部孵化 OmniGrowth 产品，曹犟和团队长期出差，和客户高层、技术负责人、业务负责人反复讨论，也要直接坐到一线“投手”旁边，一起吃饭、工作。刚开始，他们甚至听不懂对方大量业务黑话，只能把自己当成实习生，重新接受一遍业务培训，先学会客户怎么工作，再谈 AI 怎么改造工作。
同样的趋势也发生在
何震江团队日常强调“短平快”：上午与客户沟通一两个小时，快速了解业务场景与痛点，然后把模糊需求迅速翻译成 AI 能够理解的需求文档，然后下午做出 Demo 初稿，直接给客户看。
这次 FDE 热潮的核心，并非办公地点的改变，真正关键的是 AI 产品进入企业之后，传统售前、产品、研发、交付和售后的边界都在被重新压缩和定义。
多线程、频繁救火和“翻译”
何震江用三个关键词概括了 FDE 的日常状态：多线程、频繁救火和“翻译”。
项目评估期，一名 FDE 并行跟进三四个项目；到了签约后的深度交付期，两个项目往往已经接近上限。FDE 们一天四五场会并不罕见，但这些会议不是例行听汇报，而是业务架构确认、技术选型评审和风险对齐，每一场都要推动客户做出具体决策。
与传统交付不同，FDE 往往从售前阶段就介入，会有很多第一次面对的问题，流程失效是必然的，而 FDE 的频繁“救火”都是解决方案层面的。咨询公司可以只给方案不管落地成败，FDE 不行，“救”的是从方案到落地之间的所有断层，承诺的就必须真正实现。
而“翻译”是何震江认为 FDE 最核心的日常工作。这里的“翻译”是指把客户“我要智能化”这样的表达，拆成具体的问题，比如哪个场景、哪个模型完成、调用哪些数据、效果衡量指标等。
这也是 FDE 和传统交付最容易被混淆、又最本质的区别之一。客户提出的需求通常并不能直接变成技术任务。老板、IT 负责人、业务主管和一线员工，对“问题是什么”经常有完全不同的答案：老板希望得到一套 Agent，IT 部门首先担心系统安全和稳定，业务负责人关心效率和结果，一线员工则可能认为现有流程根本不是管理者描述的那样。
因此，有高管在安排好业务主管对接后，会反复提醒 FDE 团队“不能只听这位主管的”，因为主管和一线员工对同一个流程的理解、痛点和实操方式并不一致。如果只把一位关键人的意见当成事实，最终做出来的系统很可能在会议室里正确、到了业务现场却无法使用。
所以，FDE 进场之后的第一项工作往往不是开发，而是访谈、观察、追问和拆解。客户可能一次提出几十个场景，FDE 不能照单全收，而要从可行性、价值、重要性和 ROI 中筛选出少数 MVP。何震江所在团队通常会用一到两周筛出几个重点场景；曹犟也强调，最合适的起点往往是“最重要、能够端到端打通、范围尽可能窄”的问题。
接下来，Demo 成为一个重要的沟通工具。曹犟特别指出，Demo 的价值不是为了让客户点头，而是为了让客户能够“对着它说不”。
他解释道，传统瀑布式项目里，需求沟通结束后，客户可能两三个月才能看到大致可用的东西，但那时再发现方向偏了的话，修改成本会很高。AI 降低了原型开发成本后，FDE 就可以把“被否定”提前：先快速做出一个接近真实工作流的东西，让用户坐在旁边直接操作，然后听他指出“我不是这么干的”“这里不对”“这一步实际还有审批”等。这些否定本身，就是最有价值的需求输入。
因此，能不能听懂客户没有说出来的东西，能不能把模糊的业务语言转成技术结构，又能不能把技术限制重新翻译成客户可以理解和决策的业务选项，成为一个 FDE 更难复制的能力。
另外，FDE 也在试图把传统交付的终点继续向后推，但终点后推也意味着，FDE 在上线后仍然不能撤场，而这正是压力的来源之一。
传统交付的终点通常比较明确：系统上线、功能验收、签字回款。而在曹犟看来，AI 系统最理想的交付物不是一个静态的软件版本，而是一条“效果持续上升的曲线”。比如，系统上线时的效果可能只有 80%，但随着模型变化、知识完善、用户反馈和评估集迭代，效果会提升到 90%，甚至更高。
这就要求 FDE 在项目里承担的责任比传统“部署完成”更多。上线前，要处理数据隐私、安全、合规、回滚和模型不可用等风险；上线后，要逐步把系统交给客户，帮助客户真正用起来，并让客户最终具备一定的自主迭代能力。FDE 不能永远驻场，否则“客户依赖 FDE 个人”最终会重新滑向维保和人力外包。
实际上，整个环节中，客户情绪也是 FDE 的压力来源之一。很多 AI 项目都曾跑偏或失败，因此客户对 AI 项目的焦虑通常比对传统项目更高。同时，AI 场景往往受到企业高层关注，项目层面的客户也会因此承受压力，并把压力传递给 FDE。现在的 FDE 除了专业能力，还需要情商：既要安抚客户情绪，也要保持专业判断，不能让整个项目被情绪带着走。
“压力大并不是 FDE 独有的问题，而是整个 AI 交付行业都面临的问题。不过，如果压力出现在方案设计阶段，总好过系统上线后发生事故。”何震江说道。
出了错，谁负责？FDE 必须在事故之前回答这个问题
那实践中，如果 FDE 部署的 Agent 出了错，谁来承担责任？业内对此的答案很一致：责任不能等事故发生后再切割，而要在项目一开始就设计。
何震江所在团队会在评估阶段形成方案建议书，把技术选型、风险点和责任分工提前列出：哪些由 FDE 负责，哪些由客户负责，哪些需要第三方供应商配合；如果 FDE 建议方案 A、客户坚持方案 B，也要留下决策和风险记录。如果 FDE 建议方案 A、客户坚持方案 B，会形成一份决策存档，让后续每一步调整都能回溯到最初的判断依据，为了让专业判断能够形成完整闭环。
曹犟进一步把 AI 系统错误进行拆解，比如系统回答不准确，先要判断是模型能力问题还是上下文问题；如果是上下文问题，还要区分客户数据本身错误，还是数据正确但 FDE 构建知识库和上下文时出错。不同原因对应不同责任，无法一句“供应商全包”或“验收后与我无关”解决。
责任表、合同条款只是最后一道兜底，更重要的是把责任问题转化为产品和技术设计。机制越完整，真正发生事故后需要争论“到底是谁的错”的空间就越小。
尤其在金融、政企等强监管场景里，这类治理能力甚至可能比功能数量更重要。客户关心的不是供应商有 100 个功能还是 90 个功能，而是谁能把审批、审计、存档、回滚和兜底做清楚。AI 时代，治理本身正在成为产品的一部分，也是 FDE 能够进入高价值客户现场的入场券。
但到底是“外包”还是真 FDE？
FDE 这个岗位在国内常被开玩笑说，大多数只是给外包、售前实施换了一个名字。这个说法未必适用所有公司，却揭示出一个现实：FDE 目前在国内仍处于早期阶段，很多企业刚开始组建团队，岗位职责、面试标准、组织归属甚至商业模式都没有形成共识。
在曹犟看来，一个团队是否真正采用了 FDE 逻辑可以从下面三个维度判断：
l 考核。如果岗位直接背销售额、拿销售提成，它更接近售前或销售工程体系；硅谷 FDE 虽然薪酬高，但通常并不以销售额为考核标准。l 客户现场的经验能否反哺产品。如果项目做完就结束，产品团队不关心现场发生了什么，它仍更像传统交付。l 这次的经验能否让下次服务更容易交付。如果组织只是让工程师越来越熟练，却没有让平台、产品和知识体系变得更强，那这种效率提升仍然有天花板。
“我们避免变成外包公司的基本逻辑，是明确有些钱不赚。”何震江也指向了这点：FDE 必须围绕公司的核心产品工作，而不能为了服务费做完全脱离产品的定制开发。百度内部倾向于从自身产品体系出发、“我们的逻辑是，FDE 必须围绕公司核心产品工作，不能为了服务费做完全脱离产品的定制开发”。
这很重要。FDE 越深入客户现场，就越容易接到大量只属于单一客户的需求。曹犟解释称，比如现场发现十个需求，其中七个有通用性，三个完全不通用，但如果这三个不做客户就不买帐，那大概率仍然要把十个全部完成。因此，真正考验公司的，是后续能否用软件工程纪律把通用需求和一次性定制隔离开：哪些进入标准产品、哪些通过 OpenAPI 或独立模块管理、哪些只能留在项目层，不能让单个客户的特殊需求污染整个代码和产品体系。
因此，当前成熟的 FDE 必须服务于产品化。它允许公司为了拿下第一个行业标杆客户而做更深的场景适配，但这些适配中的共性知识必须回到平台、产品、知识库和方法论中，以便后续客户的边际交付成本持续下降。
这是 FDE 与传统外包最根本的利益差异。外包模式可以按人天收费，客户要求什么就做什么，无论结果如何，只要完成工单仍可以获得收入。而 FDE 如果真正对业务结果负责，就必须有能力对客户说“不”。有些需求即便客户愿意付费，如果它既无法产生长期价值，也无法沉淀成产品和能力，公司仍然可能选择不做。
中国 FDE 比硅谷版更重、更苦
FDE 并不是中国公司造出的新岗位。这个模式通常被追溯到由 Palantir 最早提出，之后 OpenAI、Anthropic 等 AI 原生公司也陆续设置类似岗位。但这套模式进入中国企业服务市场后，两个版本的 FDE 有所差异。
不同于 OpenAI、Anthropic 更青睐资深工程师，国内出现了不少新人甚至实习生直接挂 FDE 头衔。
曹犟对此持保留态度。他提到，OpenAI 的 FDE 岗位通常要求至少 5 年工程或交付经验，Anthropic 要求至少 4 年；Palantir 虽然已经开始招聘应届生，但前提是其产品、团队和培养机制已经高度成熟，新人入职仍然面对真实客户、承担真实责任。换句话说，FDE 可以招新人，却不意味着存在真正意义上的“入门级职责”。
他把国内新人 FDE 增多归结为几种可能：一是 To B 利润有限，企业难以支撑高薪资深人才；二是部分岗位本质仍是售前或实施，只是换了 FDE 名字；三是一些公司出现“过早 FDE 综合征”，即平台还没有形成可复用基础，对目标行业也没有足够认知，就先组建 FDE 团队，最后只能回到一次性定制交付。
何震江团队的 FDE 主要由熟悉公司产品的内部成员转型而来。原因并不仅是人才稀缺，更因为他们希望 FDE 足够了解自己的产品体系。一个真正以产品为核心的 FDE，如果连自家产品能力和边界都不熟悉，很难在现场做出快速而可靠的判断。
“中国 FDE 的工作更加辛苦，也更加复杂。”何震江说道。
他举例解释道，国内政企大客户往往要求私有化部署、国产化适配、安全审计、信创以及数据不能出域等，还需要与内部大量系统适配，调用的大模型也需要大量定制微调。国外 FDE 可以更多围绕 SaaS 产品和云服务推进，中国 FDE 往往还要同时解决本地基础设施和传统系统留下的问题。
这也使“接口失效”和“SOP 缺失”成为常态。传统软件交付可以沿着成熟流程推进，但 FDE 经常在做公司和客户都没有做过的事。比如，原来的设计可能是全自动调用客户办公系统，到了现场才发现安全要求不允许；原计划直接调用某个系统接口，真正进入内网后又发现接口不完整、权限拿不到，甚至根本没有统一数据标准。
因此，国内对 FDE 岗位能力的要求，未必会比硅谷更低，反而可能更杂、更重。
“FDE 不是万能药。”这也是受访者们反复强调的边界。
何震江团队会在 FDE 进场前做评估。如果客户组织内部没有能够提供业务上下文、参与方案讨论并推动内部协调的人，即便 FDE 能力再强，也可能变成“对着空气输出”。如果客户组织本身正在剧烈调整，业务人员抵触 AI，或者连真正决策者都没有形成共识，项目时机就未必成熟。
第二类问题是技术债。部分大型企业长期积累了复杂 ERP、CRM、办公系统和大量自研系统，来自不同厂商的系统彼此耦合，数据治理薄弱，基础设施也已经落后。这类情况并不少见。FDE 可以给出分阶段治理路线，但如果客户希望一次性把所有历史问题通过 AI 抹平，那这种现实和预期之间的差距不是 FDE 能够填平的。
第三类是预算与期望严重错配。客户可能希望同时实现几十个场景，预算却只够其中一小部分。FDE 可以帮助划分优先级，却不能“无中生有”。如果客户坚持全部都要，又不接受预算现实，最终就需要商务介入，甚至战略性放弃。
曹犟给出的判断框架基本类似，接单之前要回答：客户内部有没有真正有分量的支持者？是否愿意开放真实数据和必要权限？反馈周期够不够短？探索的不确定性由谁买单？如果这些条件都不能满足，最稳妥的选择可能不是强行使用 FDE，而是回到传统交付模式。
可以看出，FDE 需要的不只是“满足客户”，还要有拒绝客户的能力。传统甲乙方关系里，供应商往往被期待按照指令执行，FDE 模式则要求双方共同判断什么值得做。如果客户坚持强势的传统采购关系，不允许供应商介入业务判断，也不愿意提供上下文，FDE 就很难发挥价值。
这也是 AI 落地经常被称为“一把手工程”的原因。FDE 可以补足技术和产品能力，却无法替客户完成组织变革本身。没有内部支持者、没有数据权限、没有快速反馈，再强的工程师也很难凭空制造业务结果。
不“锁”人，也不“锁”模型
当厂商的 FDE 长时间深入客户系统、数据和工作流后，一个新的问题也随之出现：它是否会形成比模型更强的供应商锁定？
何震江坦诚道，更换 FDE 供应商的成本往往很高，因为被替换的不只是产品，而是一个长期理解客户业务的合作伙伴。双方长期形成的沟通、判断、踩坑和决策，并不一定能全部沉淀成结构化数据。而新供应商进入后，客户需要重新解释过去的业务背景、失败经验、约束和价值形成过程。
曹犟的观点也类似。在他看来，基础模型大家都可以用，常见工程技术栈也没有太多秘密，真正难复制的是业务认知，以及找到真问题、解决真问题并持续交付结果的运营机制。一个供应商的核心竞争力不是某个模型、某段代码，而是它如何形成产品和代码的能力，包括工作方法和长期积累的业务理解。
以 Palantir 为例，其经常被当作这一模式的代表，但 Palantir 的竞争壁垒不仅来自软件本身，还来自 FDE 工作机制以及围绕业务对象形成的本体论和行业认知。很多公司都能学习“派工程师去客户现场”，却很难复制其二十年积累下来的组织反馈回路。
这意味着，FDE 带来的商业护城河可能比单纯卖模型更深。一旦供应商通过 FDE 掌握客户最核心的业务流程，并持续把这些认知转化为产品能力、行业模板和组织知识，竞争就从“谁的模型更强”进入“谁更懂这个客户、谁更懂这个行业”的层面。
当然，这种认知积累必须有清晰的数据边界。曹犟强调，真实客户数据不能带走，客户专有知识也必须严格保护，真正能够复用的只能是脱敏后的行业通用认知。
需要注意的是，这些经验的积累不会催生出一个“不可替代的 FDE”，而是沉淀成能被公司复用的能力。客户最终信任的不会是某个 FDE 工程师，而是供应商持续理解业务、解决问题并稳定交付结果的体系。
如今，何震江团队正在尝试用 Agent 把一部分售后压力重新自动化。其原有售后团队把多年运维经验和问题处理路径开发成售后服务 Agent，部署到客户环境后，可以自动发现、排查甚至解决部分常见问题。据悉，这类 Agent 目前大约能够减轻现场 FDE 在 70%-80% 常见运维问题上的负担，剩下更深、更陌生的问题再给后台二线专业工程师。
FDE 横跨多个岗位，不代表公司真的要让一个人做完所有人的工作。相反，组织后方仍需要项目管理、测试、部署、运维、安全等高级专家，只是这些能力会越来越多地被封装成工具、Agent 等，由前线 FDE 直接调用。过去为了保证专业分工而建立的长协作链，正在被 AI 压缩成更少的人、更短的反馈路径。
何震江把这种组织能力称为打造“超级个体”背后的武器库。一个 FDE 不熟悉项目管理，组织可以提供项目管理 Agent；不擅长自动化测试，可以调用测试工具；现场出现部署问题，可以由部署 Agent 先处理。项目形成的行业知识、业务流程、方案和踩坑经验也要进入组织知识库，让后续 FDE 能够快速生成方案建议、需求表和开发设计清单。
前期“亏损”正在成为一种主动投资
花大量时间驻场、在售前阶段就投入人力，项目真的能赚钱吗？这是 FDE 从岗位概念走向规模化商业模式后必须面对的问题。
何震江把 FDE 比作“种一棵果树”。第一年买树苗、浇水、施肥，可能还没有立即结果，但不能因此判断整棵树亏损。第三年后开始年年有果子，还能结出新的树苗。FDE 在售前阶段提前投入，也是类似逻辑：成本发生得更早，回报则来自后续项目签约、持续采购、续约以及交付成功率提升。
因此，FDE 项目损益的观察周期变长了。传统项目通常从合同开始计算交付成本，售前投入相对受控；FDE 则可能在正式签约前就用一两周甚至几个月做场景验证。一个大型客户可能先小规模试用，再扩展到更多人、更多业务。国央企大客户从选型到 MVP 确定，至少要三个月并不罕见。
何震江认为，这些投入并非无条件烧钱，而是为了提高后续客户成功率，并把行业标杆场景固化成可复制能力。第一个客户承担从 0 到 1 的探索成本，后续再通过从 1 到 100 的复制逐步把投入赚回来。如果场景实现效率持续提升、客户愿意为真实价值付费，FDE 项目毛利率甚至有机会高于传统交付。
曹犟提醒，计算 FDE 成本不能只看工资，还要计算机会成本。假设三名 FDE 一年直接成本是 300 万元，并不意味着完成 300 万元合同就算打平，因为这三个人同时放弃了其他项目和研发机会。第一个项目是否值得亏钱做，取决于目标市场有多大、项目能否形成行业认知、后续是否存在足够多可复制客户。
从合同规模看，他给出的经验判断是：几十万元项目更适合标准产品和行业模板；百万级项目可以考虑在关键场景驻场，并探索“基础费用 + 效果分成”模式；更大规模、战略价值更高的项目，才更适合全周期嵌入 FDE。但合同金额只是一个表层指标，一个项目如果能帮助公司进入新行业、建立标杆、沉淀关键知识，即使第一单本身亏损也是可接受的。
于是，FDE 的经济模型天然依赖两个循环：对外服务中，一次次交付足够好的业务结果；对内，为公司带回足够有用的认知。只有两者同时转起来，前期昂贵的人力投入才有可能真正形成规模效应。
按结果付费听起来很美，但还没有准备好
一定程度上，目前国内的 FDE 模式还没有完全转成正收益。而 FDE 之前被行业看好的“按结果付费”（RaaS，Result as a Service）模式，进展也远远不如预期。
何震江团队尝试过按效果付费，但遇到的现实问题很难支撑。效果必须有硬指标，但数据通常掌握在客户自己的系统里；项目开始时，客户可能同意按照某个指标付费，但项目做完后数据口径可能发生变化。因此，他们现在更倾向于先挑一两个客户最关注、又容易做出明显效果的场景，快速证明价值，再通过产品 License、单场景费用、效果费和人力服务费的组合，形成混合收费模式。
曹犟观察到的情况类似。目前市场上已经出现按座席订阅、全托管、业务增量分成等不同尝试。
他解释称，理论上 RaaS 可以让甲乙双方利益更一致，但最大的阻力不全来自技术，而来自采购制度和信任结构。银行等大型机构的采购体系长期围绕软件、人天和明确 SOW 建立，新的收费方式很难直接进入现有流程。与此同时，Agent 究竟能带来多少增量，甲乙双方都没有足够长的历史数据，很难被精确归因。
未来更可能发生的，是组织被重新压缩
FDE 热起来之后，很多人开始用“外置 CTO”“超级工程师”来定义，甚至有更细分的“前线部署产品经理”等新角色出现。
曹犟对此并不赞同。他认为，AI 正在降低许多原有职能的执行成本，组织趋势应该是角色减少、链路缩短，而不是在每个旧岗位前面再加一个“前线部署”前缀。优秀的工程师和业务人员借助 AI，已经能够完成过去需要多角色协作才能完成的工作，产品经理、工程师、设计师之间的边界本身就在变化。
何震江团队的实践也体现出这种趋势。FDE 进入售前后，会和 SA 产生交集；进入交付后，又会与项目经理、技术架构师、测试、部署和售后运维等角色发生融合。但融合并不等于所有岗位消失，而是很多标准化工作被工具和 Agent 接管，前线人员把更多时间用在客户判断、方案设计、价值验证和关键责任上。
SA 仍然需要负责产品和架构层面的总体方案，让客户中高层相信产品能够实现愿景，并推进投标和签约；FDE 则在需要 POC 或场景验证时进入现场，面向真实业务人员，把抽象愿景变成可验证结果。产研团队负责更底层的平台和产品能力，FDE 把现场问题及时反馈回去。行业标杆场景从 0 到 1 跑通后，再有机会交给传统交付团队从 1 复制到 100。
因此，未来的可能趋势是：高度标准化、可自动化的工作逐渐被工具吸收，那些需要业务判断、跨部门协调、品味、决策和责任承担的工作，则被更集中地压到少数前线角色身上。
结束语
现在，人重新回到了 AI 商业化最关键的位置。只不过这个“人”不再只是销售，也不只是交付工程师，而是被要求同时理解产品、业务、技术和组织，并对结果承担更长周期责任的 FDE。
这不是一个轻松的活。长期驻场、频繁出差、多个项目并行、上线前救火、客户焦虑、内部协作和持续学习，都是 FDE 职业体验的一部分。
何震江也观察到，一些长期高压的同事会出现注意力下降、对客户问题失去敏感度等倦怠信号。因此，团队会通过项目轮换降低认知负荷：如果有人连续几个月处在高强度项目中或者长期驻扎地环境较差，就会安排过渡期，让其进入相对偏评估性质的项目。另一方面，只要每个客户的问题仍然不同，FDE 也能不断获得新的学习曲线，这种成长感又会成为岗位吸引力的一部分。
除了技术深度、能力广度，曹犟认为真正决定一个人是否适合长期做 FDE 的，往往是软素质：有人与客户沟通一天会觉得被耗尽，有人却会从这种交流中获得能量。
而从更长期看，FDE 这个名字未必会永远存在。
只要 AI 能力边界与真实业务需求之间仍有鸿沟，就总需要有人去弥合它。名字虽变，但那个被迫在业务现场和技术机房之间来回跑、同时听懂代码和业务黑话的人，短期内不会消失。
本文来自微信公众号“InfoQ”（ID：infoqchina），作者：褚杏娟，36氪经授权发布。
