Palantir FDE：把工程师放进任务现场，而不是把AI塞进会议室

Palantir FDE：把工程师放进任务现场，而不是把AI塞进会议室

原创

Huan

Huan

HuanHannah科研学习笔记

在小说阅读器读本章

去阅读

在公众号小说中沉浸阅读

写在前面

很多企业做AI项目，流程都差不多：选模型、搭平台、做Demo、写汇报。然后呢？然后项目就停在了看起来很智能的阶段。

模型很强，平台很全，Demo很炫，但一到真实业务场景就卡住了——数据散在十几个系统里，业务规则比文档复杂十倍，一线人员的工作方式跟PPT里画的完全不一样，最后AI成了会议室里的展示品，进不了任务现场。

Palantir的Forward Deployed Engineering（前置部署工程，简称FDE）提供了另一种思路。这个方法论起源于2003年Palantir成立初期，最初是为了解决一个很具体的问题：产品很强大，但情报分析师不会用。Palantir的解决方案不是写更厚的手册，也不是派更多客服，而是把真正构建产品的工程师派到客户现场，跟他们一起工作。

二十年后，FDE已经从一个应急方案变成了一套完整的方法论，支撑着Palantir在医疗、航空、制造、能源、国防等领域的数百个项目。这篇文章基于Palantir官方文档和公开资料，从概念、方法论、平台、核心产物到真实案例，系统拆解FDE到底是什么，以及国内企业可以从中学到什么。

01 企业AI落地的真正难点，不在技术，而在现场

在讨论FDE之前，先看一个普遍存在的矛盾。

今天的AI技术已经足够强大。大模型能写代码、能分析文档、能生成方案，开源模型和API的门槛越来越低，任何一个工程师都能在几天内搭出一个看起来很智能的应用。

但企业级AI落地的成功率并没有同步提升。大量项目停留在试点阶段，能真正进入日常运营、产生可衡量业务价值的比例并不高。

问题出在哪里？Palantir的观察是，企业AI的难点通常不在模型能力，而在三个现场GAP。

第一个GAP是数据GAP。企业的数据散落在ERP、MES、CRM、数据仓库、Excel表格、甚至纸质单据里。这些系统的数据格式不一致、口径不一致、更新频率不一致，更重要的是，数据之间的关系没有被建模。AI拿到的不是一个完整的业务世界，而是一堆孤立的表。

第二个GAP是语境GAP。业务规则比文档复杂得多。文档里写的是标准流程，但实际运营中充满了例外、特殊情况、历史遗留的人工操作。AI如果只按文档理解业务，就会在真实场景里不断出错。更关键的是，很多业务知识只存在于一线人员的经验里，没有被显性化。

第三个GAP是执行GAP。很多AI项目止步于给出建议，但真正的价值在于执行动作。建议能不能被系统执行？执行后能不能回写数据？出了问题能不能追溯？没有执行闭环，AI就永远是个顾问，不是操作员。

这三个GAP的共同特点是：它们都不是在实验室里能解决的，必须到任务现场去。这正是FDE的起点——不是把AI部署进企业，而是把工程师放进任务现场。

02 FDE到底是什么：把"人的反向传播"写进方法论

FDE的全称是Forward Deployed Engineering，直译是"前置部署工程"。但这个翻译只说了形式，没说本质。

Palantir官方对FDE有一个更精准的定义：FDE是一种工程方法论，它把产品工程师直接部署到客户的任务现场，与最终用户并肩工作，在真实运营环境中构建、迭代和交付软件。

这个定义里有几个关键词值得拆开看。

"产品工程师"而不是"实施顾问"。传统软件交付模式是：产品团队在总部写代码，实施团队在现场做配置和培训。FDE打破了这个分工——被派到现场的是真正构建了核心平台的产品工程师，他们有权限修改产品代码、有能力解决底层技术问题、有责任把现场发现的问题推回平台。

