AI-Native 业务建模:当 schema 不再是给人看的文档

当 AI Agent 成为业务系统的核心消费者，传统 schema 必须从"描述数据怎么存"升级为"机器可以直接执行的语义契约"。

问题从哪里来

这不是先设计出来再实现的理论，而是在把 AI 接入真实业务对象时反复撞出来的认知。

只给字段，AI 会猜。只给 API，AI 会串错路径。只给文档，AI 无法稳定执行。只靠 prompt，系统会退回一次性解释，无法形成可治理、可复用的业务能力。

真实业务里，AI Agent 不只是回答"这是什么字段"。它会继续追问：

这个值可信吗？
谁有资格改它？
它缺失会阻碍什么判断？
沿哪条路径可以找到相关事实？
这组文件里哪些是必须的、哪些缺了？

传统 schema 不回答这些问题。它默认消费者是人，人会自己补全上下文。

但 AI 不应该靠 prompt 临时猜上下文。上下文应该被写进模型契约，成为机器可读、可验证、可执行的声明。

这就是 AI-Native 业务建模的出发点：让对象定义本身包含 AI 做判断所需的全部元信息。

[图 1：从传统 schema 到 AI-Native schema]

传统建模回答的是另一类问题

BI 建模回答：过去发生了什么？ERD 建模回答：数据怎么存？API 建模回答：系统间怎么调？

这些范式都成立，但它们面向人类分析师或开发者。

当 AI Agent 成为核心消费者时，问题变成：

业务世界由哪些对象构成？
对象有哪些可供 AI 使用的事实？
事实从哪里来，是否可信？
对象之间有哪些可遍历的业务路径？
哪些缺口会影响判断？

所以这里讨论的不是"更复杂的数据建模"，而是从"人读 schema"转向"机器执行 schema"。

什么是 AI-Native 对象

传统对象定义：

Customer { id, name, credit_level, region }

AI-Native 对象定义：

Customer {  id         [identity]  name       [supply=sourced, source=CRM, refresh=daily]  credit_level [supply=derived, engine=risk_model, usage=授信判断]  region     [supply=relational, path=Customer→Branch→Region]}

区别不在复杂度，而在：每个属性自带的声明是否足够让机器自主决策。

判断标准很简单：

给定对象定义 + 实例数据，AI Agent 无需额外问人就能判断：这个值能不能用、该信任多少、缺了找谁补、该沿什么路径扩展上下文。

做不到，就还不是 AI-Native。

可执行语义：声明即行为

"语义"这个词容易说空。在这里它有一个精确含义：

可执行语义 = 机器读到定义后能直接产生行为的声明

传统语义（人读）	可执行语义（机器行为）
注释："由风控系统计算"	`supply: derived` → 禁止手动写入
文档："建议每日刷新"	`schedule: daily` → 调度器自动拉取
README："必须有正面照"	`required: true` → 缺口检测自动报警
口头约定："不参与推理"	`usage: display_only` → Agent 跳过
ERD 注释："外键关联"	`relation: belongs_to` → 图引擎可多跳遍历

可执行语义不是更详细的注释。它是直接驱动系统行为的声明。

写了 supply: none不是"标记一下"，而是：

缺口面板自动出现；
AI 回答时声明"该信息当前无供给"；
补数流程排入队列；
相关能力降级，而不是假装知道。

声明即行为。不是比喻，是系统内真实的执行链路。

属性的四根轴

一个 AI-Native 属性是四维声明：type × supply × carrier × shape。

Supply（来历）是最关键的轴——谁有资格改这个值：

来历	含义	系统行为
declared	建模者声明	禁止运行时写入
sourced	外部供给	按 schedule 刷新
derived	引擎计算	禁止手动覆盖
relational	关系推导	随关系自动更新
stateful	状态机驱动	只能通过状态转移改变
none	无供给	标记为缺口

同一个值，来历不同，信任度、刷新策略和治理方式完全不同。"客户信用等级 = A"是模型算的还是销售填的？这个区别决定 AI 能不能拿它做授信判断。

Carrier（承载）：值住在认知层（inline）还是外部系统（ref）。AI 推理时需要直接读 → inline；只是需要时跳转 → ref。

Shape（形态）：当前值（point）、滑动窗口（windowed）、时序引用（series_ref）。决定 AI 取值的策略。

