注：此文章内容均节选自充电了么创始人，CEO兼CTO陈敬雷老师的新书《GPT多模态大模型与AI Agent智能体》（跟我一起学人工智能）【陈敬雷编著】【清华大学出版社】

清华《GPT多模态大模型与AI Agent智能体》书籍配套视频课程【陈敬雷】

GPT多模态大模型与AI Agent智能体系列二百一十三

0代码搞定ChatBI！Doris+DeepSeek+Dify保姆级搭建教程：从环境到可视化全流程，附可复用DSL（小白也能上手）

在企业数字化转型中，“对话式数据分析（ChatBI）”早已不是新鲜概念，但落地门槛却让很多团队望而却步：要么需要懂SQL、Python的技术人员写代码，要么依赖昂贵的商业工具，中小企业更是陷入“想做却没能力做”的困境。

而腾讯云开发者社区这篇《0代码！教会你用Doris+DeepSeek+Dify搭建ChatBI系统》，恰好击中了“低门槛、高落地性”的核心需求——它用Apache Doris（高性能实时数仓）、DeepSeek（国产顶尖大模型）、Dify（低代码AI应用平台）的组合，打造了一套“无需手写复杂代码、跟着步骤就能成”的ChatBI方案，甚至附带了可复用的DSL配置，让技术小白也能快速落地。本文将从方案逻辑、搭建细节、关键痛点解决三个维度，拆解这套方案的核心价值与实操要点。

一、方案底层逻辑：为什么是Doris+DeepSeek+Dify？三者互补才是关键

要理解这套方案的优势，首先得搞懂三个工具的“分工”——它们并非随机组合，而是精准覆盖了ChatBI的全流程需求：从数据存储、自然语言转查询，到低代码编排，形成了“数据层-AI层-应用层”的完整闭环。

1. Apache Doris：ChatBI的“数据引擎”——快、稳、能扛量

ChatBI的核心是“快速响应用户查询”，而数据存储层的性能直接决定了查询速度。Apache Doris作为基于MPP架构的实时分析型数据库，恰好解决了“查得快、查得准”的问题：

• 高性能查询：支持列式存储、智能索引，即使是千万级数据量的多表关联查询（如“按地区统计客户订单金额”），也能秒级返回结果，避免用户等待；
• 兼容性强：完美支持SQL语法，且能对接Hive、Kafka等多种数据源，企业现有业务数据（如CRM、ERP数据）可直接导入，无需重构数据结构；
• 易维护：相比Hadoop等复杂架构，Doris部署和运维更简单，中小企业没有专业数仓团队也能上手。

文中选择导入TPC-H数据集（包含客户、订单、供应商等维度表），正是因为它贴近企业真实业务场景——多表关联、复杂指标计算（如订单金额汇总、客户地区分布），能完整演示ChatBI的核心能力，用户后续替换成自己的业务数据也更易迁移。

2. DeepSeek：ChatBI的“大脑”——懂业务、转得准

ChatBI的核心环节是“自然语言转SQL（Text2SQL）”，这就需要大模型既能理解用户的模糊需求（如“最近订单多的客户”），又能生成符合Doris语法的准确SQL。DeepSeek作为国产顶尖LLM，在这两点上表现突出：

• 语义理解精准：能识别业务术语（如“华东区”“Q1业绩”），并补全模糊需求（如“最近”自动对应“近7天”，需提前在配置中定义规则）；
• SQL生成适配性强：支持自定义数据库表结构、查询规则，可针对性优化Doris语法（如Doris的特殊聚合函数），避免生成“能运行但结果错”的SQL；
• 国产化优势：对中文语义理解更到位，且部署灵活（可私有部署），满足企业数据安全需求。

3. Dify：ChatBI的“搭建工具”——0代码、能编排

很多ChatBI方案卡在上手环节：需要写代码对接数据库、调大模型接口、做可视化。而Dify作为低代码AI应用开发平台，直接把“流程编排”做成了拖拽式操作：

