过去，和数据库交互的主要方式是写 SQL。业务人员提出问题，开发或数据分析师把问题翻译成查询语句，再返回结果。

大模型出现后，Text-to-SQL 让这个流程发生变化：用户可以用自然语言描述需求，系统尝试生成 SQL。它降低了入门门槛，也让“智能问数”成为很多企业关注的方向。

但 Text-to-SQL 只是第一步。真正落地时，系统还要理解 Schema、业务口径、权限边界、执行反馈和分析目标。

一、Text-to-SQL 的核心流程

一个完整的 Text-to-SQL 流程通常包括四个环节。

第一，Schema 理解。

模型需要知道数据库里有哪些表、字段、主外键关系、字段注释和指标口径。如果缺少这些上下文，自然语言再清楚，也可能生成错误 SQL。

第二，意图识别。

例如“统计上月新增付费客户”，系统需要识别时间范围、指标定义、客户范围、付费判断和去重规则。

第三，SQL 生成。

模型根据意图和 Schema 生成查询语句，包括 SELECT、JOIN、WHERE、GROUP BY、ORDER BY 等结构。

第四，执行验证。

SQL 可能语法错误，也可能逻辑不符合业务口径。系统需要结合报错、结果样例和人工反馈继续调整。

二、为什么通用大模型还不够

ChatGPT 这类通用大模型很适合解释 SQL、提供学习示例和帮助拆解问题，但它默认不了解企业真实数据库。

企业场景中常见的问题包括：

• 表和字段命名不规范。
• 字段注释不完整。
• 指标口径依赖业务规则。
• 权限不允许所有人查看所有数据。
• 生产环境不能随意执行查询。

因此，专业数据库管理工具需要把大模型能力放进数据库工作流中，而不是让用户手动复制表结构和数据样例。

三、从 Text-to-SQL 到智能问数

智能问数比 Text-to-SQL 更进一步。

它不只是生成 SQL，还需要把用户问题、业务指标、数据权限和结果展示结合起来。一个更完整的智能问数系统应当具备：

• 数据字典和指标口径管理。
• Schema 感知。
• 权限和脱敏控制。
• SQL 生成与解释。
• 查询结果校验。
• 可追溯的操作记录。

Chat2DB 这类 AI 数据库工具，可以作为智能问数的验证入口：先在开发测试环境或只读数据集上验证生成质量，再逐步纳入团队规范。

四、Database Agent 会带来什么变化

如果说 Text-to-SQL 是“你说一句，我写一段 SQL”，那么 Database Agent 更接近“你提出目标，我规划并执行分析流程”。

它可能包含以下步骤：

1. 理解业务问题。
2. 拆解分析框架。
3. 选择相关表和指标。
4. 生成并校验 SQL。
5. 汇总结果。
6. 生成图表或报告。
7. 给出后续问题建议。

这个方向很有想象力，但也更需要安全边界。Agent 能做的事情越多，权限、审计、审批和人工确认就越重要。

五、企业落地建议

第一，不要一开始就追求全自动。

先把 AI SQL 作为查询初稿和辅助解释工具，保留人工 Review。

第二，完善数据字典。

字段注释、表关系和指标定义越清晰，智能问数越容易稳定。

第三，从低风险场景开始。

例如开发测试库、只读副本、汇总数据集和非敏感指标。

第四，设置权限边界。

不同用户能问什么、能看什么、能导出什么，需要在工具层面控制。

第五，记录完整链路。

自然语言问题、生成 SQL、修改过程、执行结果和审批记录都应可追溯。

结语

大模型与数据库结合，不会停留在 Text-to-SQL。未来更重要的是把自然语言、Schema、权限、执行验证和分析流程连接起来。

对企业来说，智能问数和 Database Agent 的价值，不是让每个人绕过数据库规范，而是在安全边界内更快获得可验证的数据结果。