三種你可能已经在用的工具
| 類型 | 代表 | 強項 | 弱項（对「可簽核分析」） |
|---|---|---|---|
| 通用聊天 + 上传檔 | 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 交付——让分析结論能进周会，而不只停在聊天里。
更短版見 電梯簡報。