模型不稀缺了，稀缺的是把模型塞进业务的人
本文主要依据三份材料：腾讯研究院《前线共创 双向赋能：FDE模式行业观察与实践》（2026 年 7 月，公开商业版 v5.0，83 页）、范冰（XDash）开源全文的《前线部署工程师（FDE）：人工智能时代的客户价值交付秘籍》（仓库 v1.0.24），以及北美 AI Agent 公司 Cresta 的 FDE 负责人 Jove Zhong 的一线实录（2025 年 9 月）。文中数字均可在文末的参考资料中回溯。
一、0 到 80% 只要一个会写 Prompt 的工程师
2025 年，麻省理工学院 NANDA 实验室发布《生成式人工智能的鸿沟》（The GenAI Divide）。报告的结论被引用了无数次：过去三年全球企业在生成式 AI 上投入的三四百亿美元里，95% 没能产生可以写进财务报表的价值。
这个数字在引用之前得先交代口径。报告发布后，质疑集中在三点：它把"失败"定义为六个月内没有可衡量的财务报表影响，按这个标准互联网和云计算的早期投资几乎全是失败；它对价值的度量只认利润、成本、收入三项，流程提速和员工采用率这些先行指标不算数；样本以大型企业为主，失败数据又只来自项目发起人一侧。还有一层被点名的利益关系：NANDA 实验室自己就在研究智能体互联网，报告给出的解法恰好指向自家方向。
这些质疑都成立。但方向性判断被独立来源反复印证：斯坦福同年的大盘数据显示，组织里 88% 都在用 AI，真正跑进生产环境的智能体应用只有个位数百分比；麦肯锡的补充是，能说 AI 对利润贡献超过 5% 的企业只有 6%。
腾讯研究院的报告把这个现象换成了一把更锋利的尺子，叫 80/95/99 规律：
报告的原话是：FDE 不是做从 0 到 80% 的活，而是做从 80% 到 99% 的活。客户愿意为 FDE 付费，不是因为他看不到 Demo，而是因为 Demo 到生产之间有一条很长的沟。
那把尺子最反直觉的一段是 99% 这个上限。为什么是 99% 而不是 100%？因为 LLM 本质是概率系统，输出空间开放，永远存在不可见的边缘案例。从 99% 推向 99.9% 的边际成本指数级增长、边际收益递减。报告把这件事定性为工程经济学的最优解而非技术妥协：AI 覆盖可规模化的 99%，人工守住不可自动化的 1%。
在 AI 落地的三个阶段里，FDE 的介入方式还不一样：个人提效阶段是"操作训练营"，组织转型阶段需要跨行业的组织变革经验，业务重构阶段则是系统建设，把行业隐性知识沉淀为本体。
一个被反复忽略的前提：AI 项目必须先做可运行 Demo
传统信息化项目里，方案文档、原型图和参考案例足以帮客户建立信心。AI 项目不行。模型效果、边界条件和业务收益都带不确定性，客户很难只凭一份 PPT 判断系统能否在自己的数据、流程和组织约束下稳定运行。
报告给出了这条机制链：
需求异质化与效果不确定
↓
必须做可运行 Demo 验证
↓
售前交付能力前置
↓
AI 降低原型与定制成本
↓
FDE 成为更可行的组织形态
Demo 的意义不是替代生产系统，而是提前暴露风险：模型是否理解业务语言、数据是否可用、接口是否接得上、用户是否愿意用、业务指标是否有改善空间。
二、FDE 是什么，不是什么
一句话定义
范冰的书采用了鲍勃·麦格鲁的定义。麦格鲁早年在 PayPal 做工程师，后来是 Palantir 早期高管，再后来是 OpenAI 首席研究官，ChatGPT 和 GPT-4 都出自他领导的团队：
前线部署工程师，是一个驻扎在客户现场、填补「产品能做的事」与「客户需要的事」之间鸿沟的工程师。
拆开看，三个词各有一层限定。"驻扎现场"说的是工作语境嵌进客户那里：进客户的群、读客户的数据、开客户的会、认识那个"知道流程为什么是这样"的人，不一定天天坐客户办公室。"鸿沟"是这个角色存在的理由：产品开箱即用的地方不需要你，鸿沟越深的地方越需要你。"工程师"是最要紧的限定词：写的是生产环境的代码，不是报告。Palantir 命名时特意保留"软件工程师"几个字，就是向世界强调这不是咨询岗。
至于 Forward Deployed，是军事术语，指部署在前线的部队：把最有战斗力的人，放在离问题最近的地方。
它不是什么
不是售前。 售前的工作在签约前结束，目标是赢单，作品是幻灯片；FDE 的工作在签约后才进入深水区，目标是赢结果，作品是跑在生产环境里的系统。
不是驻场外包。 这个区分对中国读者尤其要紧，"工程师驻场"在国内有太长也太不堪的历史。国内第一批打出 FDE 旗号的服务商启盟科技用三句话划界：驻场按工时算钱，FDE 按阶段交付、按结果验收；驻场从零现写，FDE 带着产品底座来做工程；驻场越驻越久、人走系统停，FDE 做完会走，能力留在系统和客户团队里。
腾讯研究院的报告从另一侧给了同一个判断：FDE 与传统驻场的本质区别，在于项目结束后是否沉淀为可复用资产：
只留给客户一个系统 → 外包
带回经验却无法复用 → 项目制交付
把现场经验转化为
Skill / 模板 / 测试集 / 产品能力 → FDE
沉淀后显著降低下一个客户成本 → 可规模化 FDE
不是咨询顾问。 顾问按项目交付建议，对执行不负责；FDE 对系统的最终运转负责，终点是"客户团队能独立使用"。Anthropic 与金融科技公司 FIS 的合作是个标本：工程师嵌入 FIS 共建反洗钱智能体，把调查从几小时压到几分钟，但合作写明的目标不是交系统，而是"转移知识，让 FIS 以后能自己建智能体"。顾问的生意建立在客户持续的需要上；FDE 干没干成，标准正好反过来：客户哪天不再需要你，才说明你干成了。
不是传统产品工程师。 产品工程师面对抽象的用户（画像、漏斗、日活），FDE 面对具体的客户（一家银行的风控部、爱荷华州的农场、巴格达郊外的巡逻队）。Palantir 官方博客《Dev versus Delta》给过这对角色的官方划分：平台工程师负责"一种能力，服务多个客户"，前线部署工程师（内部代号"三角洲"）负责"一个客户，调动多种能力"。在 Palantir 干了近八年前线部署的纳比尔·库雷希把这套纪律讲成一句糙话："去他的可泛化性"——先把眼前这个客户救活，能不能复用到下一家，是平台团队的事。
从业者怎么划这条线
上面的"不是"是外部视角。北美 AI Agent 公司 Cresta 的 FDE 负责人 Jove Zhong 给了一份更工程化的版本，三条：
-
1. FDE 直接写生产代码。 SE 偏售前场景的技术表达与原型演示，SA 偏架构设计与技术选型；而 FDE 既要设计也要实现，要把方案接到客户真实系统里，并对上线质量负责。 -
2. FDE 对结果负责到"最后一公里"。 上线是否达标、能否在 SLO 下稳定扩展、出问题如何定位和回滚，都是日常。 -
3. FDE 是复合型选手。 既能和客户高层讨论业务闭环，也能和对方工程师对着日志抓 Bug；既要做需求澄清与范围控制，也要在关键路径亲自下场编码。
他对"FDE 是不是新瓶装旧酒"的回应是 "无 AI 不 FDE"——他面试过几个 Palantir 的 FDE，如果不是做 AI 项目，他更愿意叫他们"交付工程师"。按这个定义，今天的 FDE 更准确的叫法是 AI 交付工程师。
被问到"这和国内 SaaS 公司的驻场开发有什么区别"时，他的回答是：AI 里面有很多东西是非标准的，需要老师傅来打磨，而且需要把这些东西改回产品。
这套打法从哪来
2003 年，彼得·蒂尔和几个斯坦福出身的年轻人创办了名字取自《指环王》的公司：Palantir，真知晶球。他们要干的事有个能让任何产品经理当场崩溃的前提。麦格鲁后来在 YC 的播客里复盘：
"我们创业时的目标，是给情报界做软件，说白了，是给间谍做软件。而给间谍做软件的一个挑战是：我不认识任何间谍，你大概也不认识。就算你碰巧找到一个间谍，问他『你平时到底怎么工作的』，他通常也不会告诉你。"
没有用户访谈，没有需求文档，没有可用性测试。创始人之一斯蒂芬·科恩的办法笨得可爱：先做个演示样品拿给对方看，对方毫不客气地说"这东西太糟了，跟我们做的事毫无关系"，他追问一句"那你们希望它哪里不一样"，掏出本子一条条记下来，回去改，改完再送上门。
这个循环里藏着两个后来被证明价值千金的直觉：复杂领域的客户在看到能用的东西之前，并不知道自己要什么；想知道客户要什么，最快的路是让造东西的人站到用东西的人旁边。
把这套直觉升级成公司战略的是第 13 号员工希亚姆·桑卡尔。当 Palantir 从第一个客户走向第二、第三个，团队发现一个反直觉的事实：每个客户要的东西都有细微但关键的不同。标准解法是提炼共性、做通用产品、对差异说不。可 Palantir 的客户是中情局、联邦调查局、战场上的美军，说不就等于出局。
桑卡尔反着来：做一个能灵活定制的平台，派工程师驻扎客户现场，把最后一公里修完。他最关键的动作是改了这件事的账目：在软件行业的账本里，"为单个客户做定制"叫服务，是利润率的敌人；他把它翻了过来：现场定制这笔账要记在产品发现上，工程师在现场踩的每一个坑，都是平台下一次进化的路标。
2007 年前后，美军在伊拉克伤亡的最大来源是路边炸弹。桑卡尔带着一支小队和"还很粗糙"的产品，钻进保密信息室联合办公两周。所谓保密信息室是物理隔离的涉密空间，连免提电话都禁用。他用松紧带把电话绑在头上，腾出双手敲代码，一只耳朵听分析师提意见，另一只耳朵听硅谷总部说话。两周里每天干十九个小时。结束时分析师说"这东西有用"，桑卡尔自己却累垮了，打电话给 CEO 卡普说"这不可持续，我们完了"。卡普的答案后来成了公司文化：把这种"不可持续"，做成制度。
三、为什么是现在：三道成本门槛被 AI 拉低
FDE 模式不是新概念。Palantir 从 2003 年就开始实践，但过去十几年只有极少数公司真正跑通。腾讯研究院报告的核心判断是：2024—2026 年 FDE 重新火起来，原因不是企业突然需要更多驻场人员，而是 AI 同时改变了这套模式的三项成本结构。
前两项的下降好理解。第三项值得多说一句：工程执行门槛降低意味着 Delta 层成本被压缩，但判断场景价值、理解行业逻辑、推动组织采纳的 Echo 层能力并不会因此变得更容易获取。
能力被拆成两类：Echo 与 Delta
报告把这套跨边界能力拆成两类来分析。Echo 负责"该做什么"，Delta 负责"怎么做出来"。
Echo 的核心是理解客户业务：钱从哪里来、流程卡在哪里、AI 从哪个环节撬动价值。它不能只听客户说要什么，还要判断客户说的是否是问题本身：很多时候客户要求的是一个功能，但真正需要的是重构某个流程；客户想买的是一套工具，但真正缺的是一套用起来的组织机制。
Delta 的核心是快速建原型、接系统、调模型，在真实环境中不断迭代。AI coding 降低了 Delta 的技术门槛，但没有消除对工程判断的要求：粗糙原型可以，但不能没有质量底线；快速迭代可以，但不能忽视安全、权限和审计。
在国内组织中，这两者往往分散在不同团队：行业架构师懂客户但不一定能交付，交付工程师能实现但不一定能定义问题，产品团队懂平台但离客户现场太远。FDE 模式的价值正是把这些能力通过组织机制重新连接起来。实际操盘中，Echo 与 Delta 不一定是两个岗位而是两种角色。早期团队中一人可能兼有两种能力，随着项目规模扩大一般会自然分化。
双向蒸馏：交付如何变成学习
如果说 Echo 和 Delta 解释了 FDE 需要什么能力，双向蒸馏解释的是这些能力如何变成组织资产。
第一层是对客户的蒸馏：把散落在客户员工脑中的业务经验、流程规则和隐性知识，转化为 AI 能调用的知识库、规则系统、工作流、SOP 和应用能力。客户因此获得更稳定、更可复制的业务执行能力。
第二层是对厂商自身的蒸馏：把项目获得的行业知识、系统接口、测试方法、场景模板和失败案例，沉淀为产品能力、行业模板、内部工具和平台组件。厂商因此在提升同类场景的交付效率和服务深度。
承载两层蒸馏的共同载体是本体层（Ontology Layer）。本体的理论并不复杂：实体、关系、属性，本质上就是结构化的业务知识图谱。客户系统里同一个业务对象可能有不同字段名、不同编码和不同流程表达，AI 如果直接面对这些混乱系统，很难稳定理解业务含义。本体层要做的是把这些系统差异翻译成统一业务语言：这是客户，这是订单，这是审批，这是风险事件；它们之间有什么关系，能触发什么动作，在哪些条件下需要人工介入。
从一个客户总结出来的本体，有机会复制到同行业另一个客户。不是把客户数据拿去训练模型，而是把行业知识沉淀成可复用抽象。这些概念不属于任何一家企业，而属于共同的业务领域。
两层蒸馏叠在一起，过去那种很重、很贵、强依赖高端团队的模式，才有可能变成更多行业可以采用的路径。
一项容易被低估的工程约束
报告专门提醒了一件事：即使有 AI 辅助本体抽取（从代码逆向工程、从设计文档自动生成），人工确认成本依然很高。AI 生成的结果可能 98% 是正确的，但要找出那 2% 的错误，人必须读完 100%。
不能给管理者形成"AI 来了，本体建模成本很低了"的错觉。技术手段可以加速初始抽取，但最终确认和治理仍然需要领域专家投入。这也是 Echo 团队成本不可回避的原因。
需求侧还有一层推力：等不起
成本结构解释的是"这件事为什么变得可行"，但没有解释"为什么是现在这么急"。Jove Zhong 从买方和厂商两侧给了一个更直白的答案：大家等不起。
不能等 AI 平台全面到小白也能开发生产级 Agent，不能等客户经过三个月培训才自己会用一点，不能等下一代模型，更不能等竞争对手把山头抢完。他对这个窗口期的判断相当克制——"等三五年后 AI 模型非常智能、可以无脑使用了，FDE 也该转岗了，说不定不用三五年，三五个月也不是不可能"。但正因为没人知道那天什么时候来，当下才要拼命招人："我一周看几百份简历。"
顺带一提，他对当前阶段的描述比"概念验证坟墓"更刻薄，也更传神：AI Agent 就像青少年的性——大家都想要，大家都说自己做过了，其实都不太会做。
四、一次交付长什么样
六大环节
范冰的书按一次真实交付的完整旅程组织，六个环节环环相扣：
其中"守住续约"那一条对工程师尤其值得停一下。接受有损服务（不必执着于完美技术指标，优先保障业务可用）这句话在工程文化里是反直觉的，但它直接决定了项目能不能活到续约。
一线 FDE 的时间去哪了
报告引用的 Perspective AI 调查给了一组数字：47% 用于客户对接（发现访谈、现场部署、设计评审），31% 用于编写或审查代码，22% 用于内部协调与研究综合；71% 的 FDE 每月至少出差一次，64% 的主要工作模式是"将现有产品部署到新客户环境并进行大量定制"。
Jove Zhong 从 Cresta 一线给了一组更细的切法，两刀：
两组数字互相印证同一件事：**写代码只占三分之一。**对习惯以代码产出衡量自己的工程师，这是转岗前最该建立的预期。
他给适合这个岗位的人的画像用了三个字：快、准、狠。
-
• 快是多层面的快：很快 get 客户的痛点与约束，很快交付，很快学新东西。而且不追求最精巧的方案——"2 天做出一个可行的 Python 方案，往往比 20 天打磨一个 Rust 方案更实际" -
• 准是抓大放小、动态调整优先级，同时在内部找到合适的资源支援 -
• 狠是承认这不是轻松活：需求变化、人员变动是常态，该出差出差、该加班加班
还有一个硬条件：**约三分之一的时间在路上。**他的原话是"不要太远的话，项目前期和客户 onsite 聊还是效率更高，关系也更融洽，后续大量线上会议"——但他特意补了一句"毕竟不是驻场工程师"。
业务理解要在写 Prompt 之前
腾讯研究院报告从国内一线经验里抽出四步打法，第一步就值得注意：FDE 团队进入客户现场后，不应马上写 Prompt 或搭 Agent，而应先摸清客户的钱从哪里来、业务卡在哪里、AI 能从哪个环节撬动价值。这个阶段需要行业业务专家参与，把 SOP、知识库、业务链路和关键指标梳理清楚。
后面三步依次是：业务专家和 FDE 一起把场景转化为 Agent、工作流或应用原型，不再由技术人员一人硬扛；用工具保障质量，从真实聊天记录、历史工单、业务数据中生成测试集，进行自动评测和 A/B 测试；用业务结果验证价值，把 AI 组与人工组进行逐环节对比（用触达率、响应率、转化率、人效等指标），说服客户继续投入。
报告把这条原则概括成一句话：实成果，不卖软件。客户不是为"用了 AI"付费，而是为业务真的变好付费。
Land and Expand
Bob McGrew 在 YC 公开访谈里提过一条被国内团队广泛忽视的判断："要么进入高管层的前五大优先事项，要么就失败。" 如果 FDE 切入的场景不在 CEO 或业务负责人的优先列表上，IT 或流程惯性就会占上风，项目最终被搁置或降级。
FDE 模式对应的商业模式不是传统"大单一次性交付"而是 Land and Expand。初始项目可以很小，甚至短期内不一定盈利：先用一个小范围试点证明价值，在客户内部建立信任；客户看到效果后，再从一个部门扩展到多个部门、从一个场景扩展到多个场景，合同金额和续费率逐步提升。FDE 的任务是确保第一批用户真的用起来，形成业务数据和内部传播，而不是做一个领导演示后就结束。
L0–L4：成熟度判断框架
很多 AI 项目的死法不是"做不出来"，而是停留在 Demo 阶段无法进入生产。报告给了一套成熟度框架，帮助判断当前处于哪个阶段、下一步该做什么：
多数项目在 L1 到 L2 之间夭折。 原因通常不是技术问题，而是三类卡点：试点用户没有被嵌入考核，"用不用都行"导致使用率下降；数据质量在 Demo 阶段被回避，进入真实环境后问题集中爆发；组织审批流程没有提前打通，权限和合规成为最后一公里的拦路虎。报告给 FDE 的专业性下了一个定义：能提前识别这些卡点并设计应对方案，而不是等问题出现后再救火。
五、规模化的那道坎
一条成本曲线
FDE 模式最容易被质疑的地方是：这不就是高端的定制外包吗？报告用一个成本对照回答了这个质疑：两者看似都在客户现场工作，组织逻辑完全不同：前者只关心这一单能不能验收，后者还要关心这一单能不能让下一单更便宜。
本体化交付要求在做第一个客户时投入更多精力做抽象和验证，第一单成本约是普通项目的三倍；但只要抽象正确，同类客户只需做映射和适配，边际成本递减。
这背后是延迟收益和规模效应的叠加。延迟收益意味着沉淀本体的投入不会在当期项目中回收：第一个项目甚至前几个项目，成本会比纯项目制交付更高，因为除了交付客户系统还要额外完成知识抽象、结构化和验证。规模效应意味着如果这个垂直领域有足够多的同类客户，本体的价值就会被大规模释放：做完一家标杆企业后，其他几十家甚至上百家类似企业可以复用同一套本体，交付成本显著下降。一个典型垂直领域里，七到八个客户做下来，本体基本趋向稳定，后续更新幅度显著减小。
报告因此给出一条判断：**FDE 模式本质上是一种先投入后回收的商业逻辑，它不适合所有场景。**如果一个领域只有一两个客户，本体沉淀的性价比就不高；如果领域足够大、客户足够多，前期投入就能获得长期复利。这也解释了为什么平台型企业更适合承担本体构建：它们有行业深耕的战略耐心，也有足够多的客户来摊薄前期成本。
三级复制杠杆
要避免把 FDE 做成一堆定制项目，必须具备规模化复制能力。书里给出的是知识复制、组件复制、产品复制的三级杠杆；报告则把当前的沉淀形式讲得更具体。
行业实践中，知识沉淀的载体正在快速演变。早期的知识图谱和本体结构化程度强，但构建和维护成本极高；后来的工作流编排降低了部分门槛，能够解决大量流程型问题，但仍需要较强技术能力；Multi-Agent 进一步增强了复杂任务协作能力，但系统设计和调试复杂度仍然不低。
当前更值得关注的是 Skill 与连接器的组合，这三种沉淀形式对应不同层级：
报告的原话是：本体层解决"业务对象如何被理解"，Skill 解决"能力如何被复用"，连接器解决"系统如何被操作"，分别对应知识沉淀、能力沉淀和系统连接沉淀。三者组合在一起，才构成一个可复用的行业解决方案。
这里有一条容易被忽略的安全提醒：单个 Skill 并不构成护城河。 Skill 本质上是自然语言描述的流程和规则，它是明文的，一旦放上平台容易被复制；大语言模型也可以被引导"吐出"Skill 的完整内容。实践中较可行的保护方式，是把 Skill 与连接器和专属知识库封装成完整应用，只暴露使用界面或对话接口，不直接暴露底层 Skill 描述。
五个风险与早期信号
报告把落地过程中的风险收敛成一张表，并指出所有风险本质上指向同一个问题：有没有持续降低边际成本。
其中最隐蔽的是第一个，本体层缺失的恶性循环：项目多、人手紧时，团队会优先交付客户，沉淀永远排在后面；没有沉淀，下一个项目又从零开始；效率低、人更累，于是更没时间沉淀。这个循环一旦形成，FDE 就会失去规模化叙事。
报告特意澄清了这一条的口径：这里说的"本体层缺失"不是指完整本体尚未建成（那需要客户规模和客单价的前提）。**它指的是更基础的问题：团队连最基本的 Skill 积累、行业模板和术语标准化都没有做，每次交付完全从零开始。**这种程度的缺失比一般交付问题更致命，因为它直接影响商业模式：管理层看到的就是人多赚多、人少赚少；投资人看到的是不可规模化；客户看到的是某几个工程师很能干，而不是平台本身有价值。
六、中国团队的现实
中美差异不只是市场大小
报告用一张表拆开了两地市场的结构性差异：
但差异不止在数字上。报告指出，美国很多大企业的流程、数据、岗位分工和系统治理已经多年沉淀，ERP、CRM、ITSM 等体系相对完善，数据有较强标准化基础。AI 更像"在一台精密机器上加装智能大脑"。而中国很多企业更像"对话驱动"：需求常以非结构化方式提出，协作依赖即时沟通，决策链条高度依赖关键负责人，流程常常不写在系统里，而写在默契和人情里。
这个差异一面增加了 FDE 落地难度，一面也带来跳级机会。**过去的软件要求先填表、画流程、配规则；AI 的入口是自然语言，而自然语言恰恰是这类组织最熟悉的协作方式。**很多客户未必能先把流程画清楚再上系统，反而更适合在 FDE 陪伴下"一边跑、一边修路"。
四条不完全成立的前提
报告对 Palantir 模式做了一次冷静的可行性复核。这套模式能跑通，有三项条件同时成立：FDE 与产品研发之间有高质量反馈链、客户现场经验能被平台吸收、平台能力反过来提高下一个客户的交付效率。缺任何一环，FDE 都容易退化为高端咨询。
但 Palantir 技术体系的几项前提在国内并不完全成立：
-
1. Foundry 建立在客户已有多年结构化数据积累的基础上，国内多数企业的数据底层仍缺乏标准化治理，本体不是从系统中"抽出来"，而是要在项目中"重新梳理出来" -
2. Palantir 的 Ontology 耗时十余年、数百名专职工程师打磨，在国内 2B 市场的客单价和付费习惯下很难直接复制 -
3. Gotham 的客户因安全许可要求天然具有极高迁移成本，这在商业场景中不存在 -
4. Palantir 录用率约 0.3%，这种人才密度难以批量复制
报告因此给出的策略是：国内团队不应照搬 Palantir 的完整技术栈，而应抓住核心逻辑：在数据与业务之间建立统一语义层，让 AI 和 FDE 共同操作这层语义，而非直接面对原始系统。用更轻盈的方式（Skill + 连接器 + 行业知识库）逐步逼近本体层的效果。
最现实的约束是经济性
报告把国内的核心挑战定性为经济性，而不是技术：硅谷高价值客户可以支撑六到七位数美元的年合同，国内大量项目仍在十万到百万人民币量级。
FDE 如果完全采用高成本专家投入，账很难算得过来；如果完全交给低成本外包，又失去产品反馈和经验积累。 因此中国 FDE 必须解决两个问题：一是用 AI 和平台能力降低交付成本，二是用 Skill、连接器、行业模板和伙伴生态提高复用率。报告的判断是：谁先解决这个问题，谁就可能在中国企业服务市场占据结构性优势。
七、这三份材料怎么用
三份材料的视角几乎不重叠：一份讲机制，一本讲岗位与流程，一篇讲身处其中的人怎么想。下面按"先读哪份、能得到什么、要注意什么"逐一说明。
腾讯研究院《FDE模式行业观察与实践》
83 页，10 章，2026 年 7 月公开商业版 v5.0。它是机制视角，回答的是"FDE 为什么在当前阶段升温、解决了大模型落地中的哪些结构性问题、是否具备规模化可能"。核心增量在三个地方：
-
• Echo / Delta / FDPM 的角色拆分，以及双向蒸馏与本体层的理论框架 -
• 腾讯云的实践样本：教育行业的 WorkBuddy → LearnBuddy 孵化路径、传媒行业的 ISV 协作、CodeBuddy/WorkBuddy 客户成功团队的全链路实践，以及"平台 / 工具 / 伙伴"三层赋能方法论 -
• 第九章的完整操作手册：用一个虚构的 ERP 行业案例，把 Echo-Delta 协作机制从冷启动到规模化复用的全过程走一遍，五个阶段各自该做什么、产出什么、怎么考核、利益怎么分配，全部落到操作层面
需要留意它的自我限定：第九章明确说明是"方法论述用途的虚构案例"、"部分机制（如内部结算模型）基于咨询方案设计，国内外尚无完整公开实施案例"；附录 A.3 也列了五条研究局限性（招聘数据时效性、国内样本限制、薪酬口径差异、公开招聘样本偏差、腾讯云实践内容的边界）。读的时候把这些边界一起读进去。
范冰《前线部署工程师（FDE）：人工智能时代的客户价值交付秘籍》
出版方称其为「完整拆解 FDE 的第一本书」。它也是本文 §二、§四的主要依据之一。
第一本FDE书，国内全流程落地实操指南
**它回答三个问题：FDE 是什么？怎么做？谁在做？**全书分三部分。
第一部分：FDE 的起源与发展（第 1 章）。从麻省理工 NANDA 实验室 2025 年的 95% 数据切入，讲 Palantir 如何在二十年里把这套打法炼成护城河，再给出 FDE 的概念、职责与三层特质，以及面向客户、产品线、销售、组织的四重身份。§二里"它不是什么"的那四刀就在这一章，同章还讲了公司招 FDE 的具体要求、个人成为 FDE 所需的技术栈和一个实用工具箱。
第二部分：FDE 全流程实操（第 2–7 章）。沿一次真实交付的完整旅程展开六个环节，每一环给的是方法而非原则：
第三部分：海内外实战案例剖析（第 8 章）。复盘 Palantir、OpenAI、Anthropic、Harvey、Sierra、Databricks/Snowflake 等海外不同类型企业的实践路径，剖析国内大厂（火山引擎、华为）与先行者的尝试，给出对照组案例，并收录一份国内 AI 创业团队的 180 天实战复盘。
书从开源项目转化而来，作者在出版版上做了四件事：逐段润色并查证全部细节与数据；优化排版、按内容层级重做列表与标题；补绘大量可视化图表；对第 8 章做了较大篇幅的修改——相比开源版的案例汇总，精简描述并提炼可复用经验。配套资源里另增了 FDE 高频问题解答。所以用途不同，选择也不同：系统学习用出版版更省时间，快速建立认知开源全文足够。
三处我认为最有价值：
-
• 第 1 章的"它不是什么"：把 FDE 和售前、驻场外包、咨询顾问、产品工程师逐一切开。这四刀比正面定义更能建立准确认知，尤其"驻场外包"那一刀对国内读者是必需的 -
• 第 8 章的完整案例集：重点不在罗列，而在辨析哪些经验可以复制、哪些不能照搬 -
• 附录 A 的指标体系：分交付层、客户层、商业层、组织层四组，是把"FDE 干得好不好"变成可测问题的少数尝试
Jove Zhong《我在 AI 异世界重生为 FDE》
前两份材料都是研究视角，这一份是一线从业者的自述。作者 Jove Zhong 是北美 AI Agent 公司 Cresta 的 Head of FDE，此前做过四年 streaming database 创业公司的 cofounder，2025 年 8 月入职 Cresta，9 月 28 日在 Superlinear Academy 社区发出这篇实录，12 月又补了一段入职满三个月的复盘。
它的价值不在于体系化——按作者自己的说法，"此文不一定客观，也完全不权威"，价值在于提供 data points。三处最值得读：
-
• 与 SE / SA 的三点区别（见 §二）：直接写生产代码、对结果负责到最后一公里、复合型选手。比研究视角的"四个不是"更贴近日常判断 -
• 时间分配的一手数字（见 §四）：两刀切法，以及"写代码只占三分之一"这个对工程师最有冲击力的结论 -
• 对窗口期的判断（见 §三）："无 AI 不 FDE"、"大家等不起"、以及那句关于 AI Agent 现状的刻薄比喻
相关阅读
-
• AI Native 全栈实践——本仓库关于 AI 如何进入开发流程与应用架构的三层框架 -
• AI 原生 DevOps——8 阶段全流程框架，与本文的交付旅程互补 -
• 企业级 AI Agent 开发——Agent 系统本身的技术纵深
参考资料