把FDE嵌进国企：用Echo、Delta和Dev打通AI交付

国企缺的不是一个叫FDE的万能岗位，而是一套让业务、信息化建设和平台团队围绕同一结果共同工作的交付结构。

一家国企启动AI项目，通常会走过一条熟悉的路径：业务部门提出需求，信息化建设部门组织立项和采购，供应商完成方案、开发和部署，业务部门最后验收。

等系统真正进入现场，问题才开始出现。业务人员发现AI不理解那些从未写进制度的例外；供应商发现接口、数据和权限与调研时不同；信息化建设部门可以协调系统，却无法替业务部门决定哪些结果可以接受、哪些风险值得承担。每个人都完成了自己的工作，系统却没有形成可持续运行的业务能力。

这正是Forward Deployed Engineering重新受到关注的原因。但国企如果把FDE理解成一个“既懂业务、又懂模型、还能写代码”的新岗位，很可能只是把原来的接力链压到一个人身上，制造新的单点依赖。

Palantir给出的更有价值的启发，不是招聘一个超级工程师，而是把前线交付拆成三种相互配合、又相互制约的角色：Echo、Delta和Dev。

FDE不是一个人，而是一套三角色结构

Palantir当前官方角色体系把人员分为Echos、Deltas和Devs。

Echo负责“赢”。它从客户使命和一线工作倒推问题，识别真正限制结果的环节，拆解工作流，协调管理者、专业人员和使用者，并推动系统进入实际采用。

Delta负责“建”。Palantir把Forward Deployed Software Engineer归入Delta。它直接处理数据、代码、系统集成和生产约束，保证方案不只存在于演示中，而是在真实环境里工作。

Dev负责“产品化”。它把Echo和Delta在现场反复验证的做法沉淀进核心平台，让下一次交付不必从头开始。

三类角色的边界不是绝对隔离的。Echo也需要技术理解，Delta也必须理解业务，Dev也不能脱离现场。但它们不能被合并成一个没有制衡的万能角色。

如果只有Echo，团队容易形成漂亮方案，却无法面对生产系统；如果只有Delta，团队可能迅速写出代码，却优化了错误的问题；如果没有Dev，每次现场成功都会变成一套新的定制分支。

FDE真正要建立的，是一条从业务使命到现场工程，再从现场工程回到平台能力的反馈回路。

这里也需要划清证据边界：Palantir的招聘与角色页面能够说明它如何定义和组织这些角色，不能直接证明这套结构移植到国企后一定有效。下面提出的是一套需要通过试点验证的组织设计，不是成熟度已经得到普遍证明的标准答案。

原来的建设流程并非没有道理

国企传统信息化建设采用需求、立项、采购、开发、测试、上线和验收的阶段式流程，并不只是因为组织保守。

当企业建设财务、采购、ERP或生产管理系统时，产品边界相对稳定，需求可以在建设前较充分地说明，供应商能够按照功能清单报价，信息化建设部门可以通过进度、功能和文档组织验收。专业分工把大规模系统建设变成了可以采购、管理和追责的工程。

这套流程还承担着国有资产管理、采购合规、数据安全、生产安全和审计留痕等责任。FDE不能以“敏捷”为名取消这些边界。

AI改变的不是治理责任，而是发现问题和修改系统的成本结构。

模型让原型出现得更快，却没有让业务语境自动变清楚；生成代码的成本下降了，验证结果、识别例外和承担后果的成本反而更加突出。很多需求只有AI处理真实任务后才会暴露，很多风险也只有系统接触真实数据、权限和用户后才会出现。

所以，国企需要改变的不是“要不要审批”，而是审批依据何时产生。过去主要依靠需求文件和功能清单放行，FDE式交付要让每个阶段都拿出运行证据，再决定是否扩大权限和范围。

国企需要三角色、两条责任线

把Palantir体系放进国企，不能把三个英文名称直接变成三个新岗位。更合适的做法，是先明确两条不能混淆的责任线。

第一条是业务结果责任线。业务负责人决定什么结果值得改变、什么例外可以接受、什么权力可以交给系统，并对最终经营和管理后果负责。

第二条是信息化建设责任线。信息化建设部门负责技术架构、数据和系统接入、生产环境、安全控制、运行保障以及平台能力沉淀。

