很多企业第一次做 AI 问数时，最容易低估一个问题：AI 能连上数据库，不代表 AI 能理解业务。
数据库里有表、有字段、有数据，但业务问题往往不是按数据库结构提出的。老板问“这个月销售额为什么下降”，运营问“上周高潜客户转化怎么样”，区域经理问“华南门店库存风险在哪里”，这些问题背后都包含大量默认上下文。
AI 如果只看到字段名，很容易把问题理解错。
数据库结构不等于业务语言
企业数据库中的字段通常来自系统实现，而不是业务表达。
例如：
- •
amount可能是下单金额、支付金额，也可能是退款后净额。 - •
status=3可能代表已完成，也可能代表已取消。 - •
created_at可能是订单创建时间，业务复盘却需要按支付时间统计。 - •
shop_id、store_id、org_id可能都和门店有关，但含义并不相同。
业务人员不会按这些字段名提问。他们会说“本月 GMV”“有效订单”“高潜客户”“华南大区”“重点门店”。如果 AI 不知道这些词和数据结构之间的关系，就只能猜。
同一个指标背后有很多口径选择
以“销售额”为例，真正进入分析前，至少要明确：
- •是否扣除退款？
- •是否包含优惠券、满减、平台补贴？
- •是按下单时间、支付时间，还是发货时间统计？
- •是否排除测试订单、异常订单、内部订单？
- •多渠道、多系统数据重复时，以哪个系统为准？
这些判断不是 SQL 技巧，而是企业自己的业务规则。没有语义层，AI 很可能生成一条“看起来能跑”的 SQL，但结果并不是企业真正认可的业务答案。
AI 问数还必须理解权限和身份
企业数据分析不是所有人看同一张总表。
同一个问题“这个月销售额是多少”，总部、区域经理、门店店长、品牌负责人看到的范围可能完全不同。有人能看全国，有人只能看自己区域；有人能看金额，有人只能看趋势；有人能看客户明细，有人只能看聚合结果。
如果 AI 不知道提问者是谁、属于哪个组织、能访问哪些字段和行，就不能稳定给出合规答案。
业务语义层解决什么
业务语义层的作用，是把企业自己的业务语言翻译成 AI 可以使用的上下文。
它至少要告诉 AI：
- •表和字段在业务上表示什么。
- •核心指标如何定义和计算。
- •字段值、状态码、内部简称分别代表什么。
- •哪些维度可以和哪些指标一起分析。
- •哪些业务文档、分析习惯和专家经验需要被复用。
- •不同用户在什么权限边界内使用数据。
有了这些上下文，AI 才不是在数据库里盲猜，而是在企业已定义的业务语言里回答问题。
AskTable 如何承接
AskTable 的价值不只是把自然语言转成 SQL，而是让 AI 在企业真实数据、业务语义和权限边界之上工作。
在 AskTable 产品体系里，DigTable 负责把数据采集回来并建成 AI 可用的数据基础；AskTable 通过表备注、字段备注、字段值索引、业务文档、指标口径、分析偏好和权限上下文，让 AI 更稳定地理解业务问题、生成查询、解释结果。
所以，AI 问数的第一步不是“连数据库”，而是先让 AI 看懂企业自己的业务语言。