企业 AI 正在经历一个有些反直觉的阶段：模型越来越强，应用搭建越来越快，但真正进入生产、改变业务流程的项目并没有同步增加。很多团队已经能在几天内做出令人惊艳的 Demo，却仍要花几个月处理数据、权限、审批、异常、责任与用户采用。技术的进步没有自动消除“ 最后一公里 ”，反而让这段距离变得更清晰。

FDE （Forward Deployed Engineer）因此受到关注。但如果只把它理解为一种新岗位，或者更懂 AI 的驻场工程师，就会错过它真正值得讨论的部分。FDE 试图重做的是企业 AI 的交付机制：一支贴近客户现场的小队，既要把业务结果做出来，也要把现场经验带回产品，让下一次同类交付变得更快、更便宜、更稳定。

本文以腾讯研究院《FDE 模式行业观察与实践》公开商业版 v5.0 为主要事实底稿，并结合相关 FDE 实践材料，对报告的核心逻辑做了重新编排。全文沿五幕展开：先解释企业 AI 为什么失速，再定义 FDE 的责任结构，随后讨论产品杠杆、 证据飞轮 ，以及支撑规模化的组织与治理。

01 真正的问题，不是第一个项目有多难

判断一支团队是否建立了 FDE 能力，不能只看它能否攻下第一个客户。第一个项目天然需要探索，投入高并不奇怪；真正的问题是，第十个相似客户到来时，团队是否仍要重新投入同样的人月。如果成本没有随着经验积累而下降，所谓“ 前线部署 ”就只是更昂贵的项目制。

P01｜把一次性交付变成可复制的产品杠杆

02 五个问题，指向同一个经营命题

Demo 无人使用、交付无法降本、前线不愿反馈、客户不知道自己在买什么、Agent 压缩人的执行价值——这些看似分散的问题，其实都在追问同一件事：企业如何把现场的不确定性转化为可积累的组织能力。FDE 的意义，也只能放在这条转换链上理解。

P02｜五个开场问题

03 一次项目，必须同时产生两个结果

FDE 的总答案可以压缩成两条方向相反、但必须同时成立的结果线。向前，它进入真实数据、系统、流程和组织，交付可使用、可衡量的客户结果；向后，它回收接口、异常、评估和行业模式，沉淀为 Skill、连接器、模板、测试集或语义层。只有前者会退化为项目制，只有后者则会让平台脱离真实业务。

P03｜客户结果与产品资产

04 五幕故事，其实是两条线的交织

接下来的五幕，一条线始终围绕客户结果：为什么 Demo 失速、谁拥有完整责任、如何完成部署与激活；另一条线始终围绕产品杠杆：现场经验如何变成资产、如何形成规模效应、如何通过组织和激励持续运转。FDE 就发生在两条线不断交汇的地方。

P04｜五幕故事地图

05 模型已经抵达，组织还没有

企业 AI 的最后一公里并不是一个单纯的技术尾项。模型能否完成任务，只是起点；数据是否可用、系统能否连接、权限由谁批准、异常由谁接管、员工为什么愿意改变习惯，才决定一个方案能否真正进入生产。项目卡住时，缺少的往往不是更强的模型，而是一条能够承担完整结果的闭环。

P05｜第一幕：从 Demo 到生产

06 模型与组织之间的剪刀差正在扩大

模型能力以季度为单位跃迁，应用开发门槛持续下降；组织中的数据治理、审批制度、流程责任和用户习惯，却往往以月甚至年为单位改变。报告引用的时间截面显示，企业尝试生成式 AI 的比例很高，但大量项目仍停在试点阶段。招聘与企业动作也说明，市场正在为这段剪刀差寻找新的连接角色。相关比例和招聘数字具有明确采集窗口，使用时应按最新公开信息复核。

P06｜模型能力与组织采用的剪刀差

07 越接近生产，问题越不像“ 调模型 ”

