跳到主要內容
Cypher's Practical Coding
← LLM Wiki：用 AI 打造個人知識庫
第 3 / 4 課
正在準備工作環境...

讓知識長出複利：Query 回寫與 Lint 健康檢查

存進去的知識如果不會互相連結、不會自我修正，那跟書籤有什麼不同？

課程目標

  • 學會用 Query 回寫讓「查詢結果」變成知識資產
  • 理解 Lint 健康檢查的運作方式，讓知識庫自我修正
  • 掌握 index.md 和 log.md 的維護技巧
  • 建立知識庫的日常維護節奏

一、知識複利的關鍵：Query 回寫

上一課你學會了 Ingest——把新資料整合進 Wiki。但知識庫真正開始「增值」的時刻，是你開始 把查詢結果也存回去。

一個場景

你的知識庫裡已經有三篇 AI 商品推薦的案例（91APP、PChome、蝦皮），你問 AI：

「根據目前 Wiki 裡的三個案例，AI 商品推薦的共同成功因素是什麼？最大的風險是什麼？」

AI 讀完三頁 source 摘要，綜合出一份分析。這份分析本身就是新知識——它不存在於任何一篇原始文章裡，是你的知識庫「長出來」的洞察。

如果你只是看了就關掉聊天視窗，這個洞察就消失了。

但如果你把它存成 wiki/comparisons/ai-recommendation-patterns.md，下次你或同事問類似問題時，Wiki 裡直接就有現成的分析。

怎麼做 Query 回寫

用以下 prompt 結構：

請根據我的 Wiki 回答以下問題。回答完之後，如果你認為這個回答
值得保存，請同時產出一頁新的 Wiki 頁面（包含標題、內容、
建議的檔案路徑），並更新 index.md 和 log.md。

問題：[你的問題]

什麼樣的查詢值得回寫？

值得存不值得存
跨多篇 source 的綜合分析單篇文章的事實查詢
比較表、優劣評估已經在某頁 source 摘要裡的資訊
你自己的決策紀錄一次性的臨時問題
會被重複問到的問題非常具時效性的資訊

經驗法則：如果你覺得「三個月後我可能還需要這個答案」，就存。

二、Lint：讓知識庫自我修正

隨著 Wiki 長大，問題會悄悄累積：

  • 一月的文章說「市場成長 15%」，四月的文章說「市場萎縮 3%」——矛盾
  • 某個概念頁建立後，再也沒有新資料引用它——孤立
  • 五篇文章都提到「LLM Agent」，但沒有專門的概念頁——缺口
  • 引用的數據是 2024 年的，但已經有 2025 年更新版——過時

這些問題人類很難發現（你不會每週把整個知識庫重讀一遍），但 AI 可以系統性地掃描。

Lint 的四種檢查

1. 矛盾偵測

請掃描我的 Wiki，找出任何頁面之間資訊矛盾的地方。
例如：同一個指標在不同頁面有不同數字、對同一件事的評價截然相反。
列出每個矛盾：哪兩頁衝突、衝突的具體內容是什麼。

2. 孤立頁面偵測

請檢查 Wiki 裡有沒有「孤立頁面」——沒有被任何其他頁面連結到的頁面。
孤立頁面可能是被遺忘的知識，需要跟其他頁面建立連結。

3. 知識缺口偵測

請掃描 Wiki，找出「被多次提到但沒有專門頁面」的概念或實體。
這些可能是需要建立新頁面的知識缺口。

4. 過時資訊偵測

請檢查 Wiki 裡有沒有可能過時的資訊。
特別注意：引用的數據超過一年、提到的工具版本可能已更新、
市場趨勢描述可能已經改變。

Lint 的結果怎麼處理？

Lint 不是自動修正，而是產出一份健康報告。你看完報告後決定：

  • 矛盾：哪邊是對的？更新錯誤的那頁
  • 孤立頁面：需要跟哪些頁面建立連結？還是這頁已經不需要了？
  • 知識缺口：現在就建新頁面，還是等有更多資料再說？
  • 過時資訊：有新資料可以更新嗎？還是先標註「待更新」？

三、index.md 和 log.md 的維護

index.md：你的 Wiki 的目錄

隨著頁面增加，index.md 是你和 AI 的「地圖」。格式建議：

# 知識庫索引

## 概念頁
- [AI 商品推薦](concepts/ai-recommendation.md) — 利用機器學習推薦商品，需注意退貨率風險
- [RAG](concepts/rag.md) — 檢索增強生成，適合即時查詢
- [LLM Wiki](concepts/llm-wiki.md) — 用 LLM 編譯維護的知識庫模式

