FDE 落地实施手册
宏观中观篇：值不值得做，往哪个方向做

这套材料现在共四份，各管一层。读的顺序按角色走，不按编号走。管理层与业务负责人从本册开始；定了要做，项目组才需要翻卷三；卷一卷二是弹药库，用来回答"凭什么信"。

三层判断，各判什么：一个容易混的点，先说清

三层工具问的问题看起来相似，其实判断的对象和要做的决定各不相同——这也是它们不能合并成一份问卷的原因：微观六题测的三样性质（规格能否提前写清、关键信息在哪、错了能否撤回）只有场景具体化之后才存在；而量与价值又必须在任何人投入两周去定义场景之前问清。是颗粒度逼着这三刀分开切。

宏1　FDE 是什么、从哪来

FDE（Forward Deployed Engineer，前线部署工程师）不是一个新岗位名，而是一种把工程能力放进业务现场、把"从问题到方案运行起来"整条走完的工作方式。它起源于 Palantir：二十多年前，美国情报与国防体系面对的困境是多个机构的数据长期互不联通、各自的系统沿用多年难以推倒重建。Palantir 的切入方式不是重建那些老系统，而是在既有系统之上织一张数据的网——把分散的数据拎出来、对齐口径、连成可用的整体，并派工程师常驻客户现场把这张网真正用起来。

两点值得注意。第一，这个模式的起源与 AI 无关——它诞生时解决的是数据整合与落地问题；今天它与 AI 强绑定，是因为 AI 恰好把"落地"的难度放大了（详见宏4）。第二，Palantir 把这种工作方式做成了一套可定价、可交付的服务：多少人、多少天、交付什么、收多少钱、售后怎么做，全都说得清——会上引述过一个业内说法："全世界唯一能提供 FDE 服务的公司只有 Palantir，其他都是学徒。"这话有修辞成分（卷一显示各大 AI 厂商都在建自己的 FDE 组织），但它点中了要害：成熟的标志不是有一群驻场工程师，而是这套工作能被清晰地承诺与定价。

宏2　与传统方式差在哪：断点解剖

银行里最熟悉的问题解决方式是"咨询式流水线"：定义问题 → 分析 → 出方案 → 分工到人、定时间 → 交付，结束。这套方式不是不好，而是有一类问题它天然做不完——凡是方案要落到数据与系统上的，它就会在交接处断掉。

FDE 的定义可以反着这张表来说：从问题出发，一直做到解决方案运行起来为止，全程都算工作范围；按最高标准完成——自带自动化的数据流程与评估体系。要做到这一步，只靠业务的人不行，只靠写方案的人也不行——必须有工程师加入，业务、科技、前置工程师三方把整条流程从前到后一起走完。断点接不上的地方，正是 FDE 存在的理由。

宏3　该借鉴的"真东西"

我们不是要照抄 Palantir 的组织名词，而是要借三样底层的东西：

• 织网，不重建。面对沿用多年的老系统与不通的数据，第一反应不是"推倒重来"，而是在其上建一层统一的口径与关系（Palantir 称之为 ontology，本系列译作"口径与关系层"）——把数据拎出来用，让老系统继续干老系统的活。这是所有大型机构做 AI 的现实路径。
• 可定价的确定性。能说清"多少人、多少天、交付什么"，背后是方法论与资产的复用——每做一个场景，题库、组件、口径表都沉淀下来，下一个场景才能报得出更低的价。确定性是资产化的外在表现，这正是卷三 S10"第二个场景省不省"那个读数的来源。
• 驻场的在场剂量。关键信息在一线的工作流里，不在文档里——所以工程师必须坐进业务现场（卷三 S4 陈工的第一天就是这条原则的日志版）。

宏4　为什么 AI 时代绕不开它

会上形成了一个判断，值得原样记录：不用 FDE 这种方式，企业可能就走不到 AI。理由是两个反面都已经看得见：