• 低代码门槛：无需写后端代码，通过“节点拖拽+参数配置”就能串联起“用户输入→Text2SQL→数据查询→可视化”全流程；
• 插件生态完善：自带Database插件（可直接对接Doris）、LLM插件（支持DeepSeek）、可视化插件（支持ECharts），无需自己开发集成；
• 支持云端/本地：既可以用Dify Cloud快速上手（不用搭服务器），也能通过Docker部署到本地（适合数据敏感场景），兼顾灵活性与安全性。

三者的协作逻辑也非常清晰，形成“用户需求→AI处理→数据响应→可视化输出”的闭环：
用户提需求（如“查华东区Q1订单量Top5客户”）→ DeepSeek将需求转成Doris可执行的SQL → Doris执行查询返回数据 → DeepSeek再将数据转成Markdown表格+ECharts图表 → Dify将结果返回给用户
整个过程无需用户写一行代码，完全靠配置实现。

二、0代码搭建全流程：从环境到可视化，6步走不踩坑

文中最核心的“实战环节”，是基于Doris+DeepSeek+Dify的搭建步骤。这部分需要拆解每个环节的“操作要点”和“避坑指南”，因为很多用户会在环境配置、节点参数设置上卡壳。

1. 第一步：准备Doris环境——先搭好“数据仓库”

要让ChatBI能查数据，首先得有存储数据的地方。这一步的核心是“部署Doris+导入测试数据”，文中给出了明确的操作路径：

（1）Doris部署：两种方式，按需选择

文中提供了官方手动部署链接（https://doris.apache.org/zh-CN/docs/install/deploy-manually/integrated-storage-compute-deploy-manually），适合需要本地部署的用户；如果是小白想快速测试，也可以用Docker部署（社区有现成镜像），步骤更简单。
避坑点：部署时要记好Fe（Frontend）节点的IP和端口（默认9030），后续对接Dify需要用到；另外，确保Doris的服务正常启动（可通过“mysql -h FeIP -P9030 -u root”测试连接）。

（2）导入TPC-H数据：选对数据集，演示更真实

为什么选TPC-H数据集？因为它包含8张表（客户表customer、订单表orders、供应商表supplier等），覆盖“客户-订单-商品”的完整业务链路，能模拟企业常见的分析场景（如“按地区查客户订单量”“按时间查订单趋势”）。
操作要点：按照文中链接（https://doris.apache.org/zh-CN/docs/benchmark/tpch）的步骤导入，确保表结构和数据正常——可通过Doris的MySQL客户端执行“SELECT * FROM customer LIMIT 10;”验证数据是否导入成功。

这一步的目标是：让Doris里有可查询的数据，为后续ChatBI提供“数据源”。

2. 第二步：准备Dify环境——低代码平台快速上手

Dify是整个方案的“操作台”，环境准备非常简单，文中提供了两种方式，适合不同需求的用户：

（1）Dify Cloud（推荐小白）：无需部署，注册即能用

直接访问https://cloud.dify.ai/apps，注册账号后创建“空白应用”，选择“Chatflow”（对话流程）模板——这种方式最快，10分钟就能进入流程编排界面，适合想快速测试的用户。

（2）Docker部署（适合数据敏感场景）：本地掌控更安全

如果企业数据不能上云，可通过Docker部署Dify（官方文档：https://github.com/langgenius/dify），步骤是“拉取镜像→启动容器→访问本地地址”。
避坑点：Docker部署时要映射好端口（默认8000），确保本地能访问；另外，需要提前安装Docker和Docker Compose，避免启动时缺依赖。

无论哪种方式，最终都要进入Dify的“Chatflow流程编排”界面——这是后续搭建的核心阵地。

3. 第三步：核心！Dify流程编排——6个节点串联全流程

这是整个方案的“灵魂环节”，文中用6个节点（Input→Text2SQL→SQL Formatting→Doris Execute→Json Result→Doris ChatBI→Result）实现了从“用户提问”到“可视化输出”的全流程。每个节点的配置细节都决定了ChatBI的准确性，必须逐一拆解：

（1）Input节点：无需配置，用户需求入口

