本体设计实战方法论

AI系统本体设计实战方法论

> 编制：万有AI产品团队

> 定位：万有AI通用方法论系列 | 用途：指导AI系统本体设计实践 + 课程开发素材

> 依据：OntologyEngine实体引擎、52种EntityType、GraphRelation图谱关系、KB_ENTITY_MAP知识库映射等实际代码实现

第一章 为什么要做本体设计

1.1 本体是什么——用最简单的话说

本体就是让AI"懂行"的知识骨架。

没有本体的AI，像一个刚毕业的大学生——什么都学过，但什么都不精。你让它做行业分析，它给你一堆正确的废话；你让它做决策建议，它给你"视情况而定"。

有了本体的AI，像一个在行业里摸爬滚打十年的老兵——知道行业的天花板在哪、坑在哪、机会在哪、规则是什么。

1.2 不做本体设计的三大后果

1.3 本体设计的核心价值

本体设计 = 给AI装上"行业大脑"

                    没有本体                    有本体
                    ────────                  ────────
AI的回答            正确但空泛                 精准且可操作
AI的决策            凭感觉                     有框架有逻辑
AI之间协作          各说各话                   统一语言统一认知
知识复用            每次从零开始               站在本体肩膀上
新行业拓展          重新来过                   复制模板填内容

思想源流：从本体论到行业大脑

本体设计方法论的四个源流：

• 哲学与知识工程的本体传统：Ontology从哲学"存在论"走进知识工程，成为"对某个领域做系统化概念建模"的工程方法。本方法论继承其骨架，剥离其学术门槛。
• 立体思维模型：纵轴六层（体力/时间→国际）+横轴七层（PEST→内部）+时间轴+显隐性规则，源于创始人近三十年跨行业商业观察——行业知识的"立体地图"先于任何AI系统存在。
• 数据库工程纪律：先定义Schema再灌数据。本体就是AI时代的Schema——不做本体就灌知识，等于不做表结构就灌数据库。
• AHUB实战校准：25个行业本体+OntologyEngine实体引擎（52种实体类型）的落地过程，把三层架构从设计图变成可运行的数据文件。

一句话：本体设计的本质，是先给AI画好行业地图，再让它上路。

第二章 本体设计的三层架构

> 核心洞察：一个完整的AI系统本体不是一张表、一个文件，而是三层架构——元本体、行业本体、Agent本体，从通用到具体，层层递进。

2.1 三层架构总览

┌─────────────────────────────────────────────────────────┐
│                    第一层：元本体                         │
│           通用创业方法论（道）                              │
│     24个Section · 公理体系 · 五阶段 · 纵轴六层 · 横轴七层    │
│                  所有行业共享的底层逻辑                      │
└──────────────────────────┬──────────────────────────────┘
                           │ 继承 + 具体化
                           ▼
┌─────────────────────────────────────────────────────────┐
│                  第二层：行业本体                          │
│           行业知识体系（术）                                │
│     25个行业 · 纵轴映射 · 横轴定位 · 困境体系 · 术语词典      │
│               每个行业的立体思维模型                        │
└──────────────────────────┬──────────────────────────────┘
                           │ 按需抽取 + 注入
                           ▼
┌─────────────────────────────────────────────────────────┐
│                  第三层：Agent本体                         │
│           岗位操作能力（技）                                │
│     8个Agent · 思维链6步 · 原子操作 · 技能集 · 三层记忆      │
│              每个岗位的专业操作能力                         │
└─────────────────────────────────────────────────────────┘

2.2 三层之间的关系

2.3 三层本体数据量级参考

第三章 第一层：元本体设计——"道"

3.1 元本体的设计原则

原则一：元本体是"宪法"，不是"百科全书"

元本体只定义框架和约束，不填具体内容。具体内容由行业本体填充。

✅ 正确：元本体定义"纵轴有六层"（框架）
❌ 错误：元本体定义"AI行业纵轴能力层是Prompt工程师"（内容）

✅ 正确：元本体定义"创业有五个阶段"（框架）
❌ 错误：元本体定义"AI行业验证阶段的核心任务是PMF"（内容）

