與 AI 協作分析 · 5/7
團隊做過一次分析，不代表其他成員或下一個 Agent 就能接著做。
我認為 AI 在分析工作中一個容易被低估的價值，是讓保存分析經驗這件事，開始有機會在合理的成本內完成。
有數據、有業務知識，還缺什麼？
盤點團隊做分析時需要的資訊，我會分成三類：
| 類型 | 保存的內容 | 活動分析中的例子與用途 |
|---|---|---|
| 數據上下文（Data Context） | 有哪些數據、去哪裡查、欄位與指標怎麼定義 | 活動埋點、參與率指標、Schema 與查詢入口，讓 Agent 知道資料怎麼查 |
| 領域知識（Curated Domain Context） | 業務運作方式與整理好的方法 | 活動規則、用戶分型、內部用語與 Skill，讓 Agent 知道常用方法 |
| 分析經驗（Experiential Analysis Context） | 實際試過的方法、證據、取捨與限制 | 曾排查活動入口資格而調整分母的案例，讓接手者理解當時怎麼判斷 |
前兩類比較容易被辨識成「應該整理的知識」，第三類則常常只留下交付物，其餘散落在代碼、聊天紀錄和分析師腦中。
但「團隊知道什麼」，跟「團隊曾經經歷過什麼」，提供的幫助其實不太一樣。
團隊做過，不代表團隊裡的人都能接著做
比如做活動參與分析，團隊有活動埋點、參與率指標，也有整理好的活動分析方法，Agent 已經可以開始工作。
但上次分析同類活動時，我們可能先懷疑獎勵吸引力不足，拆了幾輪用戶後，才發現部分新用戶根本還沒解鎖活動入口。最後調整分母，才把「能參加但沒參加」和「根本不能參加」分開。
交付的報告可能只留下調整後的參與率和分母定義。這很正常，報告是拿來支持決策的，主管也不一定想陪我們重走一次心路歷程。
但對下一位分析師或 Agent 而言，中間那段經驗很有用：遇到參與率偏低，可以先檢查參與資格，再決定要不要往獎勵設計下鑽。
但下一次參與率偏低，也不代表又是資格問題。得知道當時比較了哪些人、看了哪些證據，才能判斷這次哪些可以參考、哪些得重新驗證。
現在這些經驗的取得方式，常常是「我記得某某之前做過，你去問他」。新人得先知道要問誰，資深同事則得不斷回憶並重講一次（做過一次分析，附贈不限次數的售後服務）。
有些經驗還不足以寫成通用規則，但可以先連同條件、證據與走不通的方向保存成案例。讓同事找到後能理解當時的選擇，從已經驗證過的位置繼續分析，這些經驗才比較有機會在團隊裡流通。
Agent 也是一樣。只有 Schema 和 Skill，它知道數據怎麼查、方法怎麼用；再取得團隊做過的案例，才有機會參考我們怎麼排查、在哪裡存疑、根據什麼收斂。遇到情境差異時，也能提出更具體的問題。
我期待的「像團隊成員一樣分析」，就是能參考團隊的歷史經驗，判斷這次怎麼接著做，並把新的發現留下來。
問題一直都在，AI 改變的是留下經驗的成本
沒有 AI 的時候，我們也知道應該寫註解、整理 Notebook、留下口徑和決策紀錄。
只是當下正忙著拆問題、查異常，停下來整理會打斷心流；等交付後再補，很多細節又已經忘了。最後常常是「有空再整理」，但下一個 deadline 已經在等了。
分析師得自己組織文字、找對應的 SQL 和結果，成本當下就得付，收益卻可能幾個月後才出現在另一位同事身上。大家知道有價值，也很難持續做。
與 Agent 協作後，有一個條件變了：它本來就在參與分析。
方法怎麼調整、查詢跑出了什麼、哪些假設沒有得到支持，很多資訊已經出現在協作過程裡。每完成一個階段，就可以讓它整理剛剛確認的決策、連上對應證據，再由我審閱。
我需要做的工作，天然就包含：「當下確認哪些值得留下、記得對不對」，那既然已經做了這個判斷，不如在同一個時刻直接結構化記錄下來，省得事後重新整理整段分析。
這也是我在 Lantide Data 裡持續做的事：讓分析交付物與形成它的過程一起保存，保留問題、計畫、證據與判斷之間的關係，讓後續的人與 Agent 有脈絡可以接手。
沒說出口的判斷仍然得補上，整理的內容也得確認，總不能讓它把猜測寫得很漂亮，我們就當成團隊經驗傳下去。
對我來說，AI 帶來的改變，是讓這些過去很難持續整理的經驗，有機會以合理的成本留下來。先讓團隊成員接住彼此的工作，再讓 Agent 透過同一套脈絡，參與團隊的分析。
延伸閱讀
在 Lantide Data 中試用這套分析工作方式：下載 Lantide Data。