讀時間： 約 8 分鐘 · 角色： 產品經理 / 決策者 · 下一步： 依下方閱讀路徑評估是否值得試用或推廣給分析團隊。
你可能在問的問題
「我們已經有 ChatGPT / BI Copilot，為什麼還要換一個桌面工具？」
「Agent 做分析，出了錯誰負責？」
「這跟 Julius 那類上傳 CSV 就出圖的工具有什麼不同？」
這些問題的核心不是「AI 能不能分析」，而是：團隊能不能對一個數字問責、審核、重跑——而不是在週會上念一段聊天摘要。
Lantide Data 是什麼（PM 視角）
一句話：本機數據分析 IDE，提供可治理的內建或外部 Agent 工作方式——把分析做成 可審閱的 Plan / Report / SQL，且 只有人能按 Approve & Execute 開跑正式分析。
它不是：
- 通用聊天模型（沒有工作區、Plan 狀態、快取血緣）
- 「上傳 CSV 就出圖」的聊天分析工具（口徑多在會話內，難當正式交付）
- 改 repo 的 coding agent（不管 Plan、Report、Execute 邊界）
它介於「快問快答的 AI 分析」與「改程式碼的 agent」之間——刻意暴露 SQL、Plan 可批註、Execute 在人，用可治理換取利害關係人可簽核的交付物。
為什麼值得推給分析團隊
1. 問責邊界清楚
Execute = 人類明確授權：「這版 Plan 我核准了，可以正式跑。」Agent 不能在 Planning 階段或對話裡假裝你已批准。週會上可以問：誰、在什麼前提下簽了這版口徑——而不是「AI 當時是這樣算的」。
2. 協作發生在文件上，不是 Slack 來回
Plan 上的批註綁定原文；Resolve 後 Agent 增量修改。共識寫進 Markdown，不是口頭答應後漏改。
3. 分析品質看內容，不是看形式
判斷一次分析能否拿去開會簽核，看的是：Plan 能否執行到 Report、Report 是否有具體數字與 limitations、漏斗是否有 stage 定義與分母——不是管線拆得多漂亮這類形式指標。多步物化與 Source Run 能加速與除錯，但不能替代可審閱的口徑與交付物。
4. Memory 可治理，不是黑盒累積
Agent 提案進 Queued Knowledge，你核准後才寫入 User / Project 知識。敏感專案可關閉；不會預設把對話灌進向量庫。
5. 外部 Agent 的權限與分析核准是兩道門
Agent Integration 的 Observe、Execute、Admin 是 connection 的能力上限；Plan 的 Planning、Executing、Executed 是分析生命週期。給外部 Agent Execute 或 Admin 並不等於核准某一版 Plan。
- Execute 雙開：正式分析仍須在 Lantide 按 Approve & Execute。
- Admin 單開（進階）：當下審閱可在外部對話完成；分析師明確確認後，Agent 可
claim_plan_approved推進 Executing，但 evidence 與 Report 紀律不變。
治理選擇見 外部 Agent Integration。
誰該用、誰可能不適合
| 適合 | 不太適合 |
|---|---|
| 需要口徑對齊、可簽核交付的分析協作 | 只要一次性圖表、不需 SQL 證據 |
| 本機 CSV / Excel 場景 | 預設重度雲端數倉 + 企業 ETL 調度 |
| 希望 Agent 探索、人保留 Execute 與批註 | 期望 Agent 全自動出報告無人審 |
| 小團隊「Plan 當規格、Report 當交付」 | 僅需 NL2SQL 單次問答 |
→ 詳細對照：和 ChatGPT / Julius 類差在哪
建議閱讀路徑（入門 → 實踐 → 進階）
入門：做採用決策（約 15 分鐘）
| # | 文章 | 概述 | 狀態 |
|---|---|---|---|
| 1 | 誰該用、誰不該用 | 團隊規模、資料型態、協作需求與 Lantide fit | 已有 |
| 2 | 和 ChatGPT / Julius 類差在哪 | 聊天分析 vs SQL-first；可治理 trade-off | 已有 |
實踐：團隊怎麼落地（約 25 分鐘）
| # | 文章 | 概述 | 狀態 |
|---|---|---|---|
| 3 | 跨角色協作：PM 怎麼用 | 人與 Agent 各環節分工；Execute 為何必須可觀測 | 已有 |
| 4 | 品質底線：Execute 前必審 | 數字、分母、limitations；形式指標不能替代內容 | 已有 |
| 5 | Agent Memory 與 Plan 別搞混 | Queued Knowledge 審批；合規與關閉策略 | 已有 |
| — | 跟做 | USER_GUIDE §2 或請分析師 demo 一輪 | 已有 |
進階：對外與導入（約 15 分鐘）
| # | 文章 | 概述 | 狀態 |
|---|---|---|---|
| 6 | 團隊導入五步法 | 選真實小專案、跑通 Plan→Report、觀察 Execute 邊界 | 已有 |
| 7 | 對外電梯簡報素材 | 品類、差異、場景、邊界四段式話術 | 已有 |
設計深度（選讀）
| 資源 | 何時讀 |
|---|---|
| 0. 系列導讀與產品定位 | 市場空位、Julius 對照、產品品類定位 |
| 1. Agent 時代的數據分析工作流 | Execute 與 Plan/Report 設計全文 |
| 2. 可治理的 Agent Memory | Queued Knowledge 治理 |
| 外部 Agent Integration | 評估外部 Agent 的 scope、mode、Activity 與撤銷方式 |
導入試用：你可以這樣驗證
- 選一個有口徑爭議的真實小專案（比 demo 資料更能體會價值）
- 請分析師跟 USER_GUIDE §2 跑通 Plan → Execute → Report
- 刻意留一條 Plan 批註，看是否只改被點段落
- 確認 Execute 只有人按——Planning 階段 Agent 不會偷跑
- 評估：Report 能否附在週會，而非再手寫一版 PPT 邏輯
其他角色
- 分析師引言 — 日常分析工作流與 SQL-first
- 業務與運營引言 — 審 Plan、驗 Report（試點第二波）
- 平台啟用（數據工程）引言 — 連線與工作區遷移（有工程支援時）
- Learn Hub