原则二：枚举值一旦确定，行业本体必须遵守

元本体中的枚举值（纵轴6层名称、横轴7层名称、5阶段名称）是全系统统一语言的基础，行业本体不得自创或改名。

VERTICAL_LAYERS = ["physical_time", "capability", "resource", "capital", "national", "international"]
HORIZONTAL_LAYERS = ["pest_macro", "industry_sector", "industry", "track", "value_chain", "competition", "internal"]
FIVE_STAGES = ["discover", "validate", "traction", "scaling", "upgrading"]

原则三：元本体必须可运行、可验证

元本体不是文档，是代码。必须能运行输出完整JSON，必须能通过自动化验证脚本检查一致性。

3.2 元本体的核心内容（24个Section）

我们将万有AI的元本体提炼为24个Section，覆盖创业全生命周期：

3.3 元本体设计实战步骤

步骤1：确定领域边界
  → 你的AI系统服务什么领域？（创业教育/医疗/法律/金融...）
  → 边界决定了元本体的广度和深度

步骤2：提炼核心公理
  → 这个领域有哪些"不证自明"的基本假设？
  → 万有AI的4条公理：因缘和合/本质不变/内因决定/外因演变

步骤3：定义阶段模型
  → 这个领域的核心过程分几个阶段？
  → 创业5阶段 vs 医疗5阶段(预防/筛查/诊断/治疗/康复) vs 法律5阶段(咨询/取证/起诉/审判/执行)

步骤4：设计分类体系
  → 这个领域如何分类？
  → 五产分类法 vs 医疗ICD-10 vs 法律部门法

步骤5：构建立体框架
  → 纵轴：从低到高的生存发展层级
  → 横轴：从宏观到微观的定位维度
  → 时间轴：过去/现在/未来
  → 规则层：显性规则+隐性规则

步骤6：编写可运行代码
  → 元本体不是文档，是代码
  → 必须能运行、能输出JSON、能自动验证

步骤7：验证一致性
  → 枚举值是否完整？
  → Section之间是否有矛盾？
  → 行业本体是否能基于此框架填充？

第四章 第二层：行业本体设计——"术"

4.1 行业本体的设计原则

原则一：行业本体是元本体的"具体化"，不是"另起炉灶"

行业本体的结构必须继承元本体，在元本体的框架内填入行业具体内容。

元本体定义：纵轴有六层（体力/能力/资源/资本/国家/国际）
行业本体填充：AI行业体力层=数据标注员，能力层=Prompt工程师，资源层=GPU算力...

原则二：每个行业必须完整填充，不允许空字段

空字段意味着AI在该维度"无知"，会导致错误推理。

原则三：行业术语词典是"统一语言"的基石

不同行业有不同的专业术语，术语词典确保AI在该行业语境下使用正确的语言。

4.2 行业本体的立体思维模型

> 这是万有AI独创的行业知识建模方法，由创始人亲自指导设计。

行业本体由四个维度构成完整的行业知识体系：

                    ┌──────────────────┐
                    │   立体思维模型     │
                    │                  │
         ┌──────────┤  纵轴六层        ├──────────┐
         │          │  ×               │          │
         │          │  横轴七层        │          │
         │          │  ×               │          │
         │          │  时间轴          │          │
         │          │  ×               │          │
         │          │  显隐性规则      │          │
         │          └──────────────────┘          │
         │                                        │
    纵向深度                                  横向广度
    "你在行业的什么位置"                    "行业在什么环境里"

维度一：纵轴——六层生存发展空间

维度二：横轴——七层精准定位

维度三：时间轴——三视角×时代杠杆

时代杠杆模型：资源时代→互联网时代→AI时代，每个时代有不同的赢的逻辑。

维度四：显性规则与隐性规则

4.3 行业本体模板（15+字段）

每个行业本体必须包含以下字段，缺一不可：

