使用情境
從痛點到解法，Lantide Data 如何支援真實分析工作
結構化分析專案
A/B 測試、漏斗、異常偵測
業務場景
電商、SaaS、遊戲、訂閱制產品等高度依賴數據決策的產品與成長團隊，經常需要分析 A/B 測試、轉換漏斗、留存變化與異常指標。
使用者
林 PM (Claire)，某 B2B SaaS 公司的產品經理，負責新功能上線後的成效評估。
痛點
Claire 想知道新版 onboarding 流程是否真的提升啟用率，但過去用聊天式 AI 問資料時，結論散落在對話裡，SQL、假設、篩選條件與分析邏輯都難以追溯。主管追問「這個結論怎麼來的？」時，分析師只能回頭翻聊天紀錄與 SQL 分頁，無法形成可審閱、可版本化的分析流程。
解決方案
- 1
分析師與 Agent 協作撰寫 Plan
分析師與 Agent 先共同把分析目的、資料範圍、成功指標與方法論整理成 Plan，讓 PM、主管與分析師在執行前先對齊問題定義。
- 2
批註審閱達成共識
Claire 可直接在 Plan 上批註，例如要求排除內部測試帳號、拆分新舊客群，所有修改都保留在文件脈絡中，不會消失在聊天氣泡裡。
- 3
Execute 產出 Report
當 Plan 被確認後才執行分析，系統鎖定 Executed Plan 並產出 Report，讓結論、方法與版本完整對應，日後可以清楚追溯。
隱私與合規
本機優先、敏感資料
業務場景
醫療、金融、跨國零售等受到 GDPR / ISO27001 嚴格法規監管的企業團隊。
使用者
張經理 (David)，某外商銀行資安與風控合規官。
痛點
公司已經有安全的 Azure 端點，也想引進 AI 提升分析效率，但一般雲端 AI 助手仍常要求把敏感客戶個資與交易 CSV 上傳到外部環境。資料外送、可控性與審計邊界不清，仍會讓資安與合規審查卡關。
解決方案
- 1
在本機 DuckDB 載入資料
分析師直接將本機存放敏感資料的資料夾指派為 Workspace，資料立刻映射為 DuckDB 資料表，100% 物理隔離。
- 2
關閉或審批知識注入
大模型從對話中總結出的任何新業務規則，一律鎖在 Queued Knowledge 待審佇列，未經審批絕不私自注入 AI 上下文。
- 3
分析結果留在工作區
搭載唯讀守衛（SELECT-only），AI 只能讀取與建立臨時計算快取，不會寫回原始資料，降低篡改、誤刪與未授權改動風險。
多步驟 SQL 管線
快取串接、血緣追溯
業務場景
電商營運、供應鏈、金融分析與資料團隊，需要把原始交易資料、用戶事件、訂單明細與產品維度表串成多步驟分析流程。
使用者
陳分析師 (Mia)，某零售電商的資深數據分析師，負責每週營運儀表板與異常營收分析。
痛點
Mia 的分析通常不是一段 SQL 就能完成。進入 AI 時代後，SQL 產生得更快、更長、也更多，分析速度提升了，但中間結果是否過期、哪個查詢依賴哪個查詢、重跑順序是什麼，反而成為依賴管理與回溯的大問題。
解決方案
- 1
建立多分頁 SQL 與快取
Mia 可以把每一步查詢拆成清楚的 SQL 分頁，並將中間結果快取成可重用的資料表，不必每次從頭重算。
- 2
Source Run 依 DAG 重算
當上游資料或某個查詢被更新時，系統依照 Source Run DAG 判斷依賴順序，特別適合週期更新、但又常持續探索並衍生更深查詢的分析場景。
- 3
查看血緣與來源 SQL
每個結果都能追溯到來源 SQL 與上游快取，Mia 可以快速回答「這個數字從哪裡來」，也能更安心地交付給團隊。
跨來源分析
檔案 + 外部 DB + MCP
業務場景
零售、製造、SaaS、財務與營運團隊的資料經常分散在本機 Excel / CSV、內部 PostgreSQL / MySQL、第三方系統匯出檔與 MCP 工具中。
使用者
王營運 (Kevin)，某跨境零售品牌的營運分析主管，負責整合訂單、庫存、廣告與客服資料，找出影響營收的關鍵因素。
痛點
Kevin 想分析「廣告投放是否造成某些地區缺貨」這類跨部門問題，但資料散落在廣告平台匯出的 CSV、ERP 資料庫、客服系統與本機 Excel。每次分析前都要先搬資料、轉格式、對欄位，真正開始分析前就已經耗掉大量時間。
解決方案
- 1
載入本機檔案
Kevin 可直接把 CSV、Excel、Parquet 等本機檔案載入工作區，快速變成可查詢資料表。
- 2
ATTACH 外部資料庫
對於存放在 PostgreSQL 或 MySQL 的營運資料，可以透過 DuckDB ATTACH 連接，不必手動匯出再匯入。
- 3
Agent 與人類共用邏輯表名查詢
AI Agent 與分析師使用同一套邏輯表名與統一查詢層，能自然 JOIN 跨來源資料，減少資料搬運與欄位理解落差。
利害關係人交付
給老闆/客戶的報告
業務場景
顧問公司、產品團隊、營運團隊與企業內部分析單位，經常需要把分析結果交付給主管、客戶、投資人或跨部門利害關係人。
使用者
黃顧問 (Sophie)，某數位轉型顧問公司的專案顧問，負責把客戶營運數據分析整理成高階主管看得懂的簡報式報告。
痛點
Sophie 可以用 SQL 和 notebook 得到分析結果，但客戶高層不會閱讀查詢過程，也不想看聊天紀錄。他們需要的是有脈絡、有結論、有圖表、有建議的報告。過去 Sophie 還要手動把分析內容整理到簡報或文件中，耗時又容易在複製貼上時出錯。
解決方案
- 1
Execute 產出 Report
分析完成後，系統根據已審閱的 Plan 產出結構化 Report，保留方法、發現、證據與建議。
- 2
Generate HTML 報告
Sophie 可以把 Markdown Report 轉成獨立 HTML 報告，產生後也能用 Quick Edit 在瀏覽器中高頻微調，細修成主管或客戶習慣的語氣與版面。
- 3
瀏覽器分享或匯出
報告可直接在瀏覽器中展示、分享或匯出，讓分析交付從「工程產物」變成「商業溝通材料」。
團隊協作審閱
PM 批註、分析師修訂
業務場景
產品、數據、營運、財務等跨職能團隊在做重要分析前，常需要多人共同確認問題定義、資料範圍、假設條件與最終解讀方式。
使用者
吳主管 (Angela)，某 SaaS 公司的 Growth Lead，負責協調 PM、數據分析師與業務團隊，一起判斷新定價策略是否有效。
痛點
Angela 的團隊過去都在 Slack 或文件留言討論分析需求，但意見分散在不同工具裡。PM 補充商業脈絡、分析師修改 SQL、主管調整決策問題，最後沒有人能確定哪些意見已處理、哪些版本才是正式執行依據。
解決方案
- 1
PM 在 Plan 上批註
PM 與主管可以直接針對 Plan 的特定段落留言，例如補充分群邏輯、排除特殊客戶或調整 KPI 定義。
- 2
分析師 Resolve 並修訂
分析師根據批註逐項修改 Plan，並在 Resolve Comments 時把回饋變成下一版分析輸入，避免討論遺失。
- 3
達成共識後 Execute
團隊確認 Plan 後才執行正式分析，讓每一次 Execute 都建立在共同審閱過的版本上，協作過程可追溯、可交接。