用 Cursor Agent + Metabase MCP 解決行銷人員的「改來改去」問題

背景：數據人員的痛點

在許多公司中，推播系統的運作流程是這樣的：

行銷人員決定推送名單的邏輯（例如：「最近 30 天有購買行為的用戶」）
數據人員透過 Metabase 將這些邏輯聚合成表單
系統根據 Metabase 表單的數據發送推播

這個流程看似合理，但在實際運作中卻有一個常見的問題：行銷人員的需求經常變動。

今天要「最近 30 天有購買的用戶」，明天改成「最近 14 天有購買且金額超過 1000 的用戶」，後天又變成「最近 7 天有購買但沒有退貨的用戶」。

數據人員每次都要：

理解行銷人員的需求
在 Metabase 中建立或修改查詢
驗證結果是否正確
處理各種邊緣情況

結果就是：數據人員被行銷人員的「改來改去」搞得疲於奔命。

傳統解決方案的兩難

當數據人員提出「能不能寫一個介面讓行銷人員自己調整」時，技術端面臨一個經典的兩難：

方案 A：簡單介面，功能受限

✅ 行銷人員容易學會
❌ 功能受限，還是要改來改去
❌ 無法應付複雜的查詢需求

方案 B：高度彈性的介面

✅ 功能強大，可以應付各種需求
❌ 複雜度高，行銷人員學不會
❌ 開發成本高，維護困難

這就是彈性與易用性的經典矛盾。

我們的解決方案：Cursor Agent + Metabase MCP

經過思考，我們找到了一個平衡點：使用 Cursor Agent 配合 Metabase MCP Server。

核心概念

自然語言輸入：行銷人員用自然語言描述需求
AI 理解與轉換：Cursor Agent 理解需求並轉換為 Metabase 查詢
直接操作 Metabase：透過 Metabase MCP 直接建立或修改查詢
權限完全掌控：API KEY 由技術端管理，行銷人員無法直接存取

技術架構

行銷人員
  ↓ (自然語言)
Cursor Agent
  ↓ (理解需求，生成查詢)
Metabase MCP Server
  ↓ (API 調用)
Metabase
  ↓ (執行查詢，產出名單)
推送系統

Metabase MCP Server 配置

首先，我們需要在 Cursor 中配置 Metabase MCP Server。這個方案使用的是 @easecloudio/mcp-metabase-server，一個提供 70+ 工具的 Metabase MCP Server。

在 mcp.json 中加入以下配置：

{
  "mcpServers": {
    "metabase-server": {
      "command": "npx",
      "args": ["@easecloudio/mcp-metabase-server"],
      "env": {
        "METABASE_URL": "http://your-metabase-url:3000/",
        "METABASE_API_KEY": "your-api-key-here"
      }
    }
  }
}

關鍵點：

METABASE_URL：你的 Metabase 實例地址
METABASE_API_KEY：由技術端管理的 API KEY
行銷人員無法直接看到或修改這些配置

實際使用場景

場景 1：建立新的推送名單

行銷人員輸入：

「幫我建立一個名單，包含最近 30 天有購買行為，且購買金額超過 1000 元的用戶，最多 5000 人」

Cursor Agent 執行：

理解需求：時間範圍（30 天）、條件（購買金額 > 1000）、限制（最多 5000 人）
透過 Metabase MCP 查詢相關表結構
建立 Metabase 查詢（Card）
執行查詢並產出名單
將名單保存到 Metabase 的指定表

結果：

行銷人員用自然語言就完成了複雜的查詢建立
數據人員不需要介入
API KEY 權限完全由技術端掌控

場景 2：修改現有名單

行銷人員輸入：

「把昨天的推送名單改成最近 14 天，其他條件不變」

Cursor Agent 執行：

找到昨天的推送名單（透過 Metabase MCP 查詢）
理解「其他條件不變」的語義
修改查詢中的時間範圍
更新 Metabase 中的查詢
重新執行並產出新的名單

場景 3：複雜的多條件查詢

行銷人員輸入：

「我要最近 7 天有購買，但沒有退貨記錄，且不在黑名單中的用戶，按購買金額降序排列，取前 3000 名」

Cursor Agent 執行：

解析多個條件：時間、購買行為、退貨排除、黑名單排除、排序、限制
透過 Metabase MCP 查詢相關表的關聯關係
建立複雜的 JOIN 查詢
執行並驗證結果
產出名單並保存

