许多企业AI系统真正缺失的一层，不是更多元数据，而是一份机器可读的记录：组织已经知道哪些错误不能犯。
企业数据经验里，有相当一部分听起来像这样：迁移之后别用那张表；别把 invoice_amount 当作已确认收入；那两张表不要直接关联；财务报告别用 created_at；去重账户之前不要先聚合这些行。
这些规则很少出现在数据库模式里，也可能根本不在数据目录中。它们往往只存在于资深分析师、工程师和业务负责人的脑子里。
人类消费数据时，这套隐性知识还能运转
当人类是企业数据的主要消费者时，这种方式还能应付。可一旦AI代理开始直接查询数据，问题就变得严重了。
常见的应对方式是给模型更多上下文。但有没有一种可能：缺失的上下文并不是对“数据是什么”的又一段描述，而是一层结构化描述，专门说明AI不能做什么。
数据模型里装的知识比我们以为的少
假设有一张发票表：
- invoice_id：BIGINT
- customer_id：BIGINT
- invoice_amount：DECIMAL(18,2)
- invoice_date：DATE
- status：VARCHAR(20)
AI能识别出客户引用、金额和日期，也大概率能为“上季度已确认收入是多少”生成合法SQL。但企业可能早就知道：invoice_amount 并不是已确认收入。
这个事实不属于模式事实，而是组织知识。没有它，代理可以在技术上完全合格，却仍然给出错误结果。
“禁用”本身是一种真实的数据资产
数据平台传统上只沉淀正向知识：有哪些表、列是什么意思、指标如何定义、实体之间怎样关联。
但资深用户还掌握着负向知识：哪个来源有误导性、哪个关联危险、哪个字段看起来正确实则不然、哪个时间戳不能用、哪种聚合会造成重复计算。
这类知识之所以宝贵，恰恰因为错误选项常常看起来非常合理。因此，一个生产环境的数据代理需要两样东西：正向知识回答“我能用什么”，负向知识回答“我必须避开什么”。
给数据对象加上结构化约束
可以设想把结构化约束附着到企业数据对象上。比如针对字段：
- 对象类型：列
- 名称：invoice.invoice_amount
- 业务含义：发票金额
- 有效用途：发票分析
- 无效用途：已确认收入
- 原因：发票金额可能包含尚未满足收入确认规则的金额
- 负责人：财务
- 状态：生效
针对关系，也可以定义约束：从 customer.customer_id 到 order.customer_id 的关联，在账户结构为合并口径时无效，必须经由“客户—账户—订单”的路径，因为直接关联会在子账户之间重复计算订单。
针对时间字段，同样可以建立规则：已确认收入指标必须使用 finance_revenue.recognition_date，不得使用 invoice.invoice_date 或 sales_order.created_at。
这些约束把原本只存在于人脑中的“不要用”知识，变成机器可以读取、可以执行、可以审计的资产。对直接查询数据的企业AI代理来说，这层“禁用”规则可能比再多一份数据说明更关键。
热门跟贴