FDE不是AI的替代者，是业务与模型之间的翻译

本文解读：《2026FDE：AI时代的落地工程师白皮书-润和软件》 · 共 28 页 · 原文

这份白皮书的核心判断是：模型能力已经不是瓶颈，挡在企业前面的是最后一公里。它把两件事放在一起讲——大模型把自然语言理解、代码生成压成一次接口调用，能力本身在迅速贬值； 而绝大多数企业级 AI 项目仍停在概念验证。

真正进生产、扛核心业务流量、还能过审计的项目屈指可数。白皮书把原因归到四个堵点。业务语义模型读不懂，关键数据拿不到，与存量系统集成成本高企，生成结果无法满足审计要求。 四条都不像算法问题，更像工程和组织问题。

FDE 不是 AI 的替代者，是 AI 与业务之间的翻译者、约束者和兑现者。

图源：《FDE》（第1页）

一、这份白皮书想解决什么问题

白皮书由润和软件首席 AI 科学家徐立扬等四人撰写，共六章：为什么需要 FDE、什么是 FDE、与相关岗位对比、如何培养、团队配置、实战案例。

它开篇就把问题摆出来：模型能力不是瓶颈，瓶颈在最后一公里。四个具体堵点是业务语义无法被模型理解、关键数据拿不到、与存量系统集成成本高企、生成结果无法满足审计要求。

所以这份材料的立场很清楚——谈的是交付，不是算法；谈的是怎么把系统放进生产，而不是模型怎么训。

图源：《FDE》（第4页）

二、能力在贬值，最后一公里在升值

引言里有一句判断值得抄下来：能力本身正在迅速贬值，甚至趋于免费。过去需要专门团队数年攻关的自然语言理解、代码生成、图像识别，现在被压缩成一次接口调用。

但企业界的体感与技术乐观并不一致。过去两年，多数企业级 AI 项目停在概念验证阶段。白皮书把原因归到一处：模型只负责推理，不负责知道。推理所需的事实散落在核心系统、数据仓库、制度文件和资深员工脑子里。

所以缺的从来不是更强的模型，而是把事实组织成模型能消费的形式的那个人。

模型只负责推理，不负责知道，而知道这件事还长在存量系统里。

图源：《FDE》（第5页）

三、三个理由：场景太多、语义不能复制、人两头都缺

第一个理由是量级。一个银行有数以千计的业务规则、数以万计的交易场景、数以十万计的测试分支。业务流程的数量远超系统数量。只要有业务的地方，就需要有人把 AI 能力接进去。

第二个理由是结构性鸿沟。能力可以被零成本复制，业务语义不能。同一个客户，在零售条线指自然人，在信贷条线指授信主体，在风控条线指风险敞口单元，模型自身消解不了这个歧义。

还有两条：模型指标不等于业务指标；AI 进生产必须可追溯、可复现、可回滚，而生成式模型天然随机，得由人设计确定性约束层。

第三个理由是人才培养难。高校学生懂算法不懂业务，传统 IT 从业者懂系统却受困于既有工程习惯。

图源：《FDE》（第6页）

四、定义要拆成两个维度才看得懂

第一维是 Forward Deployed 加 Engineer——被派往业务最前线的工程师，在现场完成问题定义和方案构建，这是内涵。第二维是前线部署工程加一个"家"——以前线部署为方法论，去研究和解决各类落地问题的人，这是外延。

白皮书对前线部署工程的定义是：一套以现场优先为原则的交付方法论。它不从既有产品能力出发去找场景，而是从现场真实约束出发定义问题，再反向决定需要什么能力组合。

核心假设只有一句：业务问题的定义权在现场，不在产品文档里。

业务问题的定义权在现场，不在产品文档里，这句是整套方法论的支点。

图源：《FDE》（第7页）

五、四项技能，加一个最容易被低估的内核

四项技能是：看懂业务问题、深度理解数据、掌握 AI 侧端到端能力、熟练运用企业级 AI 平台与算力底座。数据那一条里有个关键载体——本体。它用对象、属性、关系、动作与约束五类元素，把散落在制度、文档和专家脑子里的语义显式化。

白皮书的说法很直接：本体是 FDE 把业务理解交付给模型的主要形式。

没有本体，FDE 的业务理解就停在个人经验里，无法复用也无法被机器执行。

AI 侧的能力包括上下文工程、智能体编排、评测与回归、可观测四块，它特意点了两个常见坑。一是朴素 RAG 在千万级、高动态文档上会失效，而且先检索后鉴权等于让模型看过不该看的内容。

二是把全部上下文塞进单个长窗口，在生产里会撞上成本、时延和中间遗忘，必须做任务分解与上下文分层。

图源：《FDE》（第8页）

六、和传统交付工程师差的不是能力，是问题性质