什么该进认知层，什么不该

不是所有数据都值得成为 AI-Native 属性。两阶段过滤：

价值准入：

V1: 影响业务判断或 AI 行为？否则不进。
V2: 需要跨系统共享？否则留在源系统。
V3: 有稳定业务含义？否则是临时数据。
V4: 需要治理？否则不值得管理成本。

承载判断：

值是语义事实 → inline
值只用于回溯 → ref
值属于另一系统管辖 → 桥接链接，不进认知层
大体积非结构化 → file / asset_set

这个过滤器防止认知层退化成"所有系统字段的大杂烩"。

关系：认知路径，不是外键

传统系统用外键表达关系。AI-Native 系统把关系提升为一等对象，因为关系是 AI 做多跳推理的路由表。

用户问："这个召回影响哪些客户？"

如果只有外键，Agent 要自己猜 join 路径。如果有关系声明，Agent 沿着明确路径走：

Recall → affects → Model → Vehicle → Customer

关系不是为了画图好看，而是让 AI 能沿着真实业务路径查询、推理和行动。

而且关系可以生长：AI 从数据中发现潜在关系（learned），经人工确认后升级为正式路径（declared）。认知网络不是一次设计完的。

文件：不是附件，而是认知资产

[图 2：Asset Set 把文件从附件变成认知资产]

企业有大量文件：合同 PDF、产品图片、证照扫描、专家手册。

传统做法要么每个文件一个字段（属性爆炸），要么统一附件服务（AI 不知道缺什么）。

AI-Native 的做法是声明「文件资产集合」：

声明需要哪些文件（槽位）→ 系统知道缺什么
声明哪些必须有 → 缺口检测自动报警
声明到了怎么处理（管线）→ 自动触发 OCR / embedding / 标注
前端自动渲染上传界面，不需要硬编码

而且文件资产有两个层级：

层级	解决什么	例子
实例级	这个对象有什么证据	某辆车的照片、某份合同扫描件
类型级	理解这类对象需要什么知识	维修手册、审查规范、专家经验

只建实例级，AI 能看见证据但不知道如何解释。类型级资产提供"判断框架"。

专家经验：让 AI 更像专家，但不能假装是专家

[图 3：专家经验的三阶段演进]

专家经验不是"人工填写的数据"。它回答的是另一类问题：

系统事实回答：这个实例现在是什么？
专家经验回答：这类对象通常应该如何判断？

专家经验有三种形态，可以互相演进：

专家文档（手册/规范）→ 专家片段（可引用的判断经验）→ 专家逻辑（结构化规则）→ 驱动行动建议

例如合同审查：

合同扫描件（实例证据）  → OCR 抽取付款条款  → 对照审查专家经验（类型知识）  → 识别"付款节点缺少验收条件"  → 生成风险提示

AI 不是"凭感觉审合同"，而是在执行一个被治理过的专家经验契约。

但专家经验必须可治理：有来源、有版本、有适用边界、有审核。否则 AI 会把过期经验当硬规则。

AI 可以推荐，但不能直接改

认知层不应该只允许人手工建模。AI 运行中会不断发现候选知识：

高频问题 → 候选认知
高频跳转路径 → 候选关系
高频缺失文件 → 候选槽位
高频专家解释 → 候选经验

但"允许推荐"不等于"允许直接入模"。

核心原则：放开推荐入口，收紧入模闸门。

直接入模的风险：语义污染、相关性误当因果、治理绕过、模型膨胀。

正确姿势：AI 发现候选 → 形成提案 → 标注证据 → 专家审核 → 接受或拒绝。

这是 AI-Native 模型和普通 prompt 系统的分水岭。prompt 系统把发现留在对话里；AI-Native 模型把发现变成可审核、可演进的提案。

适合和不适合

适合：

知识密集型行业：金融合规、医疗、企业治理、供应链
AI 做行业判断：审核、预警、归因、执行前检查
多系统数据融合
文件是业务证据，不只是附件
知识会持续增长

不适合：

纯 CRUD 后台管理
纯 BI 场景
简单文件存储
不涉及 AI 判断的系统

一句话

传统 schema 是给人看的文档。AI-Native schema 是给机器执行的指令集。

区别不在复杂度，在于：读完定义后，机器能不能自主、稳定、可治理地行动。