Install
openclaw skills install hutian-opc-ontology-castingHutian Opc Ontology Casting
企业OPC化潜力评估框架，5个维度评估OPC化潜力，每个维度10分总分50分
本体铸造 · 企业魂驱动转化框架
第1页/共8页 | Skill版本：v1.1 | 适用对象：OPC导师/企业转型顾问
一、Skill概述与核心使命
1.0 命名渊源：为什么叫"本体铸造"
本体（Ontology）——源自哲学，追问"何物存在"。在企业工程语境中，指将业务世界中的实体、关系、规则提取为统一的语义层，使组织运营不依赖具体人员而持续运转。Palantir将其核心产品命名为Foundry（铸造厂），正是取"将混沌原料铸造为精确形态"之意。
铸造（Foundry）——借鉴Palantir Foundry的理念：企业如矿石，本体如模具，铸造即是将散落在员工大脑中的业务知识，工程化为可定义、可关联、可推理、可执行的数字骨架。铸造不是搭建，是提炼；不是从零建造，是从混沌中锻造秩序。
与Palantir的关系：本Skill借鉴Palantir的核心思想（Ontology语义层、FDE前沿部署模式、AIP人机协同决策回路），但并非Palantir的复刻或代理。Palantir是一家美国上市公司，本Skill是OPC体系下的独立方法论工具集，服务于中国企业转型场景。两者的关系是"思想借鉴+本土重构"，而非品牌从属。
一句话概括：本体铸造 = 帮企业把散落的"人驱动"能力，锻造为可持续的"魂驱动"本体。
1.1 使命定义
不是教企业建数据模型，是帮企业完成从"人驱动"到"魂驱动"的物种进化
本Skill服务于OPC导师，为其提供一套完整的企业诊断与转化框架。融合本体论（Ontology）语义工程与FDE（Forward Deployed Engineer，前沿部署工程师）Skill化模式，帮助传统企业识别自身是否具备"OPC化"潜力，并给出可落地的转化路径。
1.2 核心价值主张
| 传统企业困境 | OPC化企业优势 |
|---|---|
| 人力密集型，边际成本不降反升 | 魂（本体）稳定，边际成本趋零 |
| 核心能力随人员流失而流失 | 能力固化为可复制Skill |
| 转型速度追不上市场变化 | Agent替代人力，扩张速度指数级 |
| 客户粘性依赖销售个人关系 | 粘性内化为平台数据关系网络 |
1.3 适用边界
- 适合：软件服务企业、咨询公司、系统集成商、数据科技公司
- 慎用：纯硬件制造、传统贸易、资源型行业
- 不适用：个人工作室、微型团队（<5人）
第2页/共8页 | 企业诊断框架
2.1 诊断维度与评分体系
本框架从5个维度评估企业的OPC化潜力，每个维度10分，总分50分。
维度一：业务抽象度（10分）
评估企业业务能否被标准化、模块化。
| 分值 | 表现 | 典型特征 |
|---|---|---|
| 8-10 | 高度抽象 | 业务逻辑清晰，可参数化配置 |
| 5-7 | 中度抽象 | 核心流程可提炼，部分环节依赖经验 |
| 2-4 | 低度抽象 | 业务高度定制化，依赖个人判断 |
| 0-1 | 不可抽象 | 纯人力服务，无法标准化 |
维度二：数据资产度（10分）
评估企业是否已有或可建立结构化数据资产。
| 分值 | 表现 | 典型特征 |
|---|---|---|
| 8-10 | 数据原生 | 业务本身产生高质量数据资产 |
| 5-7 | 有数据基础 | 具备基础数据积累，可结构化 |
| 2-4 | 数据薄弱 | 数据分散，需大量治理工作 |
| 0-1 | 无数据 | 业务不产生或不使用数据 |
维度三：客户复购度（10分）
评估企业客户关系的可持续性。
| 分值 | 表现 | 典型特征 |
|---|---|---|
| 8-10 | 高复购 | 年度合同/持续服务，KPIs明确 |
| 5-7 | 中复购 | 项目制但客户有持续需求 |
| 2-4 | 低复购 | 单次项目为主，关系依赖销售 |
| 0-1 | 无复购 | 一次性交易，客户生命周期短 |
维度四：知识显性度（10分）
评估企业内部知识是否已被显性化、文档化。
| 分值 | 表现 | 典型特征 |
|---|---|---|
| 8-10 | 高度显性 | SOP完整，知识库系统化 |
| 5-7 | 部分显性 | 有核心文档，但不成体系 |
| 2-4 | 隐性知识为主 | 经验在个人脑中，难传承 |
| 0-1 | 零显性 | 无任何文档，纯"手把手"传承 |
维度五：组织可分离度（10分）
评估业务能力能否与特定人员分离。
| 分值 | 表现 | 典型特征 |
|---|---|---|
| 8-10 | 高度可分离 | 流程自动化，人员可替换 |
| 5-7 | 部分可分离 | 核心依赖少数人，可逐步分离 |
| 2-4 | 强人员依赖 | 业务与关键人深度绑定 |
| 0-1 | 不可分离 | 人员=业务本身 |
2.2 诊断结论阈值
| 总分区间 | 诊断结论 | 转化建议 |
|---|---|---|
| 40-50 | 优秀候选 | 可直接进入OPC化快车道 |
| 30-39 | 可转化 | 需针对性补足短板后转化 |
| 20-29 | 需培育 | 先进行知识显性化与数据基础建设 |
| 0-19 | 暂不适用 | 建议保持现状，等待条件成熟 |
第3页/共8页 | 转化路径设计
3.1 三阶段转化模型
┌─────────────────────────────────────────────────────────────┐
│ 阶段一：本体提取期 │
│ 目标：识别企业"魂"，建立业务骨架 │
│ 周期：1-3个月 │
│ 产出物：企业本体Ontology Draft v1.0 │
├─────────────────────────────────────────────────────────────┤
│ 阶段二：Skill蒸馏期 │
│ 目标：将隐性经验显性化为可执行Skill │
│ 周期：3-6个月 │
│ 产出物：核心FDE Skill包 │
├─────────────────────────────────────────────────────────────┤
│ 阶段三：Agent部署期 │
│ 目标：实现能力规模化复制与自动化交付 │
│ 周期：6-12个月 │
│ 产出物：Agent虚拟驻场能力 + OPC平台接入 │
└─────────────────────────────────────────────────────────────┘
3.2 阶段一详细步骤：本体提取
Step 1.1：业务边界划定（产出物：业务边界文档）
- 访谈企业创始人/核心业务负责人
- 梳理业务全流程，识别核心价值交付环节
- 区分"核心能力"与"支撑能力"
- 输出《业务边界与核心能力清单》
Step 1.2：本体建模（产出物：Ontology Draft）
- 识别核心实体（ObjectType）
- 客户、订单、产品、服务、流程节点...
- 定义实体关系（LinkType）
- 谁触发谁、谁属于谁、谁依赖谁...
- 提炼关键属性（Property）
- 可量化、可追踪、可决策的属性
- 输出《企业本体Ontology Draft v1.0》
Step 1.3：验证与迭代
- 用Draft在2-3个真实项目中试点
- 收集反馈，识别本体缺失或错误
- 迭代优化，输出v2.0/v3.0
3.3 阶段二详细步骤：Skill蒸馏
Step 2.1：能力解构（产出物：能力解构图谱）
- 访谈资深员工，记录决策过程
- 将决策过程分解为：触发条件→输入信息→推理逻辑→输出动作
- 识别哪些是"规则型"能力，哪些是"经验型"能力
Step 2.2：Skill模板填充
- 按照标准Skill模板编写每个核心能力
- 包含：能力描述、触发条件、输入要求、输出规范、边界条件
- 补充典型案例与边界案例
Step 2.3：OPC平台接入
- 在OPC平台创建技能商品
- 完成技能定价与合约设计
- 提交审核，进入技能市场
3.4 阶段三详细步骤：Agent部署
Step 3.1：Agent选型与配置
- 评估目标企业现有技术栈
- 选择适配的Agent平台（如万融、AIP等）
- 完成技能与Agent的配置对接
Step 3.2：人机协同设计
- 定义Human-in-the-loop节点
- 设定权限与审计链路
- 制定异常处理机制
Step 3.3：规模化复制验证
- 选择1-2个新客户进行Agent驻场试点
- 监控运行效果，收集客户反馈
- 优化后进入标准化复制阶段
第4页/共8页 | 本体工程化方法论
4.1 什么是"企业魂"
企业魂 = 可被复制的业务逻辑 + 数据驱动的决策能力 + 持续进化的知识体系
┌────────────────────────────────────────┐
│ 企业魂构成 │
├──────────────┬──────────────┬─────────┤
│ 业务骨架 │ 决策引擎 │ 知识图谱 │
│ (Ontology) │ (FDE) │ (Skill) │
├──────────────┼──────────────┼─────────┤
│ 静态结构 │ 动态推理 │ 持续积累 │
│ 不随人变 │ 持续优化 │ 可传承 │
└──────────────┴──────────────┴─────────┘
4.2 本体工程化四步法
第一步：实体识别（ObjectType Definition）
原则：找名词，而非动词
| 操作 | 示例 |
|---|---|
| 列出业务中的主要参与者 | 客户、销售、工程师 |
| 列出业务中的主要对象 | 订单、项目、工单 |
| 列出业务中的主要资产 | 产品、知识、合同 |
| 识别业务事件 | 签约、上线、交付 |
第二步：关系建模（LinkType Definition）
原则：找动词，建立实体间的关联
| 关系类型 | 示例 |
|---|---|
| 归属关系 | 客户-账户、项目-团队 |
| 时序关系 | 订单-支付-发货 |
| 依赖关系 | 需求-设计-开发-测试 |
| 组成关系 | 订单-订单项 |
第三步：属性提取（Property Definition）
原则：找可量化、可追踪的维度
| 属性类型 | 示例 |
|---|---|
| 标识属性 | ID、名称、编码 |
| 状态属性 | 阶段、状态、等级 |
| 量化属性 | 金额、数量、时长 |
| 时间属性 | 创建时间、完成时间 |
第四步：安全嵌入（Security & Audit）
原则：权限与审计贯穿全链路
- 每个ObjectType设置访问权限
- 每条LinkType记录操作日志
- 每个Property可追溯修改历史
第5页/共8页 | FDE Skill化指南
5.1 FDE vs Skill：概念区分
| 概念 | 定义 | 形态 | 生命周期 |
|---|---|---|---|
| FDE | Foundational Data Entity，基础数据实体 | 数据模型+业务逻辑 | 与企业本体共存 |
| Skill | 可被Agent调用的技能单元 | 规则+案例+执行入口 | 独立演进，可迭代 |
关系：FDE是Skill的数据基础，Skill是FDE的呈现形式
5.2 Skill蒸馏标准流程
┌──────────────┐ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐
│ 专家访谈 │───▶│ 能力解构 │───▶│ 模板填充 │───▶│ 测试验证 │
└──────────────┘ └──────────────┘ └──────────────┘ └──────────────┘
│ │ │ │
▼ ▼ ▼ ▼
记录隐性经验 分解决策链 按模板编写 实际案例测试
5.3 Skill编写规范
每个Skill必须包含以下字段：
## Skill名称
[动词+宾语，如：评估客户信用/生成项目方案]
## 触发条件
[什么情况下调用此Skill]
## 输入要求
- 必需字段：[列出必需输入]
- 可选字段：[列出可选输入]
## 输出规范
- 输出格式：[描述输出结构]
- 输出示例：[提供示例]
## 执行逻辑
[用自然语言描述核心推理过程]
## 边界条件
[什么情况下不能使用/需要人工介入]
## 典型案例
[1-3个具体应用案例]
5.4 Skill质量分级
| 等级 | 标准 | 适用场景 |
|---|---|---|
| L1 | 规则型 | 标准化流程，输出稳定 |
| L2 | 案例型 | 有典型案例，可泛化推理 |
| L3 | 学习型 | 可持续学习，持续优化 |
| L4 | 创新型 | 可跨领域迁移，创新输出 |
第6页/共8页 | OPC上游生态接入指南
6.1 OPC定位再定义
OPC = Palantir/万融等平台的上游生态供血者
┌─────────────────────────────────────────────────────────────┐
│ OPC上游生态架构 │
├─────────────────────────────────────────────────────────────┤
│ │
│ ┌─────────┐ │
│ │ OPC导师 │───蒸馏──▶┌─────────┐───分发──▶┌─────────┐ │
│ │ 专家 │ │ Skill库 │ │ 平台方 │ │
│ └─────────┘ └─────────┘ │万融/Pal│ │
│ └─────────┘ │
│ │ │
│ ▼ │
│ ┌───────────────┐ │
│ │ Agent部署 │ │
│ │ 客户企业驻场 │ │
│ └───────────────┘ │
│ │ │
│ ▼ │
│ ┌───────────────┐ │
│ │ 效果/调用 │ │
│ │ 分成 │ │
│ └───────────────┘ │
└─────────────────────────────────────────────────────────────┘
6.2 App Store类比
| App Store角色 | OPC生态对应 |
|---|---|
| 开发者 | OPC导师/专家 |
| 应用商店 | 万融/Palantir平台 |
| 用户 | 企业客户 |
| 分成模式 | 效果付费/调用分成 |
6.3 接入流程
Step 1：OPC平台注册
- 完成个人/团队认证
- 签署技能上架协议
- 设置收款账户
Step 2：技能商品化
- 按照平台规范编写Skill文档
- 设定定价策略（参考：按调用次/按效果/订阅制）
- 提交审核
Step 3：持续运营
- 收集客户使用反馈
- 迭代优化Skill版本
- 参与平台推广活动
6.4 定价参考策略
| 计费模式 | 适用场景 | 优势 | 风险 |
|---|---|---|---|
| 按调用次数 | 标准化Skill | 收入可预期 | 需高调用量 |
| 按效果分成 | 结果导向Skill | 与客户利益绑定 | 需明确定义效果 |
| 订阅制 | 持续服务Skill | 稳定现金流 | 需持续服务能力 |
| 混合模式 | 复杂Skill | 兼顾各方 | 合约复杂 |
第7页/共8页 | MVP验证流程
7.1 MVP定义与原则
MVP = 最小闭环验证
核心原则：
- 用最小成本验证核心假设
- 不追求完美，先追求能跑
- 快速迭代，持续学习
7.2 验证里程碑
里程碑1：本体可行性验证（第1-2个月）
├── 目标：验证企业业务能否被本体化
├── 方法：用简化本体跑通1个真实项目
└── 通过标准：本体覆盖项目80%以上决策点
里程碑2：Skill有效性验证（第3-4个月）
├── 目标：验证Skill能否替代部分人工
├── 方法：用Skill支持2-3个并行项目
└── 通过标准：输出质量达人工的80%，效率提升50%
里程碑3：商业模式验证（第5-6个月）
├── 目标：验证客户是否愿意为Agent驻场付费
├── 方法：在1-2个新客户试点Agent驻场
└── 通过标准：客户满意度>80%，续约率>60%
里程碑4：规模化复制验证（第7-12个月）
├── 目标：验证能否低成本复制到新客户
├── 方法：用同一套Skill+Agent服务5+客户
└── 通过标准：边际成本<首客户的30%
7.3 验证失败处理
| 失败类型 | 可能原因 | 应对策略 |
|---|---|---|
| 本体无法覆盖业务 | 业务太定制化 | 缩小边界，只本体化可标准化部分 |
| Skill质量不达标 | 知识显性化不足 | 增加专家参与，补足案例库 |
| 客户不愿付费 | 价值感知不足 | 强化试点效果展示，调整定价 |
| 规模化成本高 | 技能未充分解耦 | 重构Skill，提高复用度 |
第8页/共8页 | 附录与附录
附录A：关键术语表
| 术语 | 定义 |
|---|---|
| Ontology | 本体论，企业业务结构的语义化表示 |
| FDE | Foundational Data Entity，基础数据实体 |
| AIP | AI Platform，Palantir的AI决策平台 |
| FDE（角色） | Forward Deployed Engineer，前线部署工程师 |
| OPC | Ontology Professional Community，本体专业社区 |
| Skill | 可被Agent调用的技能单元 |
附录B：参考资源
- Palantir官方文档：Ontology开发指南
- 万融平台接入文档
- 本地参考文件：
.skills/胡田-OPC导师-Palantir本体论FDE/references/OPC-Palantir协作框架.md
附录C：使用建议
- 初次使用：先完成企业诊断（第2页），明确转化优先级
- 持续迭代：每完成一个里程碑，回顾诊断评分，更新转化计划
- 遇到卡点：参考附录参考文档，或寻求OPC导师社群支持
文档信息
- 版本：v1.0
- 创建者：OPC导师体系
- 适用场景：企业OPC化诊断与转化
- 版权声明：内部使用，禁止外传