白皮书用一张表把差别摆清楚：传统交付面对确定性问题，需求已定义，输入是需求规格说明书，数据已知已就绪。FDE 面对完全开放的问题：问题没有明确定义，用什么数据不清楚，输入输出不清楚，方案更不清楚。

它给了四个真实题面。比如一个条线的需求因子散在文档、邮件和会议纪要里，怎么变成可执行、可验证的开发任务？

再比如，怎么在不牺牲质量的前提下把交付周期压一半；怎么让不熟悉核心系统的小团队在极短窗口产出可编译的初版代码。

计量方式也不同。传统交付按人天与里程碑算，FDE 按业务指标算——成本、效率、体验、风险，至少落一项。

传统交付按人天验收，FDE 按业务指标验收，两本账没法互相折算。

图源：《FDE》（第9页）

七、和算法、平台、数据科学家怎么分工

对算法工程师和平台工程师，FDE 是带方案的人：定思路、定判据，后两者负责模型细化、算力调度、推理服务与权限体系。白皮书提醒，FDE 上岗前必须有过算法工程和平台工程的实践，否则设计出来的方案落不了地。

和数据科学家的对比最有意思。两者都面对开放问题，都不是单一模型能解决，但原料、方法、交付物完全不同。数据科学家从数据里发现规律，产出模型与洞察，价值靠业务侧采纳间接实现。

完整版报告有几十页图表，这里只挑了对经营判断最有用的部分讲，想全看的去运营动脉（www.yydm.cn）搜标题。

原文附录里还有分城市、分年龄的细表，做区域方案的时候能直接拿来用。

FDE 的产出是跑在生产环境、可被审计的系统与流程，价值直接由业务指标体现。白皮书用一句话概括：数据科学家让数据产生洞见，FDE 让洞见变成系统；前者解决看不懂，后者解决落不下。

图源：《FDE》（第10页）

八、培养路径：先立观念，再练基本功

培养路径是四层：先树立正确的 AI 落地观，再提升四大基础素质，然后快速学习行业知识，最后掌握 AI 专业技能。四大基础素质是认知、学习、创新、沟通。白皮书把它们描述成一个闭环：听懂是输入，认知是加工，学习是沉淀，创新是增值。

落地观那部分列了六个误区，几乎每个团队都踩过。比如拿着锤子找钉子，有了模型就一定要做多智能体，装了向量库就一定要做检索增强。

再比如为了体现技术能力，把三节点能解决的问题做成带反思、带规划、带自我修正的十节点智能体。还有抱怨数据质量太差、认为只有模型部分有技术含量、初学阶段直接上智能体编排、逻辑没理清就把问题丢给 AI 编码。

对应的原则是业务价值导向、落地优先事后归纳、在不确定性中求解、链路上所有环节同等重要。

能用简单方法解决复杂问题，本身就是有价值的工作，先把价值做出来再归纳。

图源：《FDE》（第2页）

九、团队不是一个超级个体，是三个位置

白皮书承认 FDE 对一个人的要求极高：既要把问题挖清楚，又要写出能进生产的代码，还要把经验沉淀成平台能力。这三件事的能力倾向和节奏完全不同：问题定义靠反复沟通，节奏慢；现场构建要快；平台沉淀靠抽象收敛，需要长期视角。

所以它的落地形态是一组人，对应 Palantir 的 Echo、Delta、Dev 三类角色。Echo 是部署策略师，回答什么值得解决；Delta 是前线部署工程师，回答怎么在现场做出来；Dev 是平台工程师，回答哪些能沉淀。

团队规模是中小型项目 1 到 3 人，大型项目 8 到 15 人。

位置之间是职责差别不是职级差别，三类角色没有上下级，只有不同视角。

协作里有结构性张力：Echo 追求做正确的事会踩刹车，Delta 追求正确地做事会踩油门。白皮书的看法是，这些张力不该被消除。

图源：《FDE》（第3页）

十、四个案例与三个提醒

四个案例分别是金融测试、金融开发、医疗院感和能源发电，共同点是问题都横跨业务理解、工程实现与组织协作。金融测试用三层本体（业务、测试、应用）加测试中间表示，把需求、规则、设计、案例和执行结果双向关联。

医疗那个例子更典型：判断难以一致，是因为缺一个显式的感染事件对象；解法是把事件建模，让结论能回到原始记录。

能源案例的核心是把专家经验瓶颈转成本体与智能体协同的问题，大模型负责规划解释，小模型负责执行反馈。提醒一，这套东西的前提是有现场。没有驻场，本体建不出来，评测集也攒不出来。

提醒二，人机分工要分四级。模板化、规则明确的交给 AI 全自动，涉及核心链路与正式结论的必须人主导，研究探索先离线验证。

提醒三，别把 FDE 当万能岗。白皮书自己说，三个维度都想做深，通常的结果是三个都做不深。