企业官网建设流程全解析

恒川工业华东工厂的缺料处置应用终于稳定了。华南工厂负责人看过演示后说：“这套东西很好，给我们复制一份，下个月上线。”

工程团队却没有立即复制。

华南的 ERP 连接、WMS 编码、身份组和通知目标都不同；华东下季度还会升级风险 Function 和 Workshop。现在复制一份，三个月后就会变成两套无法同步的系统。

问题是：怎样把跑通的用例变成有边界、有依赖、有版本、可配置、可安装、可升级，也能安全回退的 Product？

前两篇讨论了安全变更和运行观测。本篇进入最后一环：用 Foundry DevOps 与 Marketplace 把华东方案交付到华南，同时保留业务差异和生产控制。

先给结论：产品化不是复制，而是把不该复制的东西分离出来

一句话定义：Foundry DevOps 是把 Foundry 资源组织为可版本化、可发布、可安装并可管理安装群的 Product 的交付工具链；Marketplace 是发现这些 Product、完成引导式安装和管理升级的入口。

这里最重要的词不是 DevOps，而是Product。

在 Foundry DevOps 语境里，Product 是建设者发布、可供他人安装的一组 Foundry resources，可包含 Ontology fragment、Pipeline、Model、Function 或 Workshop。Palantir 的 Core concepts把它定义为 Marketplace 中可浏览、可安装的基本单位。

它不是三个东西：

• 不是 Palantir 的平台产品 Foundry、AIP 或 Apollo；

• 不是恒川对外销售的业务产品；

• 也不是把华东数据、账号和权限打成压缩包。

本篇把它称为“用例 Product”，强调它封装的是一组可交付能力及其依赖契约。

把 Foundry DevOps 放回产品架构

先看最小必要位置：

这张图解决层级问题。

层级上，Foundry DevOps 属于 Foundry 的产品交付与生产工程能力，不是 Foundry 的上一级，也不与 Foundry 平级。

Marketplace 与 DevOps 是相邻入口：前者面向安装者，后者面向 Product 建设者。

Global Branching 管“怎么改”，Observability 管“是否正常”，DevOps/Marketplace 管“怎样向多个环境交付”。

Apollo 是 Palantir 标准架构中的持续交付平台，支撑 Palantir 软件跨环境运行；Foundry DevOps 则分发建设者在 Foundry 里构建的工作流。二者不能混写。

五个核心名词，组成一条交付链

Foundry DevOps 与 Marketplace 不是两个孤立菜单。它们由一组有严格含义的名词串起来。

一个 Product 可以有多个 Installation，服务不同用户组或环境；每个 Installation 使用自己的 input data、release channel 和 upgrade window。Palantir：DevOps core concepts

所以，恒川不是“把华东 Production Project 克隆到华南”。正确的表达是：华东与华南消费同一个 Product 的不同 Installation。

Product 在产品里到底长什么样

建设者在 Foundry DevOps 中创建 Product draft，可手动添加 outputs，也可跟踪 source folder，使新版本随文件夹演进。Palantir：Create a product

以华东缺料处置为例，建设者先添加最下游的 Workshop 应用。DevOps 会自动识别其依赖，例如：

Shortage Response Workshop ├─ Supply Disruption / Material / Order 等 Ontology resources ├─ calculateShortageRisk Function ├─ Approve Allocation Proposal Action ├─ unresolved-high-risk Automate ├─ risk model 与配置 Dataset └─ ERP / WMS / SRM data inputs、groups、parameters

然后必须做一个关键判断：哪些是 Product 的outputs，哪些是安装者必须提供的inputs？

• Output：由 Product 提供，Marketplace 安装时会创建或重建的内容；

• Input：Product 依赖，但每个安装环境要自行映射或配置的内容；

• Linked product：可由另一个已安装 Product 提供的 input 依赖。

若恒川希望华南复用calculateShortageRiskFunction，它应随 Product 作为 output 交付。若华南必须使用自己的 WMS Dataset、审批组或参数，它们应成为 inputs。

参数和 groups 等某些 input 不能提升为 output，安装时必须配置；preset 可限制选项或给默认值。结论是：通用能力可以封装，环境身份与配置必须显式绑定。

“Product Lineage”到底是什么

实施团队有时会说“先看 Product Lineage”。这个说法容易让人以为 Palantir 还有一个名为 Product Lineage 的独立产品。

更严谨的说法是：产品化时要看清 Product 的依赖谱系。当前产品形态包括：

• Product draft 中 outputs 的 Dependencies 视图；

• 自动浮现为 inputs 的上游依赖；

• Linked products 及它们满足的 inputs；

• Marketplace 安装草稿里的 dependency graph；

• 从 Data Lineage 或 Workflow Lineage 图形视图选择打包资源。

本文用Product Lineage作为“产品依赖谱系”的解释性总称，不把它当成官方独立应用。

对 BA 而言，它要回答：

1. 安装 Workshop 时还必须带上哪些 Function、Action 和 Object Type？

2. 哪些依赖由 Product 提供，哪些由华南提供？

3. 升级某个 Function 时，哪些应用和安装会被影响？

4. 哪个依赖来自另一个 Product，版本是否兼容？

没有这张依赖图，所谓“产品化”只是把遗漏推迟到安装当天。

恒川工业：把华东用例拆成四层

我会要求恒川先把现有方案拆成四层，再决定如何打包。

产品核心层

这是华东与华南应该保持同一含义、由版本统一治理的能力：

• 缺料处置所需的 Ontology fragment；

• 缺口与风险 Functions；

• 候选方案和批准 Action Types；

• Workshop 页面、Automate 规则骨架；

• 测试 fixtures、验收说明和运行监控定义。

可配置业务差异层

这是同一业务能力在不同工厂允许变化的部分：

