先把问题说清楚。
同一个客户在三张表里有三个名字。“订单完成”在销售与交付部门可能含义不同。AI 即使读到了数据，也未必知道它们说的是不是同一件事。
我们把本体理解为一套可核对的业务表达：有哪些对象，各自有哪些属性，对象之间是什么关系，状态如何变化，谁可以做哪些动作。例如一张订单，关联客户、合同、商品和库存；交付被阻塞时，应能追到具体条件与原始记录。
从问题，走到结果。
- 01
从一个场景出发
先选订单跟进、项目管理等具体工作，确认业务边界。
- 02
统一对象与定义
确定客户、订单、合同等对象及属性、主键和状态口径。
- 03
连接关系与来源
让每个字段和关系对应到原系统与资料，显露冲突和缺失。
- 04
把规则接到动作
说明什么条件下可执行、由谁确认、结果怎样留痕。
从哪些资料开始
- 真实业务样本与现有表单
- 业务对象、状态口径和规则负责人
- 数据来源、字段映射及权限范围
一起留下什么
- 业务对象字典与关系模型
- 可回溯的数据映射和冲突清单
- 带权限与记录的场景验证流程
WHAT GOOD LOOKS LIKE
怎样才算做好。
用真实业务问题走完整链条：找到对象、解释关系、回到原始字段、判断规则并记录动作。分别检查业务定义错误、映射错误和源数据错误。
按场景逐步建设。知识图谱、数据库或多维表格都可能承载部分结构，选型取决于实际问题。你可能还想知道。
本体就是知识图谱吗？ ＋
知识图谱可以表达关联。本体还需要说明这些对象与关系在企业里意味着什么，并与来源、状态、规则和操作联系起来。
需要先把全公司的数据整理完吗？ ＋
从一个能验证价值的场景开始。先让一条业务链上的定义、关系和数据对应正确，再决定扩展范围。
01
不同表达
广角展示分离的业务桌面，同一个订单在几处出现不同表示。
02
统一对象
相机贴近订单载体，重复表示对齐到同一对象与属性槽位。
03
关系成形
环绕镜头揭示客户、合同、库存与订单之间可追踪的实体连接。
04
分镜图为视觉概念，用于校准三维制作；不是业务系统运行截图。规则与动作
推进到交付闸门，库存缺口导致暂停，变更提案在人工确认位等待。