{
    "industry_name": "行业名称",
    "industry_code": "industry_code_snake_case",
    "parent_industry": "父行业编码（可为空）",
    "industry_sector": "五产归属枚举值",
    "industry_sector_label": "如'第四产业·科技'",
    "version": "本体版本号",
    "design_framework": "立体思维模型（纵轴六层+横轴七层+时间轴+显隐性规则+5阶段困境）",
    "last_updated": "最后更新日期",

    "commercial_value": {
        "priority": "P0/P1/P2",
        "target_learner_count": "目标学员数",
        "payment_willingness": "付费意愿",
        "competitive_advantage": "竞争优势",
        "roi_estimate": "ROI估算"
    },

    "vertical_axis": {
        "description": "纵轴概述",
        "layers": {
            "physical_time": { "行业具体表现..." },
            "capability": { "行业具体表现..." },
            "resource": { "行业具体表现..." },
            "capital": { "行业具体表现..." },
            "national": { "行业具体表现..." },
            "international": { "行业具体表现..." }
        }
    },

    "horizontal_axis": {
        "description": "横轴概述",
        "layers": {
            "pest_macro": { "行业具体表现..." },
            "industry_sector": { "行业具体表现..." },
            "industry": { "行业具体表现..." },
            "track": { "行业具体表现..." },
            "value_chain": { "行业具体表现..." },
            "competition": { "行业具体表现..." },
            "internal": { "行业具体表现..." }
        }
    },

    "timeline_axis": {
        "past": { "历史脉络..." },
        "present": { "当前定位..." },
        "future": { "趋势预判..." }
    },

    "rule_system": {
        "explicit_rules": [ "显性规则列表..." ],
        "implicit_rules": [ "隐性规则列表..." ]
    },

    "five_phase_dilemmas": {
        "critical_dilemma": { "核心困境..." },
        "dilemmas": [
            { "stage": "discover/validate/traction/scaling/upgrading", "困境内容..." }
        ]
    },

    "term_dictionary": {
        "术语1": "定义1",
        "术语2": "定义2"
    },

    "ontology_def": {
        "entities": [ "实体定义列表..." ],
        "relations": [ "关系定义列表..." ],
        "stages_mapping": { "5阶段映射..." }
    }
}

4.4 行业本体设计实战步骤

步骤1：确定行业定位
  → 行业名称、编码、五产归属
  → 参考五产分类法：一产(原材料)/二产(制造)/三产(服务)/四产(科技)/五产(文化)

步骤2：填充纵轴六层
  → 体力层：该行业最底层的劳动者是谁？靠什么活？
  → 能力层：该行业的核心能力是什么？凭什么贵？
  → 资源层：该行业的稀缺资源是什么？谁掌握定价权？
  → 资本层：该行业的资本玩家是谁？投资逻辑是什么？
  → 国家层：该行业的政策红利是什么？国家战略是什么？
  → 国际层：该行业的全球格局是什么？中国位置在哪？

步骤3：填充横轴七层
  → PEST：宏观环境对该行业的影响
  → 五产：该行业属于哪个产业？上下游是什么？
  → 行业：行业边界定义
  → 赛道：细分领域拆解
  → 价值链：上中下游位置
  → 竞争：五类竞争分析
  → 内部：企业6维内审

步骤4：填充时间轴
  → 过去：行业从哪来？关键转折点？
  → 现在：行业现在在哪？当前阶段特征？
  → 未来：行业往哪去？趋势预判？

步骤5：提炼规则体系
  → 显性规则：政策/法律/制度/标准/准入门槛
  → 隐性规则：潜规则/人性/文化差异/不可控因素

步骤6：构建困境体系
  → 核心困境：该行业最根本的困境是什么？
  → 5阶段困境：发现/验证/跑通/复制/升级各阶段的典型困境
  → 每个困境包含：名称/根因/影响/生存路径

步骤7：编写术语词典
  → 该行业特有的专业术语
  → 每个术语必须有清晰定义
  → 术语是AI"说行话"的基础

步骤8：定义实体关系
  → 该行业的核心业务实体
  → 实体之间的关系
  → 用于知识图谱构建

步骤9：验证一致性
  → 纵轴6层名称是否与元本体一致？
  → 横轴7层名称是否与元本体一致？
  → 5阶段枚举是否与元本体一致？
  → 是否有空字段？
  → 术语词典是否覆盖核心概念？

