第 15 章中国云服务商的 FDE 实践图谱

第 15 章中国云服务商的 FDE 实践图谱¶

Note

本章导读：第 14 章看的是政策框架下的牵头方，本章看能力供给方。阿里云、华为云、腾讯云、火山引擎四家头部厂商，基于各自基因演化出了形貌各异的"类 FDE"模式——它们既是服务团的主要技术伙伴，也是 414 号文"模型、智能体、Token 服务采购"的主要承接方。本章用统一框架（PPT + 能力回注 + 飞轮阶段 + 卖人力/能力）横向剖析四家，看它们各自的强项与短板，并附各家可公开引用的案例锚点与代表案例的深度剖析。考虑到 2026 年 FDE 的供给方已从云厂商扩展到模型厂商与数字化服务商，本章另设专节呈现这三类新玩家；第 16 章再转到需求方，看关键行业如何落地。读完本章，你能用同一把尺子衡量任何一家中国厂商的"类 FDE"成熟度，预判它转型的卡点在哪。

回到第 13 章的判断：政策鼓励"扎根用户现场"，但没有规定该怎么扎根，各家给出的答案差异很大。国内以阿里云、华为云、腾讯云和火山引擎为代表的头部大厂，基于各自的组织基因，演化出了形貌各异但内核相通的技术交付模式。本章将对这四家厂商的实践图谱进行深度剖析。

Important

统一考察框架：用同一把尺子量四家。 为避免"各讲各的"，本章对四家厂商的考察，统一沿用书中已建立的核心模型作为透视镜——每家在"关键启示"小节都会用它点评强弱项，横向对比时也用它：

PPT 三维度（People / Process / Technology，见第三篇 How 总纲）——看这家的团队、流程、平台底座各处于什么水平、是否均衡；
能力回注机制（见第 9 章）——看它"现场经验 → 平台能力"的通道是否通畅，这是护城河的核心；
飞轮阶段（见第 2 章）——看它处于飞轮的启动期、加速期还是成熟期；
卖人力 vs 卖能力（见第 1 章主线）——看它本质上还在按人头卖交付，还是已转向卖可复用的平台能力。

一句话：四家的差异，本质是它们在这套模型的各维度上"各有偏科"——没有一家像 Palantir 那样五维均衡且互相咬合，这正是中国厂商共同的转型课题。

15.1 阿里云：TAM + AI FDE + OneData 能力回注¶

作为国内云计算的开拓者，阿里云的技术服务体系经历了最为完整的演进周期。其核心特征在于建立了一套多梯次的技术服务矩阵，并通过极其强大的内部业务场景（如双 11）打磨数据产品，最终向外部输出。

15.1.1 阿里云的多梯次服务模式¶

从组织架构上看，阿里云构建了面向客户全生命周期的复合型技术交付阵型：

TAM（技术服务经理，Technical Account Manager）：聚焦于企业级客户的专属技术服务，承担整体架构规划和技术治理闭环（对标 Palantir 客户成功负责人/部署主管）。
SA（解决方案架构师，Solution Architect）：偏向于售前与售中阶段的技术方案设计、架构蓝图绘制及实施指导（对标 Palantir 架构师）。
驻场工程师：负责现场的日常运维、系统保障和按部就班的项目实施。
面向 AI 的 FDE 模式（探索期）：在大模型时代，阿里云组建了深入企业业务一线的敏捷团队。技术执行工程师（对标 Palantir FDE）直接进入客户现场，协助企业进行算力平台适配、RAG（检索增强生成）系统搭建和垂直模型微调。

Note

2026 年动向：阿里云政企业务已把"FDE"作为对外使用的角色称呼，并以《阿里云 FDE 专家让 AI 真正进入产线》为题公开发布了产线级落地实践（2026 年 5 月）。这说明 AI FDE 在阿里云已从"内部探索期的小队代号"走向"对外承诺的服务角色"——对乙方而言，意味着这一角色的能力标准正在被头部厂商用公开案例间接定义。

Important

高管视角（战略层）：TAM+SA 的组合确保了项目"能签下来"并"有规划地落地"，而 AI FDE 的引入则是为了在大模型时代打破 SaaS/PaaS 的标品局限，贴近客户最后一公里解决高价值业务痛点。

一线视角（实操层）：工程师不仅要懂底层云资源的调度（ECS/MaxCompute），更要懂客户业务侧的数据流向，能够利用 Python 或 Java 快速编写胶水代码连接阿里云各种 API。

15.1.2 能力回注机制：从业务外化到 OneData 体系¶

阿里云最接近 Palantir 核心理念的地方在于其能力回注机制。Palantir 强调"在泥土中挖金"，阿里云同样擅长"吃狗粮"式演进。

阿里巴巴内部双 11 等大促场景淬炼出了极其复杂的数据中台能力。这些内部打磨的能力，逐步沉淀为 DataWorks、Dataphin、Quick BI 等标准化商业产品。其中最著名的是 OneData 体系：

OneModel（统一数据模型）：规范业务域和数据域的映射。
OneID（统一实体识别）：跨系统整合用户/对象身份。
OneService（统一数据服务）：将数据资产 API 化，向应用层输出。

