Dify + ECharts 实战：自然语言一键生成饼状图-平芜编程栈

之前在业务迭代中遇到一个高频需求：用户输入一段业务数据，系统自动生成可视化图表。常见的做法是前端先约定好数据结构，后端写死几种图表模板，一旦遇到字段变化就要改代码，整个过程并不“智能”。后来我尝试用 Dify 搭建一个“自然语言生成饼状图”的应用，把大语言模型、数据解析、ECharts 配置生成串成一条自动化链路，效果非常直接。本文整理的就是这套从零开始的完整实操方案，覆盖思路、提示词、工作流编排、代码节点和常见报错处理，适合刚接触 Dify 的开发者，也适合想快速落地 AI 可视化方案的后端工程师参考。

1. Dify 能做什么：为什么用它生成饼状图

1.1 Dify 是什么

Dify 是一个开源的大语言模型应用开发平台，主打“LLM App 的可视化编排”。你可以在上面创建对话应用、文本生成应用，也可以把多个节点串成工作流，节点之间用变量传递数据，每个节点可以是大模型调用、代码执行、条件分支、HTTP 请求等。

简单理解：Dify 把“调用大模型”这件事做成了可视化积木。以前我们要写一套后端服务，通过 LangChain 或者直接调 OpenAI SDK 来组织 Prompt、管理上下文、解析输出，现在在 Dify 的界面里就能完成大部分工作。它同时提供了应用 API 和 WebApp 页面，适合快速验证产品原型，也能接进正式业务系统。

用 Dify 生成饼状图，并不是让 Dify 直接“画图”。更准确的链路是：用户输入数据描述 → 大模型理解并整理成结构化数据 → 代码节点把数据转换成 ECharts 可识别的 option JSON → 前端或 WebApp 完成渲染。这样拆开之后，Dify 承担的是“数据处理和图表配置生成”这个 AI 能力层。

1.2 用 Dify 生成饼状图的两种思路

第一种思路是“代码生成方案”。让大模型直接生成一段 Python 绘图代码，例如基于 matplotlib 或 pyecharts 的代码，然后放到 Python 执行环境里运行，运行结果输出为图片或 HTML。优点是定制性强，缺点是代码执行环境需要额外搭建，并且大模型生成的代码不一定一次通过，需要不断调试。

第二种思路是“配置生成方案”。让大模型输出结构化的图表配置，例如 ECharts 的 option JSON，然后前端直接加载这个配置完成渲染。这种方式更稳定，因为 ECharts 是纯前端渲染，不需要在服务端跑 Python 绘图代码，而且大模型生成 JSON 比生成完整可运行代码的成功率高。

本文采用第二种思路。Dify 负责生成 ECharts option 配置，最后用一个轻量展示页面把饼状图画出来。

1.3 本文实战能获得什么

读完这篇文章，你会掌握下面这些能力：

在 Dify 中创建“工作流类型”应用。
合理编写 Prompt，让大模型输出固定 JSON 结构。
使用 Dify 的代码节点解析大模型结果。
把最终生成的 ECharts option 通过 WebApp 或 API 返回给前端。
遇到 JSON 解析失败、字段缺失、渲染空白等问题时的排查思路。

整个过程不依赖复杂的前端工程，也不需要自建大模型服务。

2. 环境准备与版本说明

2.1 Dify 部署方式选型

Dify 支持云端版和社区版。云端版直接注册账号就能用，适合快速体验；社区版需要自己部署，数据可控，适合企业内部项目。

社区版最常见的部署方式是通过 Docker Compose 启动。它依赖以下环境：

组件	作用
Docker	容器运行环境
Docker Compose	编排 Dify 多个服务
浏览器	访问 Dify 控制台
大模型 API Key	驱动 LLM 节点，例如 OpenAI、DeepSeek、通义千问等

版本方面，Dify 迭代速度比较快，不同版本的界面细节可能会有差异，但核心编排概念基本一致。本文示例基于社区版 Docker Compose 部署思路，版本需要根据你的项目实际情况调整。

2.2 启动 Dify 社区版

首先你需要有一台安装了 Docker 和 Docker Compose 的服务器或本机。拉取 Dify 源码仓库中的 docker 目录，在目录内执行启动命令：

git clone https://github.com/langgenius/dify.git cd dify/docker cp .env.example .env docker compose up -d

启动过程会拉取多个镜像，包括 API 服务、Worker、PostgreSQL、Redis、Nginx、Sandbox 等。看到所有容器状态为 healthy 或 running 后，就可以通过浏览器访问 Dify 控制台。

