continuous-learning

continuous-learning skill 概覽

continuous-learning skill 會做什麼

continuous-learning skill 會把 Claude Code 的工作階段轉成可重複使用的已學習技能。它是為了這類使用者設計：希望助手能在每次工作階段結束時，自動辨識重複出現的模式、實用的修正方式，以及專案特有的技巧，並保存下來供之後重用。若你想找的是一個能根據自己過往工作歷程，幫 Claude 持續改進的 continuous-learning skill，這正是對應的自動化類型。

適合哪些人使用

這個 skill 最適合經常在不同工作階段裡處理相似問題，並希望這些解法能被自動記錄下來的 Claude Code 使用者。對 skill 作者、repo 維護者，以及重度使用者尤其有幫助，因為它能保留除錯模式、替代作法與專案慣例，不必每次都手動把經驗整理成文字。

它和其他方案有什麼不同

它最核心的差異在於：這個 continuous-learning skill 是以 Stop hook 為基礎，而不是只靠 prompt。也就是說，它會在工作階段結束後統一評估一次，而不是在即時對話過程中檢查每一則訊息。這種做法更單純、更輕量，也更容易理解整體行為；但相對地，它的涵蓋範圍也比 continuous-learning-v2 這類較新的方案更窄，而 repo 本身也把後者視為新安裝時更優先考慮的路線。

如何使用 continuous-learning skill

安裝並接上 hook

先把 continuous-learning skill 安裝到你的 Claude skills 目錄，再把它接到 Stop hook，讓它在工作階段結束時自動執行。repo 內的 script 預設會放在 ~/.claude/skills/continuous-learning/，並把學習結果寫入 ~/.claude/skills/learned/。實際在評估是否安裝時，重點通常不在於「能不能加上去」，而是你是否想把「工作階段結束後自動抽取經驗」納入平常的 Claude 使用流程。

一開始就提供對的輸入內容

這個 skill 只有在工作階段本身有足夠內容可供抽取時，效果才會好。預設的最短工作階段長度是 10 則訊息，所以非常短的對話通常不會產出有價值的已學習技能。若你想讓 continuous-learning usage 發揮較好效果，請盡量提供包含真實問題、修正過程、替代方案，或可重複技巧的工作階段，而不是只有單次問答。

先讀這幾個檔案

實際設定時，建議先讀 SKILL.md，再看 config.json，最後看 evaluate-session.sh。照這個順序，你會先知道這個 skill 的用途，再理解有哪些參數可調，最後看懂 Stop hook 是怎麼實作的。若你想調整門檻、輸出位置，或它會偵測哪些模式，config.json 是最關鍵的檔案。

調整 prompt，讓抽取結果更實用

如果你打算把這份 continuous-learning guide 納入自己的工作流程，請讓工作階段描述得夠明確，讓 hook 能辨識出可重用的行為模式。好的輸入像是：「我需要一套可重複執行的方法來除錯這個 repo 的安裝失敗問題；請把步驟和最後修正整理成可重用模式。」較弱的輸入則像是：「幫我處理這個。」前者提供了穩定且可學習的內容，後者通常很難留下可持續重用的模式。

continuous-learning skill 常見問題

如果我想要自動學習，這是對的 skill 嗎？

是，如果你的目標是從 Claude Code 的工作階段中自動抽取可重用模式，並將它們保存成 learned skills。若你想要的是一個能從過去工作紀錄中安靜累積、改善未來工作階段表現的 continuous-learning skill，這個方案很適合這類需求。若你期待的是更主動、偏直覺式的系統，repo 本身則會引導你改看 continuous-learning-v2。

它和一般 prompt 相比差在哪裡？

一般 prompt 可以描述你想要什麼，但工作階段結束後不會留下任何可持續使用的結果。這個 skill 多了一層工作流能力：它會偵測可重用的模式，然後把它們寫進 learned-skills 目錄。對於團隊反覆處理的問題，或 repo 特定的工作方式來說，它比一次性的指令更有價值。

對新手友善嗎？

算中等。它的邏輯不複雜，但安裝設定需要理解 Claude Code hooks、工作階段邊界，以及 learned skills 會存在哪裡。新手只要嚴格照著提供的檔案設定，還是能用；但如果 hook wiring 和 config 沒有設好，就不要期待它能穩定運作。

什麼情況下應該跳過它？

如果你只想要臨時性的協助、工作階段通常都很短，或你不希望自動抽取內容寫進本機 skills 資料夾，那就不建議安裝這個 continuous-learning。另外，如果你已經很清楚自己要走較新的 continuous-learning-v2 路線，它也不會是最合適的選擇。

如何改善 continuous-learning skill

在評價結果前，先調好 config

影響最大的控制點是 config.json。請依照你實際有價值的工作階段長度，調高或調低 min_session_length；如果這個 skill 判斷得太保守或太積極，也可以調整 extraction_threshold。若你特別在意某些模式類型，就把 patterns_to_detect 聚焦在最符合你工作內容的項目上。

給 hook 更清楚的模式訊號

當工作階段裡包含明確的修正、重複的除錯步驟，或有命名清楚的 workaround 時，這個 skill 的效果會更好。舉例來說，「第一個修正失敗，是因為問題其實出在 path resolution；請把這個差異記錄下來」會比一般性的成功訊息好得多。輸入越具體，抽取出的 learned skill 就越可操作，也越不容易流於空泛。

留意常見失敗模式

最常見的失敗情況，是它過度學習一些其實沒什麼價值的變動，例如 typo、一次性的修補，或本來就該忽略的外部 API 問題。另一種情況則是保存了過度綁定單一專案、很難在其他地方重用的模式。如果你發現輸出太吵雜，就要縮小「哪些內容值得被當成可重用經驗」的範圍，並把工作階段聚焦在真正的決策或技巧本身。

從已保存的輸出反覆修正

第一次跑完之後，請檢查 ~/.claude/skills/learned/ 裡產生了什麼，並問自己：這些抽出的項目，真的能幫助未來的工作階段嗎？如果不能，就收緊模式判準，或調整你在工作階段中描述問題的方式。這個回饋循環，正是讓 continuous-learning for Skill Authoring 真正變得有用的關鍵：來源工作階段越好，最後得到的可重用 skill 就越好。