我知道国内有一拨人在做 FDE 培训，可他们自己根本没做过企业交付，现在倒好，已经开始批量教别人怎么做 FDE 了。

原来的售前、实施、驻场外包，统统换了个 FDE 新名字上岗，进到客户公司以后还是先问数据库有几个、接口什么时候开、表结构什么时候给。

等上客户几周，拿到几张脱敏表，赶一个大屏，接一个模型，最后开会演示：你看，AI 已经完全进入并且理解公司的业务了。

老板点点头，大家拍张照，散会以后没人再打开。

FDE 名字是硅谷的，交付还是那套没人用的东西，说它是企业 AI 落地，我反正不认。

先别急着谈本体论，先说说我觉得 AI Native 到底是什么

现在很多公司都喜欢说自己在做 AI Native。

给员工买一批 AI 账号，OA 里塞个问答框，知识库能写两段文案，马上就开始讲 AI Native 转型。

照这么算，凡是买过大模型 API 的公司都已经转型成功了，那这个词也就没什么牛逼可以吹了。

Microsoft 提了一个 Frontier Firm，它说企业大概要这么走：刚开始，人只是多了一个 AI 助手；再往后，人和 Agent 一起干活；最后，人来定方向，Agent 去跑一部分业务流程，中间真遇到拿不准的事，再把人叫回来。

OpenAI 讲得也还算实际：AI 得拿到公司的业务背景，得连上数据和内部系统，真正在流程里做事，而且它做了什么，有人能看见，能审计，也能判断结果到底好不好。

Salesforce 意思也差不多：人来判断，Agent 去执行，底下那套平台负责把数据、权限、规则和工作流接起来。

你把这几种说法放在一起看，就会发现 AI Native 的根本，是 AI 已经进到具体工作流程里了。

以前一个人要打开五六个系统，自己找信息、核对、判断、点按钮、追结果，现在其中一部分活可以交给 AI。

可 AI 也不能瞎干，它得知道自己在帮谁、这件事到底要解决什么、哪些数据可以看、哪些按钮可以点，做完以后又拿什么结果来验收。

问题来了，一家已经运行十年、二十年的公司，哪有那么容易改？

客户资料在 CRM，合同和发票在 ERP，库存放在 WMS，设备数据在 MES，员工还得靠 Excel、邮件和微信群去补系统留下的洞。

每套系统都有自己的账号和权限，有些字段为什么这么填，可能全公司只有几个老员工讲得清。

你总不能跟老板说，想做 AI Native，就把这些东西全扔了，我们重新建一遍。

真这么干，AI 还没上线，公司先停摆了。

你也不能说等数据治理全部做好再开始，那多半就是一直等，一直不开工。

所以别想着一口把整家公司吞下去。先挑一类员工，再挑他每天反复遇到的一件事，把其中一个决定改掉。

这个小闭环跑通了，确实省了时间、少了错误、赚到了钱，再往外扩。

老公司做 AI Native，大概只能这么干。

说到这里，有一句话必须记住，后面讲本体论、讲 FDE、讲五天交付，其实全围着它转：

哪一类员工，面对哪一类具体问题，需要看到什么信息，做出什么决定，随后执行什么动作，最后用什么结果判断它有没有价值。

这句话要是写不出来，后面那些东西就先别吹了。

做出来的可能是聊天机器人，可能是内部培训，也可能是一套领导来参观时挺好看的大屏，但公司的工作到底有没有变，没人知道。

好了，现在可以讲 Palantir 的本体论了

Palantir 官方把 Ontology 定义成企业的“操作层”。

听着还是挺抽象，对吧？

说人话就是，本体论就是一张能干活的公司地图。

它就像把送一单外卖，需要的人、信息流转事件，全部放进一张可以直接操作的地图里。

你点开这笔订单，就能看到顾客在哪、餐做好没有、骑手走到哪、有没有超时，出了问题还能直接催单、换骑手或者退款。

拿发票来举个例子，客户说某笔钱不该收，员工得去翻合同、订单、服务记录、SAP 里的发票，再看看 Salesforce 里以前聊过什么，最后才能判断这次该批准、该驳回，还是让客户补材料。

