脈絡檔案貫穿設計
脈絡檔案貫穿設計
定義
把使用者／情境的核心脈絡（背景、目標、約束、過往決策）固化成一份結構化檔案，讓後續所有 AI 產出階段都讀同一份檔案作為上下文，而不是在每個階段重新蒐集或重新交代。脈絡檔案決定了「同樣的標準化程序輸入不同人，會產出不同結果」——個人化的差異化來自脈絡檔案，而非 prompt 或模型本身。
關鍵數據點（附來源）
- 個人化 AI 學習工具用
intake.json五維度（Topic、Learner Profile、Target Outcome、Time Budget、Application Context）作為跨 skill 共讀的脈絡檔案，課綱設計、章節生成、聊天陪讀全部引用同一份檔案（personalized-learning-with-claude-code-skills） - 第一版把脈絡與規則塞進同一個巨大 prompt 撐兩週就壞——不同階段的指令互相干擾，分階段拆檔之後關鍵設計反而很無聊：「分階段 + 各階段讀對的檔案」（personalized-learning-with-claude-code-skills）
- 同一個「我想學 AI」針對旅行社老闆與保險業前主管產出完全不同的課綱（前者拉前自動化工具，後者排除圖片生成、拉前知識庫長文寫作），差異化全部來自脈絡檔案的內容（personalized-learning-with-claude-code-skills）
前提與局限性
- 假設使用者願意先花時間填脈絡檔案——對「探索式好奇心驅動」的場景反而過早收斂
- 脈絡檔案有時效性：學習者中斷一個月再回來，progress 是否需要 reset？產品脈絡半年後是否還準確？
- 完全的初學者填不出有效脈絡——選項題能緩解模糊但救不了 Dunning-Kruger 邊界
- 脈絡檔案 schema 本身需要設計：欄位太少抓不到重點，太多使用者填不下去；五個必填維度是當前的折衷
適用場景與遷移路徑
- 個人化學習：intake.json 貫穿訪談、課綱、章節、陪讀（已實作）
- 個人化醫療：EMR 病歷貫穿問診、處方、追蹤——同構映射，且醫療界已累積數十年的脈絡檔案設計經驗可參考
- 產品 onboarding：user persona + JTBD 貫穿 onboarding、推薦、互動，每一階段讀同一份 persona 檔案
- 顧問報告產出：
client-context.json（產業、規模、痛點、既有系統）讓提案、報告、簡報都對齊客戶當下狀態 - 程式碼審查：專案 context 檔（語言、團隊風格、過去 bug pattern）讓審查標準動態調整
- 架構決策：ADR 是已驗證的脈絡檔案模式，把為什麼決定做這個固化下來，後續所有決策都引用
設計原則
- 檔案要結構化——schema 先定義好，避免變成自由格式的隨筆
- 必填維度要少——五個左右是甜蜜點，多了使用者填不下去
- 每個階段都讀同一份——避免不同階段各自存一份導致脈絡漂移
- 要能演化——支援增量更新（progress.json 持續累積），不是一次填完就鎖死
- 誠實面對局限性——使用者填不出來的部分（known_misconceptions）需要設計成系統能輕推的選項，而不是硬要對方寫
衝突標記
無直接衝突。與「即時生成、不存狀態」的純對話式 LLM 應用形成張力：純對話式上手快但無法跨階段維持個人化；脈絡檔案前期成本高但後續每一輪輸出都更精準。哪個對的取決於使用場景的時間跨度（一次性 vs 長期）。
關聯概念
- [[用 AI 反向學習]]——脈絡檔案貫穿設計是反向學習的具體機制
- [[教學設計模組化]]——本概念在教學設計領域的具體實作
- [[Claude Code Skill 系統]]——脈絡檔案是 skill 之間共享的「狀態」，補足 skill 觸發即載入的瞬時性
- [[CLAUDE.md 與記憶機制]]——脈絡檔案是工作流層的記憶，CLAUDE.md 是人機介面層的記憶