docker compose ps

初始化时，Dify 默认会监听本机 80 端口或 443 端口。实际端口需要查看.env中NGINX_PORT配置。访问地址一般是http://localhost/install，按页面提示创建管理员账号。

这里需要提醒一点：大模型 API Key 并不是 Dify 自带的，需要你提前准备好。在 Dify 控制台“设置 → 模型供应商”里添加 key 之后，创建应用时才能选择模型。

2.3 创建 Dify 应用

创建完成后，你会进入工作流编排画布。画布左侧是节点列表，中间是画布，右侧是节点配置面板。这是后面实战的主要操作区域。

3. 核心概念：Dify 应用编排方式

3.1 应用类型与工作流节点

Dify 的应用类型主要分为三类：

聊天助手：面向多轮对话场景，适合客服、问答类应用。
文本生成：单次输入输出，适合摘要、翻译、文案生成。
工作流：把多个节点串起来，适合有明确业务逻辑的自动化任务。

饼状图生成属于典型的“有明确处理流程”的任务，所以工作流是最优选择。

工作流里常用的节点包括：

开始节点：定义用户输入变量。
LLM 节点：调用大模型，输入 Prompt 和变量，输出模型结果。
代码节点：运行 Python 代码，处理变量。
条件分支节点：根据条件走不同分支。
HTTP 请求节点：调用外部接口。
结束节点：定义最终输出内容。

3.2 提示词设计的基本原理

在 Dify 中，LLM 节点的效果很大程度上取决于提示词。写提示词的通用原则是：

描述清楚角色和任务。
给出输入数据格式。
明确输出格式。
提供示例。

对于饼状图场景，提示词要解决一个核心问题：把用户输入转换成“分类名 + 数值”的列表。例如用户输入“一季度销售额：手机 100 万，电脑 80 万，耳机 30 万”，我们需要模型输出：

[ {"name": "手机", "value": 100}, {"name": "电脑", "value": 80}, {"name": "耳机", "value": 30} ]

为了让模型稳定输出这个结构，提示词里一定要写清楚“只能输出 JSON，不要输出多余文字”，并给出 JSON 示例。

3.3 变量与代码节点

工作流的开始节点可以为接收用户输入定义变量。例如定义一个input_data变量，类型是“段落”，用户在发起请求时传入原始数据。

代码节点则可以接收上游 LLM 节点的输出变量，然后执行 Python 代码，把结果返回给下游。需要注意的是，Dify 代码节点目前主要支持 Python，它的入口是一个main函数，函数接收参数，返回值需要是 dict 类型。具体支持的参数类型和函数签名，会随着版本迭代发生变化，建议以官方文档为准。下面给出通用写法示例：

def main(input_json: str) -> dict: # input_json 是上游传过来的原始 JSON 字符串 # 处理逻辑 return {"result": processed_data}

代码节点的好处是：即使大模型偶尔输出格式不完美，我们也可以在代码里做容错和清洗，保证最终给前端的配置是合法 JSON。

3.4 为什么用 ECharts 而不是直接生成图片

很多初学者会希望 Dify 直接返回一张饼状图图片。但“生成图片”在工程上成本更高，因为：

需要额外部署绘图环境。
大模型生成图片的成功率不稳定。
后续修改样式、交互不灵活。

ECharts 是前端图表库，它的配置是纯 JSON。Dify 生成 JSON，前端渲染 JSON，天然解耦。而且 ECharts 的饼状图配置结构清晰，很容易映射到“分类名 + 数值”的数据结构。这也是本文选择该方案的原因。

4. 完整实战：Dify 一键生成饼状图

4.1 整体流程设计

整个工作流从用户输入到前端展示，核心流程如下：

用户输入一段自然语言描述。
开始节点接收输入变量。
LLM 节点提取数据，输出固定 JSON 数组。
代码节点解析 JSON，并组装成 ECharts 饼状图 option。
结束节点返回 option 给前端。

这样设计的好处是“LLM 只负责理解数据，代码负责生成配置”，各节点职责单一。

4.2 创建工作流并配置开始节点

在 Dify 中创建“工作流”应用，命名为“饼状图生成助手”。

进入编排画布后，点击“开始”节点，添加输入变量：

变量名：input_data
类型：段落
描述：用户输入的数据描述，例如“各产品销量：A 产品 120，B 产品 80”