"任务现场"而不是"客户办公室"。FDE不是坐在客户的会议室里做需求调研，而是进入真正的工作场景——医院的护士站、工厂的车间、航空公司的运营中心、军队的指挥设施。在Palantir早期，工程师甚至需要进入SCIF（敏感隔间信息设施，一种高度安全的情报工作空间），跟情报分析师一起工作。

"并肩工作"而不是"需求收集"。传统咨询模式是：顾问来现场访谈几周，写一份需求文档，然后离开，几个月后交付一个方案。FDE是持续在场——周一到周四在客户现场工作30-40小时，跟最终用户一起解决真实问题，在真实数据上出可运行的原型，用系统跟客户对话，而不是用PPT。

Palantir用一个很形象的说法来概括FDE的核心："人的反向传播"（Human Backpropagation）。

在机器学习里，反向传播是指把预测误差从输出层传回输入层，逐层调整参数，让模型越来越准。FDE做的是类似的事情，但传播的不是梯度，而是"现场真实需求"——从最终用户的实际工作流，传回产品工程师的代码里，再传回平台的功能迭代里。

这个过程不是一次性的，而是持续循环：理解现场→构建原型→用户反馈→修改代码→平台迭代→再回到现场。每一轮循环都让产品更贴近真实需求，也让平台能力更通用。

03 FDE的五步闭环：从现场理解到持续进化

FDE不是一个模糊的"多去现场"的建议，而是一套有明确步骤的工作闭环。基于Palantir官方文档和公开资料，可以把FDE的核心方法论拆解为五个步骤。

第一步：情境感知（Situational Awareness）。

进入现场的第一件事不是写代码，而是理解。FDE需要搞清楚：这个组织的实际工作流是什么样的（注意，不是文档里写的工作流，而是人们实际怎么做的）？数据在哪些系统之间流动？哪些步骤是人工完成的？哪些决策点需要专业判断？哪些痛点是人们已经习以为常、不再质疑的？

这一步的产出是一张"情境地图"——不是正式的流程图，而是对真实运营状态的深度理解。Palantir的经验是，文档记录的工作流和实际工作流往往在多年前就分叉了，只有在现场待足够久，才能看到真实的那一条。

第二步：定义对象与动作（Define Ontology）。

理解了现场之后，FDE需要把业务世界建模成计算机能理解的形式。这就是Ontology（本体）——定义这个业务场景里有哪些核心对象（比如医院里的患者、床位、护士、设备、药品），对象之间有什么关系，以及可以对这些对象执行什么动作（比如"分配床位""调整排班""下达医嘱"）。

Ontology是FDE最核心的产物，也是AI能从"给建议"升级到"能执行"的前提。没有Ontology，AI看到的只是一堆数据表；有了Ontology，AI才能理解"这是一个等待床位的患者，那是一张即将空出的ICU床位，它们之间可以发生分配这个动作"。

第三步：构建工作流（Build Workflows）。

有了Ontology之后，FDE开始在真实数据上构建可运行的工作流。这一步强调"第一天就出可运行代码"——不做PPT，不写需求文档，直接在真实数据上出原型，让客户能马上看到、摸到、用到。

工作流的构建是迭代式的：先做最小可用版本，给一线用户试用，收集反馈，当天就改。FDE的工作节奏是"在现场构建，在现场验证"，而不是"在总部开发，在现场验收"。

第四步：执行与写回（Execute and Write Back）。

这是FDE与传统AI项目最大的区别之一：不只是给出建议，而是真正执行动作，并把执行结果写回业务系统。

比如，AI不只是说"建议把患者A分配到床位3"，而是真的在系统里执行"分配床位"这个动作，更新床位状态，通知护士，记录操作日志。如果执行出了问题，能追溯、能回滚、能审计。

执行闭环让AI从"顾问"变成了"操作员"，这才是真正的业务价值所在。

第五步：反馈抽象（Feedback and Abstraction）。

