introduction | Lantide Data

讀時間： 約 8 分鐘 · 角色： 分析師 · 下一步： 依下方閱讀路徑逐篇深入，或直接去 USER_GUIDE §2 跟做一輪漏斗分析。

你可能已經遇過這個場景

週五用 AI 問了兩小時漏斗與 GMV 口徑，對話裡數字看起來合理。週一財務追問：「分母含不含取消單？退款怎麼扣？」你翻聊天紀錄——只有摘要、幾張截圖，中間的 JOIN 與 WHERE 邏輯說不清。

問題通常不是模型不夠聰明，而是分析被留在對話氣泡裡：沒有 Plan 寫清口徑、沒有 SQL 分頁當證據、沒有 Report 當交付物。六個月後，連你自己都難以重現那個數。

一句話：本機 SQL 分析 IDE，內建 Agent 副駕駛，也能接入受控的外部 Agent——不論從哪個對話介面工作，口徑與取數邏輯都應留在你可審閱的 SQL 分頁與 Markdown 文件裡，而不是藏在一次性 Python cell 或聊天摘要中。

你熟悉的	Lantide 的做法
上傳 CSV → 聊天出圖	本機 DuckDB 查檔案；Agent 與你共用同一套表名
口徑在腦袋或對話裡	Plan 寫清分母、粒度、checkpoint；SQL 分頁是執行證據
AI 自己跑完分析	你按 Execute 才算正式開跑；Planning 階段只探索與修 Plan
結論貼 Slack	Report 進專案文件，可批註、可 HTML 匯出

它不是「會寫 SQL 的 ChatGPT」，也不是「改 repo 的 coding agent」——而是專為分析工作設計的 Agent 執行環境：同一個 IDE 裡完成探索、起草、授權執行、交付。

1. 口徑可辯論、可重跑

活躍用戶怎麼定義、兩表 user_id 怎麼對齊、JOIN 會不會 fan-out——用 FROM / JOIN / WHERE 寫在 SQL 分頁與 Plan 裡。同事改的是同一段邏輯，不是重播一段對話。

2. 分析有階段，不是一鍵黑盒

Agent 會先探索 schema、草擬 Plan；若口徑尚未寫死，可能用對話一次一題幫你對齊，再等你批註滿意後才 Execute。這對分析師意味著：探索可以快，正式取數必須有契約——分母、stage 定義、limitations 都要在 Report 裡說清楚。

聊天輸入區可切 Agent（可改 Plan／Report／HTML／SQL）與 Ask（只問、可跑查詢，不改這些產物）。只想搞懂數字、暫時不改檔時用 Ask；要改契約或交付物時切回 Agent。詳見 USER_GUIDE §12.1.1。

3. Quick 與 Project 分工清楚

欄位探索、單次驗證 → Quick Analysis（對話 + SQL 分頁）。要 Plan 批註、正式 Report、給主管簽核 → 聚焦專案走 Plan → Execute → Report。不必在錯的模式裡抱怨「為什麼沒有 Approve & Execute 按鈕」。

4. 進階能力按需取用

快取、Source Run、統計工具、Agent Memory 都有，但分析正確性優先於管線形式——不必為了「管線看起來很完整」而硬拆步驟；一次性清楚的 JOIN 可以直接跑。

若你只是要「快問快答」，通用聊天工具可能更輕；若你要六個月後還能說清楚這個數怎麼來，Lantide 的設計更對齊。

先讀完本篇，再依序或按需跳讀。

#	文章	概述	狀態
1	為什麼分析結論不能停在聊天裡	聊天缺契約、批註綁定與鎖定交付；何時該升級專案	已有
2	Quick Analysis 與 Project Analysis	兩種模式各適合什麼任務；已聚焦專案時 Agent 的行為	已有

#	文章	概述	狀態
3	Plan → 批註 → Execute → Report	各階段該做什麼；草案後短問答對齊口徑；Execute / Report 驗收時可用 Compare view	已有
4	SQL-first：口徑寫在分頁裡	取數用 SQL；統計工具在乾淨表上啟用；與聊天出圖工具的對照	已有
5	快取與 Source Run 要懂到哪	persist vs agent 快取；何時值得拆 persist 分頁	已有
6	用 @ 精確指向資料與分析產物	在聊天引用 Plan、SQL、資料表；拖曳或 Add to chat；避免同名歧義	新增
—	跟做	USER_GUIDE §2 快速開始（orders 漏斗）	已有

#	文章	概述	狀態
7	對話裡的統計分析工具	`activate_analysis` 能做什麼；執行前 Agent 為何會問你確認	已有
8	Reference docs：大型參照怎麼放	映射表／字典與 Plan、Memory 分流；Update Intro	已有
9	Plan vs Agent Memory 分工	單次假設寫 Plan；跨專案口徑經 Queued Knowledge 審批	已有
10	Skills：可重用的分析方法論	`/` 載入；與外部 Agent 共用 definition；不是工具授權	已有

資源	何時讀
1. Agent 時代的數據分析工作流	想理解 Execute 邊界與 SQL-first 全文
5. 統一查詢層 §八	想理解物化與 Source Run 工程細節
USER_GUIDE §5–15	操作查詢、快取、Agent、Skills、Memory
外部 Agent Integration	團隊想從 Cursor、Codex 或 Claude 操作同一套 Lantide artifacts

讀完本篇 + 入門 2 篇
跟做 USER_GUIDE §2 一輪 Plan → Execute → Report
試一次聊天 Ask（只問不改）再切回 Agent 改 Plan（見 USER_GUIDE §12.1.1）
試開 Compare view：Execute 時對照 Plan，或驗收 Report 時對照 Plan（見 plan-execute-report §4–5）
在 Plan 上留一條批註，確認 Agent 只改被點段落；Resolve 後試 View changes 與 Archive
（可選）側欄 Persist SQL：為分頁設 Metadata，或 Archive 一條過時分頁（見 sql-first-workflow）
（可選）建一個小 Reference 映射 + Intro，或用 Create reference from… 匯入短文件（見 reference-docs-for-analysts）
在 Data → Cached 右鍵 查看 SQL，對一下口徑
（若使用外部 Agent）在 Lantide 核對 Plan、SQL evidence、Report 與 External MCP Activity