恒川工业的缺料项目启动会上需求清单已经有 86 行接 ERP、WMS、MES 和 SRM建立企业级 Material 模型做风险预测、供应商门户、管理驾驶舱再配一个 Agent。计划员听完只问了一句“明天下午排产冻结前M-1042再短缺我能不能看清证据提交方案让经理批准并知道 ERP 和 WMS 到底有没有执行”这句话把 86 行需求压回了一个真实问题。如果团队继续按系统和功能清单开工六个月后可能拥有丰富资源却仍让用户在电话、Excel 和 ERP 之间完成决定。FDE 方法的起点不是“平台还能建什么”而是离真实工作最近的哪个问题值得先形成一条可运行、可观察的最小闭环上一篇讲了本体反模式。本篇继续回答Palantir 所说的 Forward Deployed Engineering 到底是什么人类 FDE 与 AI FDE、Pilot 和试点阶段有什么区别以及 BA 怎样参与“问题—闭环—反馈—产品”的演进。一句话定义FDE 不是组件而是一种把现场接回产品的工程方法一句话定义Forward Deployed Engineering 是让工程团队尽可能贴近真实问题与用户和核心工程团队共同工作把现场证据持续综合为可复用产品能力的方法Forward Deployed Engineer 是实践这种方法的人类角色。Palantir Architecture Center 明确把 Forward Deployed Engineering 称为持续塑造其平台与 offering 的方法。官方用“人类版反向传播”作比喻现场团队靠近问题把反馈带回核心工程再持续发布能力。PalantirArchitecture Center这个定义有三个重点。Forward deployed不是把工程师派到现场等需求而是缩短问题、用户、数据和工程反馈之间的距离Engineering不是只做访谈或配置页面而是让数据、Ontology、Logic、Action、Security 和运行约束真正连起来反馈进入产品不是把每个本地要求都永久定制而是辨认哪些应做成通用能力、哪些应配置、哪些只是一时妥协。因此FDE 不是 Foundry 的按钮、资源类型或平台组件。你不会在 Ontology Manager 里“创建一个 FDE”也不会从 Marketplace 安装“一个 FDE 方法”。把 FDE 放回 Palantir 产品与交付结构最小架构位置如下它的上一级语境是 Palantir 的产品演进和用例交付方法而不是 Foundry 菜单。它的基础是真实用户、Outcome、数据、可执行 Action、工程工具与运行证据。它的下游是一个能被采用的运营闭环以及从现场抽出的可复用能力。人类 FDE 也不是“所有事情的 Owner”。官方 use case roles 还包括 Domain Lead、Use Case Lead、Product Owner、SME、Use Case Developer 和 End User。Use Case Lead 要协调 ROI、采用、权限和运行支持Product Owner 负责 roadmap业务 SME 和用户负责现实流程与判断。PalantirUse case rolesFDE 的独特价值是让这些角色围绕同一个正在运行的问题协作不让业务要求、平台资源和产品反馈分成三条互不相见的线。四个相似词必须分开FDE、AI FDE、Pilot 和 pilot 在口头沟通中很容易混成一团。名词类型在产品里是什么负责什么不能代替什么人类 FDE人类角色/方法实践者没有单一固定界面贴近问题、共创闭环、综合反馈、推动复用业务 Owner、审批人、核心工程团队AI FDEAIP 产品能力/Agent对话式 Foundry 操作入口按授权 context 和 tools 执行建设操作、解释和验证用户研究、业务责任、最终合并和价值签核Pilot大写Foundry 应用构建产品当前 BetaAI-powered application builder从自然语言生成 Ontology 候选、设计、React/OSDK 前端和 seed datause case 选择、真实 UAT、用户采用pilot / 试点通用实施阶段不是软件界面在限定范围、用户和时间内验证可行性与价值Product、FDE 角色或生产运营体系AI FDE它会操作 Foundry但不拥有业务问题官方当前把 AI FDE 定义为通过对话命令操作 Foundry 的交互式 Agent。它可做数据转换、管理代码库、建设 Ontology并使用原生工具验证变化操作仍尊重用户权限建设者还能限制模型、工具和上下文。PalantirAI FDE它能帮助恒川工程师创建 Object Type、修改 Pipeline 或准备 proposal但它不知道“为什么 520 EA 的调拨必须由经理复核”除非团队把规则、对象、权限和业务上下文交给它。即使它完成构建也不能替 Supply Chain Manager 承担批准责任。Pilot它会生成应用但不是“做一个试点”Palantir Pilot 是 Foundry 中通过自然语言构建应用的产品当前标注 Beta可能并非每个 enrollment 都可用。它可生成 Ontology entities、设计规格、React/OSDK 前端和 seed data并引导 Ontology promotion、Developer Console、CI 与 release。PalantirPilot overviewPilot 的 seed data 在隔离环境生成AI agents 不接触真实企业数据。这是建设安全边界不是业务验收结论。生成了一个能预览的缺料应用并不证明恒川的 Material 身份正确、Action 有权执行、写回可补偿或用户愿意使用。试点阶段它要产出继续、调整或停止的证据本文的小写 pilot 是实施阶段。它限定范围、用户、风险和时间以证据决定下一步。如果试点结束时只有一段演示视频、几张页面截图和“用户反馈不错”那不是闭环证据。至少要看见真实用户处理目标事件、提交受控 Action、系统留下运行与失败记录并能解释结果为什么发生。FDE 不从技术清单开始而从 Use case 开始Palantir 的 Use case lifecycle 把 use case 定义为由专门团队在有限时间内为一组用户交付新能力的工作。它不是“接入源系统 X”或“采用 ML 技术 Y”而要立即面对两个问题谁的工作会改善怎样知道成功。PalantirUse case lifecycle所以“接入四套系统”不是恒川的 use case“建立企业本体”也不是。一个可执行的表达是Supply Planner 在排产冻结前基于订单、库存和供应商承诺比较处置方案高影响方案由 Supply Chain Manager 复核并把批准、写回和对账状态留在同一闭环中。这句话同时包含用户、决策时刻、上下文、Action 和结果。它给工程团队一个可以缩小、测试和迭代的工作单位。恒川工业先跑一个物料、一个工厂、两个 Action恒川的 FDE 小组没有先接完全部 ERP 表也没有先画完整供应链本体而是锁定工厂PLANT-EAST物料M-1042canonical identity 为MAT-0001042事件SD-260808-01候选方案AP-2048跨仓调拨 520 EA用户Supply Planner、Warehouse Coordinator、Supply Chain ManagerBuyer 提供供应承诺证据两个 ActionOpen Shortage Disposition Task和Approve Allocation Proposal。这个范围小但不是一个“假 demo”。它仍要连接 WMS 的 800 EA 现存、20 EA 冻结、20 EA 预留和 760 EA 可用库存520 EA 又超过恒川 500 EA 教学阈值需要经理复核。真实问题进入最小闭环SD-260808-01 进入高风险范围 → Open Shortage Disposition Task 创建唯一任务 → 计划员查看订单、库存、供应商和排产证据 → 仓储协调员确认可调拨条件 → AP-2048 进入 Pending Approval → Manager 提交 Approve Allocation Proposal → WR-2048-* 跟踪 ERP/WMS 写回与回执 → Executed / Partially Failed / Failed → 对账后 Closed并保留决策与失败证据这里的重点不是 Object 数量而是每一段都可被用户、数据和运行证据验证。Approved仍不等于Executed若 WMS 没有回执页面不能用绿色成功掩盖失败。用户共创发生在真实工作节奏中FDE 小组不只在周会上请用户“确认需求”而是在排产冻结前的工作节奏中观察计划员在哪一步离开应用去查 Excel他不相信 760 EA 时会追问哪条库存证据经理拒绝AP-2048时原因是规则、权限、信息缺失还是现实经验ERP 成功、WMS 失败时哪个角色接管状态应怎样显示这些观察会反向改变 Product补充 Property 的来源与更新时间调整 Link 和 Object View把复杂判断放进 Function把拒绝理由进入 Action 参数把部分失败进入WR-2048-*状态。用户不是最后一轮 UAT 才出现的验收人而是产品学习回路中的参与者。从现场反馈到产品能力六段路径本系列把 FDE 的产品演进整理为六段。它是基于官方 FDE、Use case lifecycle、Operational application 与 DevOps 的实施综合不是 Palantir 官方固定流程。真实业务问题先确认谁正在做什么决定不要以“做供应链数字化”开题。写清用户、Trigger、Deadline、Options、错误后果和 Outcome。没有具体决定就无法判断哪些数据和模型值得进入范围。最小闭环只建完成一次决定所需的 Ontology slice从 Outcome、Decision 与 Action 反推 Object Set、Object、Property、Link、Logic、权限和 writeback。最小不等于缺关键控制身份、权限、失败、审计和人工接管都必须在范围内。用户共创用真实事件暴露错误假设让目标用户在目标节奏中处理事件。记录离开应用、手工补证、覆盖建议、拒绝 Action 和异常接管的原因而不只收集“页面好不好看”。Action 落地让决定真正进入运行系统Palantir 把 operational application 的核心放在决策与 Action应用不只呈现信息还应让用户在同一上下文中作决定并以受治理机制捕获它。PalantirOperational applications没有 Action、权限、写回和审计的应用很难产生可学习的运营证据。证据反馈同时反馈业务与产品一次 Action submission 会留下谁、何时、基于什么上下文、采取什么动作的证据Writeback 和观测又说明执行是否成功。团队据此判断问题发生在数据、语义、Logic、界面、权限、流程还是产品能力。产品化把重复模式固化把现场差异外置当同类事件反复出现团队要把反馈分成三类多地共享的稳定能力进入 Product core工厂、身份、连接和阈值差异进入配置和 installation inputs不应长期保留的一次性妥协明确债务与退出期限。上一篇 DevOps/Marketplace 已说明Productization 还需要版本、依赖、安装、升级和回退。一个部署能运行只说明 deployment 成功多个安装能受控演进才接近产品化。FDE 方法的五个失真版本把 FDE 当驻场开发。用户说什么就做什么得到的是不断扩大的本地分支不是反馈驱动的产品。把 demo 当最小闭环。只有 mock data 和绿色路径没有真实身份、Action 权限、外部回执与失败接管。把速度当作唯一结果。两周做出页面很快但若目标用户不执行 Action速度没有形成业务能力。把 AI FDE 当自动交付团队。它能加快建设与验证却不能替代问题选择、业务责任和产品判断。把 scale 理解成扩大对象范围。Scale 应扩大已被证明的决策闭环若原闭环无采用和结果证据扩大只会传播不确定性。BA 工作台一FDE Use Case Canvas这张 Canvas 用于用例启动和每轮反馈复盘。填写顺序从问题到证据不从系统清单开始。Canvas 字段恒川填写样例真实问题M-1042短缺时计划员无法在排产冻结前形成有证据、可执行的方案目标用户Supply Planner协同 Warehouse Coordinator、BuyerManager 负责高影响批准Trigger / DeadlineSD-260808-01确认为高风险下一轮排产冻结前完成批准Outcome缩短从确认中断到批准可执行方案的时间同时不增加越权和失败写回基线采集回溯电话、Excel、ERP 操作时间不虚构改善比例Decision对AP-2048批准、拒绝或退回补证Action 1Open Shortage Disposition Task有稳定去重键不重复建任务Action 2Approve Allocation Proposal520 EA 超过 500 EA 时仅 Manager 可提交最小对象与 LogicSupply Disruption、Material、Order、Inventory Position、Proposal缺口与风险 Function数据 / SoRERP 订单、WMS 库存、SRM 承诺外部执行事实仍由对应 SoR 负责Security / failure对象与属性最小权限Approved ≠ Executed部分失败转人工用户共创节奏每次真实高风险事件后复盘离开应用、覆盖建议、拒绝和失败原因运行证据Action submission、对象状态、WR-2048-*、ERP/WMS 回执、人工接管原因范围外全量企业本体、所有物料、替代料工程认证、全自动批准停止/调整门身份或库存不可信、权限未签核、无补偿路径、目标用户拒绝使用产品化候选通用状态机、Action contracts、Functions、Workshop 骨架和测试连接与 groups 外置Canvas 的价值不在于填满而在于让每一项都能被某个角色签核并在真实运行中得到证据。BA 工作台二Pilot—Scale—Productize 路线图这里的 Pilot 是实施阶段不是 Palantir Pilot 产品。阶段范围与目标用户必须跑通的闭环进入门退出门失败时动作形成的资产PilotPLANT-EAST、MAT-0001042、计划员与经理高风险事件→任务→方案→批准→写回跟踪Owner、用户、数据、Action 和权限最小条件就绪真实事件被处理正常与部分失败均可追踪用户原因可解释缩小范围、补身份/数据/权限必要时停止Canvas、对象切片、两个 Actions、UAT、运行证据Scale华东更多关键物料与同类事件复用同一状态机、Actions 和写回契约Pilot 证据显示闭环被采用且控制有效新范围主要通过配置扩展可靠性和支持责任明确回退新增范围不污染核心定义共享 Functions、配置规则、运行手册、采用证据Productize华南等更多工厂和环境同一 Product 的多 Installation 受控升级重复模式稳定差异已分为 core/config/binding版本、依赖、安装、升级、回退和 Owner 齐全暂停 release channel、降级资源、业务补偿DevOps Product、兼容表、环境矩阵、fleet 观测路线图要防止两种跳跃没有真实 Pilot 证据就宣布 Scale还没分离本地差异就宣布 Productize。回到开头FDE 怎样让产品从问题里长出来恒川不需要先完成 86 行需求。它需要先让一个计划员、一个经理围绕一个真实缺料事件用两个受控 Action 完成一次决定并让批准、执行、失败和反馈留下证据。人类 FDE 让工程团队贴近这个问题Ontology 和 Foundry 提供可运行的对象、Logic、Action 与 SecurityAI FDE 和 Pilot 可以加速建设用户反馈和运行证据决定产品怎样修改DevOps 再把稳定模式交付为可版本化的 Product。FDE 方法的核心不是“现场做得快”而是建立一条短而真实的学习回路每一轮建设都靠近用户决定每一次反馈都能改变产品每一次扩展都有证据说明为什么值得。【声明】本文依据 Palantir 公开资料与实施研究整理与 Palantir Technologies 无官方关联。恒川工业、对象编号、流程和数据均为虚构教学案例Decision-back、FDE Use Case Canvas、Pilot—Scale—Productize 路线图不是 Palantir 官方固定模板。产品能力可能变化请以官方文档和具体环境为准。