Skill 可以保存一套分析方法，甚至打包某次分析的 SQL、背景與修正紀錄；但它無法單獨保存當時用了哪版資料、實際跑了什麼、誰核准了口徑，以及結論如何連回證據。Skill 記得的是分析應該怎麼做，不是一份分析實際如何發生。
我看到一種很自然的做法：分析師和 Agent 好不容易完成一次分析後，把磨合出來的 Prompt、口徑、SQL、檢查步驟和注意事項整理成 Skill。下次遇到相似問題，再叫 Agent 載入這份 Skill 接著做。
這比把成果埋在一條找不到盡頭的聊天紀錄裡好得多。但它也暴露了另一個問題：我們正在把「可重用的方法」和「一段真實發生過的分析」塞進同一種容器。
我們其實在談兩種 Skill
Agent Skills 的通用格式把 Skill 定義為一個以 SKILL.md 為核心的資料夾，可包含指引、scripts、references、templates 與其他資源。它很適合讓 Agent 按需載入專業知識與工作流程。
放進數據分析情境後，我認為大家口中的 Skill 至少有兩種：
| Skill 類型 | 保存的內容 | 例子 | 主要價值 |
|---|---|---|---|
| 方法論 Skill | 通用方法、步驟、檢查標準與交付格式 | 漏斗分析方法、SQL review checklist、資料品質檢查 | 教 Agent「這類問題通常怎麼做」 |
| 具體分析 Skill | 某次分析累積的口徑、SQL、背景、修正與結論 | Q2 留存分析、每月營收分析、某產品的轉換率分析 | 讓 Agent 延續一段已經做過的工作 |
第一種是可重用的 expertise。第二種則更像一個被壓縮過的分析專案：我們希望 Agent 不只記住方法，還記住上次和我們一起做了什麼。
這個需求完全合理。聊天不是好的分析保存格式；換一個 Agent、開一段新對話或三個月後回頭看，之前對齊過的細節很容易消失。具體分析 Skill 因此成了實用的補丁。
但補丁終究不是分析本身。
Skill 裡有 SQL，不等於保存了那次分析
假設你和 Agent 完成了「新客 30 日付費轉換率」分析，最後把這些內容整理成 Skill：
- 新客的定義；
- 要排除的測試帳號與退款；
- 使用者、訂單與付款表的 JOIN 方法；
- 計算轉換率的 SQL；
- 報告應呈現的圖表與結論。
三個月後，另一位同事載入 Skill，要更新最新數字。Agent 確實知道該怎麼做，卻還是不一定回答得了：
- Skill 裡的 SQL 當時真的成功執行過，還是只是一份建議？
- 報告中的 18.4% 是由哪次查詢結果產生？
- 當時使用的是哪個資料範圍，資料後來更新了嗎？
- 分析師曾否決過哪些口徑？最後核准的是哪一版？
- JOIN 前後是否檢查過 grain 與 fan-out？
- 如果重新執行後得到 17.9%，差異來自資料更新、SQL 改動，還是定義改變？
你當然可以繼續往 Skill 裡加檔案：放入查詢結果、日期、版本說明、更多 SQL，甚至撰寫 script 重建流程。但當它開始負責資料快照、依賴、執行紀錄、決策歷史與最終交付時，它已經不只是一份 Skill，而是一個需要手工維護的分析工作區。
問題不是 Skill 能不能裝下這些檔案，而是這些檔案彼此的關係沒有自動成立。
一段 SQL 存在，不代表它被執行過；一個數字被寫下來，也不代表它仍能連回產生它的資料與條件。
方法是 instructions，分析是 state and evidence
這是兩者最根本的差別。
Skill 描述 intended path：應該讀哪些資料、採用哪些步驟、檢查哪些風險，以及如何交付。
分析保存 actual path：這次選了哪個口徑、實際執行哪段 SQL、使用哪個資料狀態、產生什麼結果、經過哪些審閱，以及最後仍有哪些限制。
兩者都重要，但生命週期不同。方法可以跨專案重用；分析結果則綁定特定問題、時間、資料與決策。
| 真實分析需要保存的東西 | 具體分析 Skill | Lantide Data |
|---|---|---|
| 分析方法 | 可保存步驟、規則與 Prompt | 可載入並共用 Skill |
| 業務口徑 | 寫成文字供 Agent 下次理解 | 以 Reference、Agent Memory 與 Plan 承載 |
| SQL | 可保存 SQL 檔或範例 | 成為可執行、可審閱的分析 artifact |
| 執行結果 | 需另存快照或重新產生 | 與 SQL、結果面板及工作區狀態相連 |
| 中間結果與依賴 | 需要自行描述如何重建 | 可用具名快取、持久 SQL 與 lineage 表達 |
| 人類決策 | 通常只留下整理後的最終版本 | 透過 Plan、批註與核准保留決策脈絡 |
| 報告證據 | 結論與查詢結果可能分離 | Plan、SQL、結果與 Report 留在同一專案 |
| 權限與執行邊界 | Skill 本身不是授權 | 由 Agent 狀態、工具與 access mode 控制 |
因此，真正的比較不是「Skills 和 Lantide 誰比較強」。Skill 是方法資產；Lantide 是讓方法進入真實資料、執行與審閱流程的工作環境。
一份分析至少有五層，Skill 最擅長其中一層
我會把一份可延續的分析拆成五層：
Method → Decision → Execution → Evidence → Delivery
| 層次 | 要保存的問題 | 適合的載體 |
|---|---|---|
| Method | 這類問題通常怎麼分析？ | Skill |
| Decision | 這次採用什麼口徑、範圍與假設？ | Plan、Reference、批註 |
| Execution | 實際跑了哪段查詢？ | SQL 與 query environment |
| Evidence | 結果從哪裡來，如何驗證與重跑？ | Results、lineage、activity |
| Delivery | 最後如何解讀，還有哪些限制？ | Report |
如果最後只保存了 Skill，你保存的是「下一次可以怎麼做」，卻未必保存了「上一次到底做了什麼」。這也是為什麼可重現的 AI 分析需要的不只是一份漂亮的操作說明，而是一條能從結論回到來源、轉換與限制的證據鏈。
這就是我為什麼做 Lantide Data
我不是因為 Skills 沒有價值才做 Lantide Data。相反地，我認為 Skills 會成為分析師與 Agent 協作時非常重要的知識資產。Lantide 也提供 Skill Library，讓內建 Agent 與透過 MCP 連入的外部 Agent 共用同一份方法定義；但 Skill 不會因此取得更多工具或繞過治理。實際使用方式可參考 Skills 使用指南。
真正讓我在意的是：當分析師開始把 SQL、業務口徑、分析結果、修正紀錄，甚至整個專案都塞進 Skill，他真正缺少的可能不是另一份更完整的指令文件，而是一個能保存分析工作本身的環境。
在 Lantide 的正式分析流程裡，Agent 可以使用 Skill 起草方法，但這次分析的問題、範圍與 checkpoints 會進入 Plan；使用者審閱後才 Approve & Execute；實際使用的 SQL、結果與中間依賴留在工作區；最後的 Report 則和前面的證據一起存在。方法可以重用，個案不必被壓扁成方法。
這並不代表 Lantide 能替團隊決定唯一正確的業務口徑，也不代表它是 data warehouse 或企業 semantic layer。人仍然要判斷問題、資料與限制。Lantide 想補上的，是 Agent 完成真實分析時需要的狀態、執行面與審閱介面。
Skills 是分析資產，但不是全部的分析資產
評估一套 Agent 分析工作流時，不妨問兩組問題。
第一組是關於能力：Agent 是否知道這類問題該怎麼分析？有沒有使用合適的 Skill？
第二組是關於證據：這次採用了什麼口徑？實際執行了什麼？數字如何產生？誰做了決定？下一個人能不能重跑？
前一組可以由 Skills 回答，後一組需要真正的分析工作環境。
Skills help an Agent learn how you work. Lantide helps you preserve the work you actually did.
下一次準備把一段成功的分析整理成 Skill 時，可以先做一個簡單檢查：把可重用的方法放進 Skill，把這次分析的決策、SQL、結果與限制留在能被審閱和重跑的專案裡。兩種資產分開保存，Agent 才能延續你的方法，而團隊也不會失去分析本身。