从 0 到 80 分，通用模型和 Prompt 往往能快速制造惊喜；从 80 到 95 分，项目开始面对术语歧义、脏数据、冲突样本与版本管理；从 95 到 99 分，则进入权限、审计、合规、监控和回滚。最后无法被概率模型完全消除的风险，还需要人工复核、拒答、降级和接管。生产化不是追求一个虚假的 100%，而是建立一套可托付的系统。

P07｜80、95 与 99 的陡坡

08 客户真正购买的是“ 事情被做完 ”

模型 API、软件席位和工程师人天都只是供给形式。客户真正想要的是一个稳定完成业务任务的闭环：模型要连接数据和工具，工具要受到权限控制，结果要能够评估和审计，异常要有人接管，流程还要对应明确的指标与责任。正确率、速度和自动化率只有继续翻译为复核减少、触达提升或风险变化，才构成业务价值。

P08｜企业购买的是业务闭环

09 “ 加一个 AI 功能 ”与 AI Native 是两条路

在旧流程上外挂 AI，启动快、阻力小，很适合问答、摘要和内容生成，但也容易在新鲜感消失后被放弃。AI Native 则要求重新设计工作流、权限、人机分工、绩效乃至产品形态，前期更复杂，却更可能产生结构性价值。更现实的推进方式不是要求所有客户同时变革，而是先与少数愿意改变的头部客户跑出结果，再把经验沉淀并扩散。

P09｜外挂式 AI 与 AI Native

10 第一幕的结论：瓶颈已迁移到生产责任

当模型“ 能做 ”而组织“ 不敢用 ”，真正缺失的是一条跨越售前、实施、产品和客户成功的责任链。谁定义真问题，谁保证系统稳定，谁推动用户采用，谁又把失败样本带回产品？如果这些责任被分散在多个部门之间，任何一个团队都可能完成自己的任务，但项目整体仍然失败。

P10｜第一幕结论

11 FDE 是一种责任结构

“ Forward ”不是简单地去客户现场，而是直接面对真实问题和真实约束；“ Deployed ”也不只是完成安装，而是让模型、数据、系统、流程、权限、指标和人工兜底共同运行。FDE 因此不是驻场工程师的时髦改名，而是一种对问题、技术与结果同时负责的前线组织。

P11｜第二幕：角色与所有权

12 交付、采用与学习必须成为一个闭环

传统实施通常把上线当作终点，FDE 则把上线视为中间状态。它要先理解客户原话背后的真实问题，再让系统进入稳定运行，随后推动工作方式改变，并把项目中出现的共性、接口、测试和失败模式带回平台。结果和资产必须在同一条链路中发生，否则只是把原有岗位重新命名。

P12｜重新定义 FDE

13 传统岗位的问题不是能力不足，而是终点不同

售前通常止于 Demo 与签约，实施止于配置和验收，产品关注标准功能，客户成功关注使用与续费，咨询顾问负责诊断和建议。每个角色都可能很专业，但没有人天然拥有从模糊问题到业务结果、再到产品反哺的完整闭环。FDE 不需要替代这些岗位，而是把断开的责任重新组合成一支能够运转的小队。

P13｜传统岗位的责任断点

14 单线程负责人，不等于全能超人

FDE 不必亲手完成所有任务，却必须同时拥有三类所有权：问题所有权，确保团队解决的是真问题；技术所有权，确保方案能够运行而非停在建议；结果所有权，确保系统被采用并产生价值。产品、安全、数据和行业专家仍然按需介入，但 FDE 保留上下文、统一决策，不能用“ 我的部分已经完成 ”解释整体失败。

P14｜问题、技术与结果所有权

15 不是所有复杂项目都值得重 FDE

业务复杂、工程复杂和组织复杂，只能说明项目难，并不能证明重投入合理。最后还要通过“ 可产品化 ”这道门：现场问题背后是否存在跨客户的行业共性？如果每个客户都完全不同，探索成本无法被未来客户摊薄；如果标准产品或培训已经足够，也没有必要动用高密度前线团队。

P15｜复杂度与产品化门槛

16 Echo、Delta 与 FDPM 构成最小前线单元