4.5 五产分类法——行业归属的核心工具

> 从传统三产升级到五产，是创始人的重要理论创新。

为什么需要五产而不是三产？ 因为AI、软件、新能源等科技行业和传统服务业有本质区别——它们的边际成本趋近于零、网络效应极强、赢者通吃。把AI归为"服务业"就像把飞机归为"交通工具"——没错但没用。

第五章 第三层：Agent本体设计——"技"

5.1 Agent本体的设计原则

原则一：Agent本体是行业本体的"按需子集"

Agent不需要知道行业的全部知识，只需要知道自己岗位相关的知识子集。

行业本体（全量知识）
    ├── 明察需要：纵轴能力层+横轴赛道层+内部层+术语+困境
    ├── 凤鸣需要：纵轴资源层+横轴竞争层+价值链层+术语+困境
    ├── 璇玑需要：纵轴能力层+横轴行业层+竞争层+术语+困境
    └── 天枢需要：纵轴资本层+横轴PEST层+产业层+术语+困境

原则二：每个Agent有"岗位特有术语"——行业本体没有的

行业术语是全行业通用的，但每个岗位有自己的行话。

明察的岗位术语：RICE/双轨制/三阶段论/体验官
凤鸣的岗位术语：GEO/红线/裂变/5维评分/可见性/内容工厂/A/B测试
璇玑的岗位术语：CPCC/软著/专利/技术交底书/代码脱敏/政策窗口/IP全流程
天枢的岗位术语：（无，战略层用行业通用术语即可）

原则三：行业术语覆盖岗位术语——行业是唯一真相源

当行业术语和岗位术语有冲突时，以行业本体定义为准。

5.2 Agent本体配置表设计

每个Agent需要一份"行业配置表"，定义它订阅哪个行业、在纵轴的哪个层级、在横轴关注哪些层：

CREATE TABLE agent_industry_configs (
    id VARCHAR(50) PRIMARY KEY,
    agent_id VARCHAR(50) NOT NULL,          -- Agent标识
    agent_role VARCHAR(100) NOT NULL,        -- Agent角色
    industry_code VARCHAR(100) NOT NULL,     -- 订阅的行业编码
    is_primary BOOLEAN DEFAULT FALSE,        -- 是否主行业
    vertical_layer VARCHAR(50) DEFAULT '',   -- 纵轴层级
    horizontal_layers JSONB DEFAULT '[]',    -- 横轴层级数组
    subscribed_fields JSONB DEFAULT '[]',    -- 订阅字段数组
    custom_terms JSONB DEFAULT '{}',         -- 岗位特有术语
    sync_version VARCHAR(20) DEFAULT '',     -- 同步版本号
    updated_at TIMESTAMPTZ DEFAULT NOW()
);

5.3 Agent本体与思维链的集成

Agent的思维链（Thought Chain）是Agent执行任务的核心推理过程。行业上下文必须在思维链的每一步中注入，确保Agent的每一步推理都有行业知识支撑：

5.4 Agent本体设计实战步骤

步骤1：定义Agent角色
  → 这个Agent负责什么业务？（产品/营销/知产/战略...）
  → 它的纵轴定位在哪一层？（能力/资源/资本...）
  → 它的横轴关注哪些层？（赛道+内部 / 竞争+价值链...）

步骤2：确定行业订阅
  → 这个Agent主攻哪个行业？
  → 它需要订阅行业本体的哪些字段？

步骤3：编写岗位术语
  → 这个岗位有哪些行业术语库中没有的行话？
  → 每个术语必须有清晰定义

步骤4：设计思维链注入映射
  → 思维链6步，每步注入什么行业上下文？
  → 参考上面的注入映射表

步骤5：验证Agent本体
  → 行业配置表是否完整？
  → 思维链注入映射是否覆盖6步？
  → 岗位术语是否与行业术语冲突？（冲突时以行业为准）

第六章 大脑→小脑桥接机制——BrainBridge

6.1 为什么需要桥接

