让非技术人员用日常语言就能生成SQL——听起来像是天方夜谭？但Dify确实做到了。你需要做的，只是在背后做一次性的配置。思路其实很清晰：先连上数据库，让系统理解你的表结构；再建个知识库，喂给它关于这些表的“业务知识”；最后在可视化工作流里串起来，大模型生成SQL，再加个校验节点兜底。整个过程不用写一行代码，也不用反复调试语法。

配置数据库连接与表结构识别

第一步，先让Dify认识你的数据库。进入Dify控制台，点左侧的「数据源」，选择「添加数据库」，然后填写连接信息。无论是MySQL还是PostgreSQL，主机地址、端口、数据库名、用户名、密码，这几项一个都不能少。

第二步，勾选「自动同步表结构」这个选项，然后点击「测试连接」。这一步必须成功。如果连不上，后续所有SQL生成都会直接报错或者返回空结果。这一点值得特别强调。

第三步，连接成功后，Dify会自动拉取数据库里所有的表名、字段名、字段类型、主键、外键以及注释信息。这里有一个容易踩坑的地方：如果字段缺少业务化的注释，比如user_id只写了个“用户编号”，没有说明它是对应users表的主键，那AI在生成JOIN条件的时候大概率就会出错。所以，前期数据结构梳理得越干净，后面生成SQL的准确率就越高。

构建知识库强化语义理解

光有原始的表结构还不够，AI需要理解这些表在业务场景下“意味着什么”。这里有两种方法可以给Dify喂知识。

方法一：手动整理表文档
新建一个Markdown文件，按固定格式逐表描述。比如users表下面可以写：业务含义是存储平台注册用户的基础信息；关键字段有id（主键，全局唯一用户ID）、nickname（用于前端展示的用户昵称）、created_at（账户创建时间，计算新客周期时要用到）。这种文档写得越贴近业务语言，AI越能准确理解你的意图。

方法二：用SQL自动生成结构描述
在数据库里直接跑一条 SHOW CREATE TABLE users;，把返回的建表语句复制出来，粘贴进知识库文档。这种方法比手写更快、更准，也更容易保持表结构的一致性。

文件准备好之后，上传到Dify的「知识库」，开启「启用语义检索」，选择bge-m3这类的嵌入模型，完成文档的切分和向量化。这个过程大概需要1到3分钟，期间别关闭页面，耐心等一等就好。

搭建SQL生成工作流

数据源和知识库都就位后，就可以在可视化画布里搭工作流了。

在「工作室」新建一个应用，选择「空白模板」，进入画布。拖入一个「开始」节点，配置一个输入变量，就叫query，用来接收用户输入的自然语言问题。

接着添加「知识检索」节点，绑定刚才建好的知识库，把检索结果的最大返回数设为3个表结构片段。这一步很关键：上限太高容易引入不相关的干扰信息，太低又可能遗漏关键表。

然后插入「大模型」节点。这里的提示词模板需要写得稍微讲究一点，把任务交代清楚。可以这样写：

“你是一名资深DBA，请根据以下信息生成标准SQL：
① 用户问题：{{#开始.query#}}
② 相关表结构：{{#知识检索.retrieved_documents#}}
要求：只输出纯SQL，不加任何解释、不加```sql包裹；使用ANSI SQL语法，兼容MySQL 8.0+；如需JOIN，必须写明ON条件；若问题涉及时间范围如“最近7天”，用DATE_SUB(NOW(), INTERVAL 7 DAY)表达。”

最后，强烈建议加一个「SQL校验」节点。启用关键词拦截功能，把DROP、TRUNCATE、UPDATE、DELETE、INSERT INTO SELECT这些高危操作全部拦在门外。一旦检测到，立即中断流程并返回警告。虽然Dify生成的SQL一般不会主动出这种问题，但做一次防护总是更让人放心。

测试与上线

所有节点配置好后，点击右上角的「预览」，在输入框里敲一句真实业务问题试试：“查出6月订单金额超过5000的客户姓名和下单次数”。正常情况下，3秒内就能返回对应的SQL语句。

如果返回的是类似SELECT * FROM orders WHERE...这种没有任何表关联的简单查询，说明知识检索节点没有命中到customers表的结构，需要回去检查一下知识库的内容是否覆盖了目标表。如果直接返回空，那就更常见了——数据库连接被防火墙拦截了，尤其在内网部署场景下经常遇到。

确认一切无误后，点击「发布」，获取API Endpoint或者直接嵌入Web SDK。然后你就可以把这个“SQL助手”集成到现有的BI系统，或者挂到钉钉机器人上，让团队里所有人都能用日常语言问数据了。