組織裡最有價值的知識，往往集中在少數資深專家身上: 文件寫不全、標準作業流程涵蓋不了，人一離開，知識就跟著離開。這是知識管理領域的老問題，但現在多了一個新解法: 把專家知識萃取出來，做成 AI Agent 可以載入的 skill，讓非專家也能做出專家等級的產出。最近 GitHub 上「員工蒸餾」專案引發的討論（後面 C 路線會講），也讓更多人開始關注這件事。

小編把目前找得到的論文和工具整理成一個方法論框架。範圍先講清楚: 知識來源是真人專家，終點是 Agent Skill。至於 agent 從自己的執行軌跡歸納 skill 的自我改進路線（SkillWeaver、Trace2Skill 那一系），不在這篇的討論範圍，這裡談的都是把「人」的知識拿出來。

整個框架只需要回答一個問題: 專家的知識，現在存在哪裡? 答案有五種，對應六條萃取路線:

📍 專家的知識，現在存在哪裡?
只在專家腦中
沒有任何紀錄
A人工訪談 🗣
BAI 訪談 🤖
在數位足跡裡
聊天、文件、code review
C數位足跡蒸餾 🗂
在操作過程裡
做得出來但說不出來
D示範錄製 🎥
在教材裡
教學影片、文章、手冊
E教材蒸餾 📚
在未來的協作裡
還沒發生的判斷與糾正
F互動結晶 🔄

在逐條介紹之前，先講一下為什麼終點選 skill。Anthropic 官方在 Building Agents with Skills 的定位是: skill 用檔案打包領域專業知識（工作流程、最佳實務、腳本），靠漸進式載入 (progressive disclosure) 控制上下文用量: 平常只載入約 50 token 的描述資訊，需要時才讀取 SKILL.md 主文件，深度參考資料則放得更後面。skill 還能內含腳本當工具，可執行的部分完全不用進上下文。這個「scripts/（可執行規則）+ SKILL.md（判斷知識）+ references/（深度參考）」的結構，正好給知識萃取的產出一個標準容器。而且 Anthropic 觀察到，動手寫 skill 的人已經不限於工程師，產品經理、分析師、領域專家都在自己動手。以下六條路線的產出，最後都會落到這個容器裡。

🗣 A. 人工訪談: 品質最高，也最貴

做法: 半結構化訪談，搭配情境式追問。Siemens 的論文是標準示範: 他們訪談兩位內部專家（一位模擬分析軟體專家、一位視覺化設計專家），各 60 到 90 分鐘、分開進行避免互相影響。訪談大綱只有三個主題: (1) 目前的工作流程和痛點、(2) 專家建立視覺化時的決策過程、(3) 實務上使用的具體規則和經驗法則。提問從開放式問題起頭，像是「可以帶我走一遍你為模擬資料建立視覺化的典型流程嗎?」「最常用、最有用的圖表是哪些?」，再追問具體規則和判斷標準。另外搭配「情境式討論」: 拿範例任務給專家看，讓他在回應中示範怎麼判斷。這是關鍵技巧，因為隱性知識直接問是問不出來的，要靠具體情境讓專家把判斷過程講出來。

有一點蠻意外的: 專家在訪談中就直接給出明確規則，例如「分析開始前，必須先確認最佳化目標是否收斂」，不需要研究者事後再做詮釋分析，記下來就能實作。萃取出來的知識有兩種型態，去處也不同:

明確程序規則 → 寫成程式碼
條件明確的判斷邏輯，例如「分析前先檢查目標是否收斂」。直接寫成 Python 函式，執行後產生分析報告，自動附加到 system prompt。
隱性設計原則 → 寫進 Prompt
依情境判斷的知識，例如「未收斂的變數用虛線、已收斂用實線」「一張圖最多放兩個變數」。寫進 system prompt 或 RAG，讓模型推理時套用。

論文特別提到，單獨用任何一種都不夠: 只有程式碼會缺乏分析洞察，只靠模型又會產出不符合領域要求的東西，兩者搭配才有效。這個「可以寫成程式碼的就寫成程式碼，不然就用 prompt」的分工原則，小編覺得是全篇最值得帶走的一句話。成果也很具體: 非專家用簡單的 prompt 產出的圖表，品質比未加持的版本提升 206%（12 位評審、5 個場景）。