FDE的最后一步是把一次项目中发现的共性问题，提炼成可复用的平台能力。这是"人的反向传播"的关键环节——现场学到的东西，不能只停留在这一个项目里，而要回流到平台，让所有客户都受益。

Palantir有一个经典案例：有一个部署有50多条数据管道每天运行，监控是噩梦。几个亲身经历过这个痛点的FDE工程师，就建了一个管道监控工具，后来部署到了多个站点。Palantir最好的产品想法，往往来自在现场待够久的FDE。

这五步不是线性的，而是一个持续循环。每完成一轮，Ontology更完善，工作流更成熟，平台能力更强，下一轮的起点就更高。这就是FDE的"持续进化"机制。

04 平台底座：为什么FDE不是"一个人在战斗"

FDE听起来像是"派几个工程师去现场"，但如果只有工程师，没有平台支撑，那就是传统的外包定制开发，做一个项目累一个项目，无法规模化。

Palantir的FDE之所以能规模化，是因为背后有一套强大的平台底座。FDE工程师不是从零开始写代码，而是在平台上快速组装、定制和迭代。这套平台底座由三大产品构成。

Foundry：数据与运营底座。

Foundry是Palantir的核心数据平台，负责数据接入、清洗、转换、建模和治理。它的核心能力是把分散在各个系统里的数据，整合成一个统一的、可理解的、可计算的数据资产层。Foundry不是一个简单的数据仓库，而是一个"数据运营平台"——它不仅存数据，还管理数据的血缘、质量、权限和生命周期。

对FDE来说，Foundry提供了数据基础。工程师不需要花大量时间写数据管道，而是可以快速接入数据、构建Ontology、在真实数据上出原型。

AIP：人工智能平台。

AIP（Artificial Intelligence Platform）是Palantir的AI平台，负责把大模型、机器学习模型和业务系统连接起来。AIP的核心设计理念是：AI不应该是一个孤立的聊天机器人，而应该嵌入到业务工作流里，能读取业务数据、能调用业务动作、能在业务语境里做决策。

AIP提供了12大能力类别，包括数据连接、Ontology管理、逻辑建模、动作编排、Agent构建、工作流自动化、对话界面、仪表盘、安全治理、模型管理、可观测性和开发者工具。这些能力让FDE工程师可以快速构建AI应用，而不需要从零搭建AI基础设施。

Apollo：持续部署与运维平台。

Apollo是Palantir的持续部署平台，负责软件的发布、更新、监控和回滚。它的核心能力是"在任何环境里持续交付软件"——无论是公有云、私有云、还是离线环境，Apollo都能实现零停机的持续部署。

Palantir通过Apollo每周编排数万次发布，这意味着FDE工程师在现场改的代码，可以快速、安全地部署到客户环境里，出了问题也能快速回滚。这种持续交付能力是FDE"快速迭代"方法论的技术基础。

三大平台之上，Palantir还定义了9大能力集（Capability Sets）和6大横向类别（Lateral Categories）。9大能力集包括数据连接、数据治理、Ontology、决策支持、动作执行、工作流、应用构建、AI/ML和开发者体验；6大横向类别包括安全与合规、可观测性、性能、可扩展性、可用性和可维护性。这些能力集和横向类别构成了一个完整的企业级软件能力矩阵，让FDE工程师可以在任何行业、任何场景里快速构建应用。

所以FDE不是"一个人在战斗"，而是"一个工程师 + 一套平台 + 一套方法论"的组合。平台提供通用能力，FDE提供现场定制，方法论提供工作节奏，三者结合才能规模化交付。

05 Ontology：FDE最核心的产物，也是AI能执行的前提

如果说FDE方法论有一个最核心的概念，那一定是Ontology（本体）。

Ontology这个词来自哲学，原意是"关于存在的学问"。在计算机科学里，Ontology指的是对一个领域的概念化建模——定义这个领域里有哪些事物、事物之间有什么关系、事物有什么属性、可以对事物做什么操作。

