數據基建做好了，AI 就能接手團隊分析嗎？

與 AI 協作分析 · 4/7

數據找得到，不代表下一位分析師或 Agent 就能接手我們做過的分析。

我們當然希望有個熟悉公司業務、有問必答，還不會喊累的 AI 分析助手。但如果管理層豪爽地批了這個預算，頂級 AI 模型擺在面前，除了數據庫權限、Schema 和幾份指標文件，我們還能交給它什麼？

數據找得到，不代表分析接得起來

假設三個月前，團隊做過一次回流用戶分析。SQL、報表都還在，現在新版本上線，主管想再看一次。

AI 找到舊 SQL，換了日期，很快交出結果。但它知道上次為什麼排除某個渠道嗎？是數據有問題，還是當時辦了特殊活動？當時的分群方式，這次還適用嗎？這些不一定能從程式碼裡看出來。有時甚至連原本的分析師都要想一下：「我當時到底在幹嘛？」

數據基建幫我們處理數據的取得、品質、權限與計算。但數據準備好了，不代表分析中那些方法選擇、驗證過程與判斷依據，也一起準備好了。前者讓 Agent 有數據可以分析，後者才讓它有條件接手我們做過的工作。

要準備的內容	主要回答的問題
數據取得、品質、權限與計算	有什麼資料、是否可靠、能不能使用？
方法、假設、驗證與限制	為何這樣分析、哪些判斷成立、下次要重驗什麼？

這兩層互相補充，都需要團隊投入。

聊到數據基建，我們很容易想到 DE 的工作。但如果目標是讓 AI 接手團隊分析，這套基建就不能只由 DE 完成，DA 與 DS 也得把分析中形成的方法與判斷留下來。

除了指標怎麼定義，還有：

這些不是多補幾份 Schema 就能推導出來的，往往是在實際分析、與業務來回確認的過程中才逐漸形成。上一份報告寫「回流用戶留存提升」，跟留下「為什麼這次採用這個觀察窗、排除了哪些干擾、目前還不能把提升歸因給新版本」，能交接出去的東西其實差很多。

我認為這些分析脈絡，也應當是基建的一部分。它們不只服務當次交付，也會影響下一個人、下一個 Agent 能不能正確接著做。當然，不是說記錄下來就永遠成立。恰恰相反，把當時的條件一起留下來，下一次才知道哪些可以沿用、哪些得重新驗證。

問題是，誰來整理？如果每次分析完，都得額外花半天補文件，「建立分析基建」大概很快就會淹沒在分析師的待辦事項中，無限延期。

這也是我在開發 Lantide 時把「邊分析、邊整理」放進工作流的原因。與 Agent 協作本來就會經過一輪輪討論、執行和確認。既然剛剛才對齊方法、排除一個假設，或確認某個異常，就可以趁這個階段讓它整理，再由人確認，不必等全部做完才回憶。

但光是自動寫文件還不夠。問題、計畫、執行證據、報告，以及確認後留下的知識，使用時也得接得起來。因此還要同步完成知識分類與結構化保存。這樣下一次遇到相關問題，Agent 不只是找到幾份結論相似的舊報告，而是能沿著報告找到當時的問題、方法、證據與適用條件，再用當前數據重新驗證。

如果報告越存越多，每次接手卻還是得找原本的人重新講一遍，那我們累積的可能主要還是文件，而非真正的「分析資產」。對我來說，真正的分析資產不是「曾經做過」，而是換個人、換個 Agent、換個時間，仍然能理解、驗證並繼續使用。

這是我判斷分析資產是否有用的標準：它能不能降低未來理解、驗證與接手的成本？

可以先拿一份三個月前的報告自查：換個人，能否說明當時為何排除某個渠道，以及這次重跑前哪些條件需要重新驗證？

在 Lantide Data 中試用這套分析工作方式：下載 Lantide Data。