以前信息看不全，又着急结案，最省事的办法往往就是给客户打折，钱就这么一点点流失掉了。

放到本体论里，客户、合同、订单、服务、发票，这些叫对象；

金额、日期、争议状态，这些是属性；

订单和合同怎么对应，这是关系；

批准、驳回、修改付款日期，这是动作；

谁能看、谁能改、多少钱以上必须找主管，这就是权限。

原来数据库里那些表名、字段和 ID，到这一步才变成员工能看懂、AI 能调用、权限系统也管得住的业务世界。

争议专员打开一个待办，能直接看清为什么收费、合同是怎么约定的、服务中间有没有变，不用自己在十几个系统里来回翻。AI 也不用对着几段临时拼出来的文本在那里猜。

但这事儿还没完。

本体论不能只放“名词”，还得有“动词”。

员工点了批准，案件状态要回到 Salesforce；付款日期变了，要写回 SAP。

写失败了得有人接，写成功了也得留下记录，后面还得知道这个决定到底带来了什么结果。

Palantir 对这一点看得很重。

数据仓库把数据送到报表，差不多就收工了；本体论还得往前走，让人和 AI 真做决定，再把动作送回生产系统，结果回来以后，下一次判断还能接着用。

所以只有客户、订单、发票这些“名词”，没有批准、修改、写回这些“动词”，那不叫本体论落地，顶多是数据中台换了个皮。

Agent 要是接不到真实生产系统，也别讲什么改变业务了，它就是一个会聊天的 PPT。

这样再看 Palantir 为什么快，就容易多了。

数据接入这些脏活，它也躲不过，客户照样要开网络、给账号、给字段权限，业务人员照样得解释那些奇怪的行业规则，往生产系统里写东西，失败、回滚、审计一样都少不了。

但 Palantir 已经把连接器、权限、对象、动作、审计这些反复要做的东西放进平台里了。

工程师拿到数据以后，不用先花几个月搭架子，可以直接盯着那件真正值钱的事：这个决定，到底要不要改，怎么改。

五天交付，交的到底是什么

Palantir 那个发票争议案例，前后接了 SAP、Salesforce、合同、订舱和多个旧系统。

按它自己的说法，项目做了 1 到 6 个月，后来每年多收回 5000 万美元以上，客户问询量还少了大约 10%。

当然，这是 Palantir 自己公布的案例，金额有没有这么多不知道，但至少有一件事说清楚了：

客户掏钱买的是那些不再漏走的钱，Ontology 这个单词本身一分钱都不值。

Palantir 的 AIP Bootcamp 还经常讲“5 天以内从 0 到用例”。这句话到了国内，讲着讲着就变成了一个工程师进场，五天跑通项目，客户当场签单，听起来跟爽文差不多。

五天当然改造不了一家公司，也不等于五天签单。

它要做的，就是拿真实数据跑出一条很窄的闭环，让客户亲眼看见，这件事继续做下去是值钱的。

至于稳定数据接口、补权限、清理数据、处理写回、培训用户，这些活该做还得做，往往又是几周、几个月。

采购、安全、法务、合同，更是另一只钟，拖上半年甚至一年也不奇怪。

一家财富 100 强消费品公司有至少 7 套 ERP。

Palantir 团队没去接“统一集团所有 ERP”这种无底洞任务，它就盯着一个决定：一张物料清单里，有没有更便宜、又不影响生产的替代原料？相关数据拉进工作流，5 天有了能跑的东西，一周内采购人员开始使用。

Panasonic Energy North America 的首个用例大约用了一个月，原来四小时的流程，后来压到 15 分钟。

还有一个电网本体，第一版做了差不多 12 个月，等它被做成行业库，后面的部署才缩到数周。

你看，根本没有什么“所有项目五天搞定”。

Palantir 真正快的地方，是它能先用几天证明某个决定值不值得改，第一次花一年啃下来的东西，也不会扔在项目里吃灰，而是做成积木，下一个项目接着用。

