編譯摘要 — Claude Code Skills 打造個人化 AI 學習工具

編譯摘要

編譯摘要：Claude Code Skills 打造個人化 AI 學習工具

第一步：濃縮

結論 1：個人化的關鍵是「脈絡檔案貫穿全流程」，不是把 prompt 寫長

  • 四個 skill（intake / syllabus / chapter / tutor）都讀同一份 intake.json，五個維度：Topic、Learner Profile、Target Outcome、Time Budget、Application Context
  • 同一個「我想學 AI」對旅行社老闆與保險業前主管產出完全不同的課綱：前者拉前自動化工具，後者排除圖片生成、拉前知識庫與長文寫作
  • 第一版把所有規則塞進一個巨大 skill 撐兩週就壞掉——不同階段的 prompt 互相干擾，Claude 在訪談中途讀不存在的章節
  • 拆成四個 skill 後關鍵設計反而很無聊：分階段 + 各階段讀對的檔案

結論 2：把專業方法論模組化成 Skill = 把學科知識變成可組合的工作流元件

  • intake → Socratic 提問；syllabus → UbD 倒推 + 4C/ID whole-task；chapter → 4C/ID 七段 + Make It Stick 六機制；tutor → Socratic + Feynman + Confabulation 偵測
  • Skills 不是 prompt template，是「什麼時候該做什麼、該讀哪些檔案、該寫到哪裡去」的工作流定義
  • Claude Code 的 channel kind 欄位（intake / syllabus / chapter / reader）對應 skill 觸發，自動切換上下文不互相污染

結論 3：個人化是持續的——讀的過程也要能改

  • chat 介面三個出口：修改此段（重寫某段並 commit）、追加章節（自動排先備依賴跟順序）、餵自己的資料進去（PDF / 筆記比對 intake 脈絡重寫）
  • subagent 機制把 60-90 秒的長任務丟到背景，學習者在前端繼續讀
  • 「今天的疑惑可以變成明天章節的修訂、今天發現缺的子題可以變成明天的新章節」——個人化是持續更新的脈絡，不是一次訪談的快照

第二步：質疑

對結論 1（脈絡檔案貫穿）

  • 前提假設：使用者願意花 5-10 分鐘訪談，且能誠實／具體回答 — 完全的初學者連自己想學什麼都說不清楚，選項題救不了 Dunning-Kruger 邊界
  • 邊界條件：方法假設學習有明確目標 — 對「探索式好奇心驅動」的學習（隨便逛、看看自己對什麼有興趣），脈絡檔案反而是過早收斂的限制
  • 樣本量：只有兩個朋友的對比例子 — 沒有量化驗證 N 個人化的實際效果，可能存在倖存者偏差

對結論 2（Skills 模組化方法論）

  • 前提假設：教學理論本身有效、可形式化 — UbD、4C/ID、Make It Stick 都建立在特定學習脈絡（學科知識、認知負荷模型）上，硬套到運動、藝術等程序性技能會卡住
  • 誤用風險：模組化降低了使用門檻，但 skill 之間的編排（哪個階段觸發哪個 skill）本身需要設計者懂教學理論 — 新手把規則拼裝成不對的順序，結果可能比沒有 skill 還糟
  • 跨領域有效性的邊界：UbD 強調「先定義可展演的成果」，但對某些創造性學習（寫詩、即興演奏），可展演的成果反而會限制學習者的探索空間

對結論 3（持續個人化）

  • 前提假設：學習者會主動回饋 — 多數學習者讀到不對勁直接放棄，不會回頭按「修改此段」
  • 狀態漂移問題：progress.json 持續累積，學習者中斷一個月再回來，紀錄要不要 reset？ — 文章沒處理「個人化的時效性」這個問題
  • 成本問題：每次修改此段都要跑 60 秒、消耗 token — 對訂閱有 rate limit 的用戶不一定划算；當 chat 變成編輯介面，學習者可能掉進「不斷重寫」的迴圈而不是「往下讀」

第三步：對標

跨域類比 1：軟體開發的 ADR（Architecture Decision Records）

intake.json 之於個人化學習，如同 ADR 之於軟體架構：把「為什麼決定做這個（不做那個）」固化成檔案，後續所有決策都引用同一份文件作為對齊基準。共同模式都是把決策的脈絡固化、讓未來的所有產出能持續對齊——避免「每次重新討論一次」的成本，也避免不同階段的決策互相矛盾。

跨域類比 2：醫療的 EMR（電子病歷）+ 個人化處方

intake 五個維度幾乎是病歷的同構映射：Learner Profile = 病史／既有用藥、Application Context = 治療目標／生活情境、Target Outcome = 期望療效。同一個診斷（「高血壓」「想學 AI」）對不同人開的藥／設計的課程完全不同，因為底層的個人脈絡檔案決定了標準化程序的輸出。個人化醫療長年面對的挑戰（病人說不清楚症狀、跨階段資訊整合、邊界條件）跟個人化學習幾乎同構。

跨域類比 3：產品設計的 user persona + JTBD（Jobs To Be Done）

application_context.use_case = JTBD、learner_profile.related_experience = 既有 mental model、known_misconceptions = pain points。同一個產品給不同 persona 的 onboarding 不一樣這個設計原則，跟同一份課程對不同學習者展開不同章節是同一個結構。差別在於課程的 onboarding 是整本課程，不只是前 3 步。

遷移到哪些場景？

  • 程式碼審查：審查 skill 讀一份「專案 context 檔」（語言、框架、團隊風格、過去 bug pattern），審查標準依專案脈絡動態調整。已部分實現於 Payload CMS review skills，但脈絡檔案尚未系統化
  • 顧問報告產出：每個客戶有一份 client-context.json（產業、規模、痛點、既有系統），所有 AI 產出（提案、報告、簡報）都先讀這份。與 LinkedIn 經營入門心得 中的個人品牌定位有結構相似性
  • SEO 健檢：站點 context（受眾、商業目標、競爭格局）取代「通用 SEO 規則」作為判斷基準

跟現有 wiki 概念的關聯與衝突

  • 補強 [[用 AI 反向學習]]：本文是該抽象概念的具體實作載體
  • 更新 [[Claude Code Skill 系統]]：新增「巨大 skill 整合 vs 多 skill 分工」的衝突標記——本文用兩週撐不下去的踩坑，給出「分工」這一邊的實證案例
  • 新建 [[脈絡檔案貫穿設計]]：跨域可遷移的設計模式
  • 新建 [[教學設計模組化]]：將教學理論寫成可組合 skill 的方法論

編譯產出