在 AI 应用开发里数据可视化往往比想象中麻烦写 SQL、调图表库、调样式一套流程下来可能半天就过去了。这次我们来看一个更直接的思路——用 Dify 搭建“一键生成饼状图”应用把数据贴进去或者把数据接口接进来让大模型自动完成图表代码生成和渲染配置你再决定是直接预览、下载还是通过 API 集成到自己的系统里。Dify 是一个开源的大模型应用开发平台核心价值是把 Prompt 编排、知识库、工作流、API 发布这些能力串在一起。针对“饼状图生成”这个场景你不需要单独写图表服务也不需要在前端硬编码图表组件而是让 Dify 工作流里的模型节点解析数据、生成 ECharts 配置再用代码节点做数据校验最后通过应用接口输出结构化结果。这样一来“数据分析图表生成接口对接”就变成了一条可重复执行的流水线。本文会带你把这条流水线完整跑通先看 Dify 本地部署怎么准备环境再创建一个能生成饼状图的工作流应用然后用 WebUI 做效果验证最后用 API 方式批量生成图表。如果你正打算把 Dify 接入自己的数据报表系统这篇文章可以直接收藏。1. 核心能力速览在开始动手之前先把“Dify 一键生成饼状图”这个方案的能力边界和基本规格说清楚。下面这张表的内容是基于 Dify 平台通用能力和常见本地部署方式整理的部署版本不同时个别参数可能有差异实际以你自己环境里的版本为准。能力项说明项目类型基于 Dify 工作流搭建的大模型应用非独立图表项目核心能力数据输入、图表配置生成、饼状图渲染、结构化 API 输出常见大模型接入OpenAI 兼容接口、本地 Ollama / vLLM / Xinference 等部署方式Docker Compose 一键启动或直接使用云版 SaaS支持平台Linux 服务器、Windows / macOS 开发机、云主机启动方式Docker 启动后通过浏览器访问 WebUI接口能力支持应用 API可被第三方系统调用批量任务可通过 API 批量传入多组数据生成多个图表配置是否需要显卡纯 Dify 编排不需要 GPU本地大模型推理才需要显存图表渲染方式输出 ECharts JSON 配置由前端或脚本渲染适合场景周报数据可视化、运营看板、数据简报、教学演示从这张表能看出这个方案的本质不是“让 Dify 自动画一张 PNG 图片”而是“让 Dify 帮你生成一份可以直接丢给前端图表库的配置”再由 ECharts 这类渲染器把配置变成可见的饼状图。这样做的好处是可定制性强颜色、图例、标题都可以由大模型根据数据内容自动调整你也可以在后端把配置存下来方便后续统一改样式。2. 适用场景与使用边界如果你正在做数据汇报、运营周报、教学课件这类需要频繁出饼状图的工作这个方案最直接的用法是把原始数据整理成文本或 JSON 格式发到 Dify 应用里模型自动补全标题、分类颜色、图例位置、百分比精度最后返回一份结构完整的图表配置。你只需要在 HTML 页面里使用 ECharts 渲染或者在企业内部系统里接一个相同逻辑的接口。这个方案也适合当作 Dify 入门练习。因为饼状图的输出结构相对固定你可以非常清楚地看到 Prompt 设计、数据格式、模型输出三者之间的关系。先把这一条链路跑通后面再去扩折线图、柱状图、仪表盘思路是完全一样的。不过要划清边界。第一Dify 本身不负责渲染它返回的是图表配置不是最终图片如果你需要 PNG、JPG 格式要么在前端用 ECharts 的截图工具处理要么在服务端引入无头浏览器渲染。第二数据质量直接决定图表质量如果输入数据本身有缺失、重复、负数比例模型生成的图表配置也会有问题所以工作流里必须加数据校验节点。第三注意授权和数据隐私如果数据来自业务系统、用户信息、内部经营数据不要随意把完整数据扔给外部大模型本地化部署 Dify 并接入本地模型是更稳妥的做法。涉及版权素材、第三方图标、商业配色模板时也要确认素材授权范围避免直接复用不明来源的资源。3. Dify 本地部署环境准备Dify 本地部署的难度不高但对环境有要求。建议提前准备一台内存充足的机器个人开发和轻量测试场景使用 8GB 内存以上的 PC 就能跑起来如果要在服务器上长期提供服务内存建议 16GB 以上。CPU 建议 4 核以上。磁盘预留至少 20GB 空间因为 Docker 镜像、依赖包、模型缓存都会占用空间。操作系统方面Ubuntu 22.04 或 Debian 12 是比较常见的生产选择Windows 和 macOS 用于开发调试也没有问题。你需要提前安装 Docker 和 Docker Compose 插件。Dify 官方提供 docker-compose 部署文件拉取代码后执行启动命令即可不要求你手工配置 MySQL、Redis 这些中间件。显卡方面需要注意如果你只是用 Dify 编排工作流调用的模型是云端 API比如 OpenAI 兼容接口或国内大模型 API那么完全不需要 GPU。但如果你希望完全本地推理打算连接 Ollama、vLLM 这类本地模型服务那就需要一张显存足够大的显卡实际显存占用取决于你要用的模型规模和量化精度建议先用小参数模型测试确认流程没问题后再换更大模型。下面是操作系统的通用检查清单。不同系统的命令会有差异但检查思路是一致的。# 检查 Docker 版本 docker --version # 检查 Docker Compose 插件 docker compose version # 检查系统内存 free -h # 检查磁盘剩余空间 df -h如果 Docker 还没安装可以去 Docker 官网下载对应系统的 Docker Desktop或者用系统包管理器安装 Docker Engine。确保 Docker 服务是启动状态然后进入下一步。4. Dify 部署与基础应用创建4.1 Docker Compose 启动 DifyDify 的部署流程核心只有三步拉取源码、准备环境变量、启动服务。以官方 GitHub 仓库为例流程一般是# 拉取 Dify 源码这里用当前环境能访问到的源地址 git clone https://github.com/langgenius/dify.git # 进入 docker 目录 cd dify/docker # 复制环境变量模板 cp .env.example .env # 启动服务需要等待镜像拉取完成 docker compose up -d执行完最后一条命令后Dify 会启动多个容器包括 API 服务、Web 服务、PostgreSQL、Redis 等。第一次启动需要拉取镜像过程可能较长可以通过 docker compose ps 观察容器状态也可以通过 docker compose logs -f 查看启动日志。等所有服务状态变成 running再打开浏览器访问。默认访问地址http://服务器IP 默认管理员账号在首次访问时通过页面创建如果你的服务器已经有其他服务占用了 80 或 443 端口需要提前在 .env 文件中调整端口映射避免启动后端口冲突。调整完保存再重新执行 docker compose up -d 让配置生效。4.2 连接大模型供应商Dify 部署完成后登录管理员后台进入“设置 - 模型供应商”添加你计划使用的大模型。如果使用云端 API一般只需要填写 API Key 和模型名称如果使用本地 Ollama 服务需要确保 Dify 容器能够访问到 Ollama 的地址比如 http://host.docker.internal:11434。这里强调一个容易踩的坑Dify 容器内部不能直接用 127.0.0.1 访问宿主机服务需要换成宿主机在 Docker 网络中的地址通常就是 host.docker.internal。如果你把 Ollama 装在同一台机器上配置模型地址时写错成 127.0.0.1模型连接基本上都会失败。4.3 创建工作流应用模型连接好之后进入“应用”页面创建一个“工作流”类型的应用。这个应用会负责接收用户输入的数据和请求编排数据处理流程最后输出饼状图配置。工作流的推荐结构是开始节点 - LLM 节点解析数据 生成 ECharts 饼状图配置 - 代码节点校验配置合法性补充缺失字段 - 结束节点返回图表配置 JSON在 LLM 节点的系统提示词里要明确告诉模型输出标准 ECharts 饼状图 JSON。下面给出一段可直接参考的提示词模板注意根据实际选择的模型和渲染方式调整。你是一个数据可视化专家。请根据用户提供的数据生成 ECharts 饼状图配置。 要求 1. 只输出 JSON不要输出多余解释。 2. JSON 结构必须包含 title、tooltip、legend、series 字段。 3. series 的 type 必须是 pie。 4. 如果数据中各项比例明显不协调自动调整 radius 和 label 显示方式。 5. 数据中的分类名称为空时使用“未分类”代替。 6. 百分比字段保留一位小数。 用户数据 {{data}}这里的 {{data}} 是 Dify 工作流中开始节点传入的变量实际变量名根据你的节点配置而定。在可视化编排界面里你不需要手写模板语法可以直接用鼠标选择变量Dify 会自动生成引用。4.4 加入代码校验节点大模型生成的 JSON 偶尔会有格式问题比如多了一个逗号、字段名不一致、百分比溢出。为了不让错误配置直接传给下游可以在 LLM 节点后面加一个 Python 代码节点做基础校验和字段补齐。import json def main(generated_json: str) - dict: try: # 解析模型生成的 JSON 字符串 config json.loads(generated_json) except json.JSONDecodeError: # 如果解析失败返回一个最小可用的默认配置 config { title: {text: 数据饼状图}, tooltip: {trigger: item}, legend: {bottom: 0}, series: [{ type: pie, radius: 60%, data: [] }] } series config.get(series, []) if not series: series [{type: pie, radius: 60%, data: []}] config[series] series # 确保第一组系列是饼图 series[0][type] pie series[0][name] series[0].get(name, 数据分布) # 确保 data 字段存在 if data not in series[0]: series[0][data] [] return {result: config}这个代码节点接收 LLM 节点的输出字段 generated_json返回一个 result 对象。结束节点再把 result 返回给前端或通过 API 返回给外部调用方。5. 功能测试与效果验证工作流搭建完成后不要直接对接复杂业务系统先在 Dify 页面里用几组典型数据做功能测试。测试目标很简单确认模型能正确解析数据、生成合法 JSON、字段完整、图表可渲染。5.1 基础数据测试先测试最简单的两分类数据。在“运行”面板里输入A部门 60B部门 40预期输出是一份 ECharts 配置title 里包含“数据饼状图”或类似标题series[0].data 包含两个对象{name: A部门, value: 60} 和 {name: B部门, value: 40}。如果输出能直接粘贴到 ECharts 官网示例页渲染成饼图说明这一步通过。5.2 多分类与百分比测试接着测试多分类数据同时使用不同的单位格式华东 3200华南 2100华北 1800西南 900其他 450这里重点观察两点模型是否规范化了数据格式有没有把单位“件”“万元”等误当成数值图例和配色是否自动生成。如果模型返回的 data 数组里出现 value 为 null 或字符串说明提示词约束不足需要在 LLM 节点中补充“value 必须为数字”的硬性描述。5.3 异常数据测试异常数据测试很重要。输入一组包含缺失或空值的脏数据线上渠道 45线下渠道 合作渠道 30一个合格的图表生成流程不应该直接崩溃。代码校验节点应该把空值处理成 0或者在 LLM 节点里提示“遇到无法解析的分类时统一放入‘其他’”。如果你发现模型仍然输出 value 为空的配置就需要把清洗规则的描述写得更明确。5.4 前端渲染验证为了真正验证配置能否渲染成饼状图可以在本地创建一个简单的 HTML 页面把 Dify 输出的 JSON 配置填进去。下面的代码是 ECharts 的最小渲染模板假设你已经把 Dify 的返回值复制到了 config 变量中。!DOCTYPE html html langzh-CN head meta charsetUTF-8 title饼状图渲染验证/title !-- 引入 ECharts CDN生产环境建议固定版本号 -- script srchttps://cdn.jsdelivr.net/npm/echarts5/dist/echarts.min.js/script /head body stylemargin: 0; height: 100vh; div idchart stylewidth: 100%; height: 100%;/div script // 这里替换成 Dify 工作流返回的 result 对象 const config { title: { text: 数据饼状图 }, tooltip: { trigger: item }, legend: { bottom: 0 }, series: [{ type: pie, radius: 60%, name: 数据分布, data: [ { name: A部门, value: 60 }, { name: B部门, value: 40 } ] }] }; const chart echarts.init(document.getElementById(chart)); chart.setOption(config); /script /body /html先用静态示例数据确认本地 ECharts 能渲染再替换为 Dify 返回的真实配置。如果页面显示不出图表打开浏览器控制台优先看 JSON 解析报错和字段名错误。ECharts 对字段名非常敏感比如 series 写成了 serires、data 写成了 datas都会导致渲染失败。6. 接口 API 调用与批量任务页面测试跑通之后下一步就是把这个 Dify 应用发布成 API 服务接入你自己的报表系统。Dify 的应用本身带有 API 发布能力创建应用后在“API 访问”页面可以拿到 API Key 和调用地址。你只需要把请求发过去接口会返回工作流结束节点的输出结果。下面给出一个标准的 API 调用示例使用 Python 的 requests 库。注意把 URL、API Key 和输入数据换成你自己应用的参数。import requests # Dify 应用 API 地址按实际环境替换 api_url https://your-dify-domain/v1/workflows/run # 在 Dify 应用 API 访问页面创建 api_key app-xxxxxxxxxxxxxxxx headers { Authorization: fBearer {api_key}, Content-Type: application/json } # 输入数据对应工作流开始节点中的变量 payload { inputs: { data: 华东 3200华南 2100华北 1800西南 900其他 450 }, response_mode: blocking, user: dashboard-user } resp requests.post(api_url, headersheaders, jsonpayload, timeout120) result resp.json() print(result) # 如果工作流结束节点返回字段是 result就取出图表配置 chart_config result.get(data, {}).get(outputs, {}).get(result) print(chart_config)批量任务就是在循环里多次调用同一个接口把不同数据分别发过去。这种方式适合处理一批固定格式的数据源比如每天从数据库里统计出的各渠道订单占比。下面是一个简单的多任务示例import time import requests def generate_chart(api_url: str, api_key: str, data_text: str) - dict: headers { Authorization: fBearer {api_key}, Content-Type: application/json } payload { inputs: {data: data_text}, response_mode: blocking, user: batch-dashboard } resp requests.post(api_url, headersheaders, jsonpayload, timeout120) return resp.json() batch_data [ 新品 45经典款 30联名款 25, 周一 120周二 150周三 90周四 100周五 180, 搜索 60信息流 25社群 10其他 5 ] api_url https://your-dify-domain/v1/workflows/run api_key app-xxxxxxxxxxxxxxxx for idx, data_text in enumerate(batch_data, start1): try: r generate_chart(api_url, api_key, data_text) outputs r.get(data, {}).get(outputs, {}) print(f任务 {idx} 完成result {outputs.get(result)}) except Exception as e: print(f任务 {idx} 失败{e}) # 控制调用频率避免触发限流 time.sleep(2)批量任务有个工程细节要处理失败重试。接口偶发超时或模型输出暂时不可用都是常见情况。建议在批量脚本里加入单条重试逻辑重试 2 到 3 次每次间隔数秒。同时把每一条输入和对应的输出 result 保存到本地 JSON 或数据库方便后续排查。7. 资源占用与性能观察Dify 应用本身是容器化服务资源占用主要集中在 Docker 容器组上。如果只是跑一个简单工作流内存占用通常不高但当你打开页面、执行任务、连接外部模型时CPU 和内存都会有波动。部署时应预留足够的内存余量避免在高并发调用时因为内存不足导致容器被系统杀掉。显存占用这个问题要看模型部署在哪里。如果你连接的是云端 APIDify 这边完全不用显卡显存占用为 0。如果你连接的是本地 Ollama 或 vLLM 服务显存占用由本地模型决定。同样的 7B 模型4bit 量化推理可能只需要 5GB 到 6GB 显存16bit 加载就需要更多。这部分没有统一数值必须根据模型量化格式和推理框架实测。更稳妥的做法是先用小模型跑通工作流再逐步替换成大模型同时用 nvidia-smi 命令观察显存变化。影响 Dify 工作流性能的主要因素有三个。第一是输入数据长度饼状图数据本身不大但如果你把大段报告文本一起丢给模型token 数量会明显增加。第二是模型响应速度云端 API 受网络影响本地模型受显存和推理框架影响。第三是代码节点复杂度校验逻辑越重每次运行耗时越多。针对饼状图生成输入数据应该尽量精简只保留分类名和数值其余说明文字放到 Prompt 的系统提示词里即可。在部署层面建议把 Dify 的 API 服务跑在内网环境并限制公网访问。如果多个业务系统都要调用同一个图表生成接口最好在 Dify 前面再加一层网关做鉴权、限流和请求日志。这样既能保护内部数据也方便对超时任务做更细粒度的跟踪。8. 常见问题与排查方法实际部署和调用过程中几个高频问题值得提前记录。下面表格列出的是通用排查思路具体报错信息会因版本不同而略有差异。问题现象可能原因排查方式解决方案访问 Dify 页面打不开端口映射错误或容器未启动docker compose ps 查看状态docker compose logs 查看日志调整 .env 中的端口映射重新启动服务工作流运行时提示模型连接失败Dify 容器无法访问模型服务地址确认模型供应商配置检查 API Key 和本地服务地址本地模型地址改用 host.docker.internal云端 API 核对 KeyLLM 返回的 JSON 无法解析模型输出了多余文字或格式错误查看 LLM 节点原始输出代码节点加 JSON 解析日志强化 Prompt 输出约束增加代码校验节点兜底饼图数据为空输入字段名不对应或数据清洗失败查看开始节点变量名和工作流变量映射统一输入字段名在代码节点打印中间变量批量任务部分失败单次请求超时或触发限流检查接口返回状态码和错误信息增加重试机制控制并发数图表渲染不出内容ECharts 配置字段错误打开浏览器控制台查看报错对照 ECharts 官方文档检查 series 字段容器反复重启内存不足或环境变量错误查看容器日志检查系统内存增加内存资源修正环境变量后重启模型输出统计口径不对输入数据含义有歧义检查用户输入文本和模型解析结果在 Prompt 中明确说明各字段含义和单位其中最常被忽略的是第五个问题批量任务失败。很多人第一次写批量脚本时只按顺序调用接口没有考虑限流和超时。Dify 和模型服务端都可能有调用频率限制因此在批量脚本里加入 sleep 机制、失败记录、重试逻辑是必须的不能想当然地认为接口一定会稳定返回。9. 最佳实践与使用建议做这类“大模型生成图表配置”的应用先小规模验证再推全量是成本最低的思路。第一轮先用一两组数据测试提示词和输出格式确认稳定后再接入真实业务数据。如果一上来就把几十个分类、几千行数据塞给模型不仅 token 成本高模型对数据口径的理解也可能出问题。在 Prompt 设计上建议把“数据解析规则”和“图表样式规则”拆开写。数据解析规则解决的是“数据里有哪些字段、空值怎么处理、单位怎么识别”图表样式规则解决的是“标题怎么写、图例放哪里、饼图半径多大、颜色怎么映射”。两者混在一起模型容易顾此失彼。在项目结构上建议把输入数据、生成的配置 JSON、最终渲染截图分目录管理。Dify 工作流的输出应该保存到一份带时间戳的 JSON 文件中方便回溯如果前端需要渲染图片再单独写一份截图脚本处理。# 推荐的项目目录结构 dify-pie-chart/ ├── inputs/ # 原始数据文件 ├── outputs/ # Dify 返回的配置 JSON ├── screenshots/ # 渲染后的图片 ├── scripts/ # 批量调用和渲染脚本 └── workflows/ # Dify 工作流导出文件授权和隐私是必须强调的一环。如果数据涉及用户行为、业务经营情况或个人信息不要直接发送到外部云端模型企业内部数据优先走本地模型方案并在代码中屏蔽敏感字段。如果图表中要嵌入公司 Logo、品牌色板、第三方图标确认素材授权后使用避免版权风险。发布到公网或对外商用时还要对模型输出做人工复核避免出现误导性结论或异常数据展示。10. 总结与下一步Dify 一键生成饼状图本质上是一次大模型应用编排能力的落地。它最值得尝试的点是把“数据解析、图表生成、接口输出”这三个环节组装成一条自动化流水线你不需要再单独维护一套图表生成服务大模型负责理解数据Dify 工作流负责把理解结果变成结构化配置。最先应该验证的功能就是最简单的两分类数据测试。确认输出 JSON 能被 ECharts 正常渲染后再做多分类和异常数据测试。最容易踩的坑有两个一个是 Dify 容器访问宿主机模型的地址写错另一个是模型生成的 JSON 不合法导致下游解析失败。前者通过 host.docker.internal 解决后者通过代码校验节点兜底。如果你已经跑通了饼状图下一步可以顺着同一套工作流模板扩展生成柱状图、折线图、漏斗图甚至加入知识库让模型根据历史数据自动生成数据解读文本。再往后可以把这份 API 接入到企业内部的报表平台、钉钉或飞书机器人、数据大屏系统形成完整的“数据输入 - 图表生成 - 渠道分发”链路。对一个团队来说这套方案的价值不只是省掉多次手工画图的时间更是把图表生成经验固化成了一个可复用、可治理、可审计的 AI 应用。