我们正在开源 dbt Charts，一种用于仪表板的声明式语言，这样即使是你通过与智能体聊天构建的仪表板也能受到治理。面向数据的 AI 已经到来，长期承诺的自助式分析终于成为现实。任何拥有数据连接的人都能在一个下午内通过聊天生成一份报告，而最初的成果令人印象深刻。然而，摩擦很快就显现出来。默认情况下，智能体会把一份简单的报告变成一堆文件：HTML、CSS 和 Java Script、几个图表库，以及一旦需要上线就得有的 React 或 Streamlit 应用。要将结果追溯到其来源，就意味着要穿越多种语言和文件，这对人工审计来说很慢，而且每次更改都会耗费智能体的时间和 token。BI 工具则走了另一条路，把 copilot 硬塞进它们以 UI 为先的应用中。这能让 AI 保持在受治理的轨道上，但轨道很窄：智能体只能做 UI 所暴露的事情。所以今天你要在代码的混乱自由与 BI 工具的狭窄控制之间做选择。我们构建了第三种选择：想直接看结论就跳过，或者继续阅读了解 BI 是如何走到这一步的。解绑 BI 正如 dbt Labs 创始人 Tristan Handy 最近在《BI 的第二次解绑》中所写：当我刚进入数据领域时，BI 工具是全栈的。一切都在一个产品内完成：数据摄取、转换、计算、缓存、语义、可视化、身份。BI 工具就是数据栈。Micro Strategy、Cognos 等等：它们不只是可视化工具，它们是集成的数据平台。然后现代数据栈出现了。从大约 2015 年到 2022 年，那个 BI 捆绑包中的基础设施层被抽离出来，变成了专门构建的基础设施。计算去了 Big 5。摄取去了 Fivetran。转换去了 dbt。BI 工具则只剩下：可视化、交互式分析界面、语义定义（有时！）、身份与访问管理，以及 Web 托管。数据仓库 Big 5 ELT 抽取 加载 转换 BI 其他一切 那次解绑所留下的，就是我们今天所知的 BI 工具，而图表是其中最大的一块。它们留在 UI 中是有充分理由的：对大多数人来说，点击比写 YAML 更快。但越来越多的图表将不再由人制作。随着一切的前端和用户日益变成聊天智能体，这种偏好发生了翻转。智能体精通代码、SQL 和 Git，却在别人的 UI 中笨手笨脚。所以图表需要转移到智能体工作的地方：进入代码。今天我们迈出解绑 BI 的下一步：我们正在开源 dbt Charts，它把图表从 BI 工具中拿出来，放进代码里，具体来说是一种新的结构化 YAML 语言，可以在一个可审计的 YAML 文件中声明完整的交互式仪表板。与智能体自由聊天，它生成的东西既有代码的自由，又保持易于阅读。数据仓库 Big 5 ELT 抽取 加载 转换 新 C 图表 BI 一些零碎部分 在 dbt Charts 中，SQL 仍然是声明你想看到什么数据的语言，而我们用 YAML 将其包裹起来，以声明你想如何看到它。我们花了很长时间将这门语言提炼为几个核心的、可扩展的元素：在表达能力上深入，在组织和阅读上简单。YAML 包裹的不只是 SQL。Markdown 承载散文，而 Jinja，如同在 dbt 中一样，承载变量和宏。这里有一个小例子：一个变量（一个 UI 过滤器）、一个查询和一个图表。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 可以将任何看板文件渲染为静态 SVG，或渲染为 HTML、PNG、PDF，甚至终端，在你的笔记本电脑上或 CI 中都可以，并将一个文件夹中的看板文件作为站点提供服务：dct render charts/documents.yml --format svg # 或 html、png、pdf、terminal dct serve 这几个元素可以深入扩展：如今已有超过 1,100 个配置选项……