【Agent Skills實戰】我寫了一個從 Claude Code 歷史對話裏挖 Skill 的 Skill
整理版優先睇
分享從 Claude Code 歷史對話挖出值得沉澱成 Skill 嘅兩個工具同方法論
呢篇文章係一個 Claude Code 重度用戶嘅實戰分享。佢成日用 Claude Code 做文字工作，例如寫 blog、寫教程，漸漸發現有啲工作係重複做嘅，例如成日要指導 AI 調整同一類內容，或者改完 Skill 產出之後又要做類似修改。佢認為呢啲「又嚟一次」嘅感覺，就係值得整一個新 Skill 嘅信號。不過呢啲信號散落喺 ~/.claude/projects 底下嘅舊對話入面，平時無人會翻。
為咗解決呢個問題，佢寫咗兩個 Skill，組成一條流水線：claude-session-manager 負責將原始 JSONL 格式嘅會話導出成乾淨嘅 Markdown；mining-session-skills 負責分析呢啲 Markdown，判斷有冇值得做成 Skill 嘅嘢。成個過程係對話式嘅，有兩個確認點（揀邊場對話同批准提案），唔會自動生成一堆垃圾 Skill。
佢最後嘅結論係：關鍵唔係自動產生一大堆 Skill，而係要有一道「值唔值得」嘅門。真正有用嘅 Skill 係需要人嘅品味同判斷嗰啲，唔係重複步驟。呢個方法論先係最有價值嘅部分。
- 將原始 JSONL 會話導出成乾淨 Markdown，可以將 token 數由~1.5M 降到~91k，節省 17 倍成本。
- 導出時將工具調用結果放入 sidecar 附屬文件，正文只留乾淨對話同 <tool_call> 引用，令閲讀同 AI 處理都更爽。
- 決策關鍵係一道「值唔值得」嘅門：流程係咪唔顯而易見？係咪需要你嘅品味同判斷？係咪同標準做法唔同？
- 實際使用時只需用大白話描述（例如「上次修個人網站 bug 嗰場對話」），系統會定位、切段、挖摩擦信號，最後畀三種結論：新建、更新或已有。
- 作者用「演練」方式先手動跑方法論，結果未寫成嘅 Skill 已經挖到一個真 Skill 同發現第一個 Skill 嘅 bug，證明方法有效。
claude-session-manager
將 Claude Code 原始 JSONL 會話導出成整理過嘅 Markdown，包括 sidecar 附屬文件處理
mining-session-skills
讀取導出嘅 Markdown，分析有冇值得做成 Skill 嘅嘢，提供提案
兩個 Skill，一條流水線
呢兩個 Skill 分兩層。claude-session-manager 係導出層，將 Claude Code 嗰啲睇唔明嘅會話檔轉成整理過嘅 Markdown。mining-session-skills 係判斷層，讀呢啲 Markdown 然後答一條問題：呢場對話入面有冇值得做成 Skill 嘅嘢？
流水線係咁行：JSONL 會話 → [導出] → 可讀嘅 Markdown → [挖礦] → 提案：新建 / 更新 Skill。拆開嘅原因係兩件事本質唔同：導出係數據清洗，挖礦係帶判斷嘅分析。分開每個 Skill 都細、都專一，第二個仲可以直接複用第一個嘅成果。
點解要先導出？
原始 JSONL 會話檔又重又雜，直接用嚟做分析唔划算。作者用真實會話量過：原始 JSONL 大約 150 萬 token，塞入上下文好吃力；導出之後嘅正文得大約91,000 token，細咗差唔多 17 倍。
導出嘅秘訣係將每一步嘅工具調用結果（即係命令輸出、檔案內容）全部放入一個叫sidecar 嘅附屬文件。正文只留乾淨嘅對話同 <tool_call> 引用，要睇細節先去 sidecar 度翻。咁樣讀起嚟清爽，AI 處理時亦更慳 token。
唔係自動生成，而係「值唔值得」嘅門
講到挖礦，好多人第一反應係「揾出重複步驟，自動生成 Skill」。但作者查咗高手嘅做法之後發現呢條路錯嘅。Superpowers 作者 Jesse Vincent 講過：如果一件事 Claude 一次就做得好，整成 Skill 係零價值。真正有用嘅 Skill 係過程唔顯而易見、需要人嘅品味同判斷、或者做法同標準唔同嗰啲。
所以作者設計咗一道「值唔值得」嘅門（worth-it gate）：呢個流程係咪唔顯而易見？係咪需要你嘅品味同判斷？係咪同標準做法唔同？每一個候選都要過呢道門，過唔到就 reject。如果成場對話一個都過唔倒，佢會話「今次冇乜值得做」——呢個係合法、有價值嘅答案，唔係失敗。
實際點樣行
用法好自然：唔使記會話 ID，用大白話描述就得，例如「上次我整個人網站個連線重置嘅 bug，嗰場對話挖唔挖到啲咩 Skill」。成個流程係咁：
- 1 定位：按關鍵字搜，畀個排好咗嘅候選清單你，你確認係邊場；未導出嘅會先導出。
- 2 讀：讀乾淨嘅 Markdown，再用一個 extract_session_signals.py 小 script 篩出你真係講過嘅嘢（避免撈埋工具回傳嘅內容）。
- 3 切段 + 挖：一場對話可能橫跨幾日、幾個任務，先切開話題段，每段單獨挖摩擦信號——你糾正佢嘅地方、重複手動步驟、行過嘅死路、你補充嘅領域知識。
- 4 過門 + 決策：存活嘅候選同你而家加載緊嘅 Skill 比較，畀三個結論之一：新建、更新、或者「呢個已經有，唔好重複造」。
- 5 提案：停低，先畀一份報告（候選、動作、原因、證據、建議名同觸發描述），唔改任何嘢。你點頭先起草，起草前仲會反問你對話睇唔到嘅取捨。
成個過程係對話式、帶閘門嘅，有兩個確認點：確認係邊場對話，同埋批准提案。方向盤始終喺你手度。
我點樣造出呢個 Skill
呢部分可能比 Skill 本身仲有趣。作者冇手寫，而係用 Claude 自己嘅方法論造出嚟。起初用 brainstorming 釐清想做乜，仲推翻咗最早嘅想法。跟住上網研究高手經驗。最關鍵一步係：在寫任何 code 之前，先用手行一次方法論（作者叫佢做 drill），用自己嘅真實會話做靶。
確認方法論管用之後，作者先寫設計文檔同實現計劃，然後用 subagent 配合 TDD，逐個任務實現、評審、合併。
我是 Claude Code 的重度用戶，平時很多文字活 - 寫博客、寫教程 - 都在它上面做。用久了會發現一件事：有些工作我在反覆地做。比如反覆指導它調整某一類內容；比如它基於某個 Skill 產出的東西，每次都要做幾乎一樣的修改。
這種“怎麼又來一遍”的感覺，其實是個信號 - 說明這裏有個 Skill 可以新建、或者可以改，讓下次更順。可這些信號都散在一場一場過去的對話裏，躺在 ~/.claude/projects 下，平時不會有人回頭去翻。
這篇文章分享我為這件事做的兩個 Skill - 幫我回頭看這些對話，判斷出哪裏值得沉澱成一個 Skill。
GitHub
https://github.com/sugarforever/01coder-agent-skills/tree/main/skills/claude-session-manager
https://github.com/sugarforever/01coder-agent-skills/tree/main/skills/mining-session-skills
兩個 Skill，一條流水線
這是兩個 Skill，分兩層。
claude-session-manager 是導出層，把 Claude Code 那些沒法直接看的會話文件，轉成整理過的 Markdown。mining-session-skills 是判斷層，讀這些導出的 Markdown，回答一個問題 - 這次對話裏，有沒有值得做成 Skill 的東西？
JSONL 會話 → [導出] → 可讀的 Markdown → [挖礦] → 提案：新建 / 更新 Skill為什麼要分兩層？因為這兩件事是不一樣的活。導出是數據清洗，挖礦是帶判斷的分析。拆開，每個 Skill 都小、都專一，第二個還能直接複用第一個的成果。
為什麼先導出一遍
原始會話文件就在那，為什麼不直接讀，非要先導出一道？
直接基於原始 JSONL 來做，其實也不是不行 - 內容都在裏面，grep、解析都能跑。只是它又重又雜，處理起來不划算。我用一個真實的會話量過：原始 JSONL 大約一百五十萬 token，整篇塞進上下文很吃力；導出之後的正文只有大約九萬一千 token，小了差不多十七倍。
grep '"type":"user"' 是陷阱（工具結果也算 user） | ||
秘訣在於，導出把每一步的工具調用 - 那些又長又重的命令輸出、文件內容 - 全甩進一個叫 sidecar 的附屬文件。正文只留乾淨的對話和一個個 <tool_call> 引用，需要看某一步的細節，再去附屬文件裏翻那一條。
所以導出不是必須的，但很值 - 讓人讀着清爽，也讓 AI 在理解和處理時更省 token。後面的挖礦基於這個乾淨的底子做，又快又省。
為什麼不是“自動生成一堆 Skill”
講到挖礦，很多人第一反應是 - 找出重複的步驟，自動生成 Skill 不就行了。
我一開始也這麼想。但查了一圈高手怎麼做，才發現這條路是錯的。
Superpowers 的作者 Jesse Vincent 有一句話，大意是 - 如果一件事 Claude 一次就能做好，那給它做成 Skill，價值是零。真正有用的 Skill，是那些過程不顯而易見的、需要人的品味和判斷的、或者你的做法跟標準做法不一樣的。
這就推翻了“自動生成”。一個只會找重複步驟的工具，會造出一大堆垃圾 - 全是 Claude 本來就會的事。
Anthropic 官方的說法也是一個意思 - 寫 Skill 之前，先假設 Claude 已經很聰明，只記錄它不知道的東西，你的規矩、你的非常規流程。他們甚至直說，你不需要一個“教你寫 Skill”的 Skill，因為格式 Claude 天生就會。
這句話點醒了我 - 這個 Skill 的價值，不能是“它懂 Skill 的格式”，得是那套挖礦的方法論本身。它的核心，是一道“值不值得”的門（worth-it gate）：
這個流程是不是不顯而易見？ 是不是需要你的品味、你的判斷？ 是不是和標準做法不一樣？
每一個候選都要先過這道門，過不了的直接拒。如果整場對話挖完一個都沒過，它就告訴你“這次沒什麼值得做的” - 這是一個合法的、有價值的答案，不是失敗。
它實際怎麼跑
用法很自然 - 你不用記會話 ID，用大白話描述就行，比如“上次我修個人網站那個連接重置的 bug，那次對話能挖出什麼 Skill”。
流程是這樣的：
定位 - 按關鍵詞搜，給一個排好序的候選清單，你確認是哪一場；沒導出的先導出。 讀 - 讀那份乾淨的 Markdown，再跑一個 extract_session_signals.py小腳本，把你真正說過的話篩出來。這裏有個坑 - 工具返回的結果在底層也標成“用戶”，天真地按“用戶”抓會抓出一大堆假的。同一場對話，天真抓是四百多條，腳本篩完是二十幾條真的。切段 + 挖 - 一場對話可能橫跨好幾天、好幾個任務，先切成話題段，每段單獨挖摩擦信號 - 你糾正它的地方、反覆的手動步驟、走過的死路、你補充的領域知識。 過門 + 決策 - 活下來的候選跟你這次加載的 Skill 比一比，給出三種結論之一：新建、更新、或者“這個已經有了，別重複造”。 提案 - 它停下來，先給一份報告（候選、動作、為什麼、證據、建議的名字和觸發描述），不碰任何文件。你點頭了才起草，起草前還會反過來採訪你，問那些對話裏看不出來的取捨。
整個過程是對話式的、帶閘門的，不是一鍵搞定。兩個確認點 - 確認是哪場對話、批准提案 - 始終把方向盤留在你手裏。
我是怎麼造出它的
這部分可能比 Skill 本身更有意思。因為我沒有手寫它，而是用 Claude 自己的一套方法論造出來的。
一開始我沒急着寫代碼。先用 brainstorming 釐清到底要做什麼 - 中間還推翻了自己最早的想法。然後上網研究高手的經驗。
接下來這一步最關鍵 - 在寫任何代碼之前，我先用手把這套方法論跑了一遍，拿自己的真實會話當靶子，我管它叫 drill，演練。
這場演練當場就有收穫。它從一場“把推文翻譯成博客”的舊對話裏，挖出了一個真實可做的新 Skill - 怎麼把推文翻成中文博客，還帶上我那些非常規的編輯習慣（比如去翻原推回復區找勘誤）。更妙的是，它還順手挖出了第一個 Skill 自己的一個 bug - 導出格式和文檔對不上。
這個畫面值得品一下 - 這個還沒被寫出來的 Skill，在演練階段就挖出了一個真 Skill，還挖出了餵給它數據的那個工具自己的毛病。它自己驗證了自己。
確認方法論真的管用之後，我才寫設計文檔、寫實現計劃，然後用 subagent 配合 TDD 一個任務一個任務地實現、評審、合併。
怎麼用，以及一點收穫
有一個前提 - 它判斷該新建、更新、還是直接複用，靠的是你當前這個會話里加載了哪些 Skill。邏輯很直接：一個候選如果落在某個已加載 Skill 的範圍裏，就建議更新那個；如果那個 Skill 是裝好的插件、改不了，就提示你直接複用；只有沒有任何已加載 Skill 覆蓋它，才建議新建。所以相關 Skill 沒加載，它就看不見 - 可能把本該更新或複用的，誤判成新建。這不是判斷準不準，而是它能比對的範圍，只有已經加載的那些。
觸發用大白話就行 - “幫我看看上次那場對話能挖出什麼 Skill”，然後它照那條流水線走，最後停在提案這一步等你點頭。
兩個 Skill 合起來 - claude-session-manager 把沒法讀的會話導成能挖的 Markdown，mining-session-skills 在上面判斷有沒有值得沉澱的 Skill。讓你和 AI 的協作，越用越快。
關鍵不在於自動產出一堆 Skill，而在於那道“值不值得”的門 - 這也是我自己做完這件事最大的收穫。