Palantir把Ontology作为整个平台的核心。在Palantir的架构里，Ontology是连接数据和应用的中间层：底层是各种数据源，中间是Ontology，上层是各种应用和AI。Ontology把底层的技术数据（表、字段、API）转换成上层的业务概念（患者、床位、订单、设备），让AI和应用能在业务概念层面工作，而不是在技术细节层面工作。

Palantir的Ontology由四个核心层次构成。

第一层：Data（数据层）。这是Ontology的基础，负责把各个数据源的数据接入进来，包括数据库、API、文件、流数据等。数据层解决的是"数据从哪里来"的问题。

第二层：Logic（逻辑层）。这一层定义对象的属性、关系和业务规则。比如，"患者"这个对象有姓名、年龄、病情等属性；"患者"和"床位"之间有"分配"关系；"ICU床位只能分配给重症患者"是一条业务规则。逻辑层解决的是"数据是什么意思"的问题。

第三层：Action（动作层）。这一层定义可以对对象执行的操作，以及操作的前置条件、后置效果和权限控制。比如，"分配床位"这个动作需要满足"床位未被占用""患者需要住院"等前置条件，执行后会更新床位状态和患者状态。动作层解决的是"能对数据做什么"的问题，这也是AI能从"给建议"升级到"能执行"的关键。

第四层：Security（安全层）。这一层定义谁能看什么数据、谁能执行什么动作、操作如何审计和追溯。安全层不是事后加上去的，而是内嵌在Ontology的每一个对象、每一个关系、每一个动作里。安全层解决的是"谁能对数据做什么"的问题。

这四层构成了一个完整的Ontology体系。在这个体系里，Ontology不只是一个"数据模型"，而是一个"可执行的业务模型"——它不仅描述业务是什么，还定义业务能怎么运转、谁有权参与、操作如何追溯。

Ontology还有一个重要概念：nouns和verbs。Nouns（名词）指的是业务对象，比如患者、床位、订单、设备；verbs（动词）指的是可以对这些对象执行的动作，比如分配、转移、取消、更新。Palantir的整个平台都是围绕nouns和verbs构建的——应用展示nouns，AI调用verbs，工作流编排nouns和verbs的组合。

对FDE来说，构建Ontology是项目的核心工作。一个好的Ontology能让后续的应用开发、AI集成、工作流编排都事半功倍；一个差的Ontology会让后续所有工作都事倍功半。这也是为什么FDE强调"先理解现场，再定义Ontology"——Ontology必须反映真实的业务世界，而不是反映文档里写的理想流程。

有了Ontology之后，就形成了一个完整的"读写闭环"：AI读取Ontology里的对象和关系，理解业务状态；AI基于业务规则和目标，做出判断；AI通过Ontology里的动作，执行操作；操作结果写回Ontology，更新业务状态；新的业务状态又成为下一轮决策的输入。这个闭环就是FDE方法论的技术核心。

06 从人类FDE到AI FDE：当Agent开始自己做工程

FDE方法论发展了二十年，正在进入一个新阶段：AI FDE。

传统的FDE是"人在现场"——产品工程师亲自到客户现场，理解业务、构建Ontology、编写工作流、执行动作、收集反馈。但人的时间和精力是有限的，一个FDE工程师同时只能服务少数几个客户。随着大模型和Agent技术的成熟，Palantir开始探索一个新方向：让AI Agent来承担部分FDE的工作，这就是AI FDE。

Palantir官方对AI FDE的定义是：AI FDE是一种自主Agent系统，它能在Ontology之上理解业务语境、构建工作流、执行动作、并从反馈中持续学习，从而辅助甚至替代人类FDE完成部分工程工作。

这个定义听起来很抽象，让我们拆开看AI FDE到底能做什么。基于Palantir官方文档，AI FDE具备7大核心能力模式。

1. 数据连接与管道构建。AI FDE能自动识别数据源、构建数据管道、处理数据清洗和转换。传统FDE需要手动写代码连接各种数据源，AI FDE可以根据自然语言描述自动生成数据管道代码，并在真实环境里测试和调试。