速度就是这么一点点攒出来的。

国内很多团队恰好反过来，一开口就是集团级 AI 平台，几十套系统一起接，目标大得根本没法验收。

工程师忙着堆页面、接模型，老板等着 AI 改造全公司，一线员工呢，第二天还得打开 Excel 和微信，把手里的活先干完。

差别就在这儿。一个在改业务里的决定，一个只是在给项目堆功能。

反推 SOP

Palantir 没公开过一份叫《FDE 七日 SOP》的内部手册。

下面这套东西，是我顺着它的用例生命周期、Bootcamp 和公开案例倒着推出来的，未必和它内部一模一样，但国内团队真想做交付，完全可以拿去试。

工程师进场以后，先去找那个每天真干活的人。

看看他怎么在 ERP、Excel、邮件和微信群之间搬信息，哪里天天等，哪里最容易出错。

看明白以后，把“建设智能系统”这种大话压成一个具体决定，先把结果定下来，再去拿这条闭环真正需要的数据。

数据进来了，眼前要用哪些对象、关系、动作和权限，就先做哪些。

界面一出来，马上让真实用户处理一条真实任务，批准也好，拒绝也好，纠正、升级都行，反正不能让他只坐在那里看演示。

动作要送回原来的生产流程，最后再看时间有没有少、错误有没有降、收入成本有没有变化、第二天还有没有人继续用。

真跑通了，再去补稳定性、安全、审计和规模化。

项目里做出来的连接器、对象模型和工作流，也得收回产品里。

要不然客户 A 做一套，客户 B 再做一套，工程师一走，公司又从头开始，这不还是外包吗？

所以这套 SOP 说复杂也复杂，说简单也真简单，就是反复把那句话填完整：谁遇到了什么问题，他得看什么信息，做什么决定，接着做什么动作，最后到底改了什么结果。

FDE 守的就是这条线。哪儿断了，他就去补哪儿。

最后再说 FDE：这事儿一个人根本干不了

国内现在有个很大的误会，以为招一个既懂技术、又懂业务、还能驻场沟通的人，公司就有 Palantir 那种能力了。

结果这个人白天开需求会，晚上写连接脚本，还得自己等权限、洗脏数据、猜业务规则、做大屏，最后让他为一套没人使用的系统负责。

可 Palantir 的 FDE 身后不是空气。

那里有 300 多项服务和资产，有做数据、权限、安全和产品的人；

客户那边也得有人对业务结果负责，得有熟悉旧系统的业务骨干，还得把真正使用系统的一线员工拉进来。

现场做出来的通用东西，最后还会回到产品里，下一个项目继续用。

国内倒是省事，只抄了最容易抄的那部分：驻场。

成熟平台删掉，真实数据删掉，业务负责人和一线用户也删掉，写回权限没有，产品回灌更别提。

最后只剩一个工程师坐在客户办公室里，职位叫 FDE。

没做过交付的人为什么也能出来培训 FDE？因为只要不谈真实数据，不谈生产动作，不谈结果和复用，剩下的全是名词，背几天就能讲。

需求访谈怎么做、业务流程怎么画、PoC 怎么包装，都能讲得头头是道。

可一到真问题就没声了。

客户不给权限，谁去推动？业务部门不愿意对结果负责，谁来拍板？写回生产系统出了错，谁兜底？试点会上人人叫好，回去一个人都不用，要不要停？

这些问题没答案，培训证书做得再漂亮也没用。

FDE 说白了，就是整家公司交付能力伸到客户现场的最后一截。

表面上看，是一个工程师在客户那里干活，背后站着的却应该是产品、平台、数据、安全、业务负责人和一线用户。后面什么都没有，他就是个换了名字的驻场工程师。

所以我还是那句话，国内 99% 的所谓 FDE，都是扯淡。

机器没有，闭环没有，结果没有，自己甚至都没做过交付，倒是先用硅谷发明的职位名称培训起下一批人了。

这跟企业 AI 落地有什么关系？

没有关系。

这就是一场 FDE cosplay。