知識整理：從筆記到 Wiki 條目萃取
用途
把散落的筆記、文章、會議記錄或口白摘要整理成結構化的 Wiki 條目，每個條目有定義、用法、關聯概念，方便未來搜尋和引用。
何時用
- 適合：累積了一批未整理的筆記或研究素材，想提煉成可以長期使用的知識條目時。
- 不要用：你只需要當天讀完某篇文章的臨時摘要——那種情況用當下的 chat 就夠了，不需要建成可長期維護的 Wiki 格式。
Prompt
幫我從以下原始筆記中萃取 Wiki 條目。
原始素材（直接貼入）：
{{貼上筆記、文章摘要、會議記錄，或口白轉錄文字}}
請從中找出 3-7 個可以獨立成條目的概念（不要強行湊數，找到幾個算幾個），每個條目輸出以下格式：
---
# {{概念名稱}}
**一句話定義**：{{30 字以內，可以直接背起來的那種}}
**是什麼 / 為何重要**：{{100-150 字，說清楚這個概念解決什麼問題}}
**怎麼用（實際場景）**：{{1-2 個具體使用情境，不要舉抽象例子}}
**關聯概念**：{{2-3 個，說明與哪個概念有關以及關係是什麼}}
**實用技巧或常見誤用**：{{1-2 點}}
**來源**：{{原始資料的標題或出處}}
---
如果某個概念在原始素材中資訊不足以填完所有欄位，直接說「資訊不足，建議補充 XX」，不要自行補充。範例 / 變體
- 填好變數：貼入一篇關於 RAG 架構的會議筆記，AI 可能萃取出「向量資料庫」「Embedding」「Retrieval 精準度」三個條目，每個都有獨立定義和使用情境。
- 變體（單一概念深化）：如果只有一個概念想整理成條目，把「找 3-7 個」改成「這個概念的完整 Wiki 條目」，讓 AI 做深度而不是廣度。
- 變體（中英對照）：在輸出格式最後加「概念名稱同時給中文和英文」，適合需要跨語言引用的技術知識庫。
🎯 範例輸出（實測）
在 Claude.ai 跑這句、把
{{貼上筆記}}填成「會議記錄：和客戶討論 RAG 系統，提到 chunk size 設太大會讓 embedding 混入不相關內容導致召回率下降；vector store 選型上客戶傾向用 Qdrant 因為支援 payload filter；另外客戶說他們最在乎 AI 回應的格式一致性，不是速度」的結果：
點開看 AI 實際輸出
Chunk Size 與 RAG 召回率的關係
一句話定義：RAG 系統中，chunk size 過大會讓 embedding 混入不相關語義，導致向量搜尋召回的段落精準度下降。
是什麼 / 為何重要：Chunk size 決定每個送進 embedding model 的文字片段大小。片段太大，一個 chunk 裡同時含有多個主題，向量化後的「重心」模糊，查詢時容易召回不相關段落；片段太小，上下文不足，召回的段落缺乏意義。對企業知識庫來說，chunk size 是影響 AI 問答品質最直接的參數之一。
怎麼用（實際場景）：在設計企業 FAQ 知識庫時，先測試 chunk size 256 / 512 / 1024 token 三組，用同一批測試問題評估召回精準度，再選定生產設定。
關聯概念：Embedding 模型（決定語義表示）、Retrieval 精準度（最終使用者感知到的 AI 品質）、Vector Store 索引設計
實用技巧或常見誤用：常見誤用是直接套用預設值（通常 512 token）不做測試。不同文件類型（合約 vs. FAQ vs. 技術文件）適合不同的 chunk size。
來源：客戶訪談記錄，2026-06-04
Qdrant Payload Filter
一句話定義：Qdrant 向量資料庫的 payload filter 讓你在做向量相似度搜尋時同時過濾結構化欄位（如部門、文件類型、日期）。
是什麼 / 為何重要：純向量搜尋無法區分「這份文件屬於哪個部門」或「這是今年的還是去年的」，payload filter 補足這個缺口，讓語義搜尋 + 條件篩選同時進行，適合企業需要按部門或時間隔離知識的場景。
怎麼用：在 n8n Qdrant 節點設定 filter 條件，例如 {"must": [{"key": "dept", "match": {"value": "HR"}}]}，查詢時只召回 HR 部門的文件。
關聯概念：Vector Store 選型、RAG 架構、metadata 設計
實用技巧或常見誤用：資訊不足，建議補充：Qdrant 相對其他 vector store（Pinecone、Weaviate）的 payload filter 效能比較資料。
來源：客戶訪談記錄，2026-06-04
企業客戶最在乎 AI 輸出的格式一致性
一句話定義：（觀點）在企業 AI 導入場景中，輸出格式的可預測性比生成速度更受使用者重視。
是什麼 / 為何重要：格式不一致讓下游流程（把 AI 輸出複製進系統、轉給同事確認）增加人工處理成本。速度快但格式亂的 AI，實際使用率往往低於速度慢但輸出穩定的 AI。
怎麼用：在企業 AI 培訓中，優先教「如何用 System Prompt 或 CLAUDE.md 規範輸出格式」，而非先教功能操作。
關聯概念：Prompt 設計、CLAUDE.md 設定、AI 輸出驗收 SOP
實用技巧：讓客戶先列出「最不能接受的格式問題」（例：表格欄位不固定、標題層級隨機），再把這些寫成禁止規則，比給 AI 正向描述更有效。
來源：客戶訪談記錄，2026-06-04（觀點，非研究數據）
💡 實測心得：「一句話定義」最難寫，可以先讓 AI 給三個版本再選——通常第一版太長、第二版太學術、第三版才接近「背起來能用的那種」。
延伸
重點來了：Wiki 條目和筆記最大的差別不是格式，而是「一句話定義」——那句話能不能讓你三個月後再看還立刻知道這個概念是什麼，決定了這個條目有沒有長期使用的價值。萃取完後，可以搭配「知識孤島連結器」找出不同條目之間的隱性關聯，創造新洞察。