優勢分析

1. 解決彈性與易用性的矛盾

自然語言：行銷人員不需要學習複雜的查詢語法
高度彈性：AI 可以理解各種複雜的需求描述
即時反饋：可以立即看到查詢結果，快速調整

2. 權限完全掌控

API KEY 管理：由技術端統一管理，行銷人員無法直接存取
操作記錄：所有操作都透過 Cursor Agent，可以記錄和審計
安全可控：技術端可以隨時調整權限範圍

3. 降低溝通成本

減少來回確認：行銷人員可以直接描述需求，不需要反覆溝通
即時調整：發現問題可以立即修改，不需要等待數據人員
學習成本低：行銷人員只需要會用自然語言描述需求

4. 釋放數據人員時間

專注高價值工作：數據人員可以專注於數據分析、建模等高價值工作
減少重複勞動：不需要反覆建立和修改簡單的查詢
提升整體效率：整個團隊的效率都得到提升

技術實現細節

Metabase MCP Server 的主要功能

Metabase MCP Server（GitHub 倉庫）提供了豐富的功能，包括：

查詢執行：執行 SQL 查詢或 MBQL 查詢
Card 管理：建立、更新、刪除查詢卡片
Dashboard 管理：管理儀表板
數據庫結構查詢：查詢表結構、欄位信息等
結果導出：將查詢結果導出為各種格式

Cursor Agent 的工作流程

需求理解：使用 LLM 理解行銷人員的自然語言需求
查詢生成：根據需求生成 Metabase 查詢
結構查詢：先查詢相關表的結構，確保查詢正確
執行驗證：執行查詢並驗證結果
結果保存：將結果保存到指定的表或 Card

錯誤處理

語義理解錯誤：如果 AI 理解錯誤，行銷人員可以重新描述
查詢錯誤：如果查詢有問題，AI 會根據錯誤訊息調整
權限錯誤：如果權限不足，會明確提示需要技術端協助

實際效果

使用前

行銷人員提出需求 → 數據人員理解（可能理解錯誤）→ 建立查詢 → 行銷人員驗證 → 發現問題 → 再次修改 → ...
平均每個需求需要 2-3 次來回
數據人員每天處理 10+ 個類似需求

使用後

行銷人員直接描述需求 → Cursor Agent 執行 → 立即看到結果 → 如有問題直接調整
大部分需求一次完成
數據人員可以專注於更複雜的分析工作

注意事項

1. API KEY 安全

不要將 API KEY 寫在文章中或公開場所
使用環境變數或安全的配置管理系統
定期輪換 API KEY

2. 權限範圍控制

建議建立專門的 Metabase 用戶，只給予必要的權限
限制可以操作的數據庫和表
避免給予刪除或修改核心數據的權限

3. 查詢驗證

對於重要的推送名單，建議加入人工審核流程
可以設定查詢結果的合理性檢查（例如：人數不能超過某個上限）
記錄所有操作，方便回溯和審計

4. 培訓與文檔

雖然使用自然語言，但還是需要培訓行銷人員如何更好地描述需求
提供常見需求的範例
建立問題反饋機制

未來擴展

這個方案還有許多可以擴展的方向：

模板化：將常見需求模板化，進一步簡化操作
預覽功能：在執行前預覽查詢結果，避免錯誤
版本控制：記錄查詢的歷史版本，方便回滾
自動化排程：定期自動執行某些查詢並更新名單
結果分析：自動分析查詢結果，提供洞察建議

結論

使用 Cursor Agent + Metabase MCP 的方案，成功解決了行銷人員「改來改去」的問題：

✅ 彈性與易用性並存：自然語言輸入，高度彈性的查詢能力
✅ 權限完全掌控：API KEY 由技術端管理，安全可控
✅ 降低溝通成本：減少來回確認，提升效率
✅ 釋放數據人員時間：專注高價值工作

這個方案不僅解決了當下的痛點，更重要的是展示了 AI Agent 在實際業務場景中的應用價值。透過合理的架構設計，我們可以在保持安全性的同時，大幅提升業務效率。

這篇文章記錄了使用 Cursor Agent 配合 Metabase MCP 解決實際業務問題的經驗，希望對面臨類似挑戰的團隊有所幫助。