2. Ontology辅助构建。AI FDE能分析业务文档、数据库结构和现有系统，自动推荐Ontology的对象、关系和动作定义。人类FDE的核心工作是定义Ontology，AI FDE可以作为"智能助手"，提供初稿和建议，让人类FDE专注于判断和决策，而不是重复劳动。

3. 工作流自动生成。AI FDE能根据业务需求描述，自动生成可执行的工作流。比如，用户说"我需要一个自动分配ICU床位的流程"，AI FDE就能基于Ontology里的对象和动作，自动生成床位分配工作流，包括规则判断、异常处理、通知机制等。

4. 动作执行与写回。AI FDE能直接调用Ontology里的动作，执行业务操作，并把结果写回系统。这不是"给出建议"，而是"真正执行"——AI FDE可以像人类操作员一样，在业务系统里执行分配、转移、更新、取消等操作，每一步都有审计日志。

5. 异常检测与自愈。AI FDE能持续监控系统运行状态，检测异常，并自动尝试修复。比如，数据管道失败了，AI FDE能分析失败原因，自动重试或调整配置；工作流执行出错了，AI FDE能回滚到上一个稳定状态，并通知人类工程师。

6. 反馈学习与持续优化。AI FDE能从人类FDE的操作和用户的反馈中学习，持续优化自己的行为。比如，人类FDE修改了一个工作流，AI FDE能分析修改的原因和模式，在未来类似场景中自动应用类似的优化。这是"人的反向传播"的AI版本——不是人把现场需求传回平台，而是AI自己从现场反馈中学习。

7. 多Agent协作。复杂的FDE任务往往需要多种能力的组合——数据工程、Ontology建模、工作流编排、安全审计、前端开发等。AI FDE支持多Agent协作，不同的Agent负责不同的能力，通过共享Ontology和工作流上下文协同工作。人类FDE则扮演"总指挥"的角色，负责设定目标、审核关键决策、处理AI无法解决的复杂问题。

AI FDE的工作原理可以概括为四步：输入（理解用户需求和业务语境）→ 理解（基于Ontology分析业务对象和关系）→ 判断（基于业务规则和目标生成决策）→ 执行（调用Ontology动作执行业务操作）。这四步形成一个闭环，每一轮执行的结果都会反馈给AI，让它在下一轮做出更好的判断。

需要强调的是，AI FDE不是要完全替代人类FDE，而是要扩展人类FDE的能力边界。人类FDE的核心价值在于深度理解业务语境、做出复杂判断、处理模糊和不确定性、建立客户信任。AI FDE的核心价值在于处理重复性工作、快速生成初稿、持续监控系统、从大规模数据中发现模式。两者结合，才能实现"一个人类FDE + 多个AI Agent"的高效协作模式，让FDE方法论能服务更多客户、覆盖更多场景。

Palantir的AIP平台为AI FDE提供了技术底座。AIP的12大能力类别中，Agent构建、工作流自动化、模型管理、可观测性等能力都是AI FDE的基础。可以说，AI FDE是AIP平台的"杀手级应用"——它把AIP的各种能力组合成一个自主的工程Agent，让AI真正进入企业运营的核心环节。

07 真实案例：FDE在医疗、航空、能源和国防都做了什么

方法论讲得再多，不如看几个真实案例。FDE已经在医疗、航空、制造、能源、国防等领域落地了数百个项目，这里选取几个有代表性的案例，看看FDE在真实场景里到底做了什么。

案例一：医疗——HHS Protect与医院日常运营

2020年COVID-19疫情期间，美国卫生与公众服务部（HHS）面临一个严峻问题：全国医院的数据上报极其混乱。医院通过传真、邮件和格式不一致的电子表格上报数据，联邦政府几乎无法实时掌握全国的疫情状况，更不用说协调呼吸机、个人防护装备（PPE）等关键物资的分配。

