讀時間： 約 6 分鐘 · 系列： 分析師實踐 · 上一步： Plan → Execute → Report · 下一步： 快取與 Source Run
為什麼取數用 SQL，而不是藏在對話裡
很多「上傳 CSV → AI 出圖」工具，實際在背景跑 Python/pandas，你只看到圖和摘要。分母怎麼濾、兩表怎麼 join、會不會 fan-out——往往無法當正式證據保存。
Lantide 選 SQL-first：
- Plan 寫「要算什麼、口徑是什麼」
- SQL 分頁 寫「怎麼從表裡算出來」
- Report 寫「結論與 limitations」
同事質疑數字時，你打開 SQL 分頁或 Cached 的 查看 SQL，改的是同一段邏輯，不是重播一段聊天。
分析師的日常分工
| 層次 | 放什麼 | 例子 |
|---|---|---|
| Plan | 業務口徑、stage、checkpoint | 「活躍 = 90 天內至少一筆 paid order」 |
| SQL 分頁 | FROM / JOIN / WHERE / GROUP BY |
具體濾條件與 join key |
| Reference 檔 | 大型映射、字典（全文） | 狀態碼表、欄位 rename 對照——見 Reference docs |
| 對話 | 解讀、追問、修 Plan | 「這段 NULL 比例偏高，要 exclude 嗎？」 |
| Report | 數字 + 限制 | 「轉化率 12.3%；未含退款逆向調整」 |
Agent 會幫你建分頁、寫 SQL、執行；你的責任是 審 Plan、審 SQL、按 Execute——不是自己從零寫 every query，而是確保 artifact 可審。
手動 SQL 與 Agent 可混用
Lantide 有兩條路（見 USER_GUIDE §1.2）：
- 路徑 A： 你自己在編輯器寫 SQL
- 路徑 B： Agent 協作 Plan → Execute → Report
同一工作區裡，你可以：
- 先手動探表，再叫 Agent 寫 Plan
- Agent 建的分頁，你手改後再 Execute
- Quick 裡驗 join，滿意後搬進專案 Plan
表名一致： Agent 與你共用 DuckDB 上的同一套表（本地檔案、連線、快取表）。
SQL Server／Azure SQL： 與 ATTACH 型 DB 不同，遠端查詢須單源——先在 SQL 分頁把遠端表篩選／聚合物化，再與本地或 cache JOIN。若 Agent 估計單次遠端結果超過約 50 萬列，會 pause 請你確認；這是保護本機與遠端的 guardrail，不是 bug。見 USER_GUIDE §4.5。
Execute 前 Agent 常先 list_sql_tab 列舉工作區既有 persist SQL 分頁（含 Label、專案歸屬），避免重複建 pipeline tab。你可為分頁設定 Metadata（Label / Project）；側欄會依專案分組（無歸屬者在 Unscoped），目前聚焦專案那一組預設展開（仍可手動摺疊）。也可用 Archive 軟藏過時分頁——與 Delete 不同，不會刪除 Plan Progress Steps。見 USER_GUIDE §5.6。
統計工具放哪一層
對話裡的 t 檢定、迴歸、聚類等（見 統計分析工具）建立在 Agent 先用 SQL 備好的乾淨表 上：
- 取數、清洗、聚合 → SQL 分頁（可重跑、可查看）
- 檢定、建模 → 統計工具，結果主要在對話呈現
Planning 階段 Agent 不跑正式統計；Execute 後、跑檢定前 Agent 會問你確認參數。
與「隱藏資料分析」的差別（分析師視角）
| 聊天裡出圖的工具 | Lantide | |
|---|---|---|
| 口徑證據 | 多在摘要 | SQL 分頁 + Plan |
| 重跑 | 難以復現 | 執行同一分頁或 Source Run |
| 協作 | 轉貼對話 | 批註 Plan / Report |
| 速度 | 往往更快上手 | 多幾步審核，換可簽核 |
若你只需要一張圖、永遠不會被追問口徑，前者可能夠用。若這個數會進週會、合約或半年後的 audit，SQL-first 更對齊。
實務習慣（三條）
- 每個「會被引用的口徑」都應能在 SQL 或 Plan 找到——不要只存在口頭或聊天。
- 持久分頁 + 執行 會產生快取，後續 SQL 可
FROM "分頁名"引用（見 快取）。 - 懷疑數字時，Data → Cached → 查看 SQL，比翻聊天快。