而且萃取不是一次就能完成的。初版結果發現生成的圖表資訊量不足、有視覺缺陷，他們才回頭向視覺化專家做針對性補訪，聚焦在最常用的三種圖表類型。真實流程是「訪談 → 實作 → 測試發現不夠 → 針對性補訪」，這跟 AI 評估圈講的錯誤分析 (error analysis) 是同一個邏輯: 先做出第一版，讓失敗案例告訴你接下來要補哪一塊知識。

論文還有兩個實務註腳。第一，為什麼只用兩位專家? 他們的理由是: 需要涵蓋的兩個專業領域很少重疊、目標是系統性知識萃取而非統計推論、驗證靠客觀技術指標，而且知識工程文獻本來就認為 1 到 3 位專家足以建構一致的知識庫。第二，第一作者本身是 Siemens 員工，能接觸內部資料和內部討論: 很多知識不是那 90 分鐘訪談問出來的，是長期待在組織裡累積的。

訪談技巧的系譜與工具箱: 這套技術的源頭是 1980 年代專家系統時代的知識工程。關鍵決策法 (Critical Decision Method) 原本是 Klein 在 1989 年用來訪談消防指揮官的，因為他們的判斷依賴講不出來的知覺線索，只能靠「回溯真實事件加上探測式問題」引出來。Hoffman 等人 1998 年的方法論回顧和認知任務分析 (Cognitive Task Analysis) 的現代整理都值得參考。當年萃取出來的規則放進規則引擎，現在放進 skill，訪談技術本身沒變。AgentPatterns 的整理把這些技巧翻新成 agent 時代的版本，核心觀察是: 專家「說自己怎麼做」和「實際怎麼做」中間有落差，直接問規則只能拿到前者。三個實用技巧:

  • 困難案例訪談: 請專家走一遍他親身遇過的困難案例（不是假設情境），針對每個案例問四個問題: 你最先注意到什麼訊號? 當時預期接下來會發生什麼? 有哪些互相衝突的優先順序? 你立刻想到哪些做法? 這四問就出自關鍵決策法，專門用來取得專家自己意識不到的模式判斷。
  • 失敗案例訪談: 拿 agent 的實際失敗輸出給專家看，請他說明「正確的輸出長什麼樣、為什麼」。解釋的過程，就會透露他心裡的隱性標準。
  • 範例標註: 給專家一批好壞混雜的輸出，請他逐一標註，標註理由就是評估準則，這正是「用 LLM 當評審 (LLM-as-judge)」機制裡人類要負責的那一半。Hamel Husain 的建議是找一位內部領域專家當品質標準的最終決策者就好，外部標註人員缺乏組織脈絡，反而製造更多分歧。

還有一個值得認識的變形: BC Protocol 讓「領域專家 + 知識工程師」兩人配對對話。理由是「專家盲點」: 專家獨自寫文件時，會跳過他認為理所當然的推理步驟，必須靠一個「校準過的外行人」在對話中把這些步驟逼出來。實驗顯示，對話產出的推理過程在自然度上大幅領先專家獨寫（評分 4.80 比 1.30）。這篇的產出目標是微調 (fine-tuning) 用的推理鏈資料而不是 skill，但「雙人對話外化隱性判斷」的技術完全可以搬過來用。

  • 優點: 品質最高、能拿到任何紀錄裡都沒有的「為什麼」、可以即時追問和驗證理解。
  • 缺點: 最貴、依賴訪談技巧、專家時間稀缺，而且一次訪談問不完（Siemens 也是靠失敗案例回頭補訪）。
  • 適合: 知識沒有數位足跡的老師傅（產線、實驗室、現場判斷）、高風險高價值領域、專家即將離職退休的搶救場景。

🤖 B. AI 訪談: 用規模換深度

做法: 讓 AI 當訪談者。Genentech 的 Protocol Intelligence Co-pilot 是目前最完整的案例: AI 訪談 agent 套用一組結構化的「提問視角」訪談實驗室科學家，產出附專家信心分數的知識圖譜。他們要捕捉的是「自動化掩蓋的沉默失敗」這類只存在專家判斷裡的知識: 儀器紀錄回報執行成功，但實驗的科學有效性其實已經出問題。這種知識在實驗協定文件、感測器數據、既有的知識本體裡都找不到，只能從專家口中問出來。學術圈也在把訪談本身形式化，例如 SparkMe 把「照大綱問」和「追新線索」之間的取捨寫成效用函數，用來指導 AI 訪談員; Springer BISE 的研究則讓對話 agent 模擬訪談流程，專家回答完直接產出 BPMN 流程圖。