这里的变量名会在后续节点中被引用，例如{{input_data}}。

4.3 添加 LLM 节点并编写提示词

从左侧节点列表拖入一个“LLM”节点，连接到开始节点之后。LLM 节点的系统提示词（System Prompt）里，我们要明确告诉模型任务和输出格式。

下面是一份可以直接使用的提示词模板，可以根据自己的业务调整：

你是一个数据整理助手。用户会输入一段包含分类统计数据的描述，你需要提取出“分类名称”和“数值”，并输出 JSON 数组。 要求： 1. 只输出 JSON，不要输出任何解释文字。 2. JSON 格式为：[{"name": "分类名", "value": 数值}] 3. value 必须是数字，不要带单位。 4. 如果用户输入中没有明确数值，只保留明确的分类和数值。 示例输入： 一季度各品类销量：手机 100 台，电脑 80 台，耳机 30 台 示例输出： [{"name": "手机", "value": 100}, {"name": "电脑", "value": 80}, {"name": "耳机", "value": 30}] 用户输入： {{input_data}}

在 LLM 节点的用户提示词（User Prompt）区域填入上面模板，模型选择你要用的 LLM。尽量选择支持 JSON 输出稳定的模型，例如 GPT-4o、DeepSeek-V3 或者国内云厂商的通用模型。不同模型对“只输出 JSON”的遵循程度不同，如果遇到输出带解释文字的情况，可以通过代码节点做兼容。

4.4 添加代码节点生成 ECharts 配置

拖入一个“代码节点”，连接到 LLM 节点之后。代码节点的作用有两个：

处理 LLM 输出的字符串，提取 JSON 数组。
把数组映射为 ECharts 饼状图的 option。

由于 Dify 的代码节点通常以 Python 语法实现，下面给出一份通用代码示例：

import json def main(llm_output: str) -> dict: # 1. 清理 LLM 输出，去掉可能的 markdown 代码块标记 llm_output = llm_output.strip() if llm_output.startswith("```"): llm_output = llm_output.strip("`") # 去掉可能的 json 标记 if llm_output.startswith("json"): llm_output = llm_output[4:] llm_output = llm_output.strip() # 2. 尝试解析 JSON try: data = json.loads(llm_output) except json.JSONDecodeError: # 兼容模型输出前后有解释文字的情况，尝试截取第一个 [ 到最后一个 ] start = llm_output.find("[") end = llm_output.rfind("]") if start != -1 and end != -1: json_str = llm_output[start:end + 1] data = json.loads(json_str) else: raise ValueError("无法从 LLM 输出中解析出 JSON 数组") # 3. 数据结构校验与清洗 cleaned = [] for item in data: name = str(item.get("name", "")).strip() try: value = float(item.get("value", 0)) except (TypeError, ValueError): value = 0 if name: cleaned.append({"name": name, "value": value}) # 4. 构建 ECharts 饼状图 option option = { "title": { "text": "数据分布饼状图", "left": "center" }, "tooltip": { "trigger": "item", "formatter": "{b}: {c} ({d}%)" }, "legend": { "orient": "vertical", "left": "left" }, "series": [ { "name": "数据分布", "type": "pie", "radius": "60%", "data": cleaned, "emphasis": { "itemStyle": { "shadowBlur": 10, "shadowOffsetX": 0, "shadowColor": "rgba(0, 0, 0, 0.5)" } } } ] } return {"chart_option": option}

这份代码的核心思路是“容错解析 + 数据清洗 + 配置组装”。尤其要注意第 2 步：大模型输出经常会出现前后带解释文字、Markdown 代码块标记等情况，代码里做一层兜底解析，可以显著提高成功率。

4.5 配置结束节点

拖入“结束节点”，连接到代码节点之后。结束节点里添加一个输出变量，类型选择“JSON”，值为代码节点的输出变量chart_option，并命名为result。

这样工作流运行结束后，会直接返回一个 ECharts option JSON。

4.6 运行与验证

在工作流编辑页右上角点击“运行”，输入测试数据：

各产品线收入：企业服务 560 万，智能硬件 320 万，订阅制软件 180 万，技术咨询 90 万

运行结束之后，结束节点会输出类似下面的 JSON：

{ "result": { "title": { "text": "数据分布饼状图", "left": "center" }, "tooltip": { "trigger": "item", "formatter": "{b}: {c} ({d}%)" }, "legend": { "orient": "vertical", "left": "left" }, "series": [ { "name": "数据分布", "type": "pie", "radius": "60%", "data": [ {"name": "企业服务", "value": 560}, {"name": "智能硬件", "value": 320}, {"name": "订阅制软件", "value": 180}, {"name": "技术咨询", "value": 90} ] } ] } }

