一句话定义：Text-to-SQL 指的是把用户用自然语言提的问题，自动翻译成一条能直接跑的 SQL 语句，去数据库里把数取出来。
举个例子。运营同学问：“上个月华东区新客的复购率是多少？”系统要输出一段带 JOIN、WHERE、GROUP BY 的查询。很多人以为难点在 SQL 语法，其实语法恰恰是模型最熟的部分——它见过海量 SQL，拼个关联、套个聚合函数不在话下。真正卡住它的是下面三件事：
第一，业务口径。 什么叫“新客”？注册当天算，还是首单成交算？“复购”是第二次下单，还是 30 天内再次下单？这些定义不在数据库里，在运营同学的脑子里，或者某份没人更新的文档里。
第二，表之间没说出口的关联。 订单表里没有客户等级，得去 JOIN 客户表；可这两张表的关联键可能一张叫 user_id、一张叫 uid，中间还得过一张映射表。这类“暗知识”模型看不见，只能靠表注释和文档补。
第三，状态字段和时间边界。 status = 1 到底是“已支付”还是“已完成”？“上个月”是自然月还是滚动 30 天？猜错一个，结果差一倍。
打个比方：这就像让一个刚入职的聪明实习生去写报表。他 SQL 水平比谁都高，但他不懂公司黑话——“活跃用户”到底指什么，得先给他一本《业务词典》和一张表关系图，他才干得对。
它和相邻概念的区别：
| 做什么 | 关键依赖 | |
|---|---|---|
| Text-to-SQL | 一句话 → 一条 SQL | 表结构 + 业务语义 |
| 语义层（Semantic Layer） | 把口径预先固化成可复用的指标 | 人工梳理 |
| 传统 BI 拖拽 | 人自己选字段拼报表 | 人的理解 |
实践中比较稳的做法，不是让模型对着一堆裸表自由发挥，而是先有语义层或指标定义，再让模型在它上面做“翻译”——模型负责理解意图和组织查询，口径由人提前定死。
对从业者来说，Text-to-SQL 项目的成败常常不在模型选型，而在数据治理：表注释全不全、字段命名规不规范、指标定义有没有沉淀。对普通职场人来说，它意味着“会写 SQL”带来的稀缺性在下降，而“能把业务口径说清楚”的价值在上升。你描述得越精确，工具就越好用。
具体产品的能力边界差异很大，选型时以官方页面为准。