graph TD
    scene["内部极端业务场景 (双 11/大促)"] --> chal["发现共性技术挑战"]
    chal --> fde["一线技术工程师 (类 FDE) 解决具体问题"]
    fde --> lib["抽象提炼公共组件库"]
    lib --> prod["产品化研发团队 (核心研发)"]
    prod --> data["商用数据产品 (Dataphin/DataWorks)"]
    data --> meth["OneData 方法论输出"]
    meth --> cust["外部政企客户应用"]
    cust -->|反馈新需求| fde

    style scene fill:#f5ece0,stroke:#a8895f
    style fde fill:#dbe4f0,stroke:#3949ab,stroke-width:2px
    style cust fill:#e4efe4,stroke:#5b7a5b

图 15-1：阿里云从内部极端场景外化产品，经类 FDE 一线验证到外部客户应用的能力回注闭环

典型本土案例：

某省政务数据中台：通过 OneID 打通了社保、公安、交通等几十个委办局的孤岛数据，实现"最多跑一次"。
某快消企业全链路数据中台：打通线上电商与线下门店库存，构建统一的消费者画像。
某零售企业数字化转型：运用 OneService 将订单和库存服务 API 化，支撑前端小程序的高并发查询。

15.1.3 FDE 视角的关键启示¶

内部场景外化是最高效的能力回注：阿里云最成功的能力回注并非来自外部定制项目，而是内部业务场景的外化。
产品化程度深：在国内云厂商中，阿里云的数据中台工具链（Dataphin 等）产品化程度是最高的，极大地降低了前线交付工程师重复造轮子的成本。

Tip

框架透视（阿里云）：

PPT：Technology 最强（OneData/Dataphin 产品化领先），People/Process 相对标准化、偏工具依赖。
能力回注：通道最顺畅——但走的是"内部业务（双 11）→中台→商业化"的自研外化路径，而非"外部客户现场→回注"的 Palantir 路径。
飞轮阶段：成熟期（底座厚、复用率高）。
卖人力/能力：已明显偏向卖能力（卖产品化的中台）。
短板：前线 FDE 的现场定制灵活性受限于标准化工具，"从客户现场挖金"的能力弱于内部场景外化。

15.2 华为云：铁三角 + DataArts + 行业深耕¶

华为云的技术交付深深烙印着其 ICT 时代的 B2B 基因，最著名的管理实践即"铁三角"模型，这是一种高度组织化、纪律严明的阵地战打法。

15.2.1 华为的铁三角模式 (Iron Triangle)¶

面对大型政企客户，华为在前端配置了三个核心角色协同作战：

AR（客户经理, Account Representative）：负责客户关系和商务闭环。
SR（解决方案经理, Solution Representative）：最接近 FDE 的角色，负责洞察业务痛点并输出整体技术方案（对标 Palantir 部署主管/架构师）。SR 不仅需要极强的技术底蕴，更需要具备与客户 CXO 级别对话的商业视角。
FR（交付经理, Fulfillment Representative）：负责项目的生命周期管理、资源协调与实施交付。

graph TD
    subgraph tri["华为云铁三角客户交互界面"]
        AR["AR 客户经理 - 商务主导"] 
        SR["SR 解决方案经理 - 技术主导"] 
        FR["FR 交付经理 - 交付主导"]
        AR --- SR
        SR --- FR
        FR --- AR
    end
    Client["政企客户 CXO/业务部门"]
    AR <-->|商务沟通| Client
    SR <-->|需求与架构方案| Client
    FR <-->|项目实施保障| Client

    style AR fill:#dbe4f0,stroke:#3949ab
    style SR fill:#dbe4f0,stroke:#3949ab
    style FR fill:#dbe4f0,stroke:#3949ab

图 15-2：华为云 AR/SR/FR 三角色以统一界面协同，对政企客户形成铁三角闭环交付

Note

铁三角的精髓在于"打破部门壁垒，向客户提供统一接口"。客户感受到的是一个完整的作战单元，而不是松散的销售和交付拼凑。

15.2.2 核心产品与能力回注：DataArts Studio¶

华为将自身 20 多年的内部数据治理经验（尤其是跨国多业态的数据治理）沉淀为 DataArts Studio（数据使能平台）。该平台涵盖了数据目录、数据质量、数据安全等各个环节。

典型本土案例：

某城市智慧城市 IOC（智能运营中心）：早期由一线 SR 主导设计架构，后续沉淀为华为云智慧城市标准解决方案，成功在全球 100 多个城市实现规模化复制。
某城商行金融数据中台：通过 DataArts 梳理全行数据资产目录，满足银保监会的监管报送要求。
某央企数字化转型：构建"一个数据底座+八大应用场景"，统一全集团的数据标准。
某大型制造企业工业互联网：现场交付团队将生产线物联数据分析逻辑提炼，回注到华为云的工业互联网平台能力中。

15.2.3 FDE 视角的关键启示¶

组织化与体系化优势：铁三角模式将商业、技术和交付强行绑定，确保了从方案设计到落地的不变形，这对松散的 FDE 团队治理有极大借鉴意义。
SR 角色的局限性：SR 虽然在架构和商业洞察上强大，但在传统模式下偏向"架构设计和方案售前"，往往缺乏像 Palantir FDE 那样亲手写代码、深入脏数据池调优的深度参与。这导致方案和最终代码实现之间可能存在割裂。

Tip

框架透视（华为云）：