拿到这个 JSON，就等于拿到了饼状图的所有配置数据。接下来要做的就是把 JSON 交给前端渲染。

4.7 使用 WebApp 或 API 对接前端

Dify 工作流应用发布后，可以提供 API 调用地址。如果要集成到自己的系统里，可以使用 Dify 提供的 API 发送请求，请求体示例：

{ "inputs": { "input_data": "各产品线收入：企业服务 560 万，智能硬件 320 万，订阅制软件 180 万" }, "response_mode": "blocking", "user": "demo-user" }

接口地址在应用“访问 API”页面可以查看，需要在请求头中携带 API Key。拿到返回值后，前端用 ECharts 渲染即可。

下面是一个极简的 HTML 展示页面，用来验证效果。先把上面生成的 option 粘贴到chartOption变量里，用浏览器打开即可。

<!DOCTYPE html> <html lang="zh-CN"> <head> <meta charset="UTF-8"> <title>Pie Chart</title> <script src="https://cdn.jsdelivr.net/npm/echarts@5/dist/echarts.min.js"></script> </head> <body> <div id="chart" style="width: 800px; height: 500px;"></div> <script> const chart = echarts.init(document.getElementById('chart')); const chartOption = { "title": { "text": "数据分布饼状图", "left": "center" }, "tooltip": { "trigger": "item", "formatter": "{b}: {c} ({d}%)" }, "legend": { "orient": "vertical", "left": "left" }, "series": [{ "name": "数据分布", "type": "pie", "radius": "60%", "data": [ { "name": "企业服务", "value": 560 }, { "name": "智能硬件", "value": 320 }, { "name": "订阅制软件", "value": 180 } ] }] }; chart.setOption(chartOption); </script> </body> </html>

如果页面正常显示饼状图，就说明从 Dify 工作流生成的配置可以顺畅衔接前端渲染。实际项目里，前端只需要把 Dify API 返回的result字段直接传给chart.setOption()。

5. 常见问题与排查

5.1 LLM 输出不是合法 JSON

问题现象	常见原因	解决思路
代码节点报 JSONDecodeError	模型输出了解释文字、Markdown 代码块标记或多余引号	在代码节点中做字符串清理和首尾截取
输出字段缺失	提示词未明确字段名	在提示词中增加严格示例，并要求“不要添加额外字段”
value 含单位	提示词未强调数值类型	在提示词中明确“value 必须是数字，不要带单位”

排查时建议先在 LLM 节点单独运行，查看模型原始输出。只有先看原始输出，才能判断是提示词问题还是代码解析问题。

5.2 数据量太大超出模型上下文

如果用户输入的数据分类特别多，例如 50 个品类，大模型可能会遗漏部分分类，或者生成结果截断。这时有两种处理思路：

在进入 Dify 前，由业务系统先把数据聚合好，只传需要展示的分类。
提高模型的 max_tokens 上限，给足输出空间。
在前端对数据做二次兜底，例如按“其他”归类数量过小的分类。

从工程实践来说，推荐在业务层先做数据清洗，Dify 只承担格式转换，不要让它处理超大文本。

5.3 图表渲染空白

问题现象	常见原因	解决思路
页面空白	option 中 data 为空数组	检查代码节点中 cleaned 是否为空，确认 LLM 是否提取到数据
图例显示但无饼图	series.type 不是 pie	检查代码节点中的 type 字段
中文乱码	HTML 未设置 UTF-8	在 HTML head 中声明`<meta charset="UTF-8">`
ECharts 未加载	CDN 地址不可达	换成本地 echarts.min.js 文件

渲染空白大半是数据层问题，建议先在浏览器控制台打印一遍chartOption，再确认数据是否完整。

5.4 代码节点运行超时

Dify 的代码节点有执行时间限制，如果处理逻辑太复杂或者 JSON 字符串过大，可能超时。处理方式：

简化代码逻辑，不要在代码节点里做复杂循环计算。
把清洗逻辑尽量前置到业务系统。
如果必须处理大批量数据，考虑用 HTTP 请求节点把数据抛给自建服务处理。

6. 最佳实践与工程建议

6.1 提示词工程建议

生成图表配置的场景，提示词要追求“确定性”，不要追求“创造性”。建议做到：

