讀時間： 約 5 分鐘 · 系列： 產品經理入門 · 下一步： vs Chat / BI
這篇幫你做什麼
協助你在 推工具給團隊之前 快速判斷：Lantide 解的是不是你們的痛點，以及誰會是第一批受益者。
適合的團隊與場景
1. 口徑會被反覆追問
財務、運營、業務對同一 KPI 有不同理解；週會上常出現「這個數怎麼算的？」若答案在聊天紀錄或某人的 notebook 裡，Lantide 的 Plan + SQL + Report 能讓追問有落點。
2. 資料主要在本地檔案或輕量連線
CSV / Excel / Parquet 資料夾、或掛載的 PostgreSQL / MySQL／SQLite；Pro 還可接 Cloud storage（S3／OSS／ADLS 等）、SQL Server／Azure SQL 與多個本機 Additional folder——不必先上雲數倉也能開始。適合中小團隊、活動復盤、adhoc 專案。
3. 希望 AI 加速，但人要保留控制
你接受 Agent 探索與起草，但要求 Execute 只能人按、Plan 可批註、正式交付可簽核。這是「可治理的 Agent 分析」，不是全自動黑盒。
4. 小團隊把 Plan 當規格、Report 當交付
沒有獨立 data platform 團隊，分析師兼任取數與講故事；需要 一份文件 同時給執行與匯報用。
不太適合的場景
| 情況 | 為什麼 |
|---|---|
| 只要一次性圖表、永遠不追口徑 | 通用聊天 BI 可能更輕量、快速 |
| 企圖在應用中實現企業級 ETL 調度與排程 | Lantide 是 本機分析 IDE，不是調度平台 |
| 期望 Agent 全自動出報告、無人審 | 與 Execute 在人、Plan 必審的設計相反 |
| 團隊拒絕 SQL 作為口徑契約 | 產品核心假設是 SQL-first |
| 僅需偶發 NL2SQL 一問一答 | 大材小用；除非未來會長成多步分析 |
「不適合」不代表永遠不能用——而是 第一批試點 應選更對齊的場景，成功率更高。
依團隊規模看
| 規模 | 典型用法 |
|---|---|
| 1–3 人分析 | 分析師自管 Plan / Execute；PM 偶爾批註 Plan |
| 分析 + PM + 業務 | PM / 業務批註 Plan；Execute 前分析師確認；Report 附週會 |
| 有工程支援 | 工程接 MCP / 連線、.lantide 遷移 — 見 平台啟用（數據工程）引言；PM / 分析用 Learn + USER_GUIDE onboarding |
Lantide 不要求專職「Agent 管理員」；治理來自 流程（Execute、Queued Knowledge），不是額外職位。
試點是否值得：三個訊號
- 最近三個月內，至少有一次 KPI 爭議無法指向 SQL 或文件
- 分析師願意 用 Plan 寫口徑（或願意被流程推著寫）
- 決策者願意 在 Execute 前花 15 分鐘審 Plan，而不是只要「快出數」
三條中兩條以上為真，值得安排一輪 USER_GUIDE §2 demo 或真實小專案試點。