Dify 高级实验02对话式 BI 分析——如何让业务人员用自然语言直接查数Dify 实验系列 · 高级 02/10 | 实验编号DIFY-103-02基于 Dify 1.16.1 实测2026-081. 业务场景先讲一个我们实际遇到的场景。一家电商公司的经营分析会上市场总监盯着大屏上的销售额曲线随口问了一句「上个月销量最高的产品是什么」在座的运营和数据分析师面面相觑——这个数据得找技术同学写 SQL 才能查。于是需求被记进工单排进技术团队的队列快则半天、慢则两三天答案才回到业务手里。而业务真正想要的是像跟同事聊天一样问一句立刻得到「笔记本电脑 B卖了 131 万」这种带数字、带单位的回答。我们第一次接这类需求时第一反应也是「那就给业务开个查询平台教他们写 SQL」。后来才发现这思路从根上就错了——业务要的不是 SQL是答案而「问题 → SQL → 答案」这条链路上最难的翻译步骤恰恰是 LLM 的看家本领。Dify 工作流把这条链路做成了可视化节点问题进去大白话答案出来中间那段 SQL 由模型生成、由代码校验。这不是个例。任何「业务要数据、技术写 SQL」的场景都是这个模式销售要看区域业绩对比运营要看转化率趋势财务要看回款情况——每一个看似简单的问题背后都是一次「提需求 → 排期 → 写 SQL → 返结果」的漫长等待。2. 场景痛点这个流程的痛点在业务人员身上体现得最直接等数慢决策跟着慢一个简单问题排队等技术写 SQL半天到几天不等——等数期间决策只能凭感觉等答案出来市场机会可能已经过了。沟通有损耗口径对不上业务说「上个月卖得最好的产品」技术理解成「上个月销售额最高的产品」还是「销量最高的产品」口径对不上查出来的数不是想要的来回返工。SQL 有风险错了没人知道技术手写 SQL 直接查生产库一旦写错条件漏了 WHERE、多表关联写错查出来的数据错了没人知道——基于错误数据的决策比没有数据更危险。技术资源被占用数据分析师天天被「帮我看个数」打断真正该做的专题分析反而没时间做——简单查询挤占了高价值工作。本质上「说人话查数据」的能力被卡在技术排期上是数据驱动决策最大的隐形瓶颈——问题不是没有数据而是数据到业务手里这条路太慢、太脆。3. 方案为什么是这套对话式 BI 流水线Dify 工作流里的「NL → SQL → 安全校验 → 模拟查询 → 自然语言回答」链路把「写 SQL」这件事从技术手里交还给系统。选它的理由我们实际对比过LLM 翻译自然语言是现成能力不用自研 NL2SQL 模型LLM 节点把表结构喂给模型业务问题直接翻译成 SQL理解「上个月」这类时间表达也一并解决代码节点做安全校验敢给业务用SQL 生成后先过一层「只放行 SELECT 拦截危险关键词」的代码校验把「写错查询」和「删库跑路」两类风险都挡在门外模拟查询 自然语言回答闭环查询结果经 LLM 转成带单位、带趋势判断的大白话——业务拿到的是答案不是一张表。这篇文章我们就用它搭一个「销售数据问答助手」业务人员输入自然语言问题系统自动生成 SQL、安全校验、模拟查询再用大白话回答。4. 整体架构开始user_query / query_type代码节点 cd_db模拟内存销售数据库表结构 示例数据LLM lm_sql自然语言 → SQL代码节点 cd_safe剥离围栏 安全校验 模拟查询LLM lm_answer查询结果 → 自然语言回答结束 end输出 answer链路很清晰入口收自然语言问题 → 生成 SQL → 安全校验 查询 → 自然语言回答。安全校验是这个架构的关键——LLM 生成的 SQL 不可直接信任先剥围栏、再验前缀、最后拦关键词合法才放行执行。5. 模块设计5.1 模拟数据库 cd_db输出database_schema两张表的 CREATE TABLE与sample_data2026-06/07 两个月、三个产品的销量数据供 lm_sql 与模拟查询使用defmain():return{database_schema:CREATE TABLE products ( id INT PRIMARY KEY, name VARCHAR(100), category VARCHAR(50), price DECIMAL(10,2)); CREATE TABLE sales ( id INT PRIMARY KEY, product_id INT, quantity INT, amount DECIMAL(10,2), sale_date DATE, region VARCHAR(50));,sample_data:[{product:笔记本电脑B,category:电子产品,amount:1319780,month:2026-07},{product:智能手表A,category:电子产品,amount:363720,month:2026-07},]}5.2 自然语言转 SQLlm_sql系统提示词必须用三花括号引用表结构与用户问题并约束「只输出 SQL」你是一个数据分析师。根据用户的问题和数据库表结构生成 SQL 查询语句。 数据库表结构 {{#cd_db.database_schema#}} 用户问题{{#start.user_query#}} 要求 1. 只生成 SELECT 查询不要生成 INSERT/UPDATE/DELETE 2. 如果问题要求对比使用 GROUP BY ORDER BY 3. 如果涉及上个月使用当前月份 2026-07 4. 输出格式只输出 SQL不要任何解释5.3 SQL 安全校验 模拟查询cd_safe双重防线先剥掉 LLM 可能输出的 sql 围栏再校验前缀与危险关键词safe以字符串形式输出boolean 展平defmain(generated_sql,user_query):importre,json sql_rawre.sub(r^(sql)?\s*,,(generated_sqlor).strip(),flagsre.IGNORECASE)sql_rawre.sub(r\s*$,,sql_raw).strip()sqlsql_raw.upper()ifnotsql.startswith(SELECT):return{safe:false,error:只允许 SELECT 查询,summary:查询被安全拦截,...}forkwin[DROP,DELETE,INSERT,UPDATE,ALTER,TRUNCATE]:ifkwinsql:return{safe:false,error:查询包含危险关键词: kw,...}# 按关键词返回模拟结果销量最高/销售额最高、对比/趋势return{safe:true,results:mock_results,summary:summary,generated_sql:generated_sql,results_text:json.dumps(mock_results,ensure_asciiFalse)}5.4 生成自然语言回答lm_answer查询结果以results_textJSON 字符串传入避免数组/对象在模板里无法直接遍历你是一个数据分析助手。用户问了一个问题系统已经查询到了数据。 用户问题{{#start.user_query#}} 生成的 SQL{{#cd_safe.generated_sql#}} 查询结果{{#cd_safe.results_text#}} 数据摘要{{#cd_safe.summary#}} 错误信息{{#cd_safe.error#}} 请用自然语言回答。要求 1. 直接给出答案不要说根据查询结果这种废话 2. 有数字标注单位涉及对比给出趋势判断 3. 如果错误信息不为空直接告知用户查询被拦截及原因 4. 控制在 3-5 句话以内6. 运行验证输入期望行为实测「上个月销售额最高的产品是什么」生成 SELECT SQL模拟查询返回 笔记本电脑B回答含销售额 1,319,780 元与预期一致「对比上个月和上上个月的销售趋势」命中「对比/趋势」分支回答「笔记本涨 22.2%手表跌 20.0%」与预期一致「删除所有数据」模型层消化不生成 DELETE改写为 SELECT 查询回答明确只读边界不承诺删除能力与预期一致未执行任何写操作7. 实战坑坑现象修复LLM 输出 SQL 带 sql 围栏前缀校验startswith(SELECT)失败合法查询被误拦cd_safe 先正则剥离围栏再校验dify103_02 实测LLM prompt 用双花括号变量不替换SQL 里出现字面{{#cd_db.database_schema#}}一律三花括号{{#节点id.字段#}}dify103_02 实测代码节点返回 boolean 类型safe在变量选择器不可见无法给下游/分支用转字符串true/false输出boolean 展平把数组results直接塞进 LLM prompt模板渲染成 Python 列表字面量模型读不懂代码里json.dumps成results_text字符串再引用dify103_02 实测8. 实验文档及源码获取实验文档完整操作步骤DIFY-103-02对话式BI分析助手.md源码可直接导入dify103_02_对话式BI分析助手.yml文章聚焦核心配置与采坑点实验的完整分步操作节点搭建/参数表/调试指引见实验文档原文。下一篇Dify 高级实验03智能客服——如何让 AI 自动应答并把疑难问题转人工 你在这个实验的场景里踩过什么坑欢迎评论区分享你的实战经验。 Dify 高级实验（02）：对话式 BI 分析——如何让业务人员用自然语言直接查数？
Dify 高级实验02对话式 BI 分析——如何让业务人员用自然语言直接查数Dify 实验系列 · 高级 02/10 | 实验编号DIFY-103-02基于 Dify 1.16.1 实测2026-081. 业务场景先讲一个我们实际遇到的场景。一家电商公司的经营分析会上市场总监盯着大屏上的销售额曲线随口问了一句「上个月销量最高的产品是什么」在座的运营和数据分析师面面相觑——这个数据得找技术同学写 SQL 才能查。于是需求被记进工单排进技术团队的队列快则半天、慢则两三天答案才回到业务手里。而业务真正想要的是像跟同事聊天一样问一句立刻得到「笔记本电脑 B卖了 131 万」这种带数字、带单位的回答。我们第一次接这类需求时第一反应也是「那就给业务开个查询平台教他们写 SQL」。后来才发现这思路从根上就错了——业务要的不是 SQL是答案而「问题 → SQL → 答案」这条链路上最难的翻译步骤恰恰是 LLM 的看家本领。Dify 工作流把这条链路做成了可视化节点问题进去大白话答案出来中间那段 SQL 由模型生成、由代码校验。这不是个例。任何「业务要数据、技术写 SQL」的场景都是这个模式销售要看区域业绩对比运营要看转化率趋势财务要看回款情况——每一个看似简单的问题背后都是一次「提需求 → 排期 → 写 SQL → 返结果」的漫长等待。2. 场景痛点这个流程的痛点在业务人员身上体现得最直接等数慢决策跟着慢一个简单问题排队等技术写 SQL半天到几天不等——等数期间决策只能凭感觉等答案出来市场机会可能已经过了。沟通有损耗口径对不上业务说「上个月卖得最好的产品」技术理解成「上个月销售额最高的产品」还是「销量最高的产品」口径对不上查出来的数不是想要的来回返工。SQL 有风险错了没人知道技术手写 SQL 直接查生产库一旦写错条件漏了 WHERE、多表关联写错查出来的数据错了没人知道——基于错误数据的决策比没有数据更危险。技术资源被占用数据分析师天天被「帮我看个数」打断真正该做的专题分析反而没时间做——简单查询挤占了高价值工作。本质上「说人话查数据」的能力被卡在技术排期上是数据驱动决策最大的隐形瓶颈——问题不是没有数据而是数据到业务手里这条路太慢、太脆。3. 方案为什么是这套对话式 BI 流水线Dify 工作流里的「NL → SQL → 安全校验 → 模拟查询 → 自然语言回答」链路把「写 SQL」这件事从技术手里交还给系统。选它的理由我们实际对比过LLM 翻译自然语言是现成能力不用自研 NL2SQL 模型LLM 节点把表结构喂给模型业务问题直接翻译成 SQL理解「上个月」这类时间表达也一并解决代码节点做安全校验敢给业务用SQL 生成后先过一层「只放行 SELECT 拦截危险关键词」的代码校验把「写错查询」和「删库跑路」两类风险都挡在门外模拟查询 自然语言回答闭环查询结果经 LLM 转成带单位、带趋势判断的大白话——业务拿到的是答案不是一张表。这篇文章我们就用它搭一个「销售数据问答助手」业务人员输入自然语言问题系统自动生成 SQL、安全校验、模拟查询再用大白话回答。4. 整体架构开始user_query / query_type代码节点 cd_db模拟内存销售数据库表结构 示例数据LLM lm_sql自然语言 → SQL代码节点 cd_safe剥离围栏 安全校验 模拟查询LLM lm_answer查询结果 → 自然语言回答结束 end输出 answer链路很清晰入口收自然语言问题 → 生成 SQL → 安全校验 查询 → 自然语言回答。安全校验是这个架构的关键——LLM 生成的 SQL 不可直接信任先剥围栏、再验前缀、最后拦关键词合法才放行执行。5. 模块设计5.1 模拟数据库 cd_db输出database_schema两张表的 CREATE TABLE与sample_data2026-06/07 两个月、三个产品的销量数据供 lm_sql 与模拟查询使用defmain():return{database_schema:CREATE TABLE products ( id INT PRIMARY KEY, name VARCHAR(100), category VARCHAR(50), price DECIMAL(10,2)); CREATE TABLE sales ( id INT PRIMARY KEY, product_id INT, quantity INT, amount DECIMAL(10,2), sale_date DATE, region VARCHAR(50));,sample_data:[{product:笔记本电脑B,category:电子产品,amount:1319780,month:2026-07},{product:智能手表A,category:电子产品,amount:363720,month:2026-07},]}5.2 自然语言转 SQLlm_sql系统提示词必须用三花括号引用表结构与用户问题并约束「只输出 SQL」你是一个数据分析师。根据用户的问题和数据库表结构生成 SQL 查询语句。 数据库表结构 {{#cd_db.database_schema#}} 用户问题{{#start.user_query#}} 要求 1. 只生成 SELECT 查询不要生成 INSERT/UPDATE/DELETE 2. 如果问题要求对比使用 GROUP BY ORDER BY 3. 如果涉及上个月使用当前月份 2026-07 4. 输出格式只输出 SQL不要任何解释5.3 SQL 安全校验 模拟查询cd_safe双重防线先剥掉 LLM 可能输出的 sql 围栏再校验前缀与危险关键词safe以字符串形式输出boolean 展平defmain(generated_sql,user_query):importre,json sql_rawre.sub(r^(sql)?\s*,,(generated_sqlor).strip(),flagsre.IGNORECASE)sql_rawre.sub(r\s*$,,sql_raw).strip()sqlsql_raw.upper()ifnotsql.startswith(SELECT):return{safe:false,error:只允许 SELECT 查询,summary:查询被安全拦截,...}forkwin[DROP,DELETE,INSERT,UPDATE,ALTER,TRUNCATE]:ifkwinsql:return{safe:false,error:查询包含危险关键词: kw,...}# 按关键词返回模拟结果销量最高/销售额最高、对比/趋势return{safe:true,results:mock_results,summary:summary,generated_sql:generated_sql,results_text:json.dumps(mock_results,ensure_asciiFalse)}5.4 生成自然语言回答lm_answer查询结果以results_textJSON 字符串传入避免数组/对象在模板里无法直接遍历你是一个数据分析助手。用户问了一个问题系统已经查询到了数据。 用户问题{{#start.user_query#}} 生成的 SQL{{#cd_safe.generated_sql#}} 查询结果{{#cd_safe.results_text#}} 数据摘要{{#cd_safe.summary#}} 错误信息{{#cd_safe.error#}} 请用自然语言回答。要求 1. 直接给出答案不要说根据查询结果这种废话 2. 有数字标注单位涉及对比给出趋势判断 3. 如果错误信息不为空直接告知用户查询被拦截及原因 4. 控制在 3-5 句话以内6. 运行验证输入期望行为实测「上个月销售额最高的产品是什么」生成 SELECT SQL模拟查询返回 笔记本电脑B回答含销售额 1,319,780 元与预期一致「对比上个月和上上个月的销售趋势」命中「对比/趋势」分支回答「笔记本涨 22.2%手表跌 20.0%」与预期一致「删除所有数据」模型层消化不生成 DELETE改写为 SELECT 查询回答明确只读边界不承诺删除能力与预期一致未执行任何写操作7. 实战坑坑现象修复LLM 输出 SQL 带 sql 围栏前缀校验startswith(SELECT)失败合法查询被误拦cd_safe 先正则剥离围栏再校验dify103_02 实测LLM prompt 用双花括号变量不替换SQL 里出现字面{{#cd_db.database_schema#}}一律三花括号{{#节点id.字段#}}dify103_02 实测代码节点返回 boolean 类型safe在变量选择器不可见无法给下游/分支用转字符串true/false输出boolean 展平把数组results直接塞进 LLM prompt模板渲染成 Python 列表字面量模型读不懂代码里json.dumps成results_text字符串再引用dify103_02 实测8. 实验文档及源码获取实验文档完整操作步骤DIFY-103-02对话式BI分析助手.md源码可直接导入dify103_02_对话式BI分析助手.yml文章聚焦核心配置与采坑点实验的完整分步操作节点搭建/参数表/调试指引见实验文档原文。下一篇Dify 高级实验03智能客服——如何让 AI 自动应答并把疑难问题转人工 你在这个实验的场景里踩过什么坑欢迎评论区分享你的实战经验。