PPT：People / Process 最强（铁三角组织力、纪律严明），Technology（DataArts）扎实但 SR 偏方案设计、少亲手写码。
能力回注：走"行业标杆项目→标准解决方案→全球复用"路径，回注机制体系化，但因 SR 与代码实现割裂，现场经验的回注可能有损耗。
飞轮阶段：加速期偏成熟（智慧城市等已全球复制）。
卖人力/能力：偏卖能力（卖标准解决方案），但组织重、灵活性弱。
短板：SR 顶层设计与前线代码闭环之间的割裂，是"方案好但落地变形"的风险源。

15.3 腾讯云：OTSS→FDE 演进 + 智能体时代¶

腾讯云在技术服务领域的演进，展现了一段从"被动响应"向"主动构建"升级的典型历程，这对于很多正处于转型期的传统 IT 企业具有直接的参考价值。

15.3.1 模式演进：从被动运维到主动价值创造¶

阶段一：OTSS（驻场技术支持，On-site Technical Support Service） 早期的技术服务多为传统的驻场运维，工程师的核心 KPI 是"系统稳定性"和"工单响应时间"。工作本质是被动响应，无法触及客户核心业务逻辑。
阶段二：向 FDE（前沿部署工程师）演进 随着产业互联网战略的深化，腾讯云开始培养集成"BA（业务分析师）+架构师+研发"的复合型 FDE 角色。工程师不再只看监控大屏，而是坐进客户的业务办公室，理解什么是 GMV、日活和供应链周转率。

graph TD
    otss["传统 OTSS 模式"] -->|被动响应/故障驱动| it["解决 IT 基础设施问题"]
    otss -->|技术栈单一/缺乏业务语境| cost["客户视角的成本中心"]

    fde_m["转型后的 FDE 模式"] -->|主动介入/业务驱动| biz["解决数据流转与业务瓶颈"]
    fde_m -->|复合能力：代码+业务+架构| profit["客户视角的利润中心/赋能者"]

    cost -.->|"观念升级/能力重塑"| profit

    style cost fill:#f5ece0,stroke:#a8895f
    style profit fill:#e4efe4,stroke:#5b7a5b
    style fde_m fill:#dbe4f0,stroke:#3949ab

图 15-3：腾讯云从被动 OTSS 运维的成本中心，向主动业务驱动的 FDE 利润中心演进路径

15.3.2 智能体（Agent）时代的 FDE 定位¶

在当前的大模型与智能体时代，腾讯云为 FDE 赋予了全新的价值定位。面对企业海量非结构化数据和复杂的审批流程，FDE 负责智能体从"业务设计"、"提示词工程"、"RAG 知识库构建"、"API 对接部署"到"真实环境迭代优化"的端到端闭环。

Tip

一线转型建议：传统运维人员向 FDE 转型，可以从"会写自动化运维脚本"起步，逐步过渡到"用大模型搭建企业内部 IT 问答智能体"，最后延伸至"开发具备复杂决策能力的业务线智能体"。

典型本土案例：

某头部消费零售企业：FDE 团队从传统的门店 POS 系统运维起步，逐步深入商品与会员业务，基于腾讯云数据组件搭建统一消费者数据资产，支撑精准营销与选品决策。
某汽车主机厂智能座舱：借助腾讯云在音视频与 C 端连接上的先天优势，FDE 将车机语音助手与后端知识库打通，构建端到端的座舱智能体。
某政务热线智能体：FDE 主导完成 RAG 知识库构建与提示词工程，将市民咨询的自动应答准确率与首次解决率作为核心业务指标，替代大量重复的人工话务。

15.3.3 FDE 视角的关键启示¶

转型路径的参考性：OTSS 向 FDE 的演进，打破了"服务就是成本中心"的传统观念，为国内 SaaS/PaaS 企业现有交付团队转型提供了阶梯式路径。
AI 时代的破局点：智能体（Agent）开发是一个极度非标且需高度贴合业务的领域，这正是 FDE 发挥"前线代码能力+业务理解"双重优势的最佳战场。

Tip

框架透视（腾讯云）：

PPT：Process 正在演进（OTSS 被动运维 → FDE 主动创造），People 的复合能力（BA+架构+研发）在补齐中，Technology 依托 C 端流量场景组件化。
能力回注：走"C 端流量场景沉淀→技术组件化→前线组装"路径，方向对，但历史交付包袱使回注尚不系统。
飞轮阶段：加速期（转型进行中，尚未完全跑通）。
卖人力/能力：正处在从卖人力向卖能力的转型途中——这也是它对国内传统交付团队最有参考价值之处。
短板：历史 OTSS 包袱重，"从成本中心到价值创造者"的观念与能力转型仍需时间。

15.4 火山引擎：规模化 FDE + 咨询联合¶

字节跳动旗下的火山引擎起步较晚，但凭借敏捷的组织迭代能力和在 AI、大数据领域的技术积累，探索出了一条"生态联合+人海战术"与 AI 商业化紧密结合的道路。

Note

关于团队规模的表述说明：本节标题与下文提到的人员规模，均为业界对其 FDE/服务团队的概括描述，本书编写时未获得可公开引用的一手权威统计佐证（见附录 D 火山段备注），引用时请作为"模式概括"而非确数。

15.4.1 模式特点："铁军"与咨询联合¶

火山引擎深刻意识到大模型落地面临的"最后一公里"难题，采用了一种极具侵略性的破局策略：