Echo 负责发现值得解决的问题，理解行业、价值与组织阻力；Delta 负责原型、集成、评估和生产，把事情真正做出来；FDPM 则守住范围、测试、预期和项目推进。三者首先是能力组合，不一定从第一天就对应三个岗位。只有 Echo 会停在咨询，只有 Delta 容易把伪需求做得很完整；两者都有却没有资产机制，项目仍然无法复制。

P16｜Echo × Delta × FDPM

17 工具越强，价值判断越需要前置

AI Coding 、自然语言构建和 Agent 显著降低了原型与适配成本，却没有替代业务理解。一个场景仍要依次跨过四道门：理解业务问题、翻译成 AI 任务、完成 0→1 原型、完成 1→N 优化与复用。工具主要加速第三道门，因此“ 做什么值得 ”“ 怎样衡量结果 ”反而要更早被回答。

P17｜AI 改变三项成本

18 第二幕的结论：小队必须拥有全链路

一个完整的 FDE 小队，要连续拥有问题、生产、采用和反馈。它既能找对问题，也能让系统稳定运行；既能推动行为改变，也能让经验进入资产。到这里，新的经营难题随之出现：高密度前线小队越能解决复杂问题，会不会越依赖明星人才，最终变成没有软件毛利的人力生意？

P18｜第二幕结论

19 第一个项目可以贵，第十个不能一样贵

FDE 模式是否成立，最终要接受成本曲线的检验。首个项目可能同时承担客户交付和产品探索，因此毛利较低并不必然错误；但同类客户不断增加之后，现场工时、上线周期和对少数专家的依赖必须下降。否则，收入增长只是在同步扩大人力投入。

P19｜第三幕：杠杆

20 现场经验要向两个方向蒸馏

一次项目至少产生两种知识。面向客户，经验被整理为知识库、工作流和 SOP ，让业务执行更加稳定；面向厂商，场景、接口、异常和失败被沉淀为 Skill、模板、测试集和连接器，让下一次交付更便宜。前者提升客户能力，后者形成产品杠杆。只有第一种蒸馏发生，团队仍会困在重复劳动中。

P20｜双向蒸馏

21 项目结束后留下什么，是最直接的测谎题

只留下客户系统，更像外包；经验带回了公司却无法复用，仍然是项目制；经验进入 Skill、模板、测试集或产品能力，才开始具备 FDE 特征；当同类项目周期缩短、新人更快上手、伙伴能够交付、客户逐步自助，规模化才真正发生。这个四级测试比岗位名称更可靠。

P21｜FDE 的四级规模化测试

22 资产必须从证据逐级长出来

成熟资产通常不是一开始就设计出的完整本体，而是沿着证据阶梯生长：先留下高频 Skill 和接口经验，再形成连接器、模板与测试集，随后扩展为行业知识库和轻量语义层，必要时才进入完整本体。平台的“ 第二用户 ”是 FDE；如果权限、评估、监控、版本和资产检索让前线都难以使用，客户更不可能自助。

P22｜从项目证据到完整本体

23 FDE 与产品经理之间需要一种健康张力

FDE 纵向打穿具体客户的完整闭环，产品经理横向观察跨客户共性。现场需求可以有三种归宿：客户专属能力留在客户层，多客户相似但规则不同的需求变成可配置能力，广泛且稳定的需求才进入核心产品。FDE 追求现场速度，产品经理守住产品边界，这种张力不是协作失败，而是避免平台被单一客户拖走的必要制衡。

P23｜FDE、产品经理与核心研发

24 Palantir 的启示是机制，而不是外形

Palantir 证明了一个重要可能性：重交付并不必然等于低毛利，只要高复杂现场持续把知识送回平台，统一业务语言和 Ontology 又能反向降低未来交付成本，前期投入就可能转化为软件型杠杆。图中的累计成本曲线是报告的趋势示意，不是行业保证；真正值得学习的是反馈链、平台吸收和反向降本的组合。

P24｜Palantir 的成本杠杆逻辑

