dbt Charts：開源一個用於 AI 驅動儀表板的宣告式語言

dbt Charts 透過將儀表板移入程式碼，實現受控的 AI 生成分析

dbt Labs 已將 dbt Charts 開源，這是一種宣告式語言，專門用於使用結構化的 YAML 格式定義互動式儀表板。此方法解決了 AI 驅動資料分析中的一個關鍵摩擦點：雖然 AI 代理能輕鬆生成報告，但通常會產出一團零散的 HTML、CSS 和 JavaScript 檔案，難以審計、維護和版本控制。透過提供標準化、基於程式碼的規格，dbt Charts 讓代理能建立受控、易讀且整合至現有軟體開發生命週期的儀表板。

解耦 BI 堆疊

傳統的商業智慧（BI）工具歷史上是「全棧」的，處理從資料擷取與轉換到視覺化和身分管理的全部流程。所謂的「現代資料堆疊」（約 2015–2022 年）解耦了基礎設施層級，將運算移至雲端資料倉儲，轉換則交由 dbt 等工具處理。

根據 dbt Labs 的說法，這項解耦的最後一塊拼圖是視覺化層。雖然以 UI 為主的 BI 工具對人類來說效率高，但 AI 代理精通程式碼、SQL 和 Git，卻難以應付專有 UI。dbt Charts 將視覺化的「如何做」轉換為基於 YAML 的程式碼格式，同時保留 SQL 作為「做什麼」（資料）的語言。

技術架構與功能

宣告式 YAML 規格

dbt Charts 使用 YAML 語法在單一檔案中宣告完整的互動式儀表板。此檔案通常包含：

變數：UI 篩選器與參數。
查詢：資料的 SQL 定義。
圖表：圖表類型（例如面積圖、長條圖、圓環圖）、標題，以及 SQL 欄位與座標軸的對應關係。
欄位：圖表在畫布上的佈局排列。

渲染與可擴展性

dbt Charts CLI（dct）可將這些 YAML 畫布渲染為多種格式，包括靜態 SVG、HTML、PNG、PDF，甚至終端機。系統支援超過 1,100 種配置選項，涵蓋 16 種圖表類型，並支援「組合圖表」以呈現更複雜的視覺效果。為保持簡潔，語言採用層疊式樣式，圖表繼承畫布屬性，畫布則繼承全域主題。

與 dbt 專案整合

在 dbt 專案中使用時，dbt Charts 提供與轉換層的深度整合：

基於 Git 的版本控制：charts/ 目錄與 models/ 位於同一儲存庫中，確保資料模型與對應圖表的變更能於單一分支中交付，並透過 CI 進行驗證。
ref 函數：查詢可使用 ref() 參考 dbt 模型。若模型被重命名或欄位遺失，dct validate 命令將在 PR 合併前失敗，防止錯誤圖表進入生產環境。
語意層：未來將支援 dbt 語意層，讓畫布可使用預先定義的指標，而非原始 SQL。

為 AI 代理優化

dbt Charts 特別設計以提供 AI 代理緊密的反饋迴圈。由於輸出是嚴格的 YAML 與 SQL 規格，系統可自動進行驗證與視覺化檢查。例如，CLI 可警告代理，若長條圖的條帶過窄而無法適應可用像素寬度，或表格欄位超出其槽位，讓代理能在畫布渲染前自行修正佈局。

dbtCharts.com 平台

除了開源語言，dbt Labs 還推出了 dbtCharts.com 的公開測試版。此託管平台處理 BI 中難以解耦的剩餘「捆綁」部分：主機、存取控制與使用者權限。平台包含：

對話式分析：具備權限的唯讀存取權限的聊天介面，可存取資料倉儲。
視覺化編輯器：用於對 AI 生成的圖表進行最終的手動調整。
Git 同步：透過聊天或視覺化編輯器所做的任何變更，都會寫回 Git 儲存庫中的 YAML 檔案，防止廠商鎖定。

社群觀點與反對意見

此公告在資料工程師與開發者社群中引發討論，關於 YAML 規格的實用性與更靈活替代方案的比較。

支持此方法的論點

可審計性：使用者指出，這創造了「可讀、可維護且能一致重現相同儀表板的成果」，避免了 LLM 常產出的「感覺像 JS 混亂碼」。
對 AI 友好：語言的結構化特性讓代理更容易生成與驗證其工作，相比於在複雜 UI 中導航更為簡單。

批評觀點

「YAML 地獄」的擔憂：部分開發者強烈反對將 YAML 視為「語言」，認為條件判斷與變數繫結在資料格式中會變得過於複雜，遠不如 JavaScript 或 TypeScript 等實際程式語言。
創新 vs. 實作：部分批評者認為，解耦 BI 並非新概念，AI 只要指示得當，可生成任何格式（JSON、XML、YAML），因此 YAML 的選擇並未如宣傳般具創新性。
替代工具：社群成員指出現有的替代方案，如 Malloy、Observable Framework 和 Vega-Lite，這些工具提供了不同的「儀表板即程式碼」方法。
「苦澀的教訓」：一位評論者指出，隨著模型進步，它們將能從零開始撰寫原始程式庫，可能使專門的中間規格變得過時。