Evidence.dev 程式碼優先報表：用 Markdown + SQL 取代拖拉式 BI
Evidence.dev 將數據報表定義為 Markdown 檔案內嵌 SQL 查詢，報表的每一次修改都通過 Git 版本控制與 Pull Request 審查流程，讓分析報告享有與應用程式碼相同的工程標準。根據 Evidence 官方文件，其靜態站點產生器可在 30 秒內建構含 200 頁的完整分...
Evidence.dev 將數據報表定義為 Markdown 檔案內嵌 SQL 查詢，報表的每一次修改都通過 Git 版本控制與 Pull Request 審查流程，讓分析報告享有與應用程式碼相同的工程標準。根據 Evidence 官方文件 ，其靜態站點產生器可在 30 秒內建構含 200 頁的完整分析報告，部署後的頁面載入時間低於 500 毫秒。 拖拉式 BI 工具的根本問題 拖拉式 BI 工具（如 Tableau、Power BI、Looker Studio）的報表以二進位格式或雲端私有格式儲存，無法進行有效的版本控制與差異比較。當某份關鍵報表的數字出現異常時，團隊很難追溯「是誰在什麼時候修改了哪個篩選器或計算邏輯」。更嚴重的問題是知識集中——報表的建構邏輯存在於少數人的滑鼠操作記憶中，一旦負責人離開團隊，報表的維護就成了災難。 Stack Overflow 2025 開發者調查 中，Markdown 是開發者最熟悉的標記語言，使用率達 72%。Evidence 選擇 Markdown 作為報表載體，意味著任何會寫技術文件的人都能立即上手，不需要額外學習專有的報表設計工具。 架構與運作方式詳解 資料來源連接層 Evidence 支援 PostgreSQL、MySQL、BigQuery、Snowflake、DuckDB、SQLite、CSV 與 Parquet 等多種資料來源。連線設定定義在 sources/ 目錄的 YAML 檔案中，敏感的認證資訊透過環境變數注入，不會被提交到 Git 倉庫中。一個專案可以同時連接多個不同類型的資料來源，在同一份報表中混合使用。 頁面與查詢的關係 pages/ 目錄下的每個 .md 檔案就是一個報表頁面。SQL 查詢用三個反引號加上 sql 標記定義，並賦予一個查詢名稱。例如定義名為 monthly_revenue 的查詢後，其結果自動成為頁面內的可用變數，可以直接在後續的圖表組件中透過 data={monthly_revenue} 引用。這種宣告式的寫法讓查詢邏輯與視覺化定義緊密關聯，閱讀程式碼時就能完整理解報表的資料流向。 視覺化組件系統 內建超過 20 種視覺化組件：LineChart、BarChart、AreaChart、ScatterPlot、DataTable、BigValue、Map、Histogram、BoxPlot 等。語法完全是宣告式的，例如 <LineChart data={monthly_revenue} x="month" y="amount" /> ，不需要撰寫任何 JavaScript。組件支援條件格式化、參考線、多系列疊加與自訂色彩主題，視覺品質足以用於客戶面向的報告。 與主流 BI 工具的定位差異 Metabase ：適合業務人員的即時自助查詢與互動式資料探索，強項在低門檻的點擊式操作 Looker ：適合大型企業的語義層治理與資料建模，但 LookML 的學習曲線陡峭，建模複雜度高 Evidence ：適合需要版本控制、程式碼審查與自動部署的定期報表場景，如每週業務回顧、月度財務報告、客戶面向的嵌入式資料面板 三者並非互斥關係。根據 a16z 的現代資料基礎設施架構報告 ，超過 45% 的成熟資料團隊同時使用兩種以上的 BI 工具，各自服務不同的使用場景與使用者群體。Evidence 最常與 Metabase 搭配——前者處理定期發布的正式報告，後者處理日常的臨時性數據探索。 完整部署流程 用範本初始化專案： npx degit evidence-dev/template my-report ，產生標準的目錄結構 本地開發： npm run dev 啟動熱更新開發伺服器，每次儲存檔案後報表即時刷新 建構靜態站點： npm run build 執行所有 SQL 查詢並產生純 HTML 頁面 推上 GitHub 並設定 Netlify 或 Vercel 的自動部署，每次合併 Pull Request 後自動重建並發布報表 設定排程觸發（例如 GitHub Actions 的 cron job），讓報表在每天早上八點自動重建以反映最新資料 實務建議與已知限制 查詢效能管理 ：所有 SQL 在建構時期執行，如果某個查詢掃描數十億筆資料會拉長建構時間，建議搭配 dbt 預先建立聚合表或物化視圖 互動性限制 ：Evidence 支援基礎的下拉選單篩選器與 URL 參數傳遞，但無法達到 Metabase 或 Tableau 那種即時拖放探索的互動深度 最適合的場景 ：週報與月報的自動生成、資料團隊的內部文件、客戶面向的唯讀分析報告、搭配 dbt 的資料品質監控頁面 不適合的場景 ：需要即時更新的營運儀表板、非技術人員的自助式探索分析 下一步行動 選擇團隊目
由 FeiYueh 親自審稿驗證 · 最後更新於 2026-08-19. Independently maintained — not AI-generated boilerplate.
← Back to Blog