Palantir部署了FDE团队，构建了HHS Protect这个集中式数据平台。FDE工程师不是在总部写需求文档，而是深入医院和卫生部门，理解真实的数据上报流程，在几周内就整合了超过6000家医院的数据，创建了实时仪表盘，使联邦政府能够基于数据分配呼吸机和PPE。

这个项目的关键不是技术有多先进，而是FDE团队能在极短时间内理解混乱的真实场景，把分散的数据整合成可执行的决策系统。疫情结束后，HHS Protect的能力被沉淀到Palantir的公共卫生产品中，继续服务于日常的公共卫生管理。

在日常医院运营场景，Palantir for Hospitals产品用Ontology建模患者、护士排班、医疗物资、床位容量等经常实时变化、对驱动患者生命周期至关重要的元素。应用覆盖了连接容量管理、收入周期管理、排班与人员优化、临床护理、供应链等多个领域。这些应用都构建在统一的Ontology之上，而不是各自孤立的系统——床位分配的结果会自动更新护士排班，物资消耗会自动触发供应链补货，患者状态变化会自动通知相关医护人员。

案例二：航空与制造——Skywise与RaceOS

航空业是一个高度复杂、高度实时的行业。一家大型航空公司每天要运营数千个航班，涉及飞机、机组人员、乘客、行李、燃油、天气等无数变量，任何一个环节出问题都会产生连锁反应。

Palantir帮助主要航空公司用Ontology建模航班、飞机、机组人员、排班优化器和其他分散的企业资产，支持当日航班运营和更长期的网络规划。比如，当一个航班因为天气延误时，系统能自动分析这个延误对后续航班、机组人员排班、飞机周转的影响，推荐最优的调整方案，并直接执行相关动作——而不是只给运营人员一个"建议"，让他们手动去十几个系统里改数据。

另一个航空领域的案例是Airbus Skywise。空客通过扩展Palantir标准架构的定制产品，驱动了整个航空生态系统，连接机队数据、维修记录和运营决策。航空公司、维修商、零部件供应商都在同一个平台上协作，飞机的维修状态、零部件库存、航班运营数据实时同步，大大提高了整个航空生态的运营效率。

在制造领域，一个有趣的案例是Andretti Racing的RaceOS。赛车队开发了这个系统，将实时赛车性能数据连接到一系列丰富的AI应用。在赛车比赛中，每辆车每秒产生大量传感器数据，车队需要基于这些数据实时做出策略决策——什么时候进站、用什么轮胎、调整什么参数。RaceOS用Ontology建模赛车、轮胎、燃油、赛道、天气等对象，AI应用基于实时数据做出决策建议，甚至直接执行某些调整。这是FDE方法论在极限实时场景下的应用。

案例三：能源与国防——从战场到电网

能源行业也是FDE的重要应用领域。美国最大的公用事业公司用Palantir平台实现电力运营和野火响应，连接电网数据、气象信息和现场资源调度。在野火季节，系统能实时监控火情、预测火势蔓延、协调电力切断和恢复、调度维修资源——这些决策涉及大量数据和多个部门，传统的人工协调方式根本无法应对。

在能源生产领域，Palantir覆盖油气、可再生能源等领域，整合设备传感器、生产计划和维护记录，优化运营效率。比如，一个油田有数千口井，每口井的产量、压力、温度、维护状态都在实时变化，系统能基于这些数据预测设备故障、优化生产计划、自动调度维护资源。

国防是FDE的起源领域，也是FDE方法论最成熟的应用场景。Palantir 2003年成立，最初聚焦反恐情报分析。当时面临的挑战是：产品很强大，但很难用——情报分析师的工作方式高度个性化，标准软件手册无法满足他们的需求。Palantir的解决方案是激进的：不是派支持工程师或实施顾问，而是派真正构建了Gotham核心平台的产品工程师，让他们花几个月嵌入情报分析师，进入SCIF（敏感隔间信息设施），学习他们实际如何工作、关心哪些数据源、如何构建符合其运营语境的工作流。

