语义层：先有指标，才有稳定的问数

公开长文把语义层说成自然语言和仓库之间的中间层。指标怎么算、维度怎么切、表怎么连，都先钉死。提问先落到指标意图，再由这一层编译成 SQL。个人没有引擎，也可以用字典和卡片冒充这一层。没有它，每次提问都在重新发明「销售额」。

指标、维度、实体

人问的是指标，切的是维度，连的是实体。三样分开写，才不会把城市写进计算式里。

为什么不直接写 SQL

SQL 太自由，同一指标有无数写法，难校验。先写「要什么」，再写「怎么取」，校验会容易得多。

物理表可以变

表拆了、字段改名了，改映射即可。提问卡片不用重写。这是语义层真正省下的维护。

一次完整的问法可以先写成下面这样：

意图：指标 total_revenue，维度 city，时间 2026-03，过滤已支付。

落到语句上，草稿常常是：

SELECT city, SUM(pay_amount) AS total_revenue
FROM orders
WHERE pay_time >= DATE '2026-03-01'
  AND pay_time < DATE '2026-04-01'
  AND pay_status = 'paid'
GROUP BY city;

语句是编译结果。意图才是人要负责的那一层。把两层混成一句「帮我查一下」，语义层就从未存在。

结构是地图，不是附录

公开实现文章把列出表、描述字段、抽样行、再执行写成四件工具。工具顺序不能倒。执行放第一位，等于闭眼过马路。

结构链接的失败，十之八九不是语法。是找错表、找错列、找错枚举值。注释、别名、示例值，是地图上的注记。注记质量决定问数上限。有人只补三十个核心字段的含义，可用程度就明显上升。这是最不时髦、也最管用的工作。

语义层是把指标、维度、关联路径写成中间层。个人没有引擎时，用字典和卡片冒充。没有这一层，每次提问都在重新发明销售额。宽表好问、星型好管，选边可以，口径必须唯一。

读完这一辑可以做什么

给十个核心字段写注释：时间、金额、状态、用户、地区、类目，外加四个你会用到的。注释里写计算、单位、示例值。写完再去问数，少猜一轮。

意图层稳定，物理表才可以变。反过来，每次改表都要重教口头词。