大脑（AI大脑本体层）和小脑（Agent语义层）是两套独立的知识体系，没有桥接机制就会出现"断裂"：

6.2 BrainBridge六大组件

┌──────────────────────────────────────────────────────┐
│               BrainBridge 知识桥接服务                  │
│                                                      │
│  B1 AgentIndustryConfigService                       │
│     管理每个Agent的行业配置（订阅哪个行业、纵轴横轴定位）  │
│                                                      │
│  B2 TermExtractor                                    │
│     从大脑行业本体抽取术语，与岗位术语合并               │
│     合并规则：行业术语为准，岗位术语补充不存在的key       │
│                                                      │
│  B3 ContextBuilder                                   │
│     构建行业上下文（纵轴定位+横轴定位+困境+规则+趋势）   │
│     输出限制：2000字以内，智能截断                      │
│                                                      │
│  B4 BrainBridgeInjectService                         │
│     将行业上下文注入Agent思维链6步                      │
│     每步注入不同的字段组合                              │
│                                                      │
│  B5 SyncWatcher                                      │
│     监听大脑本体更新事件，标记Agent小脑需要同步          │
│     策略：lazy sync（标记dirty，下次查询时同步）        │
│                                                      │
│  B6 IndustrySwitch                                   │
│     Agent切换行业时，更新配置+清除缓存                  │
│     性能目标：≤1秒                                    │
│                                                      │
│  B7 OntologyBridge                                   │
│     将行业本体实体关系桥接到Neo4j图谱                   │
│     Agent通过GraphQueryService查询行业实体关系          │
└──────────────────────────────────────────────────────┘

6.3 桥接设计实战要点

要点1：行业是唯一真相源
  → 行业本体数据只在大脑维护，小脑不独立定义行业知识
  → 小脑的术语库是从大脑抽取的子集+岗位特有术语

要点2：自动同步不手动
  → 大脑行业本体更新后，小脑自动同步
  → 通过EventBus发布事件，SyncWatcher监听并标记dirty

要点3：按需注入不过载
  → 不是把行业全量知识一股脑塞给Agent
  → 而是根据思维链步骤，每步只注入该步需要的字段
  → 上下文限制2000字，防止Token浪费

要点4：行业切换要快
  → Agent可能服务多个行业
  → 切换行业时更新配置+清除缓存，目标≤1秒

要点5：图谱是终极表达
  → 行业本体的实体和关系最终要写入Neo4j
  → Agent通过图谱查询实现关联推理

第七章 AHUB系统本体——五层×七层架构

7.1 两个视角看同一个系统

AHUB系统有两套体系，从不同视角描述同一个AI公司：

核心关系：5层是7层的能力基础，7层是5层的业务表达。

7.2 五层技术架构

7.3 七层业务体系

7.4 五层×七层交叉对照

第八章 本体设计的工程化落地

8.1 本体内容就是数据——不是传统PRD流水线

传统产品开发：产品出PRD → 研发写代码 → 测试验收

本体设计开发：产品总监写本体数据 → 研发做存储和接口 → 数据迁移 → 验证一致性

关键区别：本体内容本身就是数据，产品总监交付的不是文档而是可运行的数据文件。

8.2 产品总监与研发的协作边界

产品总监负责：本体是什么（内容与结构）
  → 元本体结构设计 → 产出：venture_ontology.py
  → 行业本体内容编写 → 产出：batch*.py
  → PRD需求规格说明书 → 产出：PRD文档
  → Python数据定义代码 → 产出：可直接运行的数据文件

研发负责人负责：本体怎么用（存储与接口）
  → 数据库Schema设计与实现 → PostgreSQL + Neo4j + Milvus
  → API接口开发 → REST / MCP
  → 数据迁移（.py → 数据库）→ 迁移脚本
  → 生产级部署 → Docker / K8s
  → 本体热更新机制 → 无需重启即可更新本体

8.3 衔接关键点

8.4 验收标准模板

第九章 本体设计的常见误区与避坑指南

9.1 陷阱一：元本体写成了百科全书