Echo、Delta和Dev运行在两条责任线之间。

Echo最好来自业务与数字化的交叉地带。它可以是懂信息化的业务骨干，也可以是长期服务某一专业的产品负责人，但必须能进入现场、理解数据，并有能力把“大家觉得有用”变成可以验证的结果标准。

Delta主要来自信息化建设部门、内部数科公司或专业工程团队。它必须具备生产级编码、数据工程、系统集成和AI评测能力，同时获得足以解决问题的环境与接口权限。只让Delta查看脱敏样例、等待层层转述，FDE不会真正发生。

Dev一般放在集团信息化建设部门或内部数科公司的平台团队。它不直接承包所有业务场景，而是服务多个前线小队，把重复出现的数据连接、权限控制、模型调用、评测、监控和回滚机制做成共性能力。

业务负责人不属于Palantir三角色之一，却是国企实践中不能省略的责任锚点。Echo可以推动采用，不能替有权主体作出经营决定；Delta可以实现动作，不能自行决定企业愿意承担什么后果。

一支小队不需要很大

国企不必一开始就成立几十人的FDE中心。更稳妥的起点，是围绕一项高价值任务组成一支六到八人的小队：

• 一名Echo，持续在业务现场工作；
• 两到三名Delta，覆盖AI应用、全栈开发和系统集成；
• 一到两名一线业务专家，提供真实规则、例外和验收判断；
• 一名数据或本体工程师，处理对象、口径、关系和数据质量；
• 平台、安全、法务、审计和运维人员按证据门共享介入。

小队之外，还需要一名拥有业务授权的场景责任人，以及一个服务多支小队的Dev平台团队。

这不是把各部门代表集中到一个群里。小队成员要共同面对同一批真实任务、同一套评测案例和同一个结果指标。Echo不能每周收集一次需求，Delta不能等需求冻结后才开始开发，业务专家也不能只在最后验收时出现。

不从场景清单开始，从一项使命开始

很多AI规划先收集几十个甚至上百个场景，再按价值和可行性排序。这有利于形成投资视图，却不适合直接作为FDE任务。

FDE需要的不是“建设合同审核助手”这类功能名称，而是一项能够走到结果的明确使命。例如：在不降低合规要求的前提下，把一类标准合同的初审周期从三天缩短到一天，并让所有升级、退回和人工修改都可以追溯。

一项适合首批实践的使命，通常同时满足几个条件：发生频率足够高，当前结果可以测量，数据基本可获得，错误可以被发现和回退，有明确业务负责人，而且范围足够小，能够在三个月内经历真实运行。

国资委深化中央企业“AI+”专项行动强调战略意义强、经济收益高、民生关联紧的高价值场景。这里的“高价值”不能只在立项材料中出现，而要被翻译成项目开始前的基线、项目运行中的指标和项目结束后的证据。

用五道证据门代替一次性验收

FDE强调快速进入现场，但快速不等于边建边上线。国企可以保留原有治理要求，同时把一次性项目验收改成逐级扩大权限的五道证据门。

使命门

首先确认业务负责人、现状基线、目标结果和停止条件。如果没有人对业务结果负责，或者现状根本无法测量，项目不进入开发。

数据与权限门

确认数据来源、分类分级、使用目的、环境边界和最小权限。敏感数据、重要数据和生产系统写权限不能因为项目处于试点阶段就默认开放。

评测门

使用历史真实案例建立评测集，至少包含正常案例、边界案例、不可接受后果和必须升级给人的情况。原型演示成功不构成通过，只有结果达到约定标准，才允许进入影子运行。

运行门

系统在真实任务旁路运行，先不给它最终动作权。团队比较AI结果、人工结果和后续业务结果，观察员工是否采用、错误能否被发现、异常是否有人接管。证据充分后，再开放有限生产范围。

复用门

扩大应用前，不仅检查业务收益，还要检查留下了什么资产：企业自己的对象和规则、评测集、权限矩阵、运行手册、监控指标，以及可以回到Dev平台的通用连接器和治理组件。

这五道门没有取消立项、采购、安全评审和有权决策程序。它们改变的是治理发生的位置：从项目末端检查材料，转为在系统每次扩大范围和权限前检查证据。

