datasette-agent-charts 0.1a2：AI 画图之后，先把 SQL 亮出来

一个 AI agent 自动画出图表，已经不稀奇。真正要紧的是：图画完以后，它愿不愿意把背后的 SQL 给你看。

Simon Willison 在 2026 年 5 月 21 日发布了 datasette-agent-charts 0.1a2。版本号很小，还是 alpha；改动也很窄：在渲染后的 Observable Plot 图表下方，加一个“View SQL query”按钮。

别把它看成大版本发布。它更像一颗小螺丝，拧在 AI 数据工具最容易松动的位置：结果可不可信，得能查。

这次到底改了什么

datasette-agent-charts 的位置很清楚：它不是通用 BI 平台，也不是面向所有办公用户的仪表盘产品。它更接近开发者和数据从业者用来探索数据的轻量工具。

这类流程通常是：用户提问，agent 生成查询，再把结果画成图。问题也在这里。图表天然有说服力。柱状图、折线图一出来，人很容易先信一半。

但数据分析里，最麻烦的往往不是图丑。是图看起来很对，SQL 却选错了字段、漏了过滤条件，或者把聚合口径写歪了。

所以这个按钮的实际价值很具体：开发者可以点开 SQL，看 agent 到底怎么查；分析者可以在引用图表前，先检查 WHERE、GROUP BY、字段名和聚合方式。

它不能解决所有 AI 幻觉。也不能替你判断指标口径是否合理。它只是把复查从“猜它怎么做”变成“看它怎么做”。

这一步不华丽，但有用。

自动画图卖的是快，查看 SQL 买的是信任

我不太买账那种只强调“AI 秒出图表”的叙事。

快当然重要。探索数据时，少写几行代码、少配几次图表，体验会好很多。尤其是面对陌生数据表，先让 agent 画一张图，确实能帮人快速找方向。

可一旦这张图要进入真实工作流，事情就变了。你要拿它写分析、做汇报、改产品策略，或者给别人解释一个趋势。此时最重要的不是图表好不好看，而是它能不能被追问。

这就是“View SQL query”比多一种图表样式更关键的地方。

图表样式提升的是观感。SQL 暴露提升的是可审计性。前者让 demo 更顺，后者让工具更可能进入工作流。

对开发者来说，这意味着可以把 agent 生成的 SQL 复制出来、改掉、保存，甚至放进后续脚本。对数据分析者来说，至少可以在分享图表前做一次基本校验：表用对了吗，条件漏了吗，聚合有没有把人带偏。

现实限制也要说清楚。

很多用户不懂 SQL。懂 SQL 的人也不一定每次都点开看。更深的错误可能藏在数据新鲜度、业务定义、表结构理解里。一个按钮不可能把这些问题全兜住。

但工具设计常常就差这一层台阶。门槛低一点，复查就多一点；复查多一点，信任就不必全靠祈祷。

接下来要看它能不能把过程继续摊开

这次更新小，不能拔高成行业转折。但它至少说明一个方向：AI 数据工具要从玩具走向工具，不能只展示答案，还得暴露过程。

可查看 SQL 只是第一层。

接下来最该看的变量有两个：

• 生成图表时，SQL 和图表映射是否能稳定对应。用户点开 SQL 后，能不能清楚知道这张图每个轴、每个分组来自哪里。
• Datasette Agent 后续是否继续暴露中间步骤。比如字段选择、过滤条件、图表类型选择，能不能被用户理解和修正。

如果只给一段 SQL，但图表映射仍然模糊，审计能力还是有限。用户知道它查了什么，却未必知道它为什么这么画。

这也是很多 AI 数据产品绕不过去的坎：产品想把复杂性藏起来，数据工作却要求复杂性可追踪。

历史上也有类似分岔。电子表格赢在上手快，数据库赢在可追踪、可复用、可治理。两者不完全一样，但今天的 AI 数据 agent 正在重复这个张力：越想降低门槛，越容易变成黑箱；越想进入严肃场景，越要把底层动作交出来。

《史记》里那句“天下熙熙，皆为利来”放到工具市场也合适。厂商喜欢卖效率，因为效率好展示；用户真正要留下来，靠的是出了问题能追责、能修正、能复现。

datasette-agent-charts 0.1a2 没有承诺这些都做到。它只是加了一个看 SQL 的按钮。

但这个按钮选的位置对。AI 帮你画图时，最该先问的不是“图漂亮吗”，而是“它到底查了哪张表、用了什么条件”。

能回答这个问题，才有资格谈信任。