Anthropic 官方的 skill-creator 其實也算這條路線的輕量版: 它用互動方式引導領域專家（不需要是工程師）在 30 分鐘內做出第一個 skill，本質上就是「AI 訪談你，然後幫你寫成 SKILL.md」。

  • 優點: 便宜、可重複多次、可以同時規模化到很多位專家、專家可以自助。
  • 缺點: 追問深度不如老練的人類訪談者。Genentech 的數據很直白: 多輪對話式追問的訪談逐字稿，後續萃取結果高度一致; 單次問答式的一致性就差很多（失敗模式辨識的 F1 分數從 1.0 掉到 0.43）。訪談品質決定萃取品質，AI 訪談員目前還在追趕。
  • 適合: 專家人數多而訪談人力稀缺的組織、想讓領域專家自己動手把知識寫成 skill 的場景。

🗂 C. 數位足跡蒸餾: 不佔專家時間，但雜訊多

做法: 不問人，直接處理專家留下的數位足跡。這條就是最近討論度很高的「員工蒸餾」: 今年 3 月底，上海 AI Lab 工程師 Tianyi Zhou 開源了 colleague-skill（同事.skill）專案，兩週內拿到 13k GitHub 星星，口號寫著「將冰冷的離別化為溫暖的 Skill，歡迎加入賽博永生」，後來團隊把方法寫成論文 COLLEAGUE.SKILL。

它的流程是目前文件化最完整的: 收集器和解析器先把聊天記錄、工作文件、電子郵件、會議截圖正規化成本地的知識目錄 → 分析器從中萃取「持久能力、思維模型、互動風格」的證據 → 建構器渲染成結構化的 Markdown → 寫入器打包成版本化的套件。產出分成兩軌: work.md 放工作方法、審查標準、決策準則，persona.md 放溝通風格和互動約束，可以安裝到 Claude Code 等 agent 環境。專案文件建議優先收集「主動寫的長文」和「決策類回覆」，因為這兩類素材最能反映一個人怎麼判斷。

它的修正循環設計特別值得抄: 使用者用自然語言回饋（「他不會這樣說」「這種情況他會反對」），系統轉成對應段落的修正補丁或修正紀錄，版本遞增、可以回滾。等於承認第一版蒸餾一定不準，把「修」設計成一級操作。同路線的還有 Dianoia，從公開產出物（設計文件、code review）蒸餾出「專家怎麼想」: 怎麼定義問題、怎麼判斷品質、怎麼取捨。

實際案例也出現了: Shanghai Daily 報導，山東一家遊戲公司的人資離職後，公司沒有補人，而是用她的聊天記錄和工作文件建了一個數位分身，接手例行詢問和文件工作，同事的評語是「有點笨，只能處理簡單指令」。中國社群也隨之出現「反蒸餾」工具，教你在離職前避免自己被做成 skill，勞動價值歸屬和隱私的爭議跟著浮上檯面（工商時報的整理）。

  • 優點: 完全不佔專家時間、人已經離職也能事後做、拿到的是「實際怎麼做」而不是「自己說怎麼做」。
  • 缺點: 前提是要有數位足跡，而且數位足跡雜訊多。COLLEAGUE.SKILL 論文自己明確承認只做「產物層級」的主張，不宣稱能還原本人行為。另外還有當事人同意、隱私、勞動價值歸屬的爭議。
  • 適合: 知識工作者的離職交接、有大量文字產出的角色。反過來說，工作不留數位足跡的老師傅，這條路線直接不適用。

🎥 D. 示範錄製: 捕捉「做得出來但說不出來」的操作

做法: 請專家把工作做一遍，錄下來，讓模型從錄影中萃取步驟化的操作知識。這條路線目前的研究集中在圖形介面操作: Teach-and-Repeat 從手機螢幕示範中萃取「動作類型、目標元件、輸入內容、執行順序」這樣的操作知識; Instruction Agent 從單次示範抽出逐步指令，然後嚴格照著執行; InvisibleMentor (CHI 2026) 則反過來，從螢幕錄影中偵測低效率的操作，推薦更好的工作流程。

  • 優點: 專家的成本最低（做一遍就好，不用講也不用寫）、能捕捉時間順序和畫面狀態這種文字寫不出來的資訊。
  • 缺點: 只拿得到「怎麼操作」，拿不到「為什麼這樣做」和「什麼情況要改用別的做法」，這些判斷還是得靠訪談補。而且目前技術集中在螢幕操作，實體世界的示範要另外解決感測問題。
  • 適合: 軟體操作型的專家知識（複雜工具鏈的老手、內部系統的熟練操作者）。當成訪談的前置素材也很好用: 先錄示範，再拿著錄影做情境式追問。