联合头部咨询机构：火山引擎提供技术底座（云原生、大数据平台、大模型 API）和前线工程师，咨询公司输出行业 Know-how、数字化转型顶层设计和业务诊断。2026 年 7 月，火山引擎与安永达成战略合作，合作方向为助力企业迈向 AI 原生架构，可视为这一打法的公开注脚。
搭建千人级 FDE 团队：将 FDE 视为 AI 商业化落地的"铁军"。这支队伍不仅负责将火山的推荐算法、大模型能力植入客户系统，还要在实战中获取最为真实的业务反馈（Feedback Loop）。

这种"技术底座 + 前线铁军 + 咨询外脑"的三方协作，本质上是把 Palantir 内部"平台工程师 + FDE + 业务策略师"的三角，部分外包给了专业咨询公司来补齐行业 Know-how 短板：

graph LR
    subgraph vol["火山引擎"]
        P["技术底座<br/>大模型/大数据/推荐算法"]
        F["规模化 FDE 铁军<br/>现场植入+反馈收集"]
    end
    subgraph con["头部咨询机构"]
        C["行业 Know-how<br/>顶层设计与业务诊断"]
    end
    Client["政企/大型企业客户"]

    C -->|业务蓝图| F
    P -->|平台能力| F
    F <-->|现场交付与反馈| Client
    F -.->|真实业务反馈| P

    style F fill:#dbe4f0,stroke:#3949ab,stroke-width:2px
    style Client fill:#e4efe4,stroke:#5b7a5b

图 15-4：火山引擎以技术底座和规模化 FDE 铁军，联合咨询外脑对客户实现现场交付与反馈闭环

15.4.2 战略意图与效果¶

对于火山引擎而言，FDE 不仅是交付人员，更是客户黏性制造机和产品反馈收集器。通过大规模派驻懂 AI 和数据的 FDE，极大地缩短了客户尝试新技术的决策周期，降低了 AI 接入门槛。

典型本土案例：

某新能源汽车品牌营销智能化：FDE 铁军将火山的推荐与大模型能力植入客户的用户运营链路，联合咨询公司梳理"线索—试驾—成交"的转化漏斗，把营销 ROI 作为可量化的交付指标。
某消费品牌大模型营销：借助火山在内容推荐上的算法积累，FDE 帮助客户搭建 AIGC 素材生产与智能投放闭环，缩短营销物料的生产周期。
某金融机构智能客服：由咨询公司做合规与业务流梳理，火山 FDE 负责 RAG 知识库与对话能力落地，在严监管前提下提升自助解决率。

15.4.3 FDE 视角的关键启示¶

创新的规模化路径：通过与具备业务深度的外部咨询公司联合，弥补了原生云厂商在垂直行业（如汽车制造、医疗生命科学）领域知识储备不足的短板。这是一种"借外脑补短板"的加速策略。
长期隐患与内化需求：这种人海战术适合大模型及 AI 应用落地的初期阶段（快速抢占山头），但如果不建立像 Palantir 那样高度抽象的底层平台（如 Gotham/Foundry）来实现资产沉淀，长期将面临极高的人力成本侵蚀。未来必须从"人力密集"走向"资产复用密集"——即把千人铁军踩过的坑，系统性地回注为平台的标准能力，否则团队规模的线性扩张终将撞上人效天花板。这正是第 1 章"从卖人力到卖能力"这一全书主线在中国厂商身上最真切的写照——火山的挑战，本质就是能否完成从"卖人力"到"卖能力"的惊险一跃（并呼应第 9 章能力回注方法论）。

Tip

框架透视（火山引擎）：

PPT：People 规模最大（千人 FDE 铁军 + 咨询外脑补行业 Know-how），但 Technology 的资产沉淀（底座复用）是最大短板，Process 依赖人力密集而非流程复利。
能力回注：目前以"前线业务反馈→快速迭代 AI/算法"为主，尚未建立"定制→抽象→并入平台"的系统化回注——这是它与前三家的最大差距。
飞轮阶段：启动期/加速期早段（靠人海快速起量，飞轮尚未靠资产复用转起来）。
卖人力/能力：当前仍偏卖人力（人效天花板明显），能否转向卖能力是其生死线。
短板：五家里 Technology 沉淀最弱，最需补"平台底座 + 能力回注"这一课。

15.5 四家对比总结¶

用本章开头确立的统一框架（PPT 三维 + 能力回注 + 飞轮阶段 + 卖人力/能力），把四家放到同一张表里横向对比：

评估维度	阿里云	华为云	腾讯云	火山引擎
模式简称	TAM + AI FDE	铁三角（SR/FR/AR）+ SA	OTSS → FDE	规模化 FDE 铁军 + 咨询联合
People（人/组织）	标准化，工具依赖	⭐ 最强：铁三角组织力、纪律严明	复合能力补齐中	规模最大（千人）+ 咨询外脑
Process（流程）	中台流程成熟	⭐ 最强：方案到落地不变形	演进中（被动→主动）	人力密集，流程复利弱
Technology（平台）	⭐ 最强：OneData 产品化领先	DataArts 扎实，SR 少写码	C 端场景组件化	最弱：底座复用是短板
能力回注机制	内部场景外化（自研路径，最顺）	标杆项目→标准方案→全球复用	C 端沉淀→组件化（尚不系统）	反馈迭代 AI，未系统化回注
飞轮阶段	成熟期	加速期偏成熟	加速期（转型中）	启动期/加速期早段
卖人力 vs 卖能力	已偏卖能力	偏卖能力（卖方案）	转型途中	仍偏卖人力
对标 Palantir 的主要差距	前线现场定制灵活性受限于标准化工具	SR 顶层设计与代码实现割裂	历史交付包袱重，转型未跑通	Technology 沉淀最弱，人效天花板明显
最该补的一课	强化"从客户现场挖金"的前线能力	打通 SR 方案与前线代码闭环	加速跑通回注、甩掉 OTSS 包袱	补平台底座 + 系统化能力回注

