还在手动跑数据？用Dify搭建智能问数，3步让数据自己开口说话

但如果这些问题，业务方自己一句话就能查呢？

• "查7月订单量" → 秒出结果
• "对比各区退订率排名" → 自动出图+分析结论
• "投递人数按学历分布" → 一句话生成报表

— — — — — — — — — —

传统数据查询 vs 智能问数：

一句话总结：智能问数不是替代数据团队，而是把数据团队从"取数工具人"解放出来，去做更有价值的分析。

— — — — — — — — — —

**选型建议：** 90% 的团队，路径一+路径二的组合就够了。先把流程跑通，再逐步优化。别一上来就自研，容易陷入"完美主义陷阱"。

— — — — — — — — — —

① 意图识别 → ② Text-to-SQL → ③ SQL校验 → ④ 数据库查询 → ⑤ 数据分析

实践要点：

• 用 LLM 节点做意图分类，输出结构化的场景标识
• 每个场景绑定对应的表结构说明（Schema）
• 意图模糊时，主动追问用户确认，别瞎猜

Prompt 中必须包含以下信息：

• 当前日期时间（大模型不知道"今天"是哪天）
• 数据库类型和版本（MySQL / PostgreSQL / 其他，语法有差异）
• 完整的表结构说明（表名、字段名、字段含义、字段类型）
• 关键业务ID的映射关系（如 status=1 代表"已下单"）
• 查询规则约束（只读查询、LIMIT 限制、禁止DDL等）

**踩坑提醒：** 很多人配好 Text-to-SQL 就觉得完事了，结果查出来的数据各种不对。90% 的问题出在 Schema 描述不够详细——大模型不理解你的字段含义，怎么可能生成正确的SQL？

只能查询数据库中真实存在的表和字段。只允许执行 SELECT 查询。禁止 INSERT、UPDATE、DELETE、DROP、ALTER、TRUNCATE 等操作。（这里的数据库为了安全起见必须设置只读权限账号）非聚合查询默认 LIMIT 100。涉及xxx数量时，优先使用 COUNT(DISTINCT xxx)。涉及xxx数量时，根据业务定义使用 COUNT(DISTINCT xxx)。涉及xxxx数时，根据业务定义使用 SUM(recruiting_num)。涉及“最多”“最高”时使用 DESC。涉及“最少”“最低”时使用 ASC。涉及时间时必须明确时间范围。不允许查询敏感字段。如果用户问题无法通过现有数据回答，不要编造 SQL。SQL 必须可以直接在当前数据库执行。优先使用索引字段进行查询。查询结果需要具备明确的业务含义。

校验规则建议：

• 禁止危险操作： DELETE / DROP / TRUNCATE / ALTER 等写操作一律拦截
• 权限控制：检查查询的表是否在用户权限范围内
• 性能保护：加 LIMIT 兜底，防止全表扫描拖垮数据库
• 语法校验：确保SQL语法正确，避免执行报错

这一步很多教程会跳过，但生产环境**必须做**。一旦大模型"幻觉"出一个 DELETE 语句，后果不堪设想。

实践要点：

• 使用只读账号连接数据库，从源头杜绝写操作
• 设置查询超时，防止慢查询卡死整个工作流
• 大数据量结果做截断处理，别把10万行数据全塞给大模型

实践要点：

• 配置数据分析的Prompt，要求输出结论 + 趋势 + 建议
• 支持多轮对话，用户可以追问
• 复杂分析场景可以接入图表生成能力

— — — — — — — — — —

— — — — — — — — — —

智能问数 = 指标体系 + 语义理解 + Schema检索 + Text-to-SQL + SQL校验 + 数据分析 + 安全治理

如果你的智能问数效果不好，先别急着换模型、调Prompt，回头看看你的指标体系和Schema描述做得够不够好。

— — — — — — — — — —

1. 选对工具— Marketplace 插件起步，自定义插件进阶
2. 设计好工作流— 意图识别 → Text-to-SQL → SQL校验 → 查询 → 分析
3. 做好安全治理— 只读账号 + 权限校验 + 敏感脱敏 + 日志审计
4. 统一指标口径— 这是地基，地基不稳全白搭

如果你正在做或准备做智能问数，欢迎在评论区聊聊你遇到的坑。