过去两年，企业对于AI的讨论正在发生一个明显变化。
最初，大家关心的是模型够不够聪明、参数够不够大、能不能接入最新的大模型。现在，越来越多企业开始面对一个更现实的问题：
模型已经可以用了，为什么真正创造价值的AI项目还是那么少？
斯坦福大学数字经济实验室发布的《企业AI实施手册》，研究了51个已经取得成效的企业AI项目。一个非常值得注意的结论是：决定AI项目成败的，往往不是模型本身，而是组织能否处理数据、流程、人员、权限和责任边界等一系列“看不见的问题”。
报告统计发现，77%的主要实施障碍都不是纯技术问题，而是变革管理、数据治理和业务流程等组织问题。61%的成功项目，在找到正确路径之前，都经历过一次或多次失败。
与此同时，腾讯研究院近期围绕FDE所做的行业访谈，提供了另一个来自一线的视角：当标准产品无法直接适配客户复杂的业务现场时，越来越多AI公司开始把工程师直接推到客户业务的最前线。
这类工程师被称为FDE，也就是Forward Deployed Engineer，通常翻译为前沿部署工程师或前线部署工程师。
但如果只把FDE理解成“更懂技术的实施人员”，就低估了它真正的意义。
FDE不是一个新岗位名称，而是一种解决AI落地问题的组织机制。
它要解决的核心问题是：如何把一个高度依赖客户数据、流程和知识的AI能力，真正转化为能够稳定运行、持续创造价值的业务系统。
一、为什么AI越强，企业反而越需要FDE
传统软件的基本逻辑，是先把需求抽象成标准功能，再把同一套产品卖给尽可能多的客户。
产品负责标准能力，销售负责签单，实施负责部署，客户成功负责推动使用。只要产品足够成熟，不同部门之间就可以保持清晰的分工。
AI打破了这套边界。
因为AI系统并不是安装完成就能稳定运行的标准软件。它最终能产生什么效果，取决于企业自己的数据、工作流程、行业知识、例外情况、审批机制和风险边界。
同一个模型放进两家公司，结果可能完全不同。
例如，一个客服AI是否真正有用，不只取决于它能否理解客户的问题。它还必须知道什么情况下可以直接回答，什么情况下必须转人工；哪些承诺可以给，哪些内容涉及法律风险；如何识别情绪激动的客户；如何连接订单、支付和会员系统；出现错误后，由谁负责处理。
这些知识很少完整地写在文档里。
它们通常分散在业务负责人的经验中、老员工的习惯中、部门之间的默契中，以及大量只有真实工作发生时才会出现的例外情况里。
于是，企业AI项目最困难的工作，往往发生在组织边界的缝隙中。
业务人员知道实际问题，却未必能把经验转化成系统规则；技术团队能调用模型，却不了解业务现场的异常情况；法务和风控知道风险在哪里，却不一定知道如何把风险写进系统；管理层希望AI提高效率，却无法证明AI究竟创造了多少业务价值。
传统组织中的每个部门都只负责其中一段，却没有人对“从业务问题到生产结果”的完整链路负责。
FDE的出现，正是为了填补这个空白。
二、FDE的本质，是连接现场与产品的闭环
FDE看起来像工程师，但它承担的并不只是开发工作。
它首先需要进入业务现场，理解客户真正想解决的问题。这里所谓的“现场”并不一定意味着长期驻扎在客户办公室，更重要的是进入客户的真实流程，观察员工如何工作、系统如何流转、异常如何处理，以及哪些隐性规则没有被写下来。
接下来，FDE要把这些模糊的业务经验转化为机器可以执行的系统。
客户说“重要客户要谨慎处理”，FDE必须继续追问：什么叫重要客户？由哪些数据判断？谨慎意味着必须转人工，还是需要增加一次审核？谁有权做最终决定？出现误判后如何恢复？
这个过程，本质上是在把企业的隐性知识转化为工作流、知识库、规则、评测集和异常处理机制。
但这仍然只是FDE工作的一半。
真正有价值的FDE，还必须把项目现场发现的问题带回产品团队。如果每服务一个新客户，都要重新写一套代码、重新梳理一遍流程，那么公司做的只是高成本的定制开发。
只有当现场经验能够反向推动产品变化，FDE模式才真正成立。
因此，FDE最准确的定义不是“派到客户现场的工程师”，而是：
一个连接业务现场与产品能力、并让两者不断相互学习的反馈闭环。
客户现场把真实问题反馈给产品，产品把共性问题沉淀成标准能力，再让下一次交付变得更快、更便宜、更稳定。
这也是FDE与普通外包、驻场开发和售前实施最根本的区别。
外包的目标通常是完成一个项目，FDE的目标则是在完成项目的同时，让产品本身得到进化。
三、不是所有公司都需要FDE
FDE正在成为热门概念，但它并不适合所有公司。
如果一个产品功能已经高度标准化，客户购买后几乎不需要调整就能使用，那么传统销售、实施和客户成功体系通常已经足够。强行增加FDE，只会抬高交付成本。
真正需要FDE的公司，通常处于一种特殊状态：产品已经具备一定标准能力，但距离客户真正可用，仍然存在最后一段复杂距离。
这段距离可能来自行业知识，可能来自客户独有的流程，也可能来自数据权限、系统集成、风险控制和员工使用习惯。
医疗、金融、制造、能源、政务和大型客户服务等领域尤其典型。它们的业务价值高、错误成本高、流程复杂，很难依靠一个标准化AI产品直接覆盖。
FDE最适合的，并不是完全无法标准化的项目，也不是已经完全标准化的产品，而是那些正在寻找标准化边界的业务。
假设一个AI产品已经可以解决客户70%的问题，但剩余30%决定了它能不能真正进入生产环境。这时，FDE可以进入现场，补齐最后的流程、数据和组织环节，再判断其中哪些需求属于客户特例，哪些能力值得沉淀为所有客户都可以使用的产品。
不过，要让这种模式在商业上成立，还需要一个重要前提：客户价值必须足够高。
腾讯研究院访谈中的一线从业者提到，如果客户每年的合同金额只有几万美元，就很难支撑高水平FDE长期投入。FDE不是低成本资源，它往往同时具备工程、产品、业务沟通和项目推动能力。
因此，适合FDE的公司通常具备三个条件：客户价值足够高，业务问题足够复杂，而且不同客户之间存在可以重复利用的共性。
少了最后一个条件，FDE就很容易退化成昂贵的人力外包。
四、FDE真正的考核对象，不应该只是项目交付
很多公司引入FDE之后，最容易犯的错误，是仍然使用传统项目制的方式考核他们。
项目有没有按时上线，客户是否满意，问题是否得到解决——这些当然重要，但它们只能证明一次交付完成了，不能证明公司正在形成可扩张的能力。
判断FDE是否真正有效，需要看三个更长期的问题。
第一个问题是：完成这个客户之后，公司的产品有没有变得更强？
如果客户现场暴露的问题，只存在于项目群、会议纪要和某个工程师的记忆里，而没有进入产品路线图，那么公司并没有真正学习。
第二个问题是：服务下一个相似客户时，速度有没有变快，成本有没有下降？
如果下一次项目仍然从空白文档开始，仍然需要重新访谈、重新写代码、重新设计评测，那么所谓的经验沉淀只是口号。
第三个问题是：FDE离开后，客户能不能继续稳定运行？
如果系统必须长期依赖某个工程师手工维护，客户无法自己处理常见问题，产品也无法独立运行，那么交付并没有真正完成。
这三个问题共同指向FDE最关键的能力：知识沉淀。
五、知识沉淀，不是多写几份项目文档
很多公司把知识沉淀理解成项目结束后整理文档。
但文档的数量，并不等于知识真正进入了组织。
一份只能被原项目成员看懂的会议纪要，很难帮助下一个团队；一套脱离业务背景的提示词，也很难直接复制到新的客户环境。
FDE需要沉淀的知识，至少要完成两次转化。
第一次转化，是把客户内部的隐性知识变成可执行知识。
员工口中的“通常这样处理”“这个客户比较特殊”“遇到这种情况最好问一下主管”，都需要进一步被拆解成明确的业务对象、判断条件、处理流程、权限边界和异常升级机制。
最终，这些知识不应该只停留在文字里，而要进入AI系统的工作流、知识库、工具接口、评测数据和风控机制中。
第二次转化，是把单个项目的经验变成可以跨客户复用的组织资产。
比如，一次医疗机构的AI部署，可能沉淀出一套隐私数据处理模板、一组高风险回答评测集、一套人工接管机制，以及与诊所系统连接的标准接口。下一家医疗客户到来时，团队不应该重新发明这些东西，而是从已有资产出发，只处理真正不同的部分。
这才叫知识沉淀。
它的结果不是“我们做过这个项目”，而是“我们拥有一套可以更快解决这类问题的能力”。
为了推动这种沉淀，企业需要改变FDE与产品团队的关系。FDE不能成为一个孤立的交付部门，也不能只是接收销售承诺之后负责填坑。
现场发现的问题，必须拥有稳定的通道进入产品决策。产品团队也必须有责任把反复出现的现场需求，转化为标准组件、行业模板和平台能力。
与此同时，FDE的绩效也不能只看收入和上线速度，还要看知识被复用的次数、下一次交付节省的时间，以及有多少现场方案最终进入了标准产品。
组织奖励什么，知识才会真正向哪里流动。
六、中国公司不能照搬美国FDE模式
FDE在美国受到重视，与当地企业软件市场的经济结构密切相关。
大型企业愿意为软件支付较高费用，单个客户的合同价值足以覆盖高水平工程师的投入。只要现场经验最终能够转化为标准产品，前期高成本就有机会通过后续规模化销售被摊薄。
中国市场的情况更加复杂。
许多企业客户的软件预算相对有限，却希望获得更多个性化能力。私有化部署、数据隔离、旧系统集成和定制流程又进一步增加了交付成本。
如果简单照搬“一个FDE长期服务少数客户”的模式，中国AI公司很可能陷入收入增长、人员同步增长的困境。
看起来签下了越来越多客户，实际上每个项目都需要重新投入人力。规模越大，组织越重，利润反而越薄。
因此，中国公司的FDE战略不能以全面铺开为起点，而应该以寻找可复制的行业能力为目标。
首先，FDE应该集中在少数高价值行业和灯塔客户上。
灯塔客户的价值不只在于合同金额，更在于它能否代表一类行业问题。一个理想的灯塔项目，应该帮助公司理解行业工作流、获得典型评测数据、建立风险控制模板，并验证AI能否创造可量化的业务结果。
其次，核心FDE不应该被大量客户平均消耗。
更适合中国公司的组织方式，是由少量核心FDE负责最复杂的业务探索和产品定义，平台团队负责把经验沉淀成标准能力，行业服务商和生态伙伴负责后续大规模交付。
核心FDE负责“第一次把问题做通”，平台负责“把方法做成产品”，生态负责“把产品复制出去”。
再次，中国公司需要尽早摆脱纯人力收费模式。
如果收入主要来自驻场人数和项目周期，公司就缺少减少定制工作的动力。真正健康的商业模式，应该让收入逐渐来自产品订阅、平台使用、AI调用量或明确的业务结果。
当公司因为复用能力增强而获得更多利润，知识沉淀才不再只是管理要求，而会成为商业上的必然选择。
七、中国企业还需要培养自己的“内部FDE”
FDE不只属于AI供应商。
对于大型企业来说，完全依赖外部供应商同样存在风险。因为真正决定AI效果的流程、数据和隐性知识，都掌握在企业内部。
外部团队可以帮助企业完成第一次突破，却很难替代企业长期承担流程优化、知识更新和风险治理。
因此，大型中国企业也需要建立自己的内部FDE能力。
这支团队不一定叫FDE，但应该同时理解业务、技术和组织变革。他们既能够与模型公司和软件供应商合作，又能够深入内部部门，把真实流程转化成AI系统。
外部FDE适合承担“攻坚队”的角色，快速进入现场、完成高难度验证；内部团队则需要逐渐接管知识、运行系统并持续优化。
一个健康的项目，不应该让企业永久依赖外部工程师，而应该随着交付推进，逐步把能力留在客户内部。
结语：AI竞争正在从模型竞争走向组织学习竞争
斯坦福的研究提醒我们，企业AI实施的主要障碍，越来越多地来自组织，而不是模型。
腾讯研究院的一线访谈则进一步说明，当标准产品无法直接跨越业务现场的复杂性时，FDE正在成为连接技术与价值的重要角色。
但FDE真正的价值，不在于派出了多少工程师，也不在于工程师在客户现场待了多久。
它的价值在于，能否让企业建立一个持续运转的学习闭环：
从真实业务中发现问题，把隐性知识转化为可执行系统，再把一次交付沉淀为标准产品，最终通过平台和生态复制出去。
如果每完成一个客户，产品都变得更强；如果每进入一个相似行业，交付都变得更快；如果FDE离开之后，客户仍然可以稳定运行——那么这家公司构建的就不只是一支交付团队，而是一台能够持续学习的组织机器。
FDE的终局，不是不断增加前线工程师，而是让越来越多曾经需要FDE解决的问题，不再需要从头解决。
对于中国公司而言，真正值得投入的战略也由此变得清晰：
用少量精锐团队进入现场，用真实项目找到问题，用产品化完成知识沉淀，再通过平台与生态实现规模化。
这或许才是AI从“可以演示”走向“真正创造价值”的关键一步。
参考资料：
斯坦福大学数字经济实验室，《The Enterprise AI Playbook: Lessons from 51 Successful Deployments》，2026年4月。
腾讯研究院AI透镜，《来自硅谷一线创业者的FDE非共识和落地指南》，2026年7月。