先写指标意图，再编译成语句

公开讨论里有一条技术路线：自然语言先变成指标查询，再变成 SQL。名字可以叫 NL2MQL，也可以不叫。对我有用的是分工：人不要在聊天里发明 JOIN，也不要让语句自己决定口径。先有一张意图：指标、维度、时间、过滤。意图合法，再编译。

意图是白名单

指标名必须在字典里。不在，就澄清，不编造字段。

时间在意图里绝对化

不要把 NOW() 的相对计算留给数据库临时发挥。起止在意图里就算好。

编译可以很土

个人用一张对照表把意图填进 SQL 模板。土，但可核对。

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

意图 JSON：指标 order_cnt；时间 2026-03-01/2026-03-31；过滤 city=上海，status=paid。

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

SELECT COUNT(*) AS order_cnt
FROM orders
WHERE pay_time >= DATE '2026-03-01'
  AND pay_time < DATE '2026-04-01'
  AND city = '上海'
  AND pay_status = 'paid';

把意图和语句并排贴在收据上。以后改口径，改意图；改方言，改编译。两件事不再缠死。

结构是地图，不是附录

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

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

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

读完这一辑可以做什么

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

人负责要什么，编译负责怎么取。两件事写在同一句聊天里，就会互相绑架。