Palantir Workshop：低代码构建企业应用
每个大型组织都有这个痛点：业务部门有大量的定制化应用需求，但 IT 部门的开发排期永远排不过来。
Coomia发布于 2025年6月11日21 分钟阅读
分享本文Twitter / X
Palantir Workshop：低代码构建企业应用
“系列：S1 Palantir 解密 · 第 10 篇 | 难度：入门 | 阅读时间：15 分钟
#TL;DR
- Palantir Workshop 是一个低代码应用构建平台，但与 OutSystems/Mendix/PowerApps 本质不同——Workshop 的每个组件都直接绑定 Ontology 对象，数据、权限、Action 天然贯通，不需要"连接器"或"数据源配置"。
- Workshop 能构建运营仪表盘、审批流程、控制层板、数据录入表单等企业应用，且所有操作自动走 Action 审计链路，天然满足合规要求。
- coomia-dip 通过 DashboardService 实现了 17 种 Widget 类型，支持从简单指标卡到复杂的交互式应用构建。
#引言：企业应用开发的困境
每个大型组织都有这个痛点：业务部门有大量的定制化应用需求，但 IT 部门的开发排期永远排不过来。
Code
业务部门的需求清单：
├── 供应商绩效看板（优先级：高） → IT 排期：Q3
├── 库存预警控制台（优先级：高） → IT 排期：Q4
├── 审批流程跟踪界面（优先级：中） → IT 排期：明年 Q1
├── 客户投诉处理系统（优先级：中） → IT 排期：明年 Q2
├── 设备维护工单系统（优先级：低） → IT 排期：排不上
└── ...还有 47 个需求 → IT：人手不够
低代码平台的出现就是为了解决这个问题——让业务用户自己构建应用。但传统的低代码平台有一个根本性问题：
Code
传统低代码的架构：
┌──────────────┐
│ 低代码 IDE │
│ (拖拽组件) │
└──────┬───────┘
│ 需要配置
▼
┌──────────────┐ ┌──────────────┐
│ 数据源连接器 │────→│ 数据库/API │
│ (手动配置) │ │ (各种系统) │
└──────────────┘ └──────────────┘
│ 需要配置
▼
┌──────────────┐
│ 权限系统 │
│ (又一套配置) │
└──────────────┘
│ 需要集成
▼
┌──────────────┐
│ 工作流引擎 │
│ (再配一套) │
└──────────────┘
每一层都需要单独配置和集成。结果是"低代码"变成了"低了一半的代码"——还是需要大量的配置工作。
Palantir Workshop 的革命性在于：所有这些层都被 Ontology 统一了。
#一、Workshop 能构建什么？
#1.1 运营仪表盘
实时展示业务关键指标，支持钻取和 Action 触发：
Code
┌──────────────────────────────────────────────────────────┐
│ 供应链运营中心 [全屏] [分享] │
├──────────────────────────────────────────────────────────┤
│ │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│ │ 在途订单 │ │ 库存预警 │ │ 交付准时率│ │ 供应商风险│ │
│ │ 1,247 │ │ 23 ⚠️ │ │ 94.2% │ │ 3 🔴 │ │
│ └──────────┘ └──────────┘ └──────────┘ └──────────┘ │
│ │
│ ┌─────────────────────┐ ┌─────────────────────────┐ │
│ │ 各区域订单分布 │ │ 本月 vs 上月趋势 │ │
│ │ │ │ │ │
│ │ ██ 华东 420 │ │ ─── 本月 │ │
│ │ ██ 华南 310 │ │ --- 上月 │ │
│ │ █ 华北 267 │ │ ╱─╲ ╱─ │ │
│ │ █ 西南 250 │ │ ╱ ╲╱╱ │ │
│ │ │ │ ╱ │ │
│ └─────────────────────┘ └─────────────────────────┘ │
│ │
│ ┌──────────────────────────────────────────────────┐ │
│ │ 需要关注的订单 [批量处理] │ │
│ │ ┌────┬──────────┬────────┬──────┬──────────────┐ │ │
│ │ │ □ │ 订单号 │ 供应商 │ 状态 │ 操作 │ │ │
│ │ ├────┼──────────┼────────┼──────┼──────────────┤ │ │
│ │ │ □ │ PO-12847 │ 华为 │ 延迟 │ [催单][换供] │ │ │
│ │ │ □ │ PO-12851 │ 中兴 │ 预警 │ [催单] │ │ │
│ │ │ □ │ PO-12853 │ 比亚迪 │ 延迟 │ [催单][换供] │ │ │
│ │ └────┴──────────┴────────┴──────┴──────────────┘ │ │
│ └──────────────────────────────────────────────────┘ │
└──────────────────────────────────────────────────────────┘
#1.2 审批工作流
可视化展示审批状态，一键审批/拒绝：
Code
┌──────────────────────────────────────────────────────┐
│ 采购审批工作台 │
├──────────────────────────────────────────────────────┤
│ │
│ 待我审批 (7) │ 我发起的 (12) │ 已完成 (156) │
│ ═══════════ │
│ │
│ ┌────────────────────────────────────────────────┐ │
│ │ PR-2024-0847: 采购 CNC 刀具 │ │
│ │ │ │
│ │ 申请人: 张三 (生产部) 金额: ¥ 128,000 │ │
│ │ 日期: 2024-01-15 供应商: 山高刀具 │ │
│ │ │ │
│ │ 审批链: │ │
│ │ 张三(申请) ──→ 李四(组长) ──→ [你](部长) ──→ 王五│ │
│ │ ✅ ✅ ⏳ 待审批 │ │
│ │ │ │
│ │ 关联对象: │ │
│ │ • 供应商: 山高刀具 (风险评分: 低) │ │
│ │ • 历史采购: 过去 12 个月 32 次, 总额 ¥2.1M │ │
│ │ • 当前库存: CNC 刀具剩余 15 把 (预计用完: 3 天) │ │
│ │ │ │
│ │ [✅ 批准] [❌ 拒绝] [↩️ 退回修改] [💬 评论] │ │
│ └────────────────────────────────────────────────┘ │
└──────────────────────────────────────────────────────┘
#1.3 数据录入表单
结构化数据录入，自动校验和关联：
Code
┌──────────────────────────────────────────────────────┐
│ 新建质量检验记录 │
├──────────────────────────────────────────────────────┤
│ │
│ 产品批次号: [BT-2024-01-0847 ] ← 自动关联产品 │
│ 产品名称: CNC 精密轴承 (自动填充) │
│ 产品线: A 线 (自动填充) │
│ │
│ 检验类型: ○ 首检 ● 过程检 ○ 终检 │
│ 检验数量: [100] 件 │
│ 不良数量: [3 ] 件 │
│ 不良率: 3.0% ← 自动计算 │
│ │
│ 不良类型 (多选): │
│ ☑ 尺寸超差 □ 表面缺陷 ☑ 材料异常 □ 其他 │
│ │
│ 关联设备: [CNC-007 ▼] ← 从 Ontology 选择 │
│ 操作员: [王师傅 ▼] ← 从 Ontology 选择 │
│ │
│ 附件: [+ 上传照片/报告] │
│ 备注: [ ] │
│ │
│ ⚠️ 不良率超过 2%，将自动创建质量调查工单 │
│ │
│ [保存草稿] [提交] [取消] │
└──────────────────────────────────────────────────────┘
#1.4 控制层板
设备监控和远程操作：
Code
┌──────────────────────────────────────────────────────┐
│ 车间设备控制中心 │
├──────────────────────────────────────────────────────┤
│ │
│ CNC-007 状态面板 │
│ ┌─────────────────────────────────────────────┐ │
│ │ 状态: 🟢 运行中 运行时间: 127h 23m │ │
│ │ 主轴转速: 3,200 rpm 进给速率: 120 mm/min │ │
│ │ 刀具磨损: 73% ⚠️ 冷却液温度: 42°C │ │
│ │ │ │
│ │ 振动趋势 (24h): │ │
│ │ ──────╱╲─────╱╲╱╲─────────── │ │
│ │ ↑ 异常振动 │ │
│ │ │ │
│ │ [暂停运行] [调整参数] [维护申请] [查看历史] │ │
│ └─────────────────────────────────────────────┘ │
│ │
│ 所有设备概览: │
│ CNC-001 🟢 CNC-002 🟢 CNC-003 🟡 CNC-004 🟢 │
│ CNC-005 🟢 CNC-006 🟢 CNC-007 🟡 CNC-008 🔴 │
│ CNC-009 🟢 CNC-010 🟢 CNC-011 🟢 CNC-012 🟢 │
└──────────────────────────────────────────────────────┘
#二、Workshop 的核心机制：组件与 Ontology 绑定
#2.1 组件绑定模型
Workshop 的每个组件都通过 Ontology 绑定来获取数据和触发操作：
Code
┌──────────────────────────────────────────────────┐
│ Workshop 组件绑定模型 │
│ │
│ ┌─────────────┐ │
│ │ Widget │ │
│ │ (表格/图表/ │ │
│ │ 表单/按钮) │ │
│ └──────┬──────┘ │
│ │ │
│ ┌────┴────┐ │
│ │ 绑定配置 │ │
│ └────┬────┘ │
│ │ │
│ ┌────┼──────────┬──────────────┐ │
│ ▼ ▼ ▼ ▼ │
│ ┌────┐ ┌────────┐ ┌───────────┐ ┌────────────┐ │
│ │数据│ │过滤条件 │ │排序规则 │ │Action 绑定 │ │
│ │源 │ │ │ │ │ │ │ │
│ │ │ │Object │ │property │ │ActionType │ │
│ │Obj │ │Set的 │ │+ 方向 │ │+ 参数映射 │ │
│ │Type│ │Filter │ │ │ │ │ │
│ └────┘ └────────┘ └───────────┘ └────────────┘ │
│ │ │ │
│ │ Ontology Layer │ │
│ ▼ ▼ │
│ ┌──────────────────────────────────────────┐ │
│ │ Object Type + Properties + LinkTypes │ │
│ │ + ActionTypes + Permissions │ │
│ └──────────────────────────────────────────┘ │
└──────────────────────────────────────────────────┘
#2.2 实际绑定示例
JSON
{
"widget": "DataTable",
"binding": {
"objectType": "PurchaseOrder",
"objectSet": {
"filter": {
"and": [
{ "property": "status", "eq": "DELAYED" },
{ "property": "amount", "gte": 100000 }
]
},
"orderBy": [
{ "property": "dueDate", "direction": "ASC" }
],
"limit": 50
},
"columns": [
{ "property": "orderId", "label": "订单号" },
{ "property": "supplierName", "label": "供应商", "link": "Supplier" },
{ "property": "amount", "label": "金额", "format": "currency" },
{ "property": "dueDate", "label": "交期", "format": "date" },
{ "property": "daysOverdue", "label": "超期天数", "derived": true }
],
"rowActions": [
{
"actionType": "RushOrder",
"label": "催单",
"icon": "bolt",
"parameterMapping": {
"orderId": "$row.orderId",
"priority": "HIGH"
}
},
{
"actionType": "ChangeSupplier",
"label": "更换供应商",
"icon": "swap",
"parameterMapping": {
"orderId": "$row.orderId",
"currentSupplierId": "$row.supplierId"
}
}
]
}
}
#2.3 为什么 Ontology 绑定优于数据源绑定
Code
传统低代码（数据源绑定）：
组件 → 连接器 → API/DB → 拿到原始数据 → 自己处理权限 → 自己处理关联
Workshop（Ontology 绑定）：
组件 → Ontology → 自动带权限 → 自动带关联 → 自动带 Action → 完事
具体差异：
| 维度 | 数据源绑定 | Ontology 绑定 |
|---|---|---|
| 获取数据 | 配置 API/SQL 查询 | 选择 ObjectType |
| 权限控制 | 手动实现行级/列级过滤 | Ontology 自动过滤 |
| 关联导航 | 手动写 JOIN/子查询 | 沿 LinkType 自动导航 |
| 触发操作 | 手动调 API | 选择 ActionType |
| Schema 变更 | 组件可能崩溃 | Ontology 层吸收变化 |
| 审计追踪 | 手动记录 | Action 自动审计 |
#三、Workshop vs 传统低代码平台
#3.1 核心对比
| 对比维度 | Palantir Workshop | OutSystems | Mendix | PowerApps |
|---|---|---|---|---|
| 数据模型 | Ontology 对象 | 实体模型 | 域模型 | Dataverse/连接器 |
| 数据来源 | Ontology 统一入口 | 多连接器 | 多连接器 | 多连接器 |
| 权限模型 | Ontology 继承 | 自建 | 自建 | Azure AD |
| 操作触发 | Action (含审计) | Logic 流 | Microflow | Power Automate |
| 适用场景 | 数据密集型操作应用 | 全栈应用 | 全栈应用 | 轻量级应用 |
| 离线支持 | 有限 | 完整 | 完整 | 有限 |
| 移动端 | 响应式 | 原生 App | 原生 App | 原生 App |
| 自定义代码 | TypeScript 扩展 | C#/.NET | Java | Power Fx |
| 部署方式 | SaaS / 私有化 | SaaS / 私有化 | SaaS / 私有化 | SaaS |
| 价格 | 企业定制 | $$$$ | $$$ | $ |
#3.2 根本性差异：Ontology-Backed 低代码
传统低代码平台本质上是应用开发框架的简化版——简化了 UI 构建和 API 调用，但数据模型、权限、工作流仍然需要在低代码平台内部重新定义。
Workshop 的本质不同在于：它不是一个独立的应用平台，而是Ontology 的表现层。
Code
传统低代码：
┌─────────────┐
│ 低代码平台 │ ← 一切在这里面定义
│ ┌─────────┐ │
│ │ UI │ │
│ │ 数据模型 │ │ ← 重复定义（和源系统不同步）
│ │ 权限 │ │ ← 重复定义（和企业 IAM 不同步）
│ │ 工作流 │ │ ← 重复定义（和业务流程不同步）
│ └─────────┘ │
└─────────────┘
Workshop：
┌─────────────┐
│ Workshop │ ← 只负责 UI 和交互
│ ┌─────────┐ │
│ │ UI 组件 │──┼──→ Ontology（数据 + 权限 + Action）
│ └─────────┘ │ ↑ 唯一数据源（Single Source of Truth）
└─────────────┘
这意味着：
- 在 Workshop 中创建的任何应用，数据自动与其他所有工具（Contour、Pipeline、API）保持一致
- 权限改变在 Ontology 层生效，所有 Workshop 应用自动生效
- 新增 Action 在 Ontology 层定义，所有 Workshop 应用自动可用
#四、Workshop 应用的真实案例
#4.1 案例：供应链控制中心
一个中型制造企业用 Workshop 构建了完整的供应链控制中心，替代了原来 3 个独立系统：
之前：
Code
供应商管理 → SAP 模块（操作复杂，非供应链人员不会用）
库存监控 → Excel + 人工巡检（延迟大，经常遗漏）
物流跟踪 → 第三方系统（数据不互通）
之后（Workshop 应用）：
Code
一个统一界面：
├── Tab 1: 供应商绩效看板
│ └── 从 Ontology 读取 Supplier 对象 + 关联的 PurchaseOrder
├── Tab 2: 库存预警
│ └── 从 Ontology 读取 Inventory 对象，自动计算预警阈值
├── Tab 3: 物流跟踪
│ └── 从 Ontology 读取 Shipment 对象 + 实时位置
└── Tab 4: 操作中心
└── Action: 催单、调拨、换供应商、紧急采购
构建时间：2 周（1 名业务分析师 + 1 名 IT 支持），替代了原来预估需要 6 个月开发的项目。
#4.2 案例：合规审批平台
一家金融机构用 Workshop 构建了交易合规审批平台：
Code
交易提交
│
▼
Workshop 审批界面
├── 自动展示：交易详情、客户画像、历史交易模式
├── 自动标注：风险等级（来自 Reasoning Engine）
├── 自动关联：相关的合规规则和监管要求
├── Action 选项：
│ ├── 批准（自动记录审批人、时间、理由）
│ ├── 拒绝（必须填写拒绝原因）
│ ├── 上报（自动转给上级）
│ └── 请求补充材料
└── 审计追踪：每一步操作自动记录，不可篡改
#五、coomia-dip 的 Dashboard 实现
#5.1 DashboardService 架构
Code
┌──────────────────────────────────────────────────────┐
│ coomia-dip Dashboard Engine │
│ │
│ ┌──────────────┐ ┌──────────────┐ │
│ │Dashboard IDE │ │SDK Client │ │
│ │(Web, 拖拽构建) │ │(Python/TS) │ │
│ └──────┬───────┘ └──────┬───────┘ │
│ │ │ │
│ ▼ ▼ │
│ ┌──────────────────────────────────────────────┐ │
│ │ DashboardService (gRPC) │ │
│ │ │ │
│ │ ┌──────────┐ ┌──────────┐ ┌──────────────┐ │ │
│ │ │Widget │ │Layout │ │Data Binding │ │ │
│ │ │Registry │ │Engine │ │Engine │ │ │
│ │ │(17 types)│ │(Grid) │ │(Ontology) │ │ │
│ │ └──────────┘ └──────────┘ └──────────────┘ │ │
│ │ │ │
│ │ ┌──────────┐ ┌──────────┐ ┌──────────────┐ │ │
│ │ │Action │ │Filter │ │Permission │ │ │
│ │ │Binding │ │Sync │ │Enforcement │ │ │
│ │ └──────────┘ └──────────┘ └──────────────┘ │ │
│ └──────────────────────┬───────────────────────┘ │
│ │ │
│ ▼ │
│ ┌──────────────────┐ │
│ │ Ontology Layer │ │
│ │ (Objects, │ │
│ │ Actions, │ │
│ │ Permissions) │ │
│ └──────────────────┘ │
└──────────────────────────────────────────────────────┘
#5.2 17 种 Widget 类型
Python
from ontology_sdk.dashboard import DashboardBuilder, WidgetType
# coomia-dip 支持的 17 种 Widget
widget_types = {
# 数据展示类 (7 种)
"METRIC_CARD": "指标卡 — 单一数值 + 趋势箭头",
"DATA_TABLE": "数据表格 — 支持排序/过滤/分页/行 Action",
"BAR_CHART": "柱状图 — 支持堆叠/分组/水平",
"LINE_CHART": "折线图 — 支持多系列/面积/双 Y 轴",
"PIE_CHART": "饼图/环形图 — 支持 TopN + 其他",
"MAP": "地图 — 支持热力图/标记点/区域着色",
"TIMELINE": "时间轴 — 事件序列展示",
# 交互操作类 (5 种)
"FORM": "表单 — 数据录入/编辑，字段自动从 Ontology 派生",
"FILTER_BAR": "过滤栏 — 全局过滤器，联动所有 Widget",
"ACTION_BUTTON": "操作按钮 — 绑定 ActionType，支持批量",
"APPROVAL_PANEL": "审批面板 — 审批链展示 + 一键操作",
"SEARCH_BOX": "搜索框 — Ontology 对象全文搜索",
# 布局类 (3 种)
"TAB_GROUP": "标签页组 — 多页面组织",
"SECTION": "区域 — 内容分组 + 折叠",
"MODAL": "弹窗 — 详情查看/操作确认",
# 高级类 (2 种)
"OBJECT_DETAIL": "对象详情卡 — 展示单个 Ontology 对象的所有属性和关联",
"RELATIONSHIP_GRAPH":"关系图 — 可视化 Ontology 对象之间的关系网络",
}
#5.3 代码示例：用 SDK 构建仪表盘
Python
from ontology_sdk.dashboard import DashboardBuilder, WidgetType, Layout
# 构建供应链控制中心
dashboard = (
DashboardBuilder("supply_chain_control_center")
.title("供应链运营中心")
.description("实时监控供应链关键指标")
# 第一行：4 个指标卡
.add_widget(
WidgetType.METRIC_CARD,
id="in_transit",
title="在途订单",
binding={
"objectType": "PurchaseOrder",
"filter": {"property": "status", "eq": "IN_TRANSIT"},
"aggregation": "COUNT",
},
position=Layout.grid(row=0, col=0, width=3, height=2),
)
.add_widget(
WidgetType.METRIC_CARD,
id="inventory_alert",
title="库存预警",
binding={
"objectType": "Inventory",
"filter": {"property": "daysOfSupply", "lt": 7},
"aggregation": "COUNT",
},
alert_threshold={"warning": 10, "critical": 20},
position=Layout.grid(row=0, col=3, width=3, height=2),
)
.add_widget(
WidgetType.METRIC_CARD,
id="on_time_rate",
title="交付准时率",
binding={
"objectType": "Shipment",
"filter": {"property": "deliveredAt", "gte": "THIS_MONTH"},
"aggregation": "AVG",
"property": "isOnTime",
},
format="percentage",
position=Layout.grid(row=0, col=6, width=3, height=2),
)
.add_widget(
WidgetType.METRIC_CARD,
id="high_risk_suppliers",
title="高风险供应商",
binding={
"objectType": "Supplier",
"filter": {"property": "riskScore", "gt": 0.7},
"aggregation": "COUNT",
},
position=Layout.grid(row=0, col=9, width=3, height=2),
)
# 第二行：图表
.add_widget(
WidgetType.BAR_CHART,
id="regional_orders",
title="各区域订单分布",
binding={
"objectType": "PurchaseOrder",
"groupBy": "region",
"aggregation": "COUNT",
},
position=Layout.grid(row=2, col=0, width=6, height=4),
)
.add_widget(
WidgetType.LINE_CHART,
id="trend",
title="订单趋势",
binding={
"objectType": "PurchaseOrder",
"timeSeries": {"field": "orderDate", "bucket": "1w"},
"aggregation": "COUNT",
"comparePrevious": True,
},
position=Layout.grid(row=2, col=6, width=6, height=4),
)
# 第三行：数据表 + Action
.add_widget(
WidgetType.DATA_TABLE,
id="attention_orders",
title="需要关注的订单",
binding={
"objectType": "PurchaseOrder",
"filter": {
"or": [
{"property": "status", "eq": "DELAYED"},
{"property": "daysToDelivery", "lt": 3},
]
},
"columns": ["orderId", "supplierName", "amount", "dueDate", "status"],
"orderBy": {"property": "dueDate", "direction": "ASC"},
},
row_actions=[
{"actionType": "RushOrder", "label": "催单"},
{"actionType": "ChangeSupplier", "label": "换供应商"},
],
batch_actions=[
{"actionType": "BatchRushOrder", "label": "批量催单"},
],
position=Layout.grid(row=6, col=0, width=12, height=5),
)
# 全局过滤器
.add_global_filter("dateRange", type="date_range", default="THIS_MONTH")
.add_global_filter("region", type="enum", objectType="PurchaseOrder", property="region")
.add_global_filter("status", type="enum", objectType="PurchaseOrder", property="status")
# 权限
.permission(read=["supply_chain_team", "management"], write=["supply_chain_admin"])
.build()
)
# 部署仪表盘
dashboard.deploy()
#5.4 Widget 联动机制
Python
# Widget 之间的联动配置
dashboard.link_widgets(
source="regional_orders", # 来源：柱状图
target="attention_orders", # 目标：数据表
interaction="click", # 交互方式：点击
mapping={
"region": "$clicked.category", # 点击的柱子 → 过滤表格的区域
},
)
# 效果：用户点击柱状图中的"华东"柱子 → 数据表自动只显示华东的订单
#六、从 Workshop 看企业应用的未来
#6.1 传统开发 vs 低代码 vs Ontology 低代码
Code
应用复杂度
↑
│ ┌───────────────────────────────┐
│ │ │
高 │ │ 传统开发 │ ← 什么都能做，但贵且慢
│ │ (React + Spring Boot) │
│ │ │
│ └───────────────────────────────┘
│ ┌───────────────────────────────┐
│ │ │
中 │ │ Ontology 低代码 │ ← Workshop 的甜蜜区
│ │ (Workshop) │ 数据密集型操作应用
│ │ │
│ └───────────────────────────────┘
│ ┌───────────────────────────────┐
│ │ │
低 │ │ 传统低代码 │ ← 简单表单/流程
│ │ (PowerApps, 宜搭) │
│ │ │
│ └───────────────────────────────┘
└──────────────────────────────────→ 构建速度
#6.2 Workshop 的局限性
Workshop 不是万能的。它不适合：
- 消费者面向的应用：Workshop 是为内部运营人员设计的，不适合面向最终消费者的 App
- 高度定制化 UI：Workshop 的 UI 组件库虽然丰富但有边界，极度定制化的界面仍需传统开发
- 离线优先场景：Workshop 依赖实时的 Ontology 连接，完全离线的场景不适用
- 非数据密集型应用：如果应用主要是流程而非数据操作，传统低代码可能更合适
#七、最佳实践
#7.1 仪表盘设计原则
- 5 秒原则：打开仪表盘 5 秒内能看到最关键的信息
- 三层结构：概览层（指标卡）→ 分析层（图表）→ 操作层（数据表 + Action）
- Action 可达：任何需要操作的地方都要有 Action 按钮，不让用户"看得到但做不了"
- 移动友好：关键操作要在移动端也能完成
#7.2 常见误区
| 误区 | 后果 | 正确做法 |
|---|---|---|
| 一个仪表盘放太多信息 | 信息过载，没人看 | 按角色拆分仪表盘 |
| 只有图表没有 Action | 看完不知道做什么 | 每个发现配一个 Action |
| 权限配置不当 | 数据泄露或操作越权 | 使用 Ontology 权限继承 |
| 没有全局过滤器 | 用户无法聚焦 | 提供时间/区域/状态过滤 |
#Key Takeaways
- Workshop 与传统低代码的本质区别是 Ontology 绑定——组件不是绑定数据源，而是绑定业务对象。这使得数据、权限、Action 天然贯通，消除了传统低代码中大量的"胶水配置"工作。
- Workshop 的核心价值在于"从看到做"的闭环——它不只是可视化工具，而是操作平台。每个图表、每个表格都可以直接触发业务操作，这才是企业应用真正需要的。
- coomia-dip 的 DashboardService 提供了 17 种 Widget 类型，通过 Ontology 绑定模型实现了数据驱动的仪表盘构建。SDK 的声明式 API 让仪表盘可以用代码定义、版本控制、自动化部署。
#下篇预告
“第 11 篇：Palantir 的 Actions 和 Rules——从数据洞察到业务操作的桥梁
Workshop 中那些"催单"、"换供应商"、"批准"按钮背后是什么？Actions 是 Palantir 实现"数据到行动"闭环的核心机制。下一篇我们将深入解析 Action 的内部结构、Rule 引擎、Function 运行时，以及为什么这是 Palantir 区别于所有 BI/分析平台的根本性差异。
#palantir #workshop #low-code #enterprise-applications #ontology #coomia-dip #dashboard