📚 E. 教材蒸餾: 專家已經整理過一次，別浪費

做法: 專家為了教人而做的教材（教學影片、文章、手冊、範例專案），本身就是半結構化的知識，直接拿來蒸餾。Microsoft 的 Resource2Skill 把教學影片、程式庫、文章蒸餾成可執行的 skill，組成階層式的多模態 Skill Wiki，每個條目包含結構化文字、程式碼、視覺範例和出處。設計理由是三種素材互補: 影片保留操作的時間順序和視覺效果、程式碼保留可執行的工具使用模式、文章提供概念基礎。在七個創作領域的實驗中，平均提升 11.9 個百分點。

社群工具 skill-distillery 也屬於這條路線，它有一句話講到重點: 把 5000 字文章的段落重排成 SKILL.md 格式，不算做成 skill。真正的萃取是由下而上: 先抽出讓方法有效的原則、組織這個領域的思維模型、做事時需要的決策準則，然後才設計 skill 的架構。

  • 優點: 素材現成、專家已經做過一輪結構化、不需要接觸專家本人。
  • 缺點: 教材是「教人版」不是「實戰版」，通常缺少失敗處理、邊界案例和真實世界的髒細節，而這些恰恰是老師傅最值錢的部分。教材也會過時。
  • 適合: 有成熟教學資源的領域、引入外部專家知識（買得到課程但請不到人）、給訪談路線當基礎，讓訪談時間留給教材沒寫的部分。

🔄 F. 互動結晶: 不做前期萃取，邊協作邊沉澱

做法: 前面五條都把萃取當成一次性的前期工程，Nurture-First Agent Development 反對這個前提: 專家知識是隱性的、個人的、持續演化的，一次性萃取注定會漏。它主張 agent 從最小配置開始，在與專家的日常協作對話中累積知識，再靠「知識結晶循環」定期把對話中的碎片判斷，固化成結構化的知識資產。

注意這跟「agent 看自己的執行軌跡自我改進」不一樣: 結晶的素材是專家在協作中給出的判斷、偏好和糾正，知識來源仍然是人。老實說，這就是 Claude Code 重度使用者每天在做的事: 用的過程中發現 agent 不對，糾正它，然後把糾正沉澱進 CLAUDE.md 或 skill。這篇論文等於把這個日常實務形式化了。

  • 優點: 沒有前期萃取成本、知識跟著真實使用演化、專家提供素材的動機自然（他本來就要把工作做完）。
  • 缺點: 冷啟動期 agent 表現差、依賴專家持續使用和糾正的意願、結晶需要紀律（不定期整理，就只是一堆散落的對話）。
  • 適合: 專家本人就是 agent 使用者的場景、長期一對一協作的 agent。不適合「專家即將離開、需要搶時間」的場景。

六條路線的共通原則

把六條路線攤開看，不管走哪一條，有四個原則是共通的。

1. 要萃取的東西是一樣的: 原則、思維模型、決策準則、可執行步驟。所有認真的做法都反對「格式重排就當萃取完成」，COLLEAGUE.SKILL 和 skill-distillery 在這點上講得最明白。

2. 第一版永遠是草稿: Siemens 靠失敗案例回頭補訪、COLLEAGUE.SKILL 把修正和回滾設計成一級操作、Nurture-First 乾脆把迭代當成方法本身。沒有任何一條路線宣稱一次到位，差別只在迭代的觸發方式: 評估失敗、使用者糾正，或是定期結晶。

3. 知識放到哪裡，分法是固定的: 能寫成程式碼的規則放 scripts/、判斷式知識寫進 SKILL.md、深度參考放 references/、品質標準寫成 eval。AgentPatterns 把對應關係整理得很清楚:

萃取產出 編碼成什麼 適用時機
明確規則（「做 Y 之前一定要檢查 X」） 硬性約束或 scripts/ 程式碼 不可妥協、機器可檢查
情境判斷（「情境 Z 時偏好 A 不選 B」） SKILL.md 裡附說明的範例 依賴脈絡、寫不成規則
品質標準（「這個輸出不好，因為…」） eval 測試加上評分準則 用來校準自動評估

