前两篇已经说明企业本体解决什么问题，以及它与知识图谱、数据模型的分工。接下来进入建设方法：怎样从一个高价值问题出发，做出可运行、可验证、可继续扩展的第一版本体。企业本体不应从“描述整个企业”开始。更可行的路径，是从一个高价值问题倒推“最小可用本体”：先选定场景，只建立当前问题真正需要的业务对象（技术建模中也常称“实体”）和事件，映射现有数据，把口头规则变成显式约束，再逐步接入建议、动作和权限。
本文沿用“最小可用本体”这一概念：围绕一个高价值问题，只建立当前场景真正需要的业务对象、事件、关系、数据映射和显式规则。重点不是覆盖全部企业概念，而是先让本体开始解决真实业务问题。
它至少要具备：
“最小”不是字段越少越好，而是范围只覆盖当前问题真正需要的语义；“可用”则意味着它能够连接真实数据，并在实际问数或分析中被验证。
下面用一个贯穿全文的例子说明：
哪些客户订单会受供应商延期影响？
这个问题连接客户、销售订单、商品、供应商和交付事件，也涉及“延期”如何判断，能够检验业务对象、事件、关系和规则能否共同支撑一次真实分析。
| 步骤 | 作用 | 这一阶段做什么 | 重点 |
|---|---|---|---|
| 1. 选定高价值问题 | 明确要回答的业务问题 | 从真实经营问题开始 | 用问题限定范围 |
| 2. 只建所需业务对象和事件 | 只建当前问题需要的业务对象、事件和关系 | 识别主键、时间字段和主要关系 | 不追求大而全 |
| 3. 映射现有数据 | 连接已有表、指标、模型和接口 | 暴露数据与语义缺口 | 不要求先重构全部底层系统 |
| 4. 将口头规则显式化 | 说明金额、状态、时间、唯一性和例外 | 让规则能够被检查和复核 | 规则需要持续维护 |
| 5. 逐步接入建议、动作和权限 | 先稳定回答问题，再支持建议 | 有足够证据后再放开有限执行 | 不超出权限边界 |
企业本体的第一版范围，应由业务问题决定。不要从“我们有哪些系统和表”开始，也不要从“要把公司所有概念整理出来”开始。
对于示例问题，首先确认：
先把业务问题、关键术语、使用范围以及由哪位业务负责人确认说清楚。这样，第一版本体的范围由业务问题决定，不会在一开始就扩展成覆盖整个企业的概念工程。
重点：选择一个有明确业务用途、能够连接真实数据并由业务人员确认结果的问题，用它限定首版本体的范围。
范围确定后，只建立当前问题真正需要的业务对象与事件，再补上支撑回答所需的关系和规则。亿问以业务对象（实体）、事件、指标、维度、关系和口径为核心内容。
| 类型 | 示例 | 需要说清楚什么 |
|---|---|---|
| 对象 | 客户、销售订单、商品、供应商 | 业务对象是什么，如何被识别 |
| 事件 | 下单、交期变更、入库、发货、签收 | 围绕对象发生了什么 |
| 关系 | 客户提交订单、供应商供应商品 | 对象之间如何关联 |
| 规则 | 金额口径、订单状态、供应商延期 | 这些业务判断如何成立 |
业务对象需要能在企业数据中被识别。企业已有主数据、指标或语义资产时，应优先复用；如果同一业务对象在不同系统中存在不同标识，应先让当前问题使用的对象身份能够被明确确认。
时间也是语义层的重要组成部分。业务问题中的“上个月”“截至某日”“当前状态”，需要落到明确的时间语义和状态定义，否则同一句问题可能对应不同答案。
重点：让业务人员与系统对“有哪些业务对象、发生了哪些事件、业务对象如何关联、规则怎样判断”使用同一套明确表达。
完成业务骨架后，要把这些概念连接到企业已有的数据资产。首版应尽量复用现有表、指标、模型和接口，不要求先重构全部底层系统。
对每个必要概念，逐项说明它由哪些已有数据支撑：
| 需要说明的内容 | 对应问题 |
|---|---|
| 业务概念 | 这个业务对象、事件、关系或规则是什么 |
| 现有来源 | 对应哪张表、哪个指标、模型或接口 |
| 映射与关联 | 字段如何对应，关系如何连接 |
| 状态与时间 | 使用什么状态、时间和口径 |
| 权限与审计 | 谁可以访问，结果如何留痕和复核 |
例如，“供应商延期”不能只停留在自然语言里，需要明确它由哪些已有数据和时间条件支撑；如果相关数据缺失，就应把缺口显式暴露出来，而不是让模型补出确定答案。
没有可靠来源的概念，应进入缺口清单并缩小回答范围，不能由模型补出确定答案。
重点：让目标问题使用的业务对象、事件、关系和规则能够连接到可访问的企业数据，并在权限边界内进入查询与分析。
金额定义、状态转换、时间有效性、唯一性和例外情况，都是需要从口头经验变成显式约束的业务规则。亿问也列出了指标、维度、时间语义、关系路径和权限约束等建模内容。
示例问题可以形成以下检查：
这些口头规则需要变成显式约束；具体实现则应结合企业已有的数据体系。
在亿问已公开的技术架构中，语义执行还要继承已配置的权限与审计边界。也就是说，规则不只要写出来，还要能在受控执行中被复核。
重点：把所有会改变答案的金额、状态、时间、唯一性和例外规则，写成明确、可检查、可复核的约束。
当模型先能稳定回答问题，再进一步支持建议；当建议有足够证据，再逐步放开有限自动执行。亿问的试点路径也把“验证可信结果”放在“扩展更多应用”之前。
自然语言问题 → Alisa 将经标准化的问题意图转为 LogicForm → SemanticDB 根据企业语义与物理映射，将 LogicForm 映射为 SQL、API 或 URL 等执行目标 → 执行层在权限与审计边界内完成调用 → 返回可信结果并由业务确认
在亿问的技术架构中，Alisa 将自然语言问题转换成 LogicForm（逻辑形式）；SemanticDB 根据企业语义与物理映射，把 LogicForm 映射为 SQL、API 或 URL 等执行目标；执行层在权限与审计边界内完成调用并返回结果。这条链路先解决受控问数与分析；在此基础上，建议需要有足够的数据证据，涉及企业系统动作时还要受到权限边界约束。
一次问答、一次分析和一次修正，也可以逐步沉淀为后续可复用的业务语义资产。扩展到新问题时，仍然只补充真正缺失的业务对象、事件、关系和规则。
重点：先把问题稳定答对，再支持建议；有足够证据并明确权限边界后，才逐步接入有限自动执行。
没有统一数量。只建当前问题真正需要的业务对象和事件；能支撑真实问题，并在使用中继续扩展即可。
不必先改造全部底层系统。应尽量复用已有表、指标和模型；如果同一业务对象在不同系统中存在标识冲突，就把冲突显式暴露出来，由业务人员确认。
当首个场景已经能够稳定、准确、可复核地返回结果，再根据新的业务问题补充缺失的业务对象、事件、关系和规则，并扩展到更多应用。
企业本体的第一版不需要描述整个企业。更可行的路径，是从一个高价值问题倒推最小可用本体：选定高价值场景，只建立当前问题需要的业务对象与事件，映射现有数据，把口头规则变成显式约束，再逐步接入建议、动作和权限。每一次真实问答、分析与修正，都可以继续沉淀为后续可复用的业务语义资产。