25 中国团队应复制机制，而不是复制厚度

国内企业的数据与流程标准化程度、客单价、审批方式和组织协作习惯都与海外大客户不同，机械复制高人才密度和重本体模式往往算不过账。更现实的路径是从高频 Skill、标准连接器、行业知识库、轻量语义层和明确的反馈版本机制开始，同时用自然语言、AI Coding 和 Agent 降低交付成本。

P25｜中国市场的轻量化路径

26 延迟收益必须经过三道门

首客的额外投入可能用于抽象知识、完善版本、验证测试、编写指南和准备伙伴培训，但不能把所有低毛利都包装成“ 战略投入 ”。延迟收益至少要证明三件事：客户值得深耕，项目能够沉淀，公司具备复用能力。长期衡量的也不是资产数量，而是客户成果价值与单位价值对应的现场投入是否持续改善。

P26｜首客投入与延迟收益

27 第三幕的结论：现场必须改变成本曲线

双向蒸馏把现场变成证据，资产阶梯让证据逐级进入产品，最终结果应体现为工时下降、周期缩短和毛利改善。到这里，FDE 不再只是一种英雄式交付方式，而是一台有机会产生产品杠杆的发动机。下一步，是把这台发动机拆成可执行、可评估、可版本化的生产系统。

P27｜第三幕结论

28 证据不是复盘附件，而是产品化原料

一线经验只有经历“ 假设—证据—版本—复用 ”，才会从个人体感变成组织资产。客户提出的每个特殊需求都应被视为一个待验证假设：它是客户个性、行业共性，还是产品缺口？只有被结构化记录、跨项目验证并进入版本系统，经验才会缩短下一次交付。

29 从 Demo 到生产，需要四类证据

理解业务不能只交功能清单，要留下链路、角色、指标和异常假设；协同构建不能只交演示视频，要有可运行原型、近真实数据和共创记录；质量评估不能依赖一次主观体验，要形成测试集、方法版本与人工兜底；业务验证则要与人工或历史基线逐环节对照。Demo 是风险探针，不是缩小版生产系统。

P29｜从 Demo 到生产的四类证据

30 写代码之前，先完成问题—方案匹配

一个问题“ 很痛 ”不代表值得做。团队要先确认具体是谁、在什么场景、执行什么动作、承受何种损失；随后计算工时、成本、错误损失以及效率释放后的去向；最后确认权威数据、质量门槛与人工护栏。MVD 可以缩小范围，但不能缩小价值：哪怕只处理一种工单，也必须从真实输入走到真实业务结果。

P30｜PSF 到 MVD

31 L1 到 L2，是最容易被低估的死亡谷

L0 是场景识别，L1 是原型验证，L2 才进入试点运行，随后还有生产部署和规模扩展。大量项目在原型之后失败，因为真实用户不承担使用指标、脏数据在环境中集中暴露，或者审批、权限和合规从未打通。Demo 成功只说明某个技术假设成立，不代表业务系统已经具备运行条件。

P31｜L0—L4 项目成熟度

32 评估不是开发后的验收

概率系统无法只靠传统功能测试管理。业务层要看北极星指标，系统层要看评估集是否进步，行为层要看用户是否真用；黄金集、异常场景集和安全对抗集共同构成版本基础。一旦分数达到新台阶，就应成为后续版本的新地板。FDE 负责评估机制与回归纪律，客户负责业务口径、期望答案和最终价值判断。

P32｜评估驱动开发

33 小切口要同时埋下扩展的种子

Land 并不意味着挑一个无关紧要的小场景，而是选择高管优先、结果可测、业务负责人参与，并且存在相邻流程或同类客户的高价值楔形切口。从第一天起，数据结构、权限设计、评估方法和资产归属就要为相邻流程、相邻部门与同类客户预留空间。Expand 不是上线后的销售补救，而是首日就开始的系统设计。

P33｜Land & Expand

34 上线是技术状态，激活才是业务状态