反面一：AI 能力接不进业务。模型与平台（包括总行工银智涌）提供的是通用能力；但每个业务的口径、流程、判断边界都在现场，没有人把两头缝起来，AI 就停留在演示里。缝合正是 FDE 的本职。

反面二：接进去了，没人管。会上举了一个警示例子（已匿名）：某同事私下搭了个知识库机器人，天天在用，部门没人知道——它答得对不对、口径归谁维护、出了事算谁的，全都没有答案。原来是人乱，现在是 AI 乱——AI 的能力如果不在制度之内释放，释放出来就是每天制造麻烦的乱源。所以本册把一条治理原则放进宏观层：上线一个 AI 工作流，等于全行多了一条运行中的业务流程资产——它必须登记、有人拥有口径、留痕可查、能被质询、能被安全地修改与下线。知识库同理：前线用的知识库与对客用的知识库要不要统一，可以讨论；但"它们被管理"这件事，没有讨论空间。

宏5　管理层的四问筛选器

FDE 不是普适的工作方式。改一版薪酬办法、给培训供应商重新招标、办一场一次性活动——这些照常规方式做就好，引入 FDE 是浪费。管理层需要的是一个能挂在嘴边的筛选器：

中1　业务扫描问卷（十题，业务负责人自填）

卷三的六题自测偏微观——它判断的是"这个已经具体化的场景该用什么方式交付"。会上提出的要求是往前一步：业务负责人拿着一件还没想清楚的事，答完一份问卷，就该知道值不值得进入立项论证、归哪一类。下面这十题就是那份问卷：前八题采集业务事实（条线量级、对客距离、产出物、监管审批、数据现状），后两题确认重复性与治理承诺。答完自动给出判定与类别建议。

从用途看，这十题横跨两个拍板点：量、价值、断点、重复性与治理承诺五题是宏观四问的打分版，为拍板①"进不进论证"提供纸面证据；产出物、对客距离、监管审批与数据现状四题是归类器，服务拍板②"定类别与人"。

中2　类别菜单与六张毛坯卡

会上的设想：将来行里有了 FDE 团队，工程师被派到一个场景时，手上应该先有一份菜单——问题属于哪一类、这一类的方法论是什么、通常断在哪、能沉淀什么。下面六张卡就是那份菜单的第一版。每张卡是一个"毛坯"：拿到卡，方向就定了七成；剩下三成的细刻，在卷三。

来件 → 语义理解 → 判定：这个问题答过吗？
 ├ 答过，且经多轮反馈验证、近期无口径更新
 │    → 直接给出既有答案（附出处）＋ 员工勾选确认 ＋ 留工作日志
 └ 没答过 → 问题分析
      ├ 知识库可覆盖 → 草拟答复（员工把关后发出）
      ├ 需要人工判断（新问题／内控合规） → 转人工，答案回流知识库
      └ 属产品规则且无已发布口径 → 草拟"转询"给对口部门，不自答

中3　把方向固化成"技能"

毛坯卡不只是给人看的——它同时是给 AI 的。会上的表述很准确：AI 需要被固定思维。每张毛坯卡对应一组可复用的"技能包"（类似智能体的 skills）：这一类问题怎么拆、先查什么后做什么、什么情况必须停下转人。工程师带着技能包进场，遇到卡里没有的新情况，就现做一个新技能补进去——而不是靠个人临场发挥。FDE 工作的稳定性由三样东西保证：判断标准（宏观四问＋中观问卷）、类别方法论（六张毛坯卡）、可复用资产（题库、组件、口径表）。三样都在增长，每个新场景才会比上一个更快、更省、更稳——这正是卷三 S10 那条成本曲线往下弯的机制。

中4　组织与派单：三层怎么接

设想将来行里有一支 FDE 团队（会上举例：二十人、分几个级别——数字为讨论中的设想），三层的接口就是一条派单流水线：