官方技能 · AI 实践

领域本体草稿

v1.0.0 · 2026年11月4日 更新

起草一个领域本体：能力问题、带通俗定义的类、带基数的属性、示例实例和命名规则。

可在 Claude、ChatGPT 和编程智能体中使用。在 Team 和 Business 套餐中，Pod 里的官方技能会在我们改进后自动更新到最新版。

适用场景

• 不同团队用同一个词指不同的东西，需要统一定义
• 你准备搭建知识图谱、CRM 结构或 RAG 系统

你需要提供

• 领域及其边界
• 谁使用、用来做什么
• 示例文档或系统字段

你会得到

类、属性和示例实例的表格，并与本体必须回答的问题一一对应。

工作方式

1. 写 5 到 10 个能力问题 本体必须回答的真实问题：“哪些账户在未来 90 天内续约，分别由谁负责？”这些问题界定工作范围，最后也用来检验结果。
2. 列出术语 把问题和原始资料中的每个名词和动词都列出来，先不考虑结构。
3. 选出类，每个类用一句话定义 类是有实例的一种事物。定义格式：“[类] 是一种 [父类]，其特点是 [区别特征]。”把同义词合并成一个类，并记录这些同义词。如果某个东西会进入、退出某种状态（“活跃客户”），就把它做成属性值，而不是类。
4. 建立层级 每个子类都必须是其父类的“一种”。避免只有一个子类的类，也避免直接子类超过十来个。不能共享实例的类标为互斥。
5. 添加属性和关系 每个属性挂在拥有它的最上层的类上。每个属性写明：名称、值类型（文本、数字、日期、另一个类）和基数（恰好 1、0 或 1、1 或多、0 或多）。关键关系加上反向关系（owns / owned_by）。
6. 为每个核心类创建 2 到 3 个示例实例 贴近真实，但是虚构的。如果某个示例放不进去，说明类或属性有问题。
7. 用能力问题检验 对每个问题，说明由哪些类和属性来回答。回答不了的问题说明缺了东西；没有任何问题用到的类可以考虑删掉。 本技能的默认命名规则：类用单数的 UpperCamelCase（SalesOpportunity），属性用 lower_snake_case，以动词或“has”开头（has_owner、renews_on），不用缩写，名称中不出现“class”或“type”这类词。

SKILL.md 全文

这就是 AI 读取的完整文件。 下载

---
name: ontology-draft
description: 为一个业务领域起草本体：它必须回答的能力问题、核心类及通俗定义、带基数的属性和关系、示例实例，以及命名规则；遵循 Ontology Development 101 方法，用非工程人员也能审阅的表格呈现。当团队要求定义业务的核心概念、用大白话设计数据模型、建立本体、分类体系（taxonomy）、知识图谱的 schema，或者问“我们跟踪哪些东西、它们之间是什么关系”时使用。
---

# 本体草稿

本体是一份大家共同认可的清单：业务中谈到的事物（类）、我们记录它们的哪些信息（属性），以及它们之间的关系，定义要精确到两个人会把同一件东西归到同一个地方。Noy 和 McGuinness 的《Ontology Development 101》从用能力问题（本体必须回答的问题）确定领域和范围开始；我们也这样做，因为回答不了自己问题的本体缺了东西，而回答没人问的问题的本体又太大了。

## 适用场景

- 为某个领域搭建知识图谱、CRM 结构、数据仓库或 RAG 系统之前。
- 不同团队用同一个词指不同的东西（“客户”“账户”“用户”）。
- 表格的列越加越多，没人说得清每列是什么意思。
- 不适用于从现有文档中抽取事实：类确定之后，用 knowledge-graph-extraction。

## 需要准备

- 领域及其边界（“B2B 订阅，从报价到续约”，而不是“整个业务”）。
- 谁会使用这个本体，用来做什么。
- 示例文档、表格或系统字段。如果没有，就根据领域描述来做，并把类标为“[提议]”。
- 团队已经在用的现有标准（行业 schema、schema.org、CRM 的对象）。合适的地方沿用它们的名称。

## 步骤

1. **写 5 到 10 个能力问题。** 本体必须回答的真实问题：“哪些账户在未来 90 天内续约，分别由谁负责？”这些问题界定工作范围，最后也用来检验结果。
2. **列出术语。** 把问题和原始资料中的每个名词和动词都列出来，先不考虑结构。
3. **选出类，每个类用一句话定义。** 类是有实例的一种事物。定义格式：“[类] 是一种 [父类]，其特点是 [区别特征]。”把同义词合并成一个类，并记录这些同义词。如果某个东西会进入、退出某种状态（“活跃客户”），就把它做成属性值，而不是类。
4. **建立层级。** 每个子类都必须是其父类的“一种”。避免只有一个子类的类，也避免直接子类超过十来个。不能共享实例的类标为互斥。
5. **添加属性和关系。** 每个属性挂在拥有它的最上层的类上。每个属性写明：名称、值类型（文本、数字、日期、另一个类）和基数（恰好 1、0 或 1、1 或多、0 或多）。关键关系加上反向关系（owns / owned_by）。
6. **为每个核心类创建 2 到 3 个示例实例。** 贴近真实，但是虚构的。如果某个示例放不进去，说明类或属性有问题。
7. **用能力问题检验。** 对每个问题，说明由哪些类和属性来回答。回答不了的问题说明缺了东西；没有任何问题用到的类可以考虑删掉。