作用：接收用户在对话窗口输入的需求（如“查Q1华东区客户订单量”），无需额外设置——Dify会自动将用户输入作为“上下文变量”传递给下一个节点。

（2）Text2SQL节点：DeepSeek配置是关键，决定SQL准不准

这是“让AI懂数据”的核心节点，需要配置DeepSeek大模型，告诉它“用哪些表、怎么写SQL”。文中给出的配置逻辑可分为5个关键部分，也是用户需要重点复现的：

• 核心规则定义：明确“仅使用提供的表和字段”“SQL必须兼容Doris语法”“只输出完整SQL，无注释”——避免LLM天马行空生成无效SQL；
• 数据库表结构说明：详细列出TPC-H数据集的表名、字段名、字段含义（如“customer表：c_custkey（客户ID）、c_name（客户名称）、c_nationkey（国家ID）”）——这是LLM生成SQL的“依据”，漏写字段会导致SQL错误；
• 查询技巧提示：告诉LLM常用的聚合函数（COUNT/SUM/AVG）、关联逻辑（如orders表和customer表通过c_custkey关联）——提升SQL的高效性；
• 查询示例：给出具体案例（如“查询客户订单分布数量：SELECT c_name, COUNT(o_orderkey) AS order_count FROM customer JOIN orders ON c_custkey = o_custkey GROUP BY c_name LIMIT 10;”）——LLM会模仿示例格式生成SQL，降低出错率；
• 输出格式限制：强调“只输出1个SQL语句，过滤非SQL内容”——避免LLM输出解释性文字，导致后续无法执行。

避坑点：表结构一定要写全、写准！比如“华东区”对应的字段（如c_region）和值（如“ASIA”）要明确，否则LLM会误解“华东区”的含义，生成错误的WHERE条件。

（3）SQL Formatting节点：解决LLM生成SQL的“格式乱”问题

