图表类型该让大模型选，还是用规则选？
简化版
两种做法都可行，取舍在可复现和灵活性之间。规则选：看结果的形态——只有一行出指标卡，有日期列出折线图，分类加数值出柱状图或饼图，两个数值列出散点图——同一份结果每次出同一张图，还省一次模型调用。模型选：能结合问题语义（「占比」「趋势」「对比」），处理规则想不到的情况，但结果不稳定、要花一次调用。无论哪种，模型最多只决定图表类型和字段映射，完整的图表配置由后端代码按真实数据生成，不能让模型直接写 ECharts 配置。
详细版
| 维度 | 规则选 | 模型选 |
|---|---|---|
| 可复现 | 同一份结果永远同一张图 | 同样的结果可能这次柱状、下次折线 |
| 成本 | 不调模型 | 每次一次调用 |
| 语义理解 | 只看数据形态 | 能理解「占比」「趋势」等用词 |
| 边界情况 | 规则没覆盖就退回表格 | 可能推荐不合适的图 |
| 可解释 | 规则写在代码里，一看就懂 | 需要模型给出理由 |
常用的形态规则：
结果只有 1 行 → 指标卡
有日期 / 时间列，行数不多 → 折线图
1 个分类列 + 数值列，类别不多 → 柱状图；强调占比且类别少 → 饼图
2 个数值列 → 散点图
其他 → 表格折中方案：规则优先，模型补充——规则能判定的直接出图，判定不了的再问模型；模型的推荐要校验字段是否真的存在于结果中。
完整版教学
一、图表推荐要回答哪几个问题
给一份查询结果配图，要决定四件事：
① 用什么图：折线、柱状、饼图、散点、指标卡、表格
② 横轴用哪个字段（分类或时间）
③ 纵轴用哪些字段（一个或多个指标）
④ 标题写什么前三件决定图表对不对，第四件是锦上添花。「谁来决定」的讨论主要集中在前三件上。
二、规则选：数据形态决定图表
规则的依据是结果集的形态，而不是问题的措辞：
| 结果形态 | 图表 | 理由 |
|---|---|---|
| 1 行若干数值 | 指标卡 | 单个数字画图没有意义 |
| 日期列 + 数值列，30 行以内 | 折线图 | 时间序列看趋势 |
| 分类列 + 数值列，20 类以内 | 柱状图 | 比较大小 |
| 分类列 + 数值列，6 类以内且看占比 | 饼图 | 类别太多饼图难以辨认 |
| 两个数值列 | 散点图 | 看两个指标的关系 |
| 以上都不满足 | 表格 | 宁可不画，也不画错 |
行数上限、类别上限这些阈值放在配置里，调整时不改代码。规则的最大优点是可复现：同一份结果今天和明天看到的是同一张图，截图进报告、做对比时不会出现「上次是柱状图，这次怎么变折线了」。
三、模型选：理解问题的语义
规则只看形态，有时会和用户的意图不符。比如结果是「分类 + 数值」，用户问的是「各渠道的销售额占比」，规则可能给柱状图，而用户想要的是饼图。模型能从问题里读出「占比」「趋势」「对比」这些意图，推荐更贴切的图。
模型选的代价：
不稳定：同一个问题、同一份结果，两次推荐可能不同
有成本：每次多一次模型调用
会越界：推荐一个结果里不存在的字段，或者对 50 个类别推荐饼图所以模型的推荐必须经过代码校验：字段必须存在于结果列中，类别数超过饼图上限就降级为柱状图。
四、为什么不能让模型直接生成图表配置
一个诱人的做法是让模型直接输出完整的 ECharts 配置 JSON。不建议这样做：
| 问题 | 说明 |
|---|---|
| 数据可能被改 | 模型可能在配置里自己填数据，数字和查询结果对不上 |
| 结构不稳定 | 配置项多、嵌套深，模型经常漏字段或写错层级，前端直接报错 |
| 难以统一风格 | 每次生成的颜色、图例、坐标轴样式都不一样 |
正确的分工：模型（或规则）只决定类型和字段映射，后端根据真实查询结果组装配置。数据来自查询结果本身，结构和样式由代码统一保证，模型只做它擅长的「判断」。
记忆钩子：图表的「数据」必须来自查询结果，模型只能决定「怎么画」，不能决定「画什么数」。
五、折中：规则优先，模型补充
实际系统里常用一种组合方式：
结果形态能被规则明确判定 → 直接按规则出图（大多数情况）
规则判定为「表格」或有歧义 → 调模型，带上问题和结果字段请它推荐
模型推荐 → 校验字段存在、类别数合理，不合格就退回表格这样大部分查询不花额外调用，图表稳定；少数边界情况借助模型的语义理解。
六、图和解读是两件事
图表是由查询结果「算」出来的，解读是模型在此基础上「讲」出来的，两者要解耦：解读生成失败，不应该让已经生成的图表消失；图表生成失败，也可以只展示表格和解读。页面上应该能分别看到「图表」「数据」「解读」三部分，某一部分失败时明确说明原因，而不是整块空白。同理，没有数据时显示空状态，而不是画一张全是 0 的图——「0」和「没有数据」是两回事。
七、图表推荐的结果要保存
推荐结果（图表类型、横轴字段、纵轴字段、标题）和最终生成的配置都要保存：一是切换页面、刷新之后能直接展示，不用重新推荐；二是多步分析生成报告时，可以直接复用每一步的图表配置，报告里的图和分析过程里看到的一致。查询结果变了，图表要随之作废重新生成。
八、常见误区与追问
- 误区：让模型直接输出完整的 ECharts 配置最省事。 模型可能在配置里自己编数据、漏写结构，数据必须来自查询结果，配置由代码组装。
- 误区：模型推荐的图一定比规则好。 模型不稳定、有成本，还可能推荐不存在的字段；多数情况下数据形态已经决定了合适的图。
- 误区：类别多也可以用饼图。 超过五六个类别的饼图很难辨认，应降级为柱状图，这类约束要写进规则或校验。
- 误区：图表失败了，解读也不要展示了。 图和解读是两层产物，要解耦展示，某一层失败只影响这一层。
- 误区：没有数据时画一张值为 0 的图。 0 和没有数据含义不同，应该显示空状态。
- 追问：怎么让图表推荐可复现？ 用基于数据形态的规则判定，阈值放配置；必须用模型时固定低温度，并保存推荐结果不重复生成。
- 追问：模型推荐的字段在结果里不存在怎么办？ 代码校验字段，不存在就退回规则判定或直接展示表格。
九、加强记忆
图表该由谁选，取舍在可复现与灵活之间：规则看数据形态，一行指标卡、有日期折线、分类加数值柱状或饼图、两数值散点、其余表格，同一份结果永远同一张图还省调用；模型能读懂占比、趋势等语义，但不稳定、有成本、会越界，推荐要经代码校验。不管谁选，模型只决定类型和字段映射，配置由后端按真实数据组装，绝不让模型写数据。常用折中是规则优先、模型补充。图和解读解耦，失败各自说明，没数据显示空状态；推荐结果要保存，报告直接复用。
项目实战落地
项目里怎么做的
《AI Agent数据分析平台》采用「模型选类型、后端生成配置」的做法：
- 模型只推荐四样东西：「图表推荐」模板把用户问题
{userQuestion}和结果字段{resultFields}交给模型，要求只返回包含chartType、xField、yFields、title的 JSON； - 后端组装 ECharts 配置：
buildChartConfig根据推荐结果和真实查询结果生成配置——推荐饼图就生成饼图配置；否则先用xField构建横轴分类数据，再按yFields生成一个或多个系列，推荐折线图时用折线，其余默认柱状图；模型没给标题时使用「数据图表」； - 兼容模型的不同返回格式：
yFields可能是数组也可能是字符串，统一解析成数组； - 保存与复用：图表类型、标题、坐标字段、完整配置和模型原始响应都写进分析记录，前端拿到
chart_config直接交给 ECharts 渲染；Agent 生成的分析报告也直接复用各步骤保存的图表配置，并过滤掉没有数据的空图表。
为什么这样取舍
- 模型负责判断，代码负责数据和结构：配置里的数据全部来自查询结果，结构由后端统一生成，前端拿到就能渲染。
- 图表是某一次 SQL 结果的下游产物：重新生成 SQL、纠错或重新执行时，旧的图表字段和配置会被清空，必须基于新结果重新推荐。
面试官还会追问
- 用户手动切换到「推荐图表」标签页时，图表为什么需要重新渲染一次？
- 离开页面或切换报告时，为什么要先释放旧的 ECharts 实例？
学完《AI Agent数据分析平台》，上面这些追问你都会迎刃而解。