一个系统上线后，需要经历首用、稳定使用、客户接手，最终在 FDE 撤场后仍能运行。期间要像处理线上事故一样响应热修复，把入口嵌入既有工作台，让投诉和修改进入评估集，为一线、管理者与审计角色设计不同体验，并培养客户内部支持者。三个月后无需催促仍被高频使用，才接近真正部署。

P34｜部署不等于激活

35 行业产品化，要跨过五个阶段

冷启动阶段先做 70 分的最小资产；首个客户验证共性、可选项与个性；第二到第四个客户建立反馈分级、版本和回归；第五到第八个客户检验工时、周期和伙伴承接能力；成熟期则以配置为主，原厂转向新行业。方法可以复用，但实体、关系、权限、测试集与合规边界不能直接平移。

P35｜行业 A—E 五阶段

36 第 5—8 个客户，是规模效应的验收窗口

报告用一个虚构的 ERP 案例演示规模效应：随着本体、指南、模板和连接器开始工作，Delta 工时、上线周期和新增反馈逐步下降，毛利率随之提升。这些数字是方法演示和估算值，不是行业基准。它们真正提供的是一套验收思路：资产是否正在减少重复劳动，而不是仅仅让资产库变得更大。

P36｜ERP 规模效应示意

37 反馈必须成为正式生产线

“ 项目结束后记得总结 ”无法支撑产品化。前线反馈应通过结构化反馈单进入评审：高通用问题进入下一版本，需要更多证据的等待两到三个客户验证，客户个性则留在客户层。每次发布要有日志、指南和适用范围，并回归既有路径，防止修复一个场景却破坏另一个场景。反馈还必须与绩效和奖励相连。

P37｜反馈、评审、版本与回归

38 长期形态不是原厂包办一切

原厂最适合跑通 0→1，建立标杆、平台资产、标准和认证；伙伴通过模板、Skill 与连接器完成 1→N 的行业和地域复制；客户则逐步获得配置、轻定制与日常运营能力。平台层、工具层和生态层只有进入同一条回流链，扩张才不会切断产品学习。

P38｜原厂、伙伴与客户的生态接力

39 交付增长，可能同时积累资产，也可能积累债务

如果客户越多，现场团队越忙，而平台资产、伙伴能力和客户自助率没有同步提高，增长只是在累积交付债务。第五幕关注的不是如何再做一个成功项目，而是如何通过组织形态、绩效、经营指标、专业边界和人才路径，让客户结果与产品资产长期保持平衡。

P39｜第五幕：治理与规模

40 组织形态可以不同，双结果责任不能缺席

特种单兵适合 CEO 一号工程和标杆突破，但容易依赖个人；业务专家与全栈开发组成的“ 双人舞 ”适合常规迭代和规模推广，却可能出现绩效割裂；混编纵队适合多供应商的大型项目，但必须有内部锚点。无论采用哪种阵型，都要明确前线的客户结果负责人和后方的平台资产负责人。

P40｜三种 FDE 阵型

41 信任也是部署基础设施

企业项目不仅存在系统依赖，也存在权力、利益和风险感知。团队需要识别谁能拍板、谁能否决、谁会拖延、谁能放大结果，以及每个人真正可能失去什么。高层赞助人、一线使用社群和客户内部培训师构成三条关键关系线。优秀的 FDE 不是对所有需求说“ 是 ”，而是通过敢于说“ 不 ”建立可信边界。

P41｜干系人与信任

42 不改变激励，资产沉淀只能依赖自觉

前线反馈通常会增加当期工作量，如果绩效只奖励项目上线，理性的人就会忽略沉淀。因此交付和积累需要双轨考核，资产也不能只数“ 做了多少件 ”，而要看调用、采纳和节省工时。报告提出的内部结算方案试图让资产使用与反馈采纳产生经济信号，但它属于咨询方案设计，不能被描述为已经广泛验证的标准制度。

P42｜双轨绩效与内部结算

43 完整结果覆盖整个客户生命周期

