三種你可能已經在用的工具
| 類型 | 代表 | 強項 | 弱項（對「可簽核分析」） |
|---|---|---|---|
| 通用聊天 + 上傳檔 | ChatGPT、部分 Copilot | 快、門檻低 | 口徑多在對話；難審 SQL；無 Execute 閘門 |
| 上傳即分析 | Julius 類 | 圖表快、體驗流暢 | 取數邏輯常不可審；交付在會話 |
| 傳統 BI 看板 | Looker、Tableau 等 | 指標穩、權限成熟 | 改口徑慢；adhoc 試探成本高 |
| Lantide Data | 本機 SQL IDE + Agent | Plan / SQL / Report 可審；Execute 在人 | 需建立審 Plan 習慣；本機桌面形態 |
Lantide 不是 要取代 BI 看板或通用聊天——它填的是 「這次分析」從探索到可簽核交付 的中間地帶。
和「聊天問數」差在哪（PM 一頁話）
聊天問數：
「幫我看上週轉化」→ 幾分鐘出答案 → 貼 Slack。
Lantide 專案分析：
「幫我看上週轉化」→ Agent 草擬 Plan（分母、stage）→ 你或分析師批註 → 人按 Execute → SQL 分頁留證 → Report 含數字與 limitations → 週會附連結或 HTML。
多出來的是 時間（審 Plan） 與 可問責性。適合會被追問的數，不適合純腦力 storm。
和 Julius 類「上傳 CSV 出圖」差在哪
這類產品常把 pandas / 繪圖藏在對話後面——對 探索 很友好。
Lantide 刻意 暴露 SQL：
- 分母爭議時，打開分頁或 Cached 查看 SQL （SQL 在「確定性」上優於 Python）
- 同事改的是同一段邏輯
- 統計檢定在 SQL 備好的表 上跑，取數仍可追溯
trade-off： 速度可能略輸「純聊天出圖」；換取 財務 / 法務 / 合作方能審的交付物。
和傳統 BI 差在哪
BI 擅長 已定義指標的監控；Lantide 擅長 尚未定稿口徑的探索與復盤：
- 大促結束後臨時問「這次 funnel 和上次差在哪」
- 新資料夾 drop 進來，還沒進數倉
- 分析師在 Plan 裡試口徑，定稿後 再 決定是否沉澱進 BI
許多團隊 兩者並存：Lantide 做 adhoc 與簽核；BI 做日常 dashboard。
對外怎麼一句話
Lantide 是 本機 SQL 分析 IDE + 可治理的 Agent：AI 幫你探索和起草，但 Plan 要審、Execute 要你按、SQL 留證、Report 交付——讓分析結論能進週會，而不只停在聊天裡。
更短版見 電梯簡報。