为对话而生的图表：dbt Charts 开源
文章摘要
dbt Labs 在 2026 年 9 月 14 日宣布开源 dbt Charts——一套用 YAML 声明式描述仪表盘的语言，配套的托管平台 dbtCharts.com 同时进入公测。作者 Dave Fowler 是 Chartio 的创始人（该公司 2010 年 YC 出身，后被 Atlassian 收购为 Atlassian Analytics）。
文章的出发点是一个当下很现实的矛盾。AI 让「自助式分析」真的落地了：任何人接上数据源，跟代理聊一下午就能生成一份报表。但摩擦很快显现——代理默认会把一份简单报表膨胀成一堆文件：HTML、CSS、JavaScript，两个图表库，一旦要上线还得配个 React 或 Streamlit 应用。要把某个数字追溯回它的来源，得跨好几种语言和文件翻，人审计起来慢，代理每次改动都要烧掉大量 token。另一条路是传统 BI 工具外挂一个 copilot，好处是代理跑在受管控的轨道上，但轨道很窄——UI 没暴露的能力代理就做不了。作者认为今天你只能在「代码的混乱自由」和「BI 工具的狭窄管控」之间二选一。
dbt Charts 是提出的第三条路。文章引用 dbt Labs 创始人 Tristan Handy 的「BI 的第二次解绑」：早年 BI 工具是全栈的，摄取、转换、计算、缓存、语义、可视化、身份全在一个产品里；2015 到 2022 年，现代数据栈把基础设施层一层层拆走——计算归了几大云仓、摄取归了 Fivetran、转换归了 dbt，BI 工具剩下的主要就是可视化、交互界面、语义定义、权限和托管。而图表之所以一直留在 UI 里，是因为对人来说点鼠标比写 YAML 快。但当越来越多的图表不再由人来做、而是由聊天代理来做时，这个偏好就反转了：代理精通代码、SQL 和 Git，反倒在别人的 UI 里笨手笨脚。
具体设计上，SQL 继续负责声明「要看什么数据」，YAML 负责声明「怎么看」，Markdown 承载文字，Jinja（和 dbt 里一样）承载变量与宏。一个完整的看板就是一个 YAML 文件，结构大致是：
variables:
status:
column: main.documents.status
queries:
doc_growth: |
SELECT DATE_TRUNC('month', created_at) AS month,
SUM(COUNT(*)) OVER (ORDER BY month) AS num_docs
FROM main.documents
WHERE {{ filter('status', status) }}
GROUP BY 1
charts:
growth:
title: Documents created, all time
type: area
query: doc_growth
x: month
y: num_docs
rows:
- growth
CLI 工具 dct 可以把任意看板文件渲染成 SVG、HTML、PNG、PDF，甚至直接输出到终端，既能在笔记本上跑也能在 CI 里跑，dct serve 则把一整个目录当站点服务。核心元素不多但很深：目前有 1100 多个配置项、16 种图表类型以及由它们组合出的复合图表。样式采用级联继承——图表继承看板、看板继承主题，换主题只需一行；看板之间还能用 extends: 继承，所以企业统一风格写一次就能到处复用。
与 dbt 的深度集成是另一个卖点：charts/ 目录和 models/ 并排放在同一个 Git 仓库，模型和图表的改动走同一个分支、同一次 CI，问题在进生产前就暴露。查询通过 ref() 引用模型，从 manifest 解析，所以改名模型或缺列会让那个 PR 直接挂掉，而不是等到 dbt run 重建仓库之后才发现。对语义层的支持已在计划中。
针对代理，作者强调「紧反馈回路」：YAML 和 SQL 都会被严格校验，还有一整套可视化检查，比如「640px 里塞了 182 个柱子 × 2 个系列，建议汇总到更粗的粒度」「表格需要 980px 但只有 640px 可用」这类带修复建议的告警。
视觉设计上，团队请来了数据图形设计师、作家兼历史研究者 RJ Andrews 来设计图表，理念是回到仪表盘时代之前——人们还在用心手绘图表的那个年代——而不是再做一套卡片堆砌的仪表盘网格。
语言部分采用 Apache 2.0 许可，可以完全本地使用、无需注册账号。托管平台负责剩下那些「按本性就不该被解绑」的部分：托管、权限、UI，外加对话式分析、可视化编辑器、版本历史和分享。所有改动——无论来自聊天、可视化编辑器还是代码——最终都落回 Git 仓库里的同一份 YAML。
HN 评论精华
这条提交拿到 303 分、89 条评论，作者 thingsilearned（Dave Fowler）和团队成员 data_ders、mollifier14、oconnore 全程在场回复，讨论质量相当高。
「YAML 不是编程语言」
火力最集中的批评来自 carterschonwald：「跟我念一遍：YAML 不是编程语言。」他很失望所谓的 DSL 只是 YAML——条件判断和变量绑定一旦进了 YAML 就会变成战争罪行，「你都有 LLM 了，做得更好一点」。他还补了一段实战经验：去年他有客户在评估一个基于 YAML 的 OLAP 工具，踩到不少坑；另外把数据关联关系藏在图表层之外，会导致一组共享数据的图在坐标轴不同时拿不到正确的关联，逼着人为一个本该随手画的图做一大堆 ETL。
作者的回应被公认为全场态度最好的一段：他承认「语言」这个词用得不准，「我老忘了 YAML 的全称就是 YAML Ain’t Markup Language」，并把定位改述为「看板界的 HTML，而不是编程语言」。他强调缺乏灵活性在这里是特性而非缺陷：如果图表层不能变换数据，逻辑就只能留在 SQL 里，而 SQL 可以版本化、测试和审计——这正是「这个数字从哪来」这个问题的解法。他还提到受众考量：数据社区本来每天就在写 SQL、Jinja 和 YAML，没有新语言要学。
carterschonwald 进一步提出了一个很本质的论点：LLM 之所以会写代码，靠的是「写代码 → 拿到编译/运行错误 → 修 → 迭代」这个海量 RL 循环；数据格式没有这个反馈回路，所以模型会更快跑偏，或者需要烧掉多得多的上下文。作者回应说 dct validate <file.yml> 会对语法和 SQL 问题快速报错，不是个开放 schema。对方追问「那错误信息的质量比得上一个像样的编译器吗」，并称赞作者接受批评的成熟度。
跟已有工具有什么区别
这是评论区第二大主题，被反复追问。engrav3er40 问它和 vega-lite 的关系，mollifier14 回答说底层用的就是 vega-lite：vega-lite 是给静态数据装配单张图的工具箱，dbt Charts 在其上加了一整层——可重复执行的 SQL 查询构成的看板，外加大量有主见的样式设计。谈到「统一图表规范」的理想，他认为那需要既简单又极度通用，而这个组合目前恐怕还不存在。
crabmusket 提到了 GGSQL（同样输出 vega-lite JSON），data_ders 的回答最有信息量：vega-lite、ggsql、ggplot2 都是为单张图设计的，facet_wrap() 生成的一系列图本质上仍是一张图；BI 看板必需但它们没有的是 KPI、文本框、下拉筛选、数据源、治理，以及图表在页面上如何排布、彼此如何关联。团队计划未来几个月发布一个 JSON schema，让它对看板的意义相当于 vega-lite 对单张图的意义。
关于 Observable Framework 的对比，jerdthenerd 给出了一个有意思的角度：你并不想给 LLM 客户端一个代码执行环境，而 dbt Charts 会校验整份 YAML 包括发往数据源的 SQL，所以它可以充当 MCP App 的渲染层——动态定义和渲染可视化，却不用去操心沙箱化 JS 运行时。
这有多新？
dgudkov 泼了盆冷水：BI 早就被解绑了，人们已经在用 AI 生成 Excel 和 Power BI 报表，YAML / XML / JSON 都无所谓，AI 你让它生成什么它就生成什么。他预测「等你走完功能膨胀那一遭，你的 YAML 格式也会变得很复杂」，并贴出微软给 Power BI 的 skills 文件作为对照。mollifier14 反驳的角度是产物的可复用性：AI 当然能生成任何东西，但如果那份 YAML 你唯一能做的事就是丢回给代理说「照这个画张图」，那第二次的结果会和第一次差得很远。
ramesh31 则搬出了「苦涩的教训」：人人都想搞一套统一的生成式 UI 规范，但模型会越来越快、越来越少出错地用原始库一次写成，那种灵活性会让这类努力白费。作者回应说这是个刻意限定在仪表盘领域的规范，并承认原始 HTML/SVG 路线可能最终胜出，但那会让人类几乎无法跟进和核验数字的来源；他还认为即便未来 AI 全权验证，DSL 依然能保持一致性、降低维护成本并省下大量 token。
要不要可视化这件事本身
评论区最出人意料的一条来自 pizzafeelsright：他质疑可视化的必要性，认为图表就像数学课上的「写出演算过程」，是一种强加的联觉；火箭要么安全着陆要么没有，绿灯红灯本身就是数据图的抽象，真正重要的是上下文——「着陆速度必须小于 0.2 m/s」，把数据灌进这个条件过滤器即可。
作者说自己在数据行业做了 15 年，第一次听到这个论点，并表示很喜欢；他引用南丁格尔的说法作答——可视化的目的是「通过眼睛去影响那些对文字充耳不闻的公众」。IanCal 的反驳最有力：眼睛是接到大脑上的巨大带宽通道；而且「坠毁 vs 着陆」这一个比特的信息量，对于下次修好它毫无帮助——是否有突然加速？有没有顿挫？加速度计是不是同时跳了一下？hobofan 补充说不是每个数据点都对应一个二元决策，季度营收差 1% 和差 50% 完全不同，趋势更是难以压缩成二元标记。venzaspa 给了个更犬儒的答案：我老板们就是喜欢图表，管它是干什么用的，我在做的工具里到处塞图就是为了让他们高兴。
另外，nzoschke 实测了 GitHub 上的仓库，称聊天/代理体验相当好，一句话「给我的招聘收件箱做个看板」生成的一次性仪表盘「好得出人意料」。zahlman 则代表所有非数据背景的程序员问了句「什么是 BI，什么是仪表盘，我为什么要它」，bryanrasmussen 和 data_ders 给了很耐心的科普——后者顺带讲了自己 2020 年被 dbt 吸引的原因：相比软件工程团队，分析团队的工具太落后了，至今很多 BI 团队仍在点鼠标的界面里工作，没有版本控制、测试和部署环境，「分析师能为看板改动提 PR」这件事在今天都还算稀罕。