通用 Agent 已經成熟，垂直應用還需要自己的 Agent 嗎？
我如何讓外部 Agent 保留通用能力，讓內建 Agent 深入資料分析工作流，最後接入同一個 Control Plane。
閱讀文章 →Lantide Data 部落格
可靠、可審閱的 AI 輔助數據分析觀點與實務指南。
AI 分析觀點
查看全部 →AI 把分析做快了，卻讓「這個結論怎麼來的」更難回答
當 AI Agent 開始找資料、寫 SQL、跑 Notebook 並修改報告，聊天紀錄與檔案版本已不足以保存完整證據鏈。本文說明為什麼數據分析需要 Analysis Lineage。
閱讀文章 →Skills 在數據分析中的侷限：為什麼 Skills 不足以承擔真實世界的數據分析？
Skill 能保存分析方法，也能打包特定案例的 SQL 與背景；但真實分析還包含資料版本、執行狀態、人類決策、證據與限制。本文說明為什麼分析需要一個可審閱、可重跑的工作環境。
閱讀文章 →AI Agent 和聊天機器人差在哪？從「回答問題」到「完成可驗收的工作」
AI Agent 不只是把回答寫得更長，而是能依狀態使用工具、推進多步工作並留下可驗收成果；本文用數據分析說明兩者差異、評估方式、適用情境與導入邊界。
閱讀文章 →AI 做數據分析，最危險的不是算錯，而是你不知道它怎麼算
AI 分析最難發現的是口徑、分母、JOIN 與時間窗造成的合理錯誤；本文提供 Plan、SQL、checkpoint、limitations 四層查核方法。
閱讀文章 →自然語言都能查資料了，為什麼 2026 年還需要 SQL？
自然語言能降低查詢起點，卻不能取代 SQL 對粒度、JOIN、篩選與聚合的可審閱證據；未來更合理的分工是 AI 起草、SQL 留證、人類審核。
閱讀文章 →為什麼正式分析要先寫 Plan，再讓 AI Execute？
先寫 Plan 的目的，是在取數前對齊決策問題、分母、粒度、時間窗與驗證方式；Execute 則把正式執行變成清楚的人類授權邊界，避免模糊假設先被跑成數字。
閱讀文章 →可重現的 AI 分析是什麼？從一個答案到一條可重跑的證據鏈
可重現的 AI 分析必須保留輸入資料、時間版本、轉換 SQL、依賴、執行紀錄與限制，讓他人能用同一條證據鏈重跑、核對關鍵數字並解釋新舊結果差異。
閱讀文章 →AI 分析工具、聊天 BI、傳統 BI：三者應該怎麼分工？
AI 分析 Agent、聊天 BI 與傳統 BI 解決的是不同階段：快速問答、探索口徑與穩定監控不應混為一談；本文提供五維選型矩陣與三個實務分工場景。
閱讀文章 →Local-first AI 數據分析：資料留在本機，究竟解決了什麼？
Local-first 可減少資料搬運、直接查本機檔案並保留可攜工作成果，但不自動等於完全離線或零風險；本文說清實際收益、資料流檢查與產品邊界。
閱讀文章 →Agent 治理
查看全部 →Prompt Engineering 過時了嗎？Context Engineering 才是 Agent 成敗的分水嶺
Prompt Engineering 沒有過時，但 Agent 還要管理工具、資料、狀態、歷史與記憶；Context Engineering 決定模型每一輪究竟看見什麼。
閱讀文章 →Context Window 越大越好嗎？長任務真正會遇到的 Context Rot
Context Window 變大只代表能放入更多 token，不代表模型能同樣可靠地使用每段資訊；長任務需靠壓縮、結構化 artifacts 與按需載入控制 Context Rot。
閱讀文章 →AI Agent Memory 不是「全部記住」：企業知識為什麼需要審批？
Agent 長期記憶會跨對話影響分析，因此企業知識需要來源、範圍、核准與淘汰機制；本文提供可直接採用的 Memory 治理框架與 Queued Knowledge 審批流程。
閱讀文章 →MCP 是什麼？為什麼它正在成為 AI Agent 的資料與工具介面
MCP 用標準化的 client-server 協定連接 AI 應用、資料與工具；本文說明核心元件、安全邊界，以及 Lantide 的雙向 MCP 用法。
閱讀文章 →MCP 接上資料庫就安全了嗎？從工具連線到最小權限的五層防線
MCP 只標準化連線，不保證最小權限。本文用 host、credential、scope、capability、approval 與 audit 檢查 Agent 資料存取。
閱讀文章 →AI Agent 治理怎麼落地？別從政策文件開始，先畫出「誰能做什麼」
AI Agent 治理要先把使用者、Agent、工具與資料的能力邊界畫清楚，再配置核准、監控與復原；本文提供可直接填寫、測試與指定 owner 的六格能力地圖。
閱讀文章 →Schema 都給 AI 了，為什麼還是會算錯？數據分析真正缺的是業務語意
資料表名稱與欄位型別只能描述資料長相，無法定義有效客戶、營收、轉換率與時間窗。本文拆解 AI 分析需要的業務語意，以及如何把口徑變成可審閱的分析契約。
閱讀文章 →與 Lantide 整合
查看全部 →使用 Claude Code 與 Codex 做數據分析時，為什麼還需要 Lantide？
Claude Code 與 Codex 擅長在終端機調度長任務與 MCP 工具；若分析必須留下可審閱 SQL、Plan 與 Report，可把 Lantide 當本機 MCP host，用 Access Mode 與 Approve & Execute 守住執行邊界。
閱讀文章 →使用 PostHog 時，為什麼還需要 Lantide？
PostHog 擅長產品事件、漏斗與實驗顯著性；當你要把不宜上雲的本機 CRM／財務資料與事件聯立，或需要可審閱 SQL 與正式 Report 時，可用 Lantide 做本機診斷。
閱讀文章 →使用 Hex 時，為什麼還需要 Lantide？
Hex 擅長雲端協作 Notebook、reactive 執行與 App 發布；當資料必須留在本機、或 adhoc 探索不想進入雲端專案時，可用 Lantide 做 local-first 分析，再把已去敏結果交回 Hex。
閱讀文章 →使用 dbt 時，為什麼還需要 Lantide？
dbt 適合生產轉換、測試與 CI；對一次性假說驗證，不必每次都開完整 model／CI。可用 Lantide 在本機沙盒探索，確認口徑後再把標準 SQL 回寫 dbt repo。
閱讀文章 →使用 Notion 時，為什麼還需要 Lantide？
Notion 適合 PRD、知識庫與 database chart；它不是本機 SQL 執行引擎。用 Lantide 完成可重跑分析後，再把 HTML 或 Markdown 成果貼回 Notion，讓企劃頁引用的是有證據的結論。
閱讀文章 →使用 Obsidian 時，為什麼還需要 Lantide？
Obsidian 與 Dataview 擅長本機 Markdown 知識與筆記 metadata 查詢；Lantide 補上 DuckDB SQL、可重跑分析血緣與受治理的 Agent memory。兩者可用檔案交換銜接，而非互相取代。
閱讀文章 →數據分析實務
查看全部 →每週 CSV 或 Excel 報表如何重跑，不必每次從頭開始
一套可實際執行的重複分析流程，保留輸入檔案、指標定義、SQL、驗證檢查與報告限制。
閱讀文章 →用 AI 分析 CSV 前，先做這 8 個資料品質檢查
AI 能快速探索 CSV，但不會替你定義正確資料。本文提供編碼、型別、空值、重複、鍵、時區、單位與異常值的 SQL 檢查表，並示範如何留下可重跑 checkpoint。
閱讀文章 →不裝資料庫，也能用 SQL 查 Excel／CSV：DuckDB 適合哪些人？
DuckDB 是嵌入式分析資料庫，可直接用 SQL 查本機 CSV、Parquet 與 Excel；適合檔案型 adhoc 分析，但不取代共享數倉與排程 ETL。
閱讀文章 →AI 寫的 SQL 怎麼審？不只看能不能跑的 7 點檢查表
AI SQL 成功執行不代表回答正確。本文用 grain、JOIN、filter、NULL、時間、分母與 LIMIT 七點檢查表，附最小驗證查詢。
閱讀文章 →轉化率為什麼每個人算得不一樣？先對齊分母、事件與時間窗
漏斗轉化率沒有唯一公式；使用者或事件粒度、cohort 或日曆時間窗、事件順序與取消規則不同，答案就會不同。本文附可複用 Plan 模板與最大流失檢查方式。
閱讀文章 →JOIN 後數字暴增？AI 數據分析最常漏掉的 Fan-out 陷阱
JOIN 後總額變大，通常不是加總函數壞了，而是表格粒度不一致造成 fan-out。本文用訂單案例與 SQL 檢查法，教你在 AI 查詢交付前找出重複計算。
閱讀文章 →快速問數還是正式分析？用風險而不是篇幅做決定
Quick Analysis 與正式分析的差別不在問題長短，而在答案錯誤的影響與未來是否要被追問。本文提供一張二維判斷表，幫你選對分析流程。
閱讀文章 →數據血緣不是只有大數據平台需要：一份本機報表也該知道從哪裡來
數據血緣是資料來源、轉換與輸出之間的可追溯關係。即使只有本機 CSV 與月報，只要成果會更新、交接或除錯，就值得留下最小血緣、命名規則與重跑路徑。
閱讀文章 →一份可信的 AI 分析報告，至少要有哪 6 個部分？
可信的 AI 分析報告不只要有摘要，還要交代決策問題、口徑、主要發現、可回查證據、限制與下一步。本文附可直接套用、可連回 SQL evidence 的六段式模板。
閱讀文章 →團隊導入
查看全部 →PM 不會 SQL，也能審 AI 分析：Execute 前先問這 6 個問題
PM 審 AI 分析不必逐行改 SQL；只要在 Execute 前確認目標、對象、分母、時間、排除條件與驗證方式，就能守住業務口徑與決策責任。
閱讀文章 →分析師如何和 AI Agent 分工？把時間留給口徑、驗證與解讀
AI Agent 適合加速 schema 探索、SQL 草擬與報告初稿；分析師應掌握問題定義、口徑、驗證、異常解釋與決策溝通。本文提供一套風險分工表。
閱讀文章 →外部 AI Agent 要碰公司資料前，資料平台團隊該準備什麼？
外部 AI Agent 接觸公司資料前，平台團隊應先界定來源、能力、workspace、credential、正式 evidence、writer ownership、audit 與復原。本文提供導入檢查表。
閱讀文章 →從第一次試跑到團隊採用：可治理 AI 分析的 30 天導入路線圖
30 天 AI 分析試點應從真實、可控的復盤開始，逐步建立品質底線、審閱失敗、權限與擴大條件。本文提供週次任務、必要產物，以及判斷是否擴大的四組指標。
閱讀文章 →