本技能的默认命名规则：类用单数的 UpperCamelCase（SalesOpportunity），属性用 lower_snake_case，以动词或“has”开头（has_owner、renews_on），不用缩写，名称中不出现“class”或“type”这类词。

## 输出格式

```markdown
# 本体草稿 — [领域]
**范围：** [边界] · **使用者：** [谁，做什么] · **状态：** 草稿

## 能力问题
1. [问题]

## 类
| 类 | 父类 | 定义 | 同义词（不使用） |
|---|---|---|---|

## 属性和关系
| 属性 | 所属类 | 值类型 | 基数 | 反向关系 | 定义 |
|---|---|---|---|---|---|

## 示例实例
| 实例 | 类 | 属性值 |
|---|---|---|

## 问题覆盖
| 问题 | 由什么回答 |
|---|---|

## 命名规则
- [规则]

## 待定事项
- [需要做的决定，可选方案]
```

## 示例

**输入：** “领域：我们的 SaaS 订阅。我们卖给企业；每家企业可以有多个工作区；每个工作区有一个套餐和若干席位。大家对企业的叫法有‘账户’也有‘客户’。我们需要知道谁在什么时候续约、每次续约由谁负责，以及哪些工作区超出了席位上限。”

**输出：**

```markdown
# 本体草稿 — SaaS 订阅
**范围：** 企业、工作区、订阅、续约 · **使用者：** 客户成功和财务团队，用于跟踪续约 · **状态：** 草稿

## 能力问题
1. 哪些订阅在未来 90 天内续约，每次续约由谁负责？
2. 哪些工作区使用的席位超过了套餐允许的数量？
3. 每家企业有多少个工作区？

## 类
| 类 | 父类 | 定义 | 同义词（不使用） |
|---|---|---|---|
| Company | — | 购买或可能购买我们产品的法律实体 | 账户、客户、组织 |
| Workspace | — | 我们产品中一个独立的区域，供某家企业的用户登录使用 | 实例、租户 |
| Subscription | — | 一个工作区在一段时间内使用一个套餐的付费协议 | 合同、许可 |
| Plan | — | 有名称、有价格和席位上限的套餐 | 版本、档位 |
| Person | — | 我们记录的一个人 | 联系人、用户 |

## 属性和关系
| 属性 | 所属类 | 值类型 | 基数 | 反向关系 | 定义 |
|---|---|---|---|---|---|
| has_workspace | Company | Workspace | 1 或多 | belongs_to | 企业付费的工作区 |
| has_subscription | Workspace | Subscription | 恰好 1（当前） | covers | 当前的付费协议 |
| on_plan | Subscription | Plan | 恰好 1 | — | 购买的套餐 |
| renews_on | Subscription | 日期 | 恰好 1 | — | 当前周期的结束日期 |
| has_renewal_owner | Subscription | Person | 0 或 1 | owns_renewal | 我方负责这次续约的人 |
| seat_limit | Plan | 数字 | 恰好 1 | — | 套餐的最大席位数 |
| seats_used | Workspace | 数字 | 恰好 1 | — | 当前在用的席位数 |

## 示例实例
| 实例 | 类 | 属性值 |
|---|---|---|
| 北峰科技有限公司 | Company | has_workspace: 北峰-华东, 北峰-华南 |
| 北峰-华东 | Workspace | seats_used: 48; has_subscription: SUB-1042 |
| SUB-1042 | Subscription | on_plan: Team; renews_on: 2026-03-31; has_renewal_owner: 欧阳琳 |
| Team | Plan | seat_limit: 40 |

## 问题覆盖
| 问题 | 由什么回答 |
|---|---|
| 1 | Subscription.renews_on、has_renewal_owner |
| 2 | 通过 Subscription.on_plan，对比 Workspace.seats_used 与 Plan.seat_limit |
| 3 | Company.has_workspace（计数） |

## 命名规则
- 类：单数 UpperCamelCase。属性：lower_snake_case，以动词或“has”开头。不用缩写。

## 待定事项
- 试用是价格为 0 的 Subscription，还是单独的一个类？会影响问题 1。
```

## 发送前检查

- [ ] 每个能力问题都对应到具体的类和属性。
- [ ] 每个类都有一句话的定义，写明父类和区别特征。
- [ ] 同义词合并到一个类中并列出来，而不是建成多个类。
- [ ] 每个属性都有值类型和基数。
- [ ] 每条“是一种”关系对子类的每个实例都成立。

## 常见错误

- 把状态做成类（“ChurnedCustomer”）。用状态属性；事物会进入和退出状态。
- 把业务里提到过的一切都建模。做到能力问题需要的程度就停。
- 定义只是把类名换个说法（“客户就是客户”）。要说清它和别的东西有什么不同。

与团队共享

把它添加到 AI Skill Pod，团队里的每个人（包括外包人员）都能在自己的 AI 中使用同一个版本。 了解与团队共享 AI 技能的最佳方式

添加到团队的 Pod

更新记录

• v1.0.0 · 2026年11月4日 · First release.