❌ 错误做法：在元本体里写"AI行业的核心能力是Prompt工程"
✅ 正确做法：元本体只定义"能力层"这个概念，AI行业的具体能力由行业本体填充

原因：元本体是框架，不是内容。如果把内容写进元本体，每新增一个行业就要改元本体，
     违反了开闭原则。

9.2 陷阱二：行业本体自创概念

❌ 错误做法：汽车行业本体自创纵轴"制造层""设计层""销售层"
✅ 正确做法：汽车行业本体使用统一纵轴六层，在每层内填入汽车行业具体表现

原因：如果每个行业自创概念，Agent切换行业时需要重新学习概念体系，
     违反了"统一语言"原则。

9.3 陷阱三：Agent获取全量行业知识

❌ 错误做法：把AI行业全部知识一股脑塞给明察Agent
✅ 正确做法：明察只订阅纵轴能力层+横轴赛道层+内部层+术语+困境

原因：全量知识=Token浪费+推理变慢+可能混淆。Agent只需要知道自己岗位相关的知识子集。

9.4 陷阱四：本体更新不同步

❌ 错误做法：大脑本体更新了，Agent小脑不知道
✅ 正确做法：通过EventBus发布事件，SyncWatcher监听并自动同步

原因：过时的知识比没有知识更危险。Agent用旧知识做决策，可能给出错误建议。

9.5 陷阱五：忽视隐性规则

❌ 错误做法：只梳理显性规则（政策/法律/制度），忽视隐性规则
✅ 正确做法：显性规则+隐性规则都要梳理

原因：很多行业的"潜规则"比显性规则更重要。比如"大厂优先选有融资背景的团队"
     不是任何政策规定的，但它是真实存在的规则。

9.6 陷阱六：本体设计者和工程实现者职责混淆

❌ 错误做法：产品总监写完PRD就不管了，研发自己理解自己实现
✅ 正确做法：产品总监交付可运行的数据文件+验证脚本，研发基于交付物工程化

原因：本体内容就是数据，产品总监必须交付可运行的数据，不能只交付文档。
     文档可能有歧义，代码不会。

第十章 本体设计课程化——如何将方法论转化为课程

10.1 课程体系设计

基于本体设计实战方法论，可以开发以下课程：

10.2 实战练习设计

10.3 课程案例库

万有AI已完成的25个行业本体可作为课程案例：

第十章 方法论关系（知识乐高）

本体设计是知识链路的"上游图纸"，下游方法论都吃它的产出：

• 知识库搭建通用方法论（04）：本体是知识库的Schema设计图——先有本体定实体与关系，再建库灌卡片，顺序不能反
• 知识注入与智能检索（07/08）：注入什么、注入到哪个子库，由本体的三层结构决定
• 行业专家Agent蒸馏方法论（12）：蒸馏的原料挂在行业本体的立体思维模型上，蒸馏产出回灌本体——本体越厚，专家越强
• 创建第一个AI联合创始人方法论（10）：Agent本体的配置表（角色/三观/红线/能力）是创建Agent的直接输入
• AI原生公司技术与解决方案全景方法论（36）：OntologyEngine实体引擎是本方法论的工程实现，技术选型见其第二章2.3

一句话：本体是知识乐高的底座积木——底座不正，上层全歪。

附录A 术语表

附录B 万有AI本体设计成果清单

附录C 参考资源

附录D V1.1补充：OntologyEngine实体引擎（基于实际代码）

D.1 实体类型体系（52种EntityType）

Ahub实际代码中定义了52种实体类型，覆盖8大知识域：

D.2 实体定义结构

@dataclass
class EntityField:
    name: str           # 字段名
    type: str           # 字段类型（str/int/float/datetime/list/dict）
    label: str          # 中文标签
    required: bool      # 是否必填
    default: Any        # 默认值

@dataclass
class EntityDefinition:
    entity_type: EntityType
    display_name: str
    description: str
    fields: List[EntityField]
    owner_agents: List[str]  # 归属Agent

D.3 图谱关系类型（GraphRelationType）

D.4 OntologyEngine核心API

D.5 本体引擎与三层架构的对应