分析整理成 Skill 之後，為什麼 AI 還是用錯口徑？

與 AI 協作分析 · 3/7

一次成功的分析，整理成 Skill，下一次就能直接用了嗎？

好不容易跟 AI 對齊了口徑、修完 SQL、排掉幾個坑，當然會想把這些經驗留下來。遵循著通用 Agent 的解決方案，我也自然而然地嘗試使用 Skills 來記錄，但經歷幾輪分析後，我發現我的 Agent chat 中多了許多「你用的是另一個專案的口徑，這裡應該是...」。

我開始思考，為什麼這些對我來說很直觀的「知識選擇」，似乎對於 Agent 有一定的難度。

Skill 可以很完備，但哪些知識適合帶到下一次？

我們的直觀理想是：讓 Agent 把做完的分析整理成 Skill，希望下次遇到類似問題，可以少溝通一點、直接接著做。

比如付費用戶留存分析：

假設這次分析某個伺服器的付費活動，最後決定只看活動期間有付費的角色，按帳號 x 伺服器計數。這個定義在當時完全合理，整理進 skill 也沒有記錯，但下一次分析整體歷史付費用戶的流失，這套口徑就不一定適用了。

我用知識的「過擬合」來比喻這個問題：把單次案例裡成立的條件，也整理成了可以反覆使用的做法。AI 讀這份 Skill 時，未必分得清哪些是通用方法，哪些是當時才做的決定（每個字都記對了，用起來還是錯的，比忘記還難抓）。

很直覺的補法是，把付費期間、計數單位、跨服去重方式改成參數，要求 AI 每次先確認。對簡單、穩定的分析，這樣確實可能就夠了，但隨著同一份 Skill 被不同專案反覆使用，裡面開始多出各種預設值、適用條件與例外：這個專案看歷史付費，那個專案只看近 30 天；這裡跨服去重，那裡又要分開算。

為了讓 Agent 知道參數該怎麼填，還得把每一種選擇背後的業務背景一起寫進去。原本只是想留下留存分析的方法，最後卻順便養了一本跨專案操作大全。

對穩定、範圍清楚的方法，參數化可以是合適的做法；但當不同專案的規則混在一起時，它就比較像持續補洞：每遇到一個新情境，就繼續往 Skill 補條件，但不同範圍的知識仍然混在一起，如果拆成多份 Skill 各抄一份，共用口徑更新時又容易漏改。

其實傳統分析也有這些問題。我們也會複製舊 Notebook、拿上次的 SQL 改一改來用。但差別在於，自己的分析通常會有印象，記得哪些條件要調整，頂多算是「隱隱作痛」等級。可能到了交接，或隔幾個月接回專案時，才會疑惑：「我當時為什麼排除這群人？」

但 Agent 加入後，分析產出和任務切換都變快了，這種知識交接被快速放大到 daily work 中。每天除了審結果，還得檢查它今天繼承了哪些歷史包袱，哪些可能是已經不適用的知識。

盤點混雜在既有 Skills 中的知識後，我逐漸分出幾種落點：

這不是說每次開工都要先寫四份文件，而是在 Agent 寫入知識時進行「即時分流」。一次性的條件留在 Plan，確實需要反覆使用時，再抽成方法或共用知識。

分開保存後，使用時也要接得起來：Skill 提醒 Agent 確認付費口徑，專案規則提供可參考的定義，最後把本次採用的版本寫進 Plan。AI 可以知道公司有好幾種付費口徑，但應該知道它們各自用在哪裡，不確定時提出疑問而非靜默選擇。

其實沒有 Agent 時，我們也知道邊分析邊記錄，通常比做完再回憶完整，但過去沒遇到幾個分析師能持續這麼做，除了麻煩、打斷心流，deadline 通常也不太想聽我們解釋。

Agent 加入後，這件事反而有了比較自然的做法。與它協作本來就會經過一輪輪討論、驗證和確認，可以趁每個階段結束，讓它整理剛剛確認的知識、提出適合的落點，再由我確認。

於是「即時分析、即時分流、即時確認、即時寫入」開始變得可行，不必等整份分析做完，才回頭考古自己到底做了什麼（不知道大家有沒有想跟過去的自己搏擊的時刻）。

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