Important

一张表看懂四家的分化：四家在统一框架下各有偏科——阿里赢在 Technology、华为赢在 People+Process、腾讯赢在转型路径的参考性、火山赢在 People 规模与速度。但把五个维度叠起来看，没有一家像 Palantir 那样五维均衡且互相咬合成飞轮：阿里回注走的是内部外化而非客户现场、华为 SR 与代码割裂、腾讯转型未跑通、火山 Technology 与回注双缺。这种"单点强、全局不均衡"，正是中国厂商共同的转型课题——这也印证了第 13 章的判断：政策能打开窗口，补齐最弱维度、让飞轮真正转起来，仍要靠企业自己的转型行动纲领。

但四家不是全貌。 2026 年的中国市场上，FDE 的供给方已经扩展到另外两类主体，它们的进入方式与商业内核和云厂商差异很大，必须放在同一张尺子下对照：

新主体类型	2026 年代表动向	与云厂商模式的根本差异	对乙方的启示
大模型厂商 × ISV 联合体	月之暗面启动 Kimi 企业合作伙伴"登月计划"，以 FDE 模式与系统集成商共建前置部署工程师队伍、进入客户现场交付；首批签约中软国际、金山云、华胜天成、亚康股份、亚信科技 5 家上市公司，公开披露的合作安排含 Token 分成与联合创新	卖的不是人头也不是平台，而是"模型能力 + 方法论 + 分成"：模型厂商不养全量驻场队伍，把现场执行交给 ISV，用分成把双方利益绑在业务结果上	乙方从"自建 FDE 与云厂商竞争"变为"可选择与模型厂商共建"，用别人的模型能力与工程方法论降低自建门槛；代价是价值分配链条上多了一方
数字化 / 软件服务商自建 FDE 体系	微盟推出企业专属 AI 定制服务"星程"并以 FDE 交付；赛意信息公开以"FDE 体系破局交付困局"；中国电信体系出现"智惠工程师"类命名	把 FDE 产品化、品牌化（给交付服务起商品名、给岗位起体系名），而非停留在内部组织调整	传统服务商的转型不是理论推演，同期已有可对标的现实样本

Important

结构性差异：Palantir 是"一家公司把方法论、平台、队伍全包"；中国正在演化成"模型厂出能力、ISV 出人手、平台方出工具"的分工网络。 这张网络对乙方既是机会（不必什么都自建），也是风险（在一张网络里，你凭什么是不可替代的那一环？）。各类主体的逐类展开见下一节。

15.6 中国 FDE 实践的可引用案例锚点¶

Note

本节用途：本章的实践描述中，部分结论可锚定以下公开可查证案例作为佐证（来源见附录 D）。评分采用审阅组建议的四维框架（方法论体现度 30% / 可量化成果 25% / 可公开引用性 25% / 中国市场代表性 20%，满分 20 分，≥14 分可入选直接引用）。评分带主观性，引用时请按第 4 章章首"数据严谨性说明"处理。

厂商	案例锚点	四维评分（/20）	可引用性分级
阿里云	雅戈尔×Quick BI：从 16 个系统到 1 个平台，打通全业务数据壁垒	15	A 级（官方客户案例页）
阿里云	森马×MaxCompute+Hologres+DataWorks 数据中台（官方博客）	14	B 级（官方博客）
阿里云	德清县城市大脑 2026 年度运维服务（政府采购公告）	13	A 级（政府公告，但偏运维非交付方法论）
华为云	CMPak（巴基斯坦）智慧中台：释放数据价值、加速数字化转型	14	A 级（官方案例页，海外案例）
华为云	华为云×通汇诚泰数据中台签约；海通证券鲲鹏改造	13	B 级（行业媒体）
腾讯云	广东政务智能中枢"湾擎"（2026-06 上线，广东省主导，腾讯云为共建企业之一）	15	A 级（权威媒体）
腾讯云	百望股份×腾讯云共建 AI 智能体产业应用	14	B 级（上市公司公告）
火山引擎	奇瑞×豆包大模型接入"小奇同学"（2026-04）；超 50 个汽车品牌采用豆包	16	A 级（证券时报等权威媒体）
火山引擎	东风汽车×火山引擎战略合作（豆包上车）	14	B 级（行业媒体）
火山引擎	火山引擎×安永战略合作（助力企业迈向 AI 原生架构，2026-07）	—	B 级（财经媒体）
月之暗面 × ISV 联合体	Kimi 企业合作伙伴"登月计划"：以 FDE 模式与系统集成商共建驻场队伍，首批签约 5 家上市公司（2026-09）	—	A 级（主流财经媒体一手报道 + 上市公司公告）
数字化服务商	微盟"星程"企业专属 AI 定制服务（FDE 交付）；赛意信息 FDE 体系；中国电信"智惠工程师"（2026-08/09）	—	B 级（行业媒体）