这就是FDE的起源。二十年后，Palantir支持美国及盟国的全谱军事行动，统一前线部队战备信息与侦察、目标选择流程，为多国部队提供共享作战世界。在战场上，FDE的价值体现得最充分——决策时间从几天缩短到几分钟，跨部门协作从"互相发邮件"变成"在同一个数字世界里实时协作"，每一个决策都有完整的审计追溯。

这些案例有一个共同特点：越复杂、越实时、越需要跨系统协调动作的场景，越能体现FDE和Ontology的价值。这也是FDE从战场走向工厂、医院和电网的原因——这些场景的底层问题是一样的：如何把分散的系统和数据整合成一个可理解、可计算、可执行、可治理的运营系统。

08 对国内企业的三条启发，以及一个90天落地节奏

Palantir的FDE方法论是在美国市场、特定行业（国防、情报、医疗、航空）里发展起来的，不能直接照搬到国内企业。但它的核心思路——深入现场、建模业务、闭环执行、持续进化——对国内企业的AI落地有很强的参考价值。

基于FDE方法论，结合国内企业的实际情况，可以提炼出三条核心启发。

启发一：FDE要在业务流程里，而不是在会议室里。

国内很多企业做AI项目，流程是：业务部门提需求→IT部门评估→找供应商做方案→开会评审→立项→开发→测试→上线。整个过程中，真正做开发的人可能从来没去过业务现场，没跟一线人员一起工作过，不知道真实的业务流程是什么样的。

FDE的思路是反过来的：做AI的人要先到业务现场去，跟工厂、医院、仓网、调度中心的一线人员一起工作，先理解真实的业务流程和痛点，再定义AI能做什么，而不是反过来——先有个AI模型，再到处找场景。

这意味着企业需要调整组织方式：不是把AI团队放在总部的IT部门，而是让AI团队嵌入到业务一线，跟业务人员一起工作，用业务指标来考核AI团队，而不是用"模型准确率""系统上线时间"这类技术指标。

启发二：先建对象和动作（Ontology），再做AI应用。

国内很多企业做AI，一上来就做应用——做个智能客服、做个智能推荐、做个智能审批。但这些应用往往是孤立的，每个应用都有自己的数据模型、自己的业务规则、自己的用户界面，应用之间无法协作，数据无法共享，AI无法形成合力。

FDE的思路是：先围绕ERP、MES、CRM、设备、人员和订单等核心业务对象，构建统一的Ontology——定义有哪些对象、对象之间有什么关系、可以对对象执行什么动作、谁有权执行什么动作。有了统一的Ontology之后，再在上面构建各种AI应用，所有应用都共享同一个业务模型，应用之间可以自然协作。

这就像建房子：先打地基（Ontology），再盖房间（应用）。如果不打地基直接盖房间，每个房间都是孤立的，无法连通，也无法扩建。Ontology就是企业AI的"地基"——它不是一个能直接看到价值的应用，但它决定了企业AI能走多远。

启发三：把验收写进闭环，用硬指标衡量AI价值。

国内很多AI项目的验收标准很模糊——"系统上线""用户满意""领导认可"。这些标准无法衡量AI真正创造了多少业务价值，也无法指导后续优化。

FDE的思路是：用硬指标来衡量AI价值，比如人工接管率（AI执行的动作中有多少需要人工干预）、处理时长（AI处理一个任务需要多长时间，对比人工需要多长时间）、异常闭环率（发现的异常中有多少被真正解决了）、写回成功率（AI执行的动作中有多少成功写回了业务系统）、审计完整性（每一个AI决策是否都有完整的审计追溯）。

这些指标的共同特点是：它们衡量的是AI在真实业务闭环里的表现，而不是在实验室里的表现。一个模型在测试集上准确率99%，但在真实场景里人工接管率50%，那它的业务价值就大打折扣。FDE强调的是"闭环里的表现"，而不是"模型的表现"。

