Metabase 參數儀表板開發

應用 AI agent 的小技巧

最近在幫客戶開發 Metabase 的參數化儀表板（parameterized dashboard）時，我發現了一個有趣的開發模式。

什麼是參數化儀表板?

參數化儀表板就是那種「讓使用者自己選日期範圍、類別、地區」的互動式報表。比方說，業務主管想看「2024 年第一季，電子產品類別，在台北地區的銷售趨勢」，他就在儀表板上選擇這些參數，圖表就即時更新。

聽起來很簡單，但實作起來有些眉角:

• SQL query 要處理可選參數(有些參數可能不填)

• 參數之間可能有相依性(選了某個類別，子類別的選項要跟著變)

• Query 效能要顧好(使用者不會想等 30 秒)

AI 的標準答案

我問了 AI：「如何透過 AI 開發 Metabase 參數化儀表板?」

AI 給了很典型的回答:

1. 需求討論階段：描述儀表板目的、目標使用者、關鍵指標

2. Query 生成：AI 產生 SQL，你在 Metabase 的 SQL editor 裡測試

3. 參數設定：AI 建議用什麼類型的參數(下拉選單、日期選擇器、輸入框)

4. 除錯：遇到問題時把錯誤訊息丟給 AI

這個流程本身沒錯，但有個實務上的很不方便：人要在 Metabase UI 和 AI 之間不斷 copy and paste。

• 把 AI 生成的 SQL 貼到 Metabase

• 測試失敗，把錯誤訊息複製回去給 AI

• AI 修正後，再貼回 Metabase

• 重複以上步驟

如果是簡單的 query，這樣做還好。但參數化儀表板的 SQL 通常不簡單，可能有多層邏輯、多個可選參數、複雜的 JOIN。還有，最麻煩的還是要複製查詢出來的報表，每次修改都要手動 copy and paste，我乾脆自己動腦想，搞不好還勝過反覆 copy and paste 的時間。

引入 DuckDB 的快速驗證

我想了想，決定換個做法:先在 DuckDB 裡驗證邏輯，再轉到 Metabase。

DuckDB 有個很棒的特性：它的 view 可以引用 session variable。這意味著我可以在本地建立「參數化的 view」，快速驗證邏輯是否正確。

工作流程變成這樣:

-- 1. 設定測試參數
SET VARIABLE start_date = '2024-01-01';
SET VARIABLE category = 'electronics';

-- 2. 建立參數化 view
CREATE VIEW sales_summary AS
SELECT 
  order_date，
  SUM(total) as revenue
FROM orders
WHERE created_at >= getvariable('start_date')
  AND category = getvariable('category')
GROUP BY order_date;

-- 3. 立即測試
SELECT * FROM sales_summary;

改成這個流程後，得到的改變是:

快速迭代：人不用在 Metabase UI 點來點去，AI 直接透過終端機操作 DuckDB。改一行測一次，幾秒鐘就知道結果。

輔助驗証：原始資料、「參數化的 view」、還有預期會長成的結果的 Excel 資料，我也把它一併放進了 DuckDB 。直接叫 AI 幫我驗証。

從 DuckDB 到 Metabase

當然，最後還是要轉回 Metabase。DuckDB 和 Metabase 的參數語法不太一樣:

-- DuckDB
WHERE created_at >= getvariable('start_date')

-- Metabase
WHERE created_at >= {{start_date}}

-- 或者用 optional parameter
[[WHERE created_at >= {{start_date}}]]

我甚至寫了個簡單的 Babashka Script 來自動化這個轉換：

(defn duck->metabase [sql]
  (-> sql
      (str/replace #"getvariable\('(\w+)'\)" "{{$1}}")
      ;; 其他轉換規則...
      ))

這樣一來，整個開發流程就變得很順暢:

1. 在 DuckDB 裡快速驗證邏輯(與 AI 協作)

2. 確認無誤後，用腳本轉換語法

3. 貼到 Metabase，微調 UI 細節

Process Knowledge 再現

這個經驗讓我又看到一次「人負責 process,AI 負責 content」的模式。

AI 提供了什麼 content?

• SQL 語法細節

• Metabase 參數的用法

• 常見的效能優化技巧

但整個開發流程的設計，卻是我自己決定的:

• 我判斷「copy and paste 來回太麻煩」

• 我知道 DuckDB 有 session variable 這個特性

• 我設計了「先在本地驗證，再轉到 Metabase」的流程

• 我決定寫腳本自動化語法轉換

這些都是 process knowledge。AI 可以告訴我「Metabase 怎麼用」，但它不會主動建議「你應該先用 DuckDB 驗證」。因為這個判斷需要:

• 對工具生態的了解 => 知道 DuckDB 存在且適合這個情境

• 對開發的敏感度 => 察覺 copy and paste 會是瓶頸

• 對整體流程的掌控 => 知道什麼時候該引入新工具

這些流程知識是從真實的開發經驗中累積出來的。而「什麼情況該用什麼流程」的直覺，很多時候我也是狀況來了，直覺才冒出來。