小編覺得第三列最容易被忽略: 有些專家知識最適合的存放形式不是 prompt，而是 eval。太依賴當下脈絡的判斷，硬寫成靜態規則，平均來看是對的，但在最要緊的個案上反而出錯，不如寫成 eval 去測試行為。

4. 萃取完，還要壓縮: 訪談逐字稿、蒸餾出來的草稿，就算整理成文件通常還是太長。直接塞進 skill 會佔掉大量上下文，效果反而變差。壓縮是獨立的一道工序，具體做法值得單獨講，見下一節。

壓縮的做法: 不是摘要，而是重組

壓縮這個主題，Knowledge Activation 這篇講得最完整。作者是 Yahoo 的工程師，框架實際部署在 Yahoo 內部，論文還附了 67 位工程師的使用調查，不是純理論。它把知識進入 skill 的過程拆成三個階段: 「編碼」(codification) 把散落在專家腦中、操作手冊、事故報告裡的知識轉成明確結構; 「壓縮」(compression) 把它重組成精簡的「原子知識單元」(AKU); 「注入」(injection) 則在執行時只把當下需要的單元載入上下文。

其中壓縮階段是精華。論文強調壓縮不是摘要，而是有原則的重組，關鍵做法有四個:

  • 刪掉修辭性內容: 鋪陳背景的段落、截圖、對其他文件的交叉引用，這些是寫給人看的，對 agent 只是負擔。留下來的是: 意圖、步驟、該用的工具、限制條件。
  • 可執行的內容放最前面: 描述資訊內嵌在條目裡，並且順著模型注意力的特性安排資訊位置，重要的東西不要埋在中段。
  • 一個單元只做一件事: 每個知識單元只涵蓋一件連貫的動作，跨主題的內容不塞進同一份文件，而是宣告成「接下來去哪」的連結，讓 agent 執行時自己走訪相關單元。這其實就是 skill 漸進式載入的精神，放大到整個知識庫來做。
  • 能驗證的規範寫成程式: 組織規範不用散文描述，直接寫成可執行的驗證腳本 (validator)，讓 agent 的產出能被自動檢查。又一次呼應「能寫成程式碼的就寫成程式碼」。

效果用論文自己的例子來看: 一份 2,000 token 的敘事式部署手冊，重組之後只剩約 300 token，任務完成能力不變，知識密度提升 6 到 7 倍。論文還引用「上下文品質劣化」(context rot) 的研究提醒: 塞進上下文的冗餘內容不只是浪費，還會實際拉低 agent 的推理品質。所以壓縮不是省成本的最佳化，是正確性的必要條件。

怎麼選: 一張對照表

路線 前提 專家成本 拿得到 拿不到
A. 人工訪談 專家在、有好的訪談者 高（每場 60-90 分鐘） 為什麼、判斷邊界 專家意識不到的習慣
B. AI 訪談 專家願意配合 中 結構化規則、可規模化 深度追問的細節
C. 數位足跡蒸餾 有數位足跡 零 實際行為模式 數位足跡外的判斷、為什麼
D. 示範錄製 工作在螢幕上進行 低（做一遍） 操作步驟、順序 為什麼、替代方案
E. 教材蒸餾 有現成教材 零 結構化的方法 失敗處理、實戰細節
F. 互動結晶 專家持續使用 agent 低（分攤在日常） 演化中的真實判斷 冷啟動期的能力

實務上的組合大概是: 有數位足跡先蒸餾 (C)、有教材先打底 (E)、有螢幕操作先錄示範 (D)，這三條便宜的先做，產出第一版草稿。然後把最貴的專家訪談時間 (A/B) 留給草稿裡的缺口: 為什麼、邊界條件、失敗處理。上線之後切換到互動結晶 (F) 持續演化，用 eval 的失敗案例決定下一輪要補訪什麼。

換句話說，六條路線不是互斥的選項，而是同一個流程的不同階段: 便宜的路線負責涵蓋面，昂貴的路線負責深度，持續的路線負責不過時。真正的關鍵決策只有開頭那一個問題: 你要萃取的那位專家，他的知識現在存在哪裡? 而起點可以很輕: Siemens 就是兩位專家、各 90 分鐘、開放式問題加情境追問，先做出第一版，讓失敗案例告訴你接下來要補什麼。老師傅的知識不會自己變成文件，但把它變成組織資產的成本，已經比以前低非常多了。