PostHog Context Mill 是什麼？把文件做成版本化 Skills，讓 AI 代理跟上產品
PostHog Context Mill 將文件、指引與範例包成版本化 Skills，供 Wizard 代理載入。拆解知識和程式分開更新、資料維護責任與整合驗收，幫產品團隊判斷是否值得導入。
PostHog Context Mill 在 X 再次被分享，談的是 AI 代理常見的問題：程式還能跑，但它依賴的產品知識已經落後。
SDK 是協助程式接上服務的開發工具組。如果每換一組工具或框架，就得重新發行整個安裝代理，知識更新會被綁在程式更新上。文件明明已改好，使用者卻可能繼續得到舊做法。
PostHog 的做法是把文件、範例 App 與指引組成版本化 Skills，再讓 Wizard 安裝代理於執行時載入。這份公開流程不是全新發布的產品，而是一次對既有架構的說明。
Skills 可以理解成針對某類任務整理好的資料與做法。代理先選任務需要的部分，團隊則獨立維護資料來源和發行。
對產品整合路徑常變的團隊，這種分工值得參考。若連基本文件都還不完整，先補來源與維護責任，會比照搬整套架構更有用。
PostHog Context Mill 在更新哪一種資料？
Context Mill 主要管理代理要用的知識，執行工作仍由 Wizard 負責。Wizard 可以先理解成協助安裝與整合 PostHog 的工具，而 Context Mill 則替它準備任務需要的文件、範例與做法。
這個分工寫在 PostHog 官方手冊。知識放在 Context Mill，執行代理的程式放在 Wizard，兩者可以各自維護，因此不必每改一段產品文件，就一起重新發行整個執行工具。
對讀者而言，這和替聊天機器人補一份常見問答有相似處，但要求更高。因為安裝代理會實際修改專案，錯誤的參數、過期的範例或不合適的框架做法，都可能變成程式變更。
產品知識也不只有功能介紹。使用哪個套件、設定應放哪個檔案、應如何確認資料有送達，都會影響整合結果，所以資料必須接近工作現場。
這也是 Context Engineering 常被討論的原因。它指的是替 AI 工作安排合適資料與取得方式，讓模型在需要做決定時，有足夠而且相符的依據。
PostHog 在 X 分享的是這套做法的說明，不能因為貼文是近期發布，就把所有架構都稱為當天才推出的新功能。對產品團隊，比發布日期更有用的是它解決了哪一段維護問題。
知識範圍確定後，要讓代理能選到符合任務的那一份。
文件如何變成 AI 可以選用的 Skills？
封裝不是把所有文件一次塞進對話，而是讓代理找到相符的任務資料。Skills 在這裡是按用途整理的資料包，讓「安裝某功能」比「讀完整個網站」更容易開始。
官方公開流程包含資料蒐集、組裝與交付。文件、手寫指引與範例先匯入，再整理成資料包和選單，最後以版本發行的方式提供其他工具取用。
Context Mill 原始專案也說明，Wizard 會讀取最新選單，再依需求下載對應內容。這讓代理先知道有哪些任務資料，而不必一開始就背負所有產品知識。
可以把它想成有分類的工具說明櫃。代理先確認這次要安裝分析、錯誤追蹤或其他功能，再拿出相應資料。分類與描述寫得清楚，選錯資料的機會才會降低。
對自己的產品，第一份 Skill 不必很大。可以先把最常見的整合問題、正確步驟、已知限制與驗收方法整理在一起，讓代理能完成一個有明確結果的小任務。
來源仍要能回查。如果資料包裡的做法來自不同文件，就應保留連結與更新責任，因為之後工具失效時，需要知道是模型理解錯，還是資料本身已經過期。
一個好的資料包也應交代什麼時候不要用。像是只適用某個框架版本的範例，若沒有寫出前提，代理可能在不相容的專案裡照做，反而增加修復工作。
代理找得到資料後，更新路徑才能與執行程式分開管理。
為什麼知識更新與代理程式要拆開？
兩條發行路徑拆開後，文件改善才能更快進入下一次工作。當問題只出在過期指引，團隊就可以先更新資料，不必把它和執行介面的改版綁在一起。
這對產品種類多、支援多個框架的團隊特別有感。因為某個功能的安裝方式可能只影響一條整合路徑，若每次都發行整套工具，其他無關工作也會一起承受更新成本。
不過，更新更快也代表影響更快傳出去。PostHog 手冊明確要求，在合併 Skill 變更前先測試，因為新的 Context Mill 發行會直接被後續 Wizard 執行採用。
因此，拆開更新不等於可以省略檢查。比較合理的工作順序，是先確認資料改動能被建置與讀取，再用對應任務檢查輸出，最後才讓新版本進入使用路徑。
資料和執行程式同時變動時，也要交代相依關係。例如新資料使用了舊工具尚未支援的操作，就不能假設它們各自成功發行後一定能合作。
下面可以用來判斷一個問題應該修在哪一層。
| 遇到的問題 | 優先檢查的位置 | 想確認的結果 |
|---|---|---|
| 指引引用舊參數 | 產品文件與任務資料 | 新內容能指向正確做法 |
| 工具執行失敗 | 執行程式與環境 | 同一步驟能可靠完成 |
| 選錯整合方式 | 選單描述與前提 | 代理能挑到相符資料 |
| 完成卻沒有資料 | 驗收與實際接收端 | 事件或設定真的生效 |
表格把錯誤拆回可處理的位置，所以團隊不必每次都先換更強模型。因為缺少正確資料時，增加推理時間也未必補得回來。
更新可以更快到達使用者，但仍需要檢查安裝結果。
團隊怎麼確認新資料真的改善安裝結果？
更新速度只有搭配結果檢查，才知道新知識是否真的幫到使用者。最直接的比較，是同一個任務在更新前後，是否需要更少人工修正，並且完成相同驗收。
先選一條常出錯的路徑，例如在既有網站加入指定事件。記錄原本哪一步失敗、代理讀到什麼資料，以及最後實際有沒有收到事件，再決定要補哪一段說明。
安裝完成不能只看程式碼中出現套件名稱。對分析工具，還要檢查設定指向正確專案、資料是否真的送達，以及預期操作會不會重複產生事件。
如果只檢查檔案存在，就容易把「有寫程式」算成「已經可用」。這是代理導入常見的落差，因此驗收應盡量靠近使用者最後要得到的結果。
也要保留沒有通過的案例。若每次只挑成功整合當示範，團隊看不出哪些框架、既有設定或帳戶條件仍會讓代理卡住，資料包也就無從改善。
測試資料應避免混入正式使用者資訊。先用可辨識的測試事件和測試專案，能讓工作者知道是哪次執行的結果，也降低把驗證流量當成正式數據的機會。
當資料更新後，請比較錯誤是否真的減少，而不只看回答變得更長。新增說明可能讓模型更會解釋，卻沒有改善實際安裝，所以最後仍應回到完整流程。
先知道哪一類錯誤有改善，才有依據投入更多知識整理工作。
維護責任要怎麼分，才不會又變成過期文件？
文件有負責人，資料包才有機會長期保持可用。PostHog 把不同產品的 Skills 交給對應產品團隊，並由 Wizard 與文件團隊維護建置及沒有明確產品歸屬的內容。
這個安排可以參考，但小團隊不必一開始照搬所有角色。先指定誰負責內容正確、誰確認建置發行、誰驗收實際結果，就能讓一個最常用的整合路徑持續被照顧。
產品改版時，文件和代理資料也應一起被檢查。因為使用者看得到的新設定，代理未必知道。若兩邊資訊不同，客服就會接到「照官方教學做卻失敗」的問題。
範例程式也要交代定位。Context Mill README 特別提醒，裡面的範例是簡化示範，不是可直接上線的產品起始專案，部分驗證甚至是模擬設計。
這項限制對讀者很重要。代理可以從範例學習怎麼整合，但不能因為範例能跑，就推論它已具備正式登入、資料保護與營運需要的所有條件。
發行紀錄則應寫清楚改了哪個任務、適用什麼版本，以及驗收做過什麼。當使用者回報問題，團隊才能對回當次代理拿到的資料，而不只看到隨時變動的文件頁。
同時保留回退方式。如果新資料導致原本能完成的任務失敗，應能回到先前版本並定位差異，避免使用者在修復期間持續拿到同一份錯誤做法。
維護流程還可以加上一個容易執行的檢查：當產品文件改了安裝參數，確認引用它的任務資料是否也取得新內容。這能把更新責任落在實際事件上，不必只靠定期提醒。
如果同一份做法在不同來源出現矛盾，先指定權威來源，再修其他引用。因為代理看到多份答案時，未必知道團隊最後採用哪個版本，單純增加文件數量反而可能擴大混淆。
哪些團隊值得做，哪些先整理文件就夠？
當產品有多個整合入口、資料頻繁變動，而且代理已經在替使用者實作，知識供應流程就值得投入。因為同一份錯誤指引會被反覆執行，修正來源能一次改善多個後續任務。
如果產品只有少數穩定功能，而且人工安裝文件還不完整，先整理清楚的一頁做法通常更有用。工具可以之後再補，來源、前提與驗收則是任何形式都需要的基礎。
PostHog 也沒有把 Context Mill 描述成永久終點。官方手冊把它視為過渡做法，目標是讓文件本身更容易整理成 Skills，而不必一直維護另一套重複知識。
這讓讀者看到一個實際取捨：包裝能讓資料更容易被代理使用，但包裝層越多，維護來源一致性的工作也越多。因此，先避免文件與資料包各寫一份不同答案。
比較好的起點，是挑一個最常讓使用者卡住的任務，整理原始依據、適用條件、錯誤處理與完成證據。等這條路徑穩定，再擴充到其他產品或框架。
當下一次產品文件更新時，可以問團隊一個具體問題：正在工作的代理會在什麼時候讀到新做法。答案越清楚，AI 整合工具就越有機會跟得上產品本身。
延伸閱讀：Garry Tan 刪減 gstack 上千行指引：AI 程式代理的規則該留多少？
延伸閱讀：Claude 寫了九成程式，誰來審？Claude Code 團隊公開分層審查流程
PostHog Context Mill 常見問題
它是一個新的大型語言模型嗎？
不是。它整理並交付產品知識，讓既有代理取得相符資料，模型與執行工具仍是另外的部分。
把文件全部放進提示詞不就好了？
文件越多，越需要選擇和維護。按任務供應資料，可以讓代理先取得相符內容，也方便產品團隊管理更新。
使用最新資料就能保證整合成功嗎？
不能。資料正確只是前提，執行環境、既有專案和帳戶設定仍會影響結果，所以要檢查實際接收端與使用流程。
小團隊一定要建立同樣架構嗎？
不必。先完成一條常用任務的文件、來源與驗收，再依重複需求決定是否需要版本化資料供應。
怎麼開始第一份任務資料？
先挑最近一次真實整合失敗的案例，把當時缺少的前提、正確步驟與驗證方式寫清楚，再用相同情境確認改善。