## 實體頁
- [91APP](entities/91app.md) — 台灣電商 SaaS，2025 導入 AI 推薦
- [Vertex AI](entities/vertex-ai.md) — Google Cloud 的 ML 平台

## 來源摘要
- [91APP AI 推薦經驗](sources/91app-ai-recommendation.md) — 點擊率 +23%，退貨回饋是關鍵
- [PChome 個人化首頁](sources/pchome-personalization.md) — 首頁改版，轉換率 +18%

## 比較分析
- [AI 推薦三案例比較](comparisons/ai-recommendation-patterns.md) — 共同成功因素與風險

最後更新：2026-04-07 | 頁面總數：8

index.md 每次 Ingest 和 Query 回寫時都要更新。 如果你發現 AI 常常忘記，在 Schema 裡加粗這個要求。

log.md：你的 Wiki 的歷史

log.md 是 append-only（只加不改）的紀錄。格式建議：

# 操作紀錄

## [2026-04-07] ingest | 91APP AI 推薦經驗分享
- 新增 sources/91app-ai-recommendation.md
- 新增 concepts/ai-recommendation.md
- 新增 entities/91app.md、entities/vertex-ai.md
- 更新 index.md

## [2026-04-07] query | AI 推薦三案例比較
- 新增 comparisons/ai-recommendation-patterns.md
- 更新 index.md

## [2026-04-07] lint | 週例行檢查
- 發現：concepts/rag.md 與 concepts/llm-wiki.md 對 RAG 的評價不一致
- 行動：更新 concepts/rag.md 加入「RAG 的限制」段落

小技巧： log.md 的格式統一用 ## [日期] 操作類型 | 說明，這樣你可以用搜尋快速找到特定類型的操作。

四、建立日常維護節奏

知識庫不需要每天花很多時間。建議的節奏：

頻率動作花費時間
讀到好文章時Ingest：餵給 AI，存檔5-10 分鐘
有好問題時Query + 決定要不要回寫3-5 分鐘
每週一次Lint：讓 AI 做健康檢查10-15 分鐘
每月一次回顧 index.md：刪掉不需要的、調整分類15 分鐘

核心原則：你的時間花在「策展」和「判斷」，AI 的時間花在「整理」和「記帳」。

如果你發現自己花太多時間在維護知識庫本身（而不是使用知識庫的內容），那表示你的 Schema 需要簡化。

AI 協作：學了這個，跟 AI 怎麼配合？

Query 回寫和 Lint 是 LLM Wiki 中最需要人機協作的環節——AI 做初步分析，你做最終判斷。

你的人類優勢：

  • 你知道哪些矛盾是真矛盾（市場真的變了）vs 假矛盾（統計口徑不同）——AI 只能找到矛盾，不能判斷原因
  • 你知道哪些查詢結果值得長期保存——AI 不知道你未來的工作方向

可以這樣跟 AI 說：

你找到的這個矛盾很好。A 頁的數據是 2024 年的調查，B 頁是 2025 年的實際結果，所以不是矛盾，而是趨勢變化。請在兩頁都加上時間標註，並在概念頁說明這個趨勢轉變。

小練習

本課重點回顧

  • Query 回寫是知識複利的來源：好的查詢結果存回 Wiki，下次直接可用
  • 不是所有查詢都要回寫：跨文件綜合分析、比較表、決策紀錄值得存，一次性問題不需要
  • Lint 四種檢查：矛盾偵測、孤立頁面、知識缺口、過時資訊
  • Lint 產出報告，你做決策：AI 找問題，你判斷怎麼修
  • 維護節奏：Ingest 隨時做、Query 回寫看情況、Lint 每週一次
  • 如果維護知識庫比使用知識庫花更多時間，Schema 要簡化

挑戰任務

Task 1

用你在上一課建好的 Wiki，問一個需要綜合多頁資訊的問題（如果你目前只有一頁，再 Ingest 一篇相關文章後再問）。判斷 AI 的回答值不值得存回 Wiki，如果值得，請 AI 產出新頁面。寫下你問了什麼問題、AI 的回答品質如何、你有沒有決定存回 Wiki。

Task 2

對你的 Wiki 做一次完整的 Lint。把四種檢查（矛盾、孤立頁面、知識缺口、過時資訊）都跑一次。記錄 AI 找到了什麼，以及你決定怎麼處理。

← BackNext Lesson →