基于这三条启发，可以设计一个适合国内团队的90天落地节奏。

第0-2周：选任务。锁定一个可量化、跨系统、有人负责的运营问题。不要选"提升客户体验"这种模糊的目标，要选"把订单处理时长从48小时缩短到24小时""把库存盘点的人工工作量减少50%"这种具体的、可衡量的目标。同时确保这个问题跨多个系统（这样才能体现Ontology的价值），并且有一个明确的业务负责人（这样才能推动跨部门协作）。

第3-6周：建模型。定义核心对象、关系、权限、规则和第一条工作流。这一步的核心是构建Ontology的最小可用版本——不需要覆盖所有业务对象，只需要覆盖当前任务涉及的对象和动作。同时构建第一条工作流，在真实数据上跑通，让业务人员能看到、摸到、用到。

第7-10周：跑闭环。实现人机协同、动作写回、评估和现场复盘。这一步的核心是让AI真正进入业务闭环——不只是给出建议，而是真正执行动作，写回业务系统。同时建立评估机制，用硬指标（人工接管率、处理时长、异常闭环率等）衡量AI的表现，定期跟业务人员一起复盘，持续优化。

第11-13周：做复用。实现分支发布、监控审计、沉淀组件和规划下一场景。这一步的核心是把第一个项目的成果沉淀成可复用的能力——Ontology模型、工作流组件、AI Agent模板等，然后规划下一个应用场景，让AI能力在企业里持续扩散。

这个90天节奏的目标不是"做一个完美的AI系统"，而是"跑通一个可验证、可交付、可复制的真实任务闭环"。第一个闭环跑通了，后续的扩展就有了基础；第一个闭环跑不通，做再多的规划和愿景都是空中楼阁。

写在最后

回到开头的那个问题：为什么很多AI项目停在了"看起来很智能"的阶段？

Palantir的FDE方法论给出的答案是：因为AI没有进入任务现场，没有被建模成可执行的业务系统，没有形成完整的决策-执行-反馈闭环。AI成了会议室里的展示品，而不是运营现场的生产力。

FDE的核心，不是把AI部署进企业。而是深入企业任务现场，把真实世界建模成可理解、可计算、可执行、可治理的系统，再用持续反馈让它不断进化。

四个关键词：现场、Ontology、平台、闭环。

现场是起点——不到现场去，就不知道真实的业务是什么样的；Ontology是核心——没有统一的业务模型，AI就无法理解和执行；平台是底座——没有强大的平台支撑，FDE就无法规模化；闭环是目标——没有完整的决策-执行-反馈闭环，AI就永远是个"顾问"，不是"操作员"。

对国内企业来说，FDE不是一套可以直接照搬的方法论，而是一种思考方式：做AI之前，先到现场去；做应用之前，先建模型；做验收之前，先定硬指标；做第一个项目之前，先想清楚怎么复用。

AI的价值不在模型里，不在平台里，也不在Demo里。AI的价值在真实的业务闭环里——在每一个被自动处理的订单里，在每一张被智能分配的床位里，在每一次被精准调度的维修里，在每一个被及时发现的异常里。

把AI放进任务现场，而不是放进会议室。这可能是FDE方法论给我们的最重要的启发。

重庆AI创享俱乐部第八期线下活动：FDE破冰会

关注并私信后台留言“FDE”获取本次活动的Palantir案例分享PPT

欢迎加入俱乐部

加入方式：点击“阅读原文”登录官网 https://cqaiclub.asia/

#FDE #AI落地 #人工智能 #Palantir

预览时标签不可点

阅读原文

不喜欢

阅读原文

微信扫一扫

关注该公众号

知道了

微信扫一扫

使用小程序

取消

允许

取消

允许

取消

允许

分析

微信扫一扫可打开此内容，

使用完整服务

视频

小程序

，轻点两下取消赞

在看

，轻点两下取消在看

留言

听过