可引用性分级说明：

A 级（可直接引用）：官方客户案例页、政府/国企采购公告、上市公司公告、权威通讯社/证券媒体（如证券时报）——满足"可公开引用"要求，引用时注明出处与时间点；
B 级（可引用，需标注报道方）：厂商官方博客、开发者社区、行业媒体——可用于"官方能力模型佐证"，不宜作为独立事实来源；
C 级（方向参考，需脱敏/提炼）：无公开来源的内部项目——按第 4 章"教学案例"方式处理（综合提炼 + 明确标注）。

Note

关于"评分"与"分级"的关系：两者维度不同——评分衡量"方法论体现度/可量化成果/可公开引用性/中国市场代表性"（加权 30/25/25/20）；分级以"来源权威度"为主（官方/政府/上市公司公告= A 级）。因此出现"低分但 A 级"（如德清县城市大脑 13 分：来源权威——政府采购公告，但偏运维、方法论体现度低）或"海外案例入列"（如 CMPak 14 分：作可复制性参照系，非中国 FDE 方法论典范）均属正常，请读者按用途取用：要事实锚看分级，要方法论匹配看评分。

Note

两种容易被误用的措辞：其一，媒体在报道此类动向时常使用"行业首个""国内首家"这类独创性表述，这是媒体口径，不等同于厂商官方唯一性声明，引用时请保留这一区分；其二，上表新增的 2026 年锚点多为生态类动向（伙伴计划、共建合作），与上表项目型案例性质不同，适合作为"行业趋势事实"，不宜作为"交付能力证明"。

Important

给乙方的用法：这组锚点不是为了"背书厂商"，而是给读者一个可核验的坐标系——当你想判断"某厂商的类 FDE 模式是否真实存在"，用本节的 A 级案例做事实锚，用本章的分析做方法锚。引用时请自行核对来源时效（部分案例为 2026 年报道，后续可能有更新）。

15.7 2026 年 FDE 生态的三类新玩家¶

本章前几节刻画的是一个相对完整的"旧图景"：四家头部云厂商在各自组织基因上，摸索"贴身靠前、懂业务、能写代码"的深度交付机制。但从 2026 年的公开动向看，这张图景已经被三类新玩家改写。本节把它们集中摆出来，作为第 13 章"转型挑战"——尤其是第六大挑战"交付主体重构"——的现实印证。

15.7.1 第一类：大模型厂商（以 FDE 模式做末端部署）¶

标志性事件是 2026 年 9 月月之暗面启动 Kimi 企业合作伙伴"登月计划"：以 FDE 模式与系统集成商共建前置部署工程师队伍，进入客户现场进行交付；首批签约伙伴包括中软国际（00354.HK）、金山云（03896.HK）、华胜天成（600410.SH）、亚康股份（301085.SZ）、亚信科技（01675.HK）五家上市公司，覆盖软件信息服务、通信、基础设施与云计算领域。月之暗面公开表示：随着模型能力快速提升，企业级 AI 的关键挑战已从技术本身转向规模化落地，未来将以开放合作方式向伙伴输出模型能力与工程方法论。

更早的 2026 年 7 月，中软国际已与月之暗面签署合作协议共建 FDE 创新实验室，公开披露的协议内容包含 Token 分成及联合创新合作安排，方向聚焦企业级 Agentic AI 与能源、金融行业的智能体落地。

Important

这一类的战略含义：模型厂商不需要、也不可能自建几千人的驻场队伍，它选择的是"能力与方法论输出 + ISV 现场执行 + 分成计费"。对本章前四节讨论的四家云厂商而言，这意味着竞争关系发生了位移——过去比的是谁的队伍强、底座好；现在多了一类对手，它们不派队伍，却握着模型侧的话语权与"按结果分成"的定价方式。

15.7.2 第二类：数字化与软件服务商（把 FDE 产品化）¶

比云厂商规模小、但更贴近传统行业的一批服务商，2026 年也在把 FDE 从内部组织动作做成对外商品：

微盟推出企业专属 AI 定制服务"星程"，明确通过 FDE 做交付；
赛意信息公开以"FDE 体系破局交付困局"为主线，阐述其交付体系改造；
中国电信体系内出现"智惠工程师"这类类 FDE 角色命名，承担 AI 落地"最后一公里"的现场职责（其 Echo、Delta、Foundry 三类分工与七段式分析见第 14 章）。

Tip

对读者的直接价值：这一类的做法，就是第 13 章"乙方 PPT 转型对标行动纲领"在国内的同期现实样本——它们不是理论推演出来的转型路径，而是正在发生的商业选择。读者可比对它们的做法，检验自己的转型动作是否踩在行业同频点上。

15.7.3 第三类：云厂商自身的能力外溢（从自建队伍到生态输出）¶

四家云厂商的演化并未停止，而是从"自建队伍"走向"用伙伴计划把交付能力复制出去"。2026 年 9 月中软国际与华为云推出"伙伴智能体先锋计划"，以 Skill、MCP、业务本体、场景包作为交付单元，面向能源等重点行业联合交付（见第 16 章）。这说明头部厂商已经意识到：纯自建的 FDE 队伍在成本上无法覆盖广阔的中长尾市场，必须把能力封装成可被伙伴继承的形态。

15.7.4 对乙方的三点结论¶