如果团队只负责上线，不负责激活、续约和扩张，就仍然没有拥有完整结果。从问题—方案匹配、最小可行部署、生产运行到激活、续约和扩张，每个阶段都需要证据。续约准备应从开工第一天开始：记录工时、错误率、处理量、收入或风险基线，并持续观察使用、价值、关系和商业健康。

P43｜从 PSF 到扩张的价值生命周期

44 六类风险最终汇聚到一个指标

退化为外包、组织归属错位、人才成为瓶颈、资产沉淀恶循环、Land 容易而 Expand 困难、模型厂既是伙伴又是竞争者——这些风险表面不同，底层都在追问：单位价值对应的现场成本有没有下降。工时、周期、复用率、伙伴率、自助率和毛利应进入同一张边际成本仪表盘。

P44｜FDE 风险仪表盘

45 重 FDE 不是默认答案

一个项目在立项前应同时通过价值门、客户门、生产门、复用门和资产门。业务只是边缘提效、客户高度碎片化且客单价低、标准产品已经可以解决，或者行业共性太弱，都属于 No-Go 信号。任一关键门失败，就应转向标准产品、轻服务或暂缓，而不是用高成本 FDE 强行完成。

P45｜Go / No-Go 五道门

46 越深入客户现场，越需要主动设计退出

FDE 会接触客户数据、流程、权力和决策，因此专业边界必须比普通交付更清晰：数据主权属于客户，结果要诚实报告，系统不能制造永久依赖，受流程变化影响的人要有申诉与退出机制，对越权、过度监控和伤害性决策要明确拒绝。平台可以沉淀抽象规则，却不能带走客户账本。优秀 FDE 的终点，是逐渐不再被当前问题需要。

P46｜专业边界与主动撤场

47 Agent 越强，FDE 的人才价值越分化

Agent 会持续压缩写代码、搭原型和常规适配的时间，但不会自动承担场景定义、异常判断、组织推动、信任建立和知识沉淀。人才培养因此应从 Delta 基础与原型开始，逐步进入集成与异常闭环、独立项目负责，最终成长为 Echo 或行业负责人。组织还要为高级前线人才设计长期路径，不能把最强的人全部“ 晋升离开现场 ”。

P47｜Agent 之后的 FDE 人才

48 最终要建设的，是一台持续学习的机器

管理层可以用三个问题检查自己的 FDE 建设：谁同时对问题、技术和结果负责？上线后是否真正激活，客户能否独立接手？现场经验是否已经转化为第 5—8 个客户的工时、周期和毛利改善？只有交付没有沉淀，FDE 会退化为外包；只有沉淀没有现场结果，平台会退化为概念工程。

P48｜从现场结果到产品杠杆

结语：FDE 是企业 AI 的学习机制

FDE 之所以值得研究，不是因为市场多了一个高薪岗位，而是因为企业 AI 需要一种新的组织答案。模型能力正在快速商品化，真正稀缺的将是定义问题、穿透系统、推动采用、建立信任，并把现场经验沉淀为组织资产的能力。

这套模式也没有天然正确。它需要高密度人才、明确责任、严格的场景选择、可验证的业务结果、正式的反馈与版本机制，以及持续改善的成本曲线。缺少其中任何一项，FDE 都可能退化为昂贵驻场、英雄式救火或无法落地的概念工程。

真正成熟的 FDE，不是永远依赖一群人在客户现场解决问题，而是让每一次深入现场，都为产品、伙伴和客户留下可以复用的能力。第一个客户提供问题，前线把问题变成证据，平台把证据变成资产，资产再让下一次交付更轻——这才是从现场结果走向产品杠杆的完整闭环。

内容说明：本文以腾讯研究院《FDE 模式行业观察与实践》公开商业版 v5.0 及其既有 FDE相关读书笔记为主要事实来源，并结合相关 FDE 实践材料进行结构化改写。报告中的招聘、企业动作与市场数据具有采集窗口；Palantir 成本曲线为趋势示意；ERP 案例为虚构方法演示，数字为估算值；内部结算属于咨询方案设计。对外发布前，建议对时点性数据再次复核。