06 构建方法（上）：定范围、写能力问题、识别对象与关系
从这一篇开始进入"怎么做"。本体构建分上下两篇：上篇（本篇）解决"建什么"——确定范围、写能力问题、盘点术语、识别对象和关系，产出名词层的骨架；下篇（第 07 篇）解决"怎么让它动起来并持续可用"——动作、规则、数据绑定、验收与演进。全程以示例商城的退货退款为例。
1. 全流程一览
本系列把构建过程拆成八步。它借鉴了斯坦福《Ontology Development 101》的七步法，并按企业实践补上了动作、数据绑定和验收：
| 本系列步骤 | 对应 Ontology 101 | 产出 |
|---|---|---|
| 1 定范围 | 确定领域和范围 | 范围卡 |
| 2 写能力问题 | 确定范围时写下能力问题 | 能力问题清单 |
| 3 盘点术语与来源 | 考虑复用现有本体、列举重要术语 | 术语表、同义词表、来源清单 |
| 4 识别对象类型 | 定义类和类层级 | 对象类型清单 |
| 5 识别关系 | 定义属性（槽）；注：101 的"槽"同时包含数据属性和关系，本系列把属性草稿放在第 4 步、关系放在第 5 步 | 关系表、关系图 |
| 6 定义动作与规则 | 定义约束（侧面）；企业实践扩展 | 动作定义卡、规则表、状态机 |
| 7 绑定数据 | 创建实例 | 映射表、数据质量报告 |
| 8 验收与演进 | 迭代 | 测试集、版本记录 |
Noy 和 McGuinness 反复强调两点，值得在动手前记住：建模没有唯一正确答案，好坏取决于用途；建模一定是迭代的，第一版一定会改。
2. 第一步：定范围
2.1 选一个小闭环
不要一开始就建"全公司本体"。选范围的标准是：价值明确、边界稳定、能形成从发现到处置的闭环。有平台厂商建议从"设备告警到维修处置"这样的闭环起步，再扩展到相邻业务；放到电商，"退货退款"就是一个合适的起点：每天发生、牵涉多个系统、规则和例外多、出错就是钱的问题。
2.2 写一张范围卡
| 项 | 示例商城 V1 |
|---|---|
| 业务目标 | 客户发起退货退款后，客服和 AI 客服能准确判断资格、计算金额、按规则走审批，并能回答"钱到哪了" |
| 包含 | 售后申请、审核、退货寄回与验收、退款（含部分退款、分次退款）、相关客服工单 |
| 暂不包含 | 换货、价格保护、发票、商家结算、营销补偿券的发放 |
| 主要用户 | 一线客服、客服主管、仓库验收员、AI 客服 |
| 涉及系统 | 订单系统、售后系统、支付系统、物流系统、客服工单系统、会员系统 |
| 成功标准 | 能力问题清单全部可回答；V1 动作在影子模式下误判率达到约定阈值（见第 07 篇） |
| 语义裁决人 | 客服运营负责人（"客户以谁为准""退款完成以哪个时间点为准"由其拍板） |
最后一行最容易被忽略，却最重要。本体会遇到大量"听谁的"的问题，必须有人拍板。
2.3 组一支混编小队
本体不是数据团队自己关起门能做完的。有实践者列过一份角色清单，按示例商城的规模可以精简为：
| 角色 | 职责 | 示例商城中谁来担任 |
|---|---|---|
| 业务负责人 | 裁决语义冲突，确认范围和优先级 | 客服运营负责人 |
| 领域专家 | 讲清规则、例外和真实案例 | 资深客服、售后主管、仓库验收组长 |
| 本体建模者 | 把口述整理成对象、关系、动作和规则 | 产品经理或数据架构师 |
| 数据工程 | 找到数据来源、做映射和质量检查 | 数据平台同学 |
| 应用工程 | 把动作接到业务系统，接入 AI 客服 | 售后系统和 AI 平台研发 |
| 测试评测 | 维护能力问题的标准答案和回归测试 | 质量或运营分析同学 |
第一版不必追求人多，一人可以兼任多个角色；关键不在人数，而在业务负责人和领域专家是否真的投入时间。
2.4 先听业务，不先画图
一位做过咨询建模的作者的做法是：先听业务方口述，不先画类图。听的时候重点记五件事：管什么、不管什么；组织怎么分层；有哪些人员角色；事情靠什么连起来；能对上号的真实例子。比起直接看数据库表，这样更不容易被现有系统的历史包袱带偏。
2.5 第一场访谈工作坊怎么开
对新手来说，最难的往往是"第一次坐下来和业务方聊什么"。下面是一场约 90 分钟工作坊的参考议程，参加者是业务负责人、两三位领域专家和建模者：
| 环节 | 时长（参考） | 做什么 | 产出 |
|---|---|---|---|
| 开场 | 10 分钟 | 说明目的：不是做系统需求，而是把"售后这件事"讲清楚 | 统一预期 |
| 讲一个真实案例 | 20 分钟 | 请资深客服完整讲一单最近处理过的复杂售后，从客户来电到钱到账 | 一条完整的业务链 |
| 圈名词和动词 | 20 分钟 | 建模者把案例里出现的名词、动词写在白板上，大家补充遗漏 | 术语初稿 |
| 找分歧 | 20 分钟 | 逐个问"这个词在你们部门是什么意思"，记录不一致之处 | 待裁决清单 |
| 定边界 | 10 分钟 | 哪些事这次不管 | 范围卡的"不包含"一栏 |
| 收尾 | 10 分钟 | 业务负责人对最重要的两三个分歧当场拍板，其余约定时间 | 第一批裁决结论 |
几个小技巧：用真实单据而不是抽象流程图做引子；让不同部门的人坐在一起，分歧会自然暴露；建模者少说术语，多问"然后呢""如果……怎么办"。
3. 第二步：写能力问题
能力问题（Competency Question，简称 CQ）是本体建成后必须能回答的业务问题清单。它是范围的具体化，也是最终验收的标准：有实践者建议写 10 到 20 个，并且本体里的每个元素都应能追溯到至少一个能力问题——追溯不到的，可能就是过度设计。
能力问题以查询、判断、动作三类为主，另可加统计、追溯两类辅助（下表的 CQ11、CQ12）：
| 编号 | 类型 | 能力问题 |
|---|---|---|
| CQ1 | 查询 | 这位客户（含其所有账号）最近 30 天有哪些售后单，各处于什么状态？ |
| CQ2 | 查询 | 这笔退款现在卡在哪一步，在等谁处理？ |
| CQ3 | 查询 | 这个订单行已经退过多少钱，还能退多少？ |
| CQ4 | 查询 | 这个售后单对应的退货包裹到哪里了，仓库验收了吗？ |
| CQ5 | 判断 | 这件商品现在还能申请无理由退货吗？依据是哪条规则？ |
| CQ6 | 判断 | 这笔退款是否需要主管审批？ |
| CQ7 | 判断 | 这个售后申请是否与已有售后单重复？ |
| CQ8 | 动作 | 为这个售后单发起一笔 120 元的部分退款，需要哪些参数、会产生什么结果？ |
| CQ9 | 动作 | 主管驳回退款后，售后单回到什么状态，客户会收到什么通知？ |
| CQ10 | 动作 | AI 客服能为客户做到哪一步，哪一步必须转人工？ |
| CQ11 | 统计 | 上个月各品类的退款率是多少？（口径交给指标层） |
| CQ12 | 追溯 | 某笔已完成的退款是谁发起、谁批准、依据哪版规则？ |
写能力问题时的几个提示：用业务方的原话；尽量具体到可以给出标准答案；包含"判断"和"动作"类，否则建出来的只会是一份数据字典。
3.1 好的能力问题和差的能力问题
| 差的写法 | 问题在哪 | 改进后的写法 |
|---|---|---|
| 系统要能查询售后信息 | 太笼统，无法判断是否回答正确 | 这位客户（含所有账号）最近 30 天有哪些售后单，各处于什么状态？ |
| 退款要符合规定 | 没说哪条规定，也没说要回答什么 | 这笔退款是否需要主管审批？依据哪条规则？ |
| 提升售后效率 | 是目标，不是问题 | 这笔退款现在卡在哪一步，在等谁处理？ |
| 查询 refund_apply 表的 status 字段 | 用了技术语言，绑定了实现 | 这个售后单现在处于什么阶段？ |
好的能力问题有四个特征：用业务语言；具体到能给出标准答案；能看出需要哪些对象和关系；不预设技术实现。写完后，最好请业务方为每个问题准备一两个真实例子和正确答案，它们会直接成为第 07 篇验收用的测试集。
4. 第三步：盘点术语与来源
把访谈记录、制度文档、系统表结构、客服话术里出现的名词和动词全部列出来。名词通常会变成对象类型或属性，动词通常会变成关系或动作。
这一步最有价值的产出是同义词表：
| 业务中的说法 | 系统里的写法 | 本体中的统一概念 |
|---|---|---|
| 售后、退货申请、退换货 | after_sale、refund_apply、return_order | 售后单 |
| 退款、退钱、打款 | refund、payback | 退款单 |
| 买家、用户、会员、来电人 | user_id、member_no、openid、caller | 客户 |
| 已完成（售后系统） | after_sale.status=40（注意：和第 01 篇订单表里的 status 是两套编码） | 售后单状态：退货验收完成，不代表已退款 |
| 已完成（支付系统） | refund_status=SUCCESS | 退款单状态：已退款 |
同时登记每个概念的权威来源：客户以会员系统为准，签收时间以物流系统为准，退款结果以支付渠道回执为准。
复用方面，Ontology 101 建议先看看有没有现成的本体可以借用。企业里通常不会整体导入公开本体，而是参考其中相关片段的命名和结构。以电商为例，公开词表 schema.org 里就有 Order（订单）、OrderItem（订单行，带数量和对应的包裹）、ParcelDelivery（包裹配送，带运单号）、MerchantReturnPolicy（退货政策，其中退货天数从送达日起算）等类型，可以拿来对照自己的命名和关系。
5. 第四步：识别对象类型
从名词清单里挑出对象类型时，可以用下面的流程逐个判断：
按这个流程过一遍示例商城的名词：
| 候选 | 判断 | 结论 |
|---|---|---|
| 客户 | 独立身份，长期存在 | 对象类型 |
| VIP | 客户的一种资格，会变化 | 客户的属性"会员等级" |
| 订单 | 独立身份 | 对象类型 |
| 订单行 | 连接订单与商品，有数量、实付金额 | 关系体对象 |
| 商品 / SKU | 独立身份 | 对象类型（以 SKU 为粒度） |
| 售后单 | 承载一次诉求的处理过程，连接订单行、退款单和退货包裹，有状态和历史 | 过程对象（兼起关系体的作用） |
| 已退款 | 售后单的一个阶段 | 状态 |
| 退款单 | 独立身份，与支付流水对应 | 对象类型 |
| 支付单 | 独立身份，权威来源为支付系统；"原路退回"就是退回到它 | 对象类型 |
| 审批记录 | 记录谁在何时、按哪版规则批准了哪一次动作，有自身历史 | 关系体对象（连接动作实例与审批人） |
| 退货包裹 | 有运单号和物流轨迹；一个包裹可能装着多个订单行或多个售后单的商品 | 对象类型（发货单的一种，用"方向"属性区分正向发货和退货寄回，见下文） |
| 客服工单 | 独立身份，有处理人 | 对象类型 |
| 收件人 | 客户或他人在发货单上的角色 | 发货单的属性 |
两个常见困惑：
- 类还是实例？这取决于用途。《Ontology Development 101》用 Sterling Vineyards Merlot（一款梅洛葡萄酒）举例：如果只关心酒菜搭配，它就是一个实例；如果还要管理餐厅库存，具体的每一瓶酒才是实例。电商里同样，"某款外套"在商品管理里是一个对象，在库存管理里可能要细到 SKU 甚至批次。V1 只按能力问题需要的粒度建。
- 要不要建层级？可以自上而下（先定大类再细分）、自下而上（先列具体再归纳），或两者结合，实践中结合最常见。例如"发货单"下可以区分"正向发货"和"退货寄回"，但只有当两者的属性或动作确实不同时才值得拆。
命名上，对象类型用名词、单数，中英文名都定下来，避免缩写——用 AfterSalesCase，不用 AS。
5.1 顺手写下属性草稿
识别出对象类型后，趁访谈记忆还新鲜，为每个对象写一份属性草稿。上篇阶段不必追求完整，重点记三件事：业务名、取值和来源。以"订单行"为例：
| 属性 | 业务含义 | 取值或单位 | 来源 | 待确认 |
|---|---|---|---|---|
| 数量 | 该商品购买的件数 | 正整数 | 订单系统 | 部分退货时是否拆行？ |
| 实付金额 | 分摊优惠后该行实际支付的钱 | 元，两位小数 | 订单系统 | 运费是否分摊到行？ |
| 已退金额 | 该行累计已成功退款的钱 | 元，两位小数 | 由退款单汇总 | 以支付渠道回执为准 |
| 是否生鲜 | 决定能否无理由退货 | 是 / 否 | 商品中心 | 预售生鲜如何处理？ |
"待确认"一栏很重要：它把访谈中暴露的疑问留在纸面上，交给裁决人或在下一次访谈中澄清。第 07 篇会在此基础上补全数据类型、必填、校验规则等细节。
6. 第五步：识别关系
从动词清单里找关系：客户"下"订单，订单"包含"订单行，售后单"针对"订单行。每条关系都写清名称、方向、两端、基数，并标注它来自哪个系统的哪个字段。
图里有三处值得解释。第一，发货单和订单行之间是多对多：一个包裹装着一个或多个订单行，一个订单行也可能分装在几个包裹里（或者还没发货）。这条"装运"关系是回答 CQ5 的关键：判断无理由退货期，要先找到该订单行所在正向包裹的签收时间，自签收次日起算 7 天。"订单有哪些包裹"可以沿订单行推出来，所以不再单独画订单到发货单的边。第二，退货包裹和售后单是"多对零或一"：一个售后单最多对应一个退货包裹，一个退货包裹却可能装着多个售后单的商品。第三，"客户—售后单"这条边看似是捷径，保留它是因为申请人可能不是下单人（例如礼品单的收礼人），它记录的是"谁提出了诉求"这一独立事实，而不是"这位客户的订单有售后"。
识别关系时有三条经验：
- 外键进关系，不留成字符串属性。售后单上不要放一个"订单号"文本字段了事，而是建立"针对"关系。
- 不造捷径。"这位客户退过哪些商品"应该沿"客户—售后单—订单行—商品"走，而不是额外建一条"客户退过商品"的边。捷径会丢掉中间的事实（哪次售后、退了多少、是否被驳回），也会和正式路径产生矛盾。确实需要快捷查询时，把它标为派生关系，由正式路径计算得出。
- 基数要问业务。"一个售后单能不能针对多个订单行？"系统可能允许，业务可能禁止。基数是业务承诺，要由裁决人确认。
7. 上篇的产出与自查
完成前五步后，你手上应该有：范围卡、能力问题清单、术语与同义词表、对象类型清单（含属性草稿）、关系表和关系图。用下面的问题自查：
- 每个能力问题，能否在关系图上找到一条回答它的路径？
- 每个对象类型和关系，能否追溯到至少一个能力问题？
- 有没有"一表一对象"的照搬？有没有把状态或角色建成了对象类型？
- 每个对象类型的身份（主键）和权威来源是否明确？
- 语义冲突是否都记录了裁决人和结论？
有作者提醒："本体是现实的抽象，而不是现实的镜像。"V1 宁可小而准，也不要大而全。下一篇（第 07 篇）在这个骨架上加上动作和规则，绑定真实数据，并讨论如何验收和持续演进。
8. 常见问题
问：能力问题写不出来怎么办？
从三个地方找：客服最常被问的问题（看客服系统的高频问题统计）、业务方最常吵的问题（看会议纪要和投诉升级记录）、AI 客服最常答错的问题（如果已有试点）。这三类问题往往就是最有价值的能力问题。
问：业务方说不清楚，或者几个人说法不一样，怎么办？
这是正常现象，也正是本体要解决的问题。不要急着替他们统一，把不一致之处原样记录下来，交给裁决人拍板。说不清楚的地方，回到真实单据上去问："这一单当时是怎么处理的？"
问：现有系统的表结构要不要参考？
要参考，但要放在听完业务之后。表结构能帮你发现业务方忘记提到的东西（比如某个很少用的状态），也能告诉你数据实际上怎么存。但如果先看表，很容易被历史设计带偏，变成"一表一对象"（见第 08 篇）。
问：对象类型和关系画到什么程度可以进入下一篇的工作？
当每个能力问题都能在关系图上找到一条回答路径，每个对象都有主键和权威来源，主要的语义分歧都有了裁决结论时，就可以开始定义动作和规则了。不必等到完美，第 07 篇的工作也会反过来帮你发现遗漏。
问：可以让大模型直接帮我们画对象和关系吗？
可以让它出初稿，例如从访谈记录里抽取名词和动词、提出候选对象和关系。但构型判断（是对象、状态、角色还是关系体）和语义裁决必须由人完成。第 07 篇第 6 节介绍了具体做法和提示词骨架。
本篇要点
- 构建分八步：定范围、写能力问题、盘点术语与来源、识别对象、识别关系（本篇），以及动作与规则、数据绑定、验收与演进（第 07 篇）。
- 范围选价值明确、边界稳定的小闭环，并指定能拍板的语义裁决人。
- 第一场工作坊用真实案例做引子，圈出名词动词、暴露分歧、当场裁决最关键的几个。
- 能力问题是范围的具体化和验收标准，以查询、判断、动作三类为主，统计、追溯为辅；每个本体元素都应能追溯到能力问题。
- 识别对象时区分属性、状态、角色、关系体和普通对象；粒度按能力问题需要来定。
- 关系要有名称、方向、基数和来源；外键进关系、不造捷径，基数由业务确认。
参考引用
- 《Ontology Development 101: A Guide to Creating Your First Ontology》，Natalya F. Noy、Deborah L. McGuinness，Stanford University。原文
- 《本体论（七）:本体构建方法论》，数翼。Cubox，原文
- 《本体建模过程案例：FDE如何根据业务口述建立静态本体？》，基线沉思。Cubox，原文
- 《我用微软开源工具Ontology Playground可视化了本体推理，顺便在建模层对照了一遍》，基线沉思。Cubox，原文
- 《深入浅出学习本体论（Ontology）：从哲学根基到实践应用概要》，Tom 汤姆的技术雷达。Cubox，原文
- 《01-认识 Ontilio：把业务世界建模成可运行的本体》，OntologyHub。Cubox，原文
- 《准备上知识图谱和本体（Ontology）？要什么团队、选什么场景、花多少成本 | 人人都是产品经理》，叶小钗。Cubox，原文
- 《别把RAG当架构：Ontology（本体）才是Agent的业务世界》，KK AI应用落地社。Cubox，原文
- 《Protégé实战：Docker部署WebProtégé，30分钟创建第一个企业本体》，飞翔海马 AI手抄笔记。Cubox，原文
- 《一文读懂本体四大核心技术：RDF、OWL、SPARQL、SHACL，看懂语义层完整工作流》，女王的专属领地 AI产品观察局。Cubox，原文
- schema.org 类型说明：OrderItem、ParcelDelivery、MerchantReturnPolicy。OrderItem，ParcelDelivery，MerchantReturnPolicy