很多人忽略这个节点，但它是“SQL能否执行”的关键——LLM生成的SQL可能带换行符、代码块标记（如```sql），甚至多余的解释文字，直接执行会报错。
文中提供了一段Python代码，作用是“清理SQL格式”：

import re  

def main(text2sql: str) -> dict:
    # 移除代码块标记和换行符
    text2sql = text2sql.replace('```sql\n', ' ').replace('\n```', ' ').replace('\n', ' ').strip()
    # 过滤LIMIT后的多余内容（如LLM可能加注释）
    text2sql = re.sub(r'(LIMIT \d+;).*', r'\1 ', text2sql, flags=re.IGNORECASE)
    return {
        "text2sql": text2sql,
    }

操作要点：在Dify中添加“Python代码”节点，粘贴这段代码，将Text2SQL节点的输出作为输入——这样就能自动清理SQL格式，确保后续Doris能正常执行。

（4）Doris Execute节点：对接Doris，执行SQL查数据

这是“连接AI与数据”的节点，需要通过Dify的“Database”插件对接Doris。配置核心是“数据库连接串”，文中给出的格式是：

mysql+pymysql://{user}:{passwd}@{fe_ip}:9030/tpch

• {user}：Doris的用户名（默认root）；
• {passwd}：Doris的密码（默认空，可后续设置）；
• {fe_ip}：Doris Fe节点的IP；
• tpch：数据库名（TPC-H数据导入的库）。

避坑点：

1. 确保Dify服务器能访问Doris的9030端口（关闭防火墙或配置白名单），否则会连接超时；
2. 测试连接时如果报错，先检查Fe IP、端口是否正确，再用MySQL客户端验证Doris是否能正常登录。

（5）Json Result节点（可选）：规范数据格式，方便后续可视化

Doris返回的查询结果可能是表格格式，需要转成JSON格式，方便DeepSeek后续处理（如提取字段做可视化）。Dify中只需添加“变量赋值”节点，用{{ json_result }}将查询结果转成JSON——这一步虽可选，但能减少后续节点的格式适配问题，建议配置。

（6）Doris ChatBI节点：让数据“说话”，生成表格+ECharts

这是“让结果更易懂”的节点，同样用DeepSeek，核心是“将JSON数据转成人类易读的表格+可视化图表”。文中的配置逻辑和Text2SQL类似，重点在3个方面：

• 数据处理规则：要求先输出Markdown表格（直观展示数据），再输出ECharts配置（可视化），且图表要简洁（避免冗余配置）；
• 分析维度提示：告诉LLM常见的分析场景（如订单分析看数量/分布/趋势，客户分析看地区/消费），让图表类型更贴合需求（如分布用饼图、趋势用折线图）；
• 特殊情况处理：空数据时返回“没有查询到相关数据”+空白ECharts图，异常值如实报告（不主观修改）——避免用户看到错误或模糊的结果。

示例效果：如果用户问“Q1华东区订单量Top5客户”，这个节点会输出：

1. Markdown表格：包含“客户名称、订单量、所属地区”；
2. ECharts柱状图：X轴是客户名称，Y轴是订单量，自动配色和标注。

（7）Result节点：输出结果，对话窗口展示

最后一步很简单：添加“回复”节点，将Doris ChatBI节点的输出直接返回给用户——至此，整个ChatBI流程就搭建完成了！

4. 测试验证：用一个需求跑通全流程

搭建完后，一定要测试验证。文中建议用简单需求（如“查询TPC-H数据中，订单表（orders）2024年Q1的订单数量”）测试，重点看3个环节：

1. Text2SQL是否准确：查看节点输出的SQL是否包含“WHERE o_orderdate BETWEEN ‘2024-01-01’ AND ‘2024-03-31’”“COUNT(o_orderkey)”；
2. Doris Execute是否成功：查看返回的订单数量是否合理（如几千或几万，根据数据集规模）；
3. 可视化是否正常：对话窗口是否显示Markdown表格和可交互的ECharts图。

如果某一步出错，可按“节点日志→错误提示→配置检查”的流程排查：比如SQL执行失败，先看Doris Execute节点的日志，是否是连接串错误或SQL语法错误。

三、方案价值与落地建议：不止于“查数据”，中小企业如何复用？

文中的结语不仅总结了方案的当下价值，还提到了未来方向（Data Agent、RAG与ChatBI结合），这部分需要提炼对企业的实际意义，尤其是中小企业如何基于这套方案落地自己的ChatBI。

1. 核心价值：解决中小企业的3大痛点

这套方案之所以值得关注，本质是解决了中小企业落地ChatBI的核心障碍：

• 门槛痛点：0代码搭建，无需招聘SQL工程师、AI算法工程师，业务人员跟着教程也能上手；
• 成本痛点：三个工具都是开源或低代码（Doris开源、DeepSeek有开源版本、Dify有免费额度），无需支付昂贵的商业软件费用；
• 效率痛点：从环境搭建到测试跑通，1天内就能完成，相比定制开发（动辄1-3个月），落地效率提升10倍以上。

正如文中用户所说：“以前Doris数据分析像是在翻译两种语言（业务需求→SQL），现在可以直接用母语和数据对话”——这正是ChatBI的本质：让数据回归“解决业务问题”的核心，而不是被技术门槛挡住。

2. 落地建议：从“演示”到“业务化”，3个关键步骤

很多企业搭完Demo后就卡壳，不知道怎么对接真实业务数据。结合文中方案，建议分3步推进：

• 第一步：替换业务数据：将TPC-H数据集换成企业自己的数据（如CRM中的客户数据、ERP中的销售数据），在Text2SQL节点中更新“表结构说明”（务必写全字段含义和关联逻辑）；
• 第二步：自定义业务规则：根据行业需求调整配置，比如零售企业可添加“客单价=销售额/订单量”的计算规则，制造业可添加“产能利用率=实际产量/理论产量”的指标定义，让DeepSeek更懂业务；
• 第三步：权限控制：通过Dify的“用户角色”功能，给不同岗位配置不同数据权限（如销售人员只能查自己的客户数据，管理者能查全公司数据），避免数据泄露。

3. 未来方向：ChatBI不止于“查询”，还要“主动洞察”

文中提到未来会分享“Data Agent、RAG与ChatBI的结合”，这其实是ChatBI的下一阶段方向：

• Data Agent（数据代理）：让ChatBI主动发现问题，比如“自动识别本周销售额环比下降10%，并分析根因（如某地区物流延迟）”，而不是等用户提问；
• RAG（检索增强生成）：将企业知识库（如产品手册、销售政策）融入ChatBI，比如用户问“某产品的订单返利怎么算”，ChatBI既能查该产品的订单数据，又能引用知识库中的返利规则，给出完整答案。

这些方向也为中小企业提供了长期优化的路径——先落地“查询型ChatBI”，再逐步升级为“智能洞察型ChatBI”。

四、总结：0代码方案的本质，是让ChatBI“人人可用”

这篇文章的核心价值，不止是提供了一套“Doris+DeepSeek+Dify”的技术组合，更重要的是打破了“ChatBI是大企业专属”的误区——通过开源工具+低代码平台的组合，中小企业也能以“零代码、低成本、快落地”的方式，实现“用自然语言对话数据”的目标。

文中附带的“完整DSL”（虽然演示版未完全公开，但核心配置逻辑已给出）更是降低了复用成本——用户无需从零编写Text2SQL、ECharts的配置规则，只需根据自己的业务数据微调即可。对于技术小白或资源有限的企业来说，这无疑是“上手ChatBI的最佳跳板”。

正如文中所说：“ChatBI的魅力不仅在于简化数据获取，更在于改变了人与数据的交互方式”——当业务人员不用再等技术人员出报表，不用再学SQL，而是直接用“母语”和数据对话时，数据才能真正成为“每个人的决策助手”，这也是这套0代码方案最值得推广的意义所在。

更多技术内容

更多技术内容可参见
清华《GPT多模态大模型与AI Agent智能体》书籍配套视频【陈敬雷】。
更多的技术交流和探讨也欢迎加我个人微信chenjinglei66。

总结

此文章有对应的配套新书教材和视频：

【配套新书教材】
《GPT多模态大模型与AI Agent智能体》（跟我一起学人工智能）【陈敬雷编著】【清华大学出版社】
新书特色：《GPT多模态大模型与AI Agent智能体》（跟我一起学人工智能）是一本2025年清华大学出版社出版的图书，作者是陈敬雷，本书深入探讨了GPT多模态大模型与AI Agent智能体的技术原理及其在企业中的应用落地。
全书共8章，从大模型技术原理切入，逐步深入大模型训练及微调，还介绍了众多国内外主流大模型。LangChain技术、RAG检索增强生成、多模态大模型等均有深入讲解。对AI Agent智能体，从定义、原理到主流框架也都进行了深入讲解。在企业应用落地方面，本书提供了丰富的案例分析，如基于大模型的对话式推荐系统、多模态搜索、NL2SQL数据即席查询、智能客服对话机器人、多模态数字人，以及多模态具身智能等。这些案例不仅展示了大模型技术的实际应用，也为读者提供了宝贵的实践经验。
本书适合对大模型、多模态技术及AI Agent感兴趣的读者阅读，也特别适合作为高等院校本科生和研究生的教材或参考书。书中内容丰富、系统，既有理论知识的深入讲解，也有大量的实践案例和代码示例，能够帮助学生在掌握理论知识的同时，培养实际操作能力和解决问题的能力。通过阅读本书，读者将能够更好地理解大模型技术的前沿发展，并将其应用于实际工作中，推动人工智能技术的进步和创新。

【配套视频】

清华《GPT多模态大模型与AI Agent智能体》书籍配套视频【陈敬雷】
视频特色： 前沿技术深度解析，把握行业脉搏

实战驱动，掌握大模型开发全流程

智能涌现与 AGI 前瞻，抢占技术高地

上一篇：《GPT多模态大模型与AI Agent智能体》系列一》大模型技术原理 - 大模型技术的起源、思想
下一篇：DeepSeek大模型技术系列五》DeepSeek大模型基础设施全解析：支撑万亿参数模型的幕后英雄