• 高额调拨复核阈值；华东教学基准为 500 EA，华南必须由自己的业务 Owner 签核；

• 仓库范围、计划周期、通知节奏；

• 重点订单分类、升级路径和本地化显示文本。

这些差异应进入 configuration Dataset、parameters 或受控 presets，而不是复制 Function 后直接改代码。

环境绑定层

这是绝不能从华东原样复制的部分：

• 华南 ERP、WMS、SRM 的 Data Connection 或 Dataset；

• PLANT-SOUTH、华南仓库和组织编码；

• 华南 Supply Planner、Buyer、Warehouse Coordinator、Manager groups；

• API endpoint、凭据、通知收件人与 Project/Space/Ontology；

• DEV、TEST、PROD 的 release channel 与 maintenance window。

运行状态层

华东的SD-260808-01、AP-2048、WR-2048-*是华东运营实例，不是 Product 模板。华南安装后应基于自己的数据生成对象与 Action submissions。

这条边界尤其重要：Product 复制定义和可交付能力，不复制另一个工厂的业务事实与审计历史。

华南安装时，Marketplace 做了什么

华南实施人员在 Marketplace 找到Hengchuan Shortage Response，创建 Installation draft，选择 Project、Space、Ontology 与 version，映射 mandatory inputs，并预览 outputs。Palantir：Install a product

一次可验收的华南安装至少要经历：

选择 Product version → 选择目标 Space / Project / Ontology → 映射华南 ERP/WMS/SRM inputs → 映射华南 groups、parameters 与配置 Dataset → 检查 linked products 和 dependency graph → 预览 outputs 与 validation warnings → 在 TEST 安装、构建、验证 → UAT 通过后进入 PROD Installation

看 Store、安装 Product、使用 input 和写入目标位置分别受权限控制。Product builder 拥有 Product，不代表能打包底层数据或安装到任意环境。Palantir：Store permissions

Production mode 建议 Project locking。若 Product 只是一次性起点，可考虑 Bootstrap mode；代价是本地分叉后难以继续统一升级。

这不是技术选项而已。BA 必须和 Product Owner 先选清楚：我们要的是“统一产品，多地配置”，还是“复制起点，各地独立演进”？

升级不是覆盖文件，而是一份兼容性承诺

Product builder 每次改变内容，都发布新的 Product version。Installation 可以手动升级，也可以选择自动接收新版本。

Release channel 控制版本进入哪些 Installation，且是分层接收机制。当前不同官方页面对中间 channel 的显示名存在差异，项目应核对本环境配置，治理重点是：哪个安装跟踪哪条渠道，在什么条件下接收版本。

Marketplace 支持手动升级。新增 mandatory input 或 blocking validation 时，安装者仍要介入。自动升级当前为 Beta、默认关闭；升级会产生停机，建议设置 maintenance window。Palantir：Marketplace upgrades

所以，“可升级”不等于：

• 新版本必定兼容旧输入；

• 自动升级不需要人；

• 升级过程零停机；

• 本地修改会被聪明地保留；

• Ontology schema、对象 edits 和外部系统状态会自动迁移。

升级契约至少包含 input compatibility、Ontology/API schema compatibility、配置迁移、数据迁移、停机窗口、健康检查和回退条件。

回滚也不是按一下 Undo

Marketplace 支持选择较早 Product version 进行 downgrade。但这只说明安装可以发起回到某个版本的交付动作，不代表所有业务状态都会自动恢复。

恒川必须把“回滚”拆成四件事：

1. Product resource downgrade：Workshop、Function、Ontology definition 等安装资源回到兼容版本；

2. 配置恢复：参数、groups、连接和通知目标回到已知正确值；

3. 数据与对象迁移恢复：新增 Property、索引、配置 Dataset 或对象 edits 是否可逆；

4. 外部业务补偿：已经写进 ERP/WMS 的调拨或采购动作，不能靠 Product downgrade 撤销，必须走业务补偿和审计。

Recall 也不是 fleet 回滚：本地 Store 中 recall 会阻止新安装和升级，但已安装的 Installation 不受影响。运营团队仍要另行处置。

BA 工作台一：完整产品化清单

下面的清单用于 Product draft 前评审。每项都要有 owner 和验收证据。

这张表是 Product 的边界合同；空白项会在更多 Installation 中放大。

BA 工作台二：环境差异矩阵

同一个 Product 可以有多个 Installation，但不能假设环境完全相同。

矩阵的价值在于把“本地化”从口头要求变成可审计配置。尤其是 groups、credentials、writeback endpoint，绝不能作为通用 Product 的固定 output。

BA 工作台三：版本兼容表

最后一张表决定某个 Installation 能否升级，而不是只看“有新版本”。

版本号是教学设计。BA 要关注业务身份、Action contract、input mapping、权限和外部副作用是否兼容。

回到开头：华南要复制的不是华东系统，而是受控产品能力

恒川华东方案能够推广到华南，不是因为文件可以复制，而是因为团队完成了四个分离：

• 产品核心与本地配置分离；

• outputs 与 inputs 分离；

• Product version 与 Installation 状态分离；

• 技术 downgrade 与业务补偿分离。

Foundry DevOps 把资源、版本、依赖、release channel 和安装群组织起来；Marketplace 把发现、输入映射、安装和升级交给安装者。真正决定它能否规模化的，则是 BA 与工程团队共同定义的产品边界和兼容契约。

【声明】本文依据 Palantir 公开资料与实施研究整理，与 Palantir Technologies 无官方关联。恒川工业、产品名、版本号、编号和数据均为虚构教学案例；产品化清单、环境差异矩阵与版本兼容表不是 Palantir 官方固定模板。产品能力可能变化，请以官方文档和具体环境为准。