让 LLM 只做数据提取，不做额外总结。
输出格式用 JSON Schema 描述清楚。
每次迭代修改提示词后，保留一份历史版本，方便对比效果。
在提示词中用“示例输入 → 示例输出”比长篇解释更有效。

可以建立一个提示词版本管理目录，把不同业务场景的提示词模板统一维护。后续如果发现模型效果不稳定，优先检查是不是提示词被改动了。

6.2 数据聚合与预处理

饼状图适合展示“分类占比”，不适合展示过于细碎的数据。如果原始数据有 100 个分类，建议先按业务规则聚合，例如只展示 Top 10，其余归为“其他”。这一步可以在上游业务系统完成，也可以在 Dify 代码节点里完成。

在代码节点里做聚合时，可以用下面的逻辑：

# 按 value 降序排序 cleaned.sort(key=lambda x: x["value"], reverse=True) # 只保留前 8 个 top = cleaned[:8] # 剩余归为其他 rest = cleaned[8:] other_value = sum(item["value"] for item in rest) if other_value > 0: top.append({"name": "其他", "value": round(other_value, 2)})

这样的好处是图表更清晰，也不会因为分类太多导致提示词截断。

6.3 安全性

在 Dify 应用中，如果允许用户自由输入数据描述，需要注意两类安全风险：

Prompt 注入：用户可能在输入中夹带“忽略之前的指令”等恶意内容，诱导模型输出异常结果。
资源消耗：恶意用户通过大量调用消耗 API 额度。

应对方式：

在业务层面对输入长度做限制。
对调用 API 的用户做身份认证和频率限制。
对 Dify 应用的 API Key 做最小权限隔离，不同业务使用不同 Key。
不要在前端暴露 Dify API Key，应通过后端转发请求。

6.4 异常兜底与降级方案

完全依赖大模型生成 JSON，在极端场景下仍可能失败。生产环境建议增加兜底逻辑：

如果 LLM 节点解析失败，尝试让模型重新生成一次。
如果重试仍然失败，返回一个固定的“数据解析失败”页面。
在接口层设置超时时间，避免前端长时间等待。
记录每次失败的原始输入和模型输出，用于持续优化提示词。

6.5 性能与成本优化

生成饼状图这类任务，对响应时间要求一般不高，但成本优化还是值得关注：

优先选择便宜的模型做数据提取任务，不需要用最强模型。
如果数据格式固定，可以在代码节点直接解析，跳过 LLM。
对相同输入做缓存，避免重复调用模型。
在低峰期提前生成一次配置，避免用户等待。

这些优化顺序从“减少不必要调用”到“控制模型成本”，工程上都能直接落地。

6.6 日志与监控

Dify 应用上线后，建议把每次调用的输入、输出、耗时、失败原因记录下来。日志字段可以参考：

时间戳 用户标识 输入数据 模型输出 最终 chart_option 是否成功 失败原因 耗时

有了这些日志，后续排查问题和优化提示词会有非常明确的方向。

7. 总结与学习路线

通过本文的实战，你应该已经掌握了 Dify 工作流的核心编排思路，也理解了“大模型生成结构化配置，前端负责渲染”的通用设计模式。整个过程可以概括为五步：Dify 接收输入、LLM 提取数据、代码节点清洗数据、组装 ECharts option、前端渲染饼状图。这套思路不仅适用于饼状图，也可以扩展到柱状图、折线图、仪表盘配置生成等场景。

如果想继续深入，建议从这几个方向入手：

熟悉 Dify 的更多节点类型，例如条件分支、知识库检索、HTTP 请求，尝试搭建更复杂的业务工作流。
深入学习 ECharts 的配置语法，了解不同图表类型对数据格式的要求。
研究提示词工程，特别是 Few-shot 示例和 JSON Schema 约束方法，提高大模型输出的稳定性。
尝试把 Dify 工作流集成到现有业务系统，通过 API 方式发布，并完善监控、限流和降级机制。

实际项目中，最值得优先关注的是“异常兜底”和“数据清洗”这两块。模型能力再强，也无法保证 100% 输出合法 JSON，代码节点里的容错解析是最后一道防线。把这层逻辑处理好，Dify 生成图表的整体体验会稳定很多。

你可以打开 Dify，创建一个工作流应用，按本文步骤先跑通基础版，再根据自己的业务调整提示词和图表样式。亲手试一遍之后，你会发现“用 AI 一键生成饼状图”并不是什么复杂的事。