涉及重大投资、重要制度调整、生产控制或其他重大事项时，企业仍应按照事项性质履行党委前置研究讨论、董事会或经理层决策、采购、审计及行业监管程序。FDE提供新的运行证据，不能替代有权主体作出正式决定。

信息化建设部门要从中转站变成连接器

在传统项目中，信息化建设部门经常承担需求汇总、供应商协调、项目管理和验收组织。它连接了所有人，却未必有足够工程力量直接修改系统。

FDE体系要求它增加两种能力。

一种是前线工程能力。信息化建设部门要能够派出Delta，与业务人员共同调试数据、代码、接口和评测，而不是把所有技术变化继续转交供应商。

另一种是平台产品能力。Dev团队要持续判断：哪些变化只属于当前企业和当前场景，哪些问题会在多个场景反复出现。前者进入业务本体、规则和评测，后者进入企业级连接器、权限、监控和开发平台。

这不会削弱信息化建设部门，反而使它从项目流程的组织者，转变为业务现场与企业平台之间的能力连接器。

采购和合作方式也要随之改变

如果合同仍然只按功能清单、人员数量和上线日期验收，供应商就会自然回到需求接力模式。

FDE项目可以在现有采购和内控制度内，把探索期与规模建设期分开：探索期验证问题、数据和结果，规模建设期再明确范围、投资和长期责任。外部团队的验收物也不应只有代码和文档，还应包括评测集、权限配置、运行记录、复用组件和内部人员独立运行能力。

这不是绕过采购程序，也不是用模糊的“效果付费”替代必要的范围和责任约定。它只是承认AI场景在进入真实工作前存在较高的不确定性，并用阶段证据减少一开始就把错误假设固化进大合同的风险。

三类人才要分开培养

国企很难直接招聘到大量同时精通行业、组织和AI工程的人。Palantir三角色体系的价值之一，就是不再等待这种全能人才。

Echo的培养重点是现场观察、工作流拆解、价值测量、技术判断和利益相关者协调。适合从懂数字化的业务骨干、行业产品经理和长期服务一线的信息化人员中选拔。

Delta的培养重点是生产级代码、数据工程、企业集成、AI应用、评测、安全和故障处理。适合从ERP、MES、数据平台、集成开发、算法工程和SRE团队中选拔。

Dev的培养重点是平台架构、产品抽象、多租户与权限、可观测性、组件复用和开发者体验。它需要理解现场，但考核不能只看完成了多少项目，而要看减少了多少重复建设。

三类人员需要共同轮岗，却不应使用同一套评价标准。Echo主要看业务采用和结果闭环，Delta主要看生产交付和可靠性，Dev主要看复用率和平台杠杆。安全、合规和重大生产事故则应作为共同红线，而不是可以用业务收益抵消的普通分数。

先用两个任务验证这套机制

国企第一次引入FDE，不需要先画完整组织图。可以从两项任务开始。

第一项任务验证闭环：Echo能否找到真正的问题，Delta能否在三个月内把它带到受控生产，业务负责人能否根据运行证据决定继续、收缩或停止。

第二项任务验证复用：第二支小队能否直接使用第一项任务留下的连接器、评测框架、权限模板、监控能力或交付方法。如果第二次仍然完全从头开始，说明企业得到的只是一次高水平定制，还没有形成FDE体系。

评价试点时，至少看四组结果：业务周期、质量和成本是否变化；员工是否持续采用；系统在异常、升级和回滚时是否可靠；项目人员退出后，企业能否继续运行和改进。

FDE成功的标志，不是企业拥有了多少名FDE，而是业务问题出现时，Echo、Delta和Dev能够快速形成闭环：有人定义值得改变的结果，有人把它建成可运行系统，有人把重复经验沉淀为企业能力。

过去，业务把需求交给信息化建设部门，信息化建设部门再把项目交给供应商。

未来，业务与信息化建设仍然各自承担责任，但不再隔着文档和阶段门等待对方。它们围绕同一项使命共同观察现场、修改系统、验证结果，再把一次成功写进企业平台。

这才是Palantir FDE体系对国企真正有价值的地方：它不是创造一个新岗位，而是重新组织业务结果、现场工程与平台积累之间的关系。