dbt Charts：将仪表板引入代码，迎接 AI 时代

现代数据栈经历了一次显著的“解构”。从历史上看，商业智能工具是全栈平台，处理从数据摄入、转换到最终可视化的所有环节。如今，这些层级往往是分离的：计算由主要的云提供商处理，摄入由专用工具处理，而转换则由 dbt 等平台处理。这使得 BI 工具主要负责最终的展示层——即图表和交互界面。然而，随着 AI 智能体成为生成报告的主要接口，“编写”正逐渐取代“点击”成为首选。相比于导航复杂的、专有的传统 BI 软件用户界面，智能体在代码、SQL 和 Git 方面的熟练程度更高。

当用户今天要求 AI 智能体生成报告时，智能体往往会产生一堆杂乱的文件——包括 HTML、CSS、JavaScript 和各种图表库。这种代码的“混乱自由”使得人类难以审计结果，并迫使智能体在每次更改时消耗更多的时间和 Token。相反，传统的 BI 工具通过提供受管制的 UI 提供“狭窄的控制”，但它们将智能体限制在界面暴露的内容范围内。dbt Charts 提出了第三种选择：一种结构化的 YAML 语言，允许在单个可审计的文件中声明完整的交互式仪表板。在这个系统中，SQL 定义数据，而 YAML 定义视觉呈现，包括通过 Markdown 提供的文字说明和通过 Jinja 提供的变量。

dbt Charts 工作空间允许用户在统一环境中与仪表板和 AI 智能体进行交互。

通过将图表与数据模型放入同一个 Git 仓库中，dbt Charts 将可视化直接整合到开发生命周期中。这允许团队使用共享的 CI/CD 流水线，其中对数据模型及其对应图表的更改可以在单个分支中完成验证并发布。该系统包含一个 CLI，可将这些 YAML 文件渲染为 SVG、HTML 或 PDF 等各种格式。虽然 dbt Charts 为这些声明提供了语言，但开发人员还推出了一个托管平台，以处理 BI 中剩余的“无法解构”的方面，例如身份管理、托管以及针对非技术用户的权限管理。

开发人员推出了一个托管平台，用于处理非技术用户的身份管理、托管和权限。

这种方法的一个特定局限性是代码的自由度与 UI 的易用性之间的权衡。虽然 dbt Charts 使智能体更容易以代码形式构建仪表板，且人类更容易审计，但它仍需要托管环境或本地渲染设置，才能让这些仪表板供整个组织使用。此外，虽然该系统为图表提供了一套统一的设计语言，但与传统 BI 工具相比，在“Token 成本”或执行速度方面的具体性能差异，仍是随着工具向 1.0 版本成熟过程中需要进一步观察的领域。

最终，dbt Charts 寻求建立一个新的标准，即数据栈的仪表板层应像驱动它的数据转换一样受到版本控制且透明。通过在 SQL 和最终视觉效果之间提供声明式的桥梁，它旨在创建一个人类和 AI 可以共同协作进行数据展示的流程，而无需受到专有 UI 约束的摩擦或未管理代码产物的混乱影响。