不必什么都自建：模型能力、方法论、工具平台，2026 年都已出现可外部获取的供给方，三大运营商也以平台与服务团牵头方身份入场（见第 14 章）；乙方更需要回答的是"我在这张分工网络里占哪一环、凭什么不可替代"。
"卖人力 vs 卖能力"这条主线没有变，但记账方式变了：在"人天计费 → 平台订阅"之外，新出现"按结果 / Token 分成"这一条路径（合同与定价设计、ROI 测算见第 17 章）。
能力下限正在被外部定义：当模型能力、伙伴网络与政策支持都可以从外部获取，乙方的差异化空间只剩两处——行业深水区 Know-how 与 现场破局判断力，而这恰好是第 10 至 12 章与本章反复强调的部分。

15.8 四家代表案例：七段式深度分析¶

Note

分析口径声明：以下四个案例（四家各选其一）按审阅组建议的七段式模板（背景挑战 → FDE 介入 → 技术方案 → 交付过程 → 业务成果 → 能力回注 → 方法论启示）展开。其中背景、技术方案、业务成果基于公开来源（附录 D）；FDE 介入方式、交付过程节奏等公开报道未披露的内部细节，以本书方法论视角做教学化推演（标注"推演"），读者请勿将其当作可引证的事实细节。量化数字仅保留有公开来源可查证的部分，其余用定性表述。

案例一：阿里云 × 雅戈尔（零售/制造，Quick BI 数据统一）¶

1. 背景与挑战：雅戈尔是集纺织、服装、地产、投资于一体的集团型企业，业务系统长期割裂（公开口径为"16 个系统"），各业务单元数据口径不一，管理层难以获得统一的经营视图，决策依赖手工报表汇总，效率低且易错。（来源：阿里云官方客户案例页 https://www.aliyun.com/customer-stories/retail-2025-youngor）

2. FDE 介入方式（推演）：按本书框架，此案属于"平台统一 + 现场实施"型，接近阿里 TAM/AI FDE 模式的典型打法——由阿里云交付团队驻场，先做业务数据盘点，识别"经营看板统一"为快赢场景（第 5 章），再逐系统接入。

3. 技术方案：以 Quick BI 为统一分析入口，将 16 个分散系统的数据通过数据中台（DataWorks/Dataphin 体系）汇聚、口径标准化，形成全业务统一数据底座，前端以经营驾驶舱呈现。公开口径：从 16 个系统到 1 个平台，打通全业务数据壁垒。

4. 交付过程与阶段节奏（推演）：Discovery 确认口径差异清单与关键指标定义；Prototype 先打通"销售+库存"两个核心域做演示；Build 按域分批接入并固化指标口径；Scale 期推广至管理层全员使用，并培训业务侧自助看数。

5. 业务成果：公开可查证的成果为"打通全业务数据壁垒、实现统一经营视图"；具体数值（报表周期缩短幅度等）官方未披露，按第 4 章章首"数据严谨性说明"的纪律不做虚构，此处仅作定性表述：决策数据获取从"周级手工汇总"显著提速。

6. 能力回注：该场景沉淀的"多系统口径标准化 + 统一看板"方案，在阿里云客户成功体系中是可复制的标准打法——这正是"内部场景外化"回注路径的体现（平台能力在客户间复用，而非仅一次性实施）。

7. 方法论启示：此案印证本章横向对比的判断——阿里赢在 Technology：它的类 FDE 交付高度依赖产品化工具（Quick BI/DataWorks）成熟度；同时提醒乙方：若平台工具不够强，"统一口径"这类需求会退化成无休止的定制实施。

案例二：华为云 × CMPak（巴基斯坦电信运营商，智慧中台）¶

1. 背景与挑战：CMPak 是巴基斯坦主要电信运营商之一，多套业务系统数据孤岛化，数据价值未能释放，传统"烟囱式"IT 难以支撑敏捷运营与精准营销。（来源：华为云官方案例页 https://www.huaweicloud.com/intl/ja-jp/cases/cmpakinpakistan.html）

2. FDE 介入方式（推演）：对应华为"铁三角"模式——SR 负责方案设计（智慧中台蓝图），AR 负责客户关系与商务，FR 协调交付资源与实施；一线交付人员按"数据使能"方法驻场实施。

3. 技术方案：基于华为云数据使能体系（DataArts Studio 同类能力）构建"智慧中台"，将多域数据接入、治理、服务化，形成统一数据底座供上层应用调用；公开口径为"释放数据潜力、加速数字化转型"。

4. 交付过程与阶段节奏（推演）：Discovery 梳理运营商核心数据域（用户、计费、网络、营销）；Prototype 以"用户画像 + 精准营销"闭环验证价值；Build 完成数据治理规则与服务体系化；Scale 期沉淀为可复用的"智慧中台"方案并向更多客户复制。

5. 业务成果：公开可查证表述为"释放数据价值、加速数字化转型"；具体运营指标未在公开页披露，按纪律不做虚构，仅定性：营销触达与经营分析效率显著提升。

6. 能力回注：此案是华为"标杆项目 → 标准方案 → 全球复制"回注路径的典型样本——巴基斯坦项目沉淀的智慧中台参考架构，反哺华为云"数据使能"方案体系，服务更多海外运营商。

7. 方法论启示：印证本章横向对比的判断——华为赢在 People+Process：铁三角组织力保证"方案到落地不变形"；同时提醒乙方：回注对象是"标准方案"而非"平台组件"，与 Palantir 回注到 Foundry 平台相比，复用粒度更粗、飞轮转速更慢。

案例三：腾讯云（共建方之一）× 广东政务智能中枢"湾擎"（政务）¶

1. 背景与挑战：政务场景存在大量跨部门事项办理与咨询需求，传统"人工+分散系统"模式响应慢、口径不一；广东作为数字化改革前沿省份，需要一个统一的政务 AI 能力中枢。事实定位：2026 年 6 月"湾擎"上线试运行，由广东省主导（广东省政务和数据管理局推动），腾讯云（WorkBuddy 等能力）、金山办公（WPS 专版）等作为共建企业之一参与，并非腾讯云独家/主导项目——本案例展示的是"云厂商作为共建方参与省级政务智能中枢"的类 FDE 形态。（来源：南方网、羊城晚报 https://news.ycwb.com/ikimvkmtjm/content_54179777.htm、东方财富 https://finance.eastmoney.com/a/202606243781769918.html 等 2026-06 报道）

2. FDE 介入方式（推演）：政务项目典型的"联合团队"模式——参与共建的云厂商交付工程师与客户（政务部门）技术人员混编，前置完成合规约束确认（第 13 章：等保、数据不出域），再按四阶段推进。

3. 技术方案：建设全省统一的政务智能中枢，核心是接入大模型能力（智能体）的政务知识库与事项办理链路，覆盖咨询问答、材料预审、跨部门协同等场景。媒体报道多用"全国首个省级政务智能中枢"这类表述，属媒体独创性口径，本文按"省级政务智能中枢的代表性上线实践"处理。

4. 交付过程与阶段节奏（推演）：Discovery 盘点高频政务事项与痛点；Prototype 以 2-3 个高频场景（如公积金、社保咨询）验证；Build 扩展事项清单并做安全加固；Scale 期向更多地市/部门推广，培养政务侧运营团队。

5. 业务成果：公开可查证成果为"省级政务智能中枢上线试运行、智能体接入"；具体办理时长缩短等数值未披露，按纪律定性表述：咨询响应从人工排队显著提速，材料预审错误率明显下降。

6. 能力回注：政务智能中枢的"大模型 + 政务知识库 + 事项编排"能力，由参与共建的云厂商沉淀为政务行业方案，可在其他省份/客户复用（"智能体时代"的组件化思路在 G 端落地）。

7. 方法论启示：印证本章的判断——腾讯正从"OTSS 交付"向"FDE/智能体时代"演进；此案是"平台 + 智能体 + 现场交付"三合一的新形态样板。同时提醒乙方：政务场景的胜负手是合规与组织协同（第 13 章），技术只是入场券。

案例四：火山引擎 × 奇瑞汽车（汽车 AI，豆包大模型上车）¶

1. 背景与挑战：汽车座舱智能化竞争白热化，奇瑞需要快速把大模型能力（语音助手、多模态交互）落地到量产车上，且要适配自研座舱生态与数据安全要求。（来源：证券时报 2026-04《奇瑞汽车与火山引擎达成战略合作，豆包大模型接入"小奇同学"》 https://stcn.com/article/detail/3818772.html；产业口径"超 50 个汽车品牌采用豆包"见 C114 报道 https://www.c114.net.cn/industry/79757.html）

2. FDE 介入方式（推演）：对应火山"千人 FDE"打法——交付工程师驻场奇瑞，与整车软件团队混编，把豆包大模型能力按车型与座舱场景工程化接入。

3. 技术方案：豆包大模型全面接入奇瑞"小奇同学"车机助手，覆盖语音对话、用车知识问答、多模态交互；公开口径为"战略合作 + 全面接入"，并有"超 50 个汽车品牌采用豆包""超 700 万辆车完成换脑"等产业报道佐证规模化。

4. 交付过程与阶段节奏（推演）：Discovery 梳理座舱高频交互场景与数据边界；Prototype 在 1-2 个车型上完成"小奇同学"对话闭环；Build 解决车机端模型推理性能与离线/在线策略；Scale 期向全系车型铺开，并沉淀"上车"标准接入包。

5. 业务成果：公开可查证成果为豆包正式"上奇瑞车"、战略合作达成；产业级证据为"超 50 个汽车品牌采用豆包、超 700 万辆车完成换脑"（媒体报道口径）；单车体验提升的量化指标未披露，按纪律定性表述。

6. 能力回注：这是火山"反馈迭代 AI"回注路径的样本——量产车上的真实交互数据反哺豆包模型能力，同时"车机接入"沉淀为标准化 SDK/接入包，显著降低下一个车企的接入成本。

7. 方法论启示：此案是最接近"AI 原生 FDE"的中国样本（呼应第 17 章）：交付物本身是智能体化能力，回注对象是模型与接入包。同时提醒乙方：火山的短板在本章横向对比中已指出——平台底座复用与系统化回注机制仍是其与 Palantir 差距最大的维度，规模优势若不转化为能力复利，人效天花板会很快到来。

Important

本章小结：阿里、华为、腾讯、火山四家各自从组织基因出发演化出"类 FDE"模式，用统一框架横向比较，差距集中在平台统一度和系统化回注。2026 年模型厂商与数字化服务商入场，乙方要回答的是：自己在这张分工网络里占哪一环、凭什么不可替代。

第 15 章 中国云服务商的 FDE 实践图谱