LLM Wiki 實戰：我們怎麼把 59 篇部落格變成一座知識庫

我們的部落格有 59 篇文章，涵蓋 WordPress 開發、AI 工具、部署踩坑、商業策略。寫了快一年，回頭看卻發現一個尷尬的事實——這些文章之間幾乎沒有連結。

寫「透明時薪制」報價的那篇，跟講「敏捷式接案」的那篇，其實在談同一件事的不同面向。寫 Claude Code Skill 系統的十幾篇文章，散落在不同時間點，概念定義前後不一致。更慘的是，每次要寫新文章，AI 都從零開始理解我們的業務，同一個問題問兩次，答案不一樣。

59 篇文章，但知識沒有累積。寫作量在增加，但認知深度原地踏步。

Karpathy 的 LLM Wiki 改變了什麼

2026 年 4 月初，Andrej Karpathy（OpenAI 共同創辦人）公開了一套他自己在用的知識管理方法，叫 LLM Wiki{target=“_blank”}。核心概念一句話就能講完：別在提問時才讓 AI 翻原始文件，讓它提前把所有資料「編譯」成結構化的 Wiki。

這裡的「編譯」不是寫程式的那種編譯。想像你有一箱雜亂的筆記，每次要找資料都得整箱翻。Karpathy 的做法是：讓 AI 先把這箱筆記整理成一本有目錄、有索引、有交叉引用的百科全書。之後要查什麼，翻百科就好。

傳統做法（包括 NotebookLM、ChatGPT 的檔案上傳）都是「即時檢索」——每次問問題，AI 現場搜、現場讀、現場拼答案。這就是為什麼同一個問題問兩次，答案可能不同。因為每次搜到的段落不一樣，拼出來的理解也不一樣。

LLM Wiki 反過來：先編譯，再查詢。概念定義只有一份，矛盾在編譯時就被標記，新資料加入時做增量更新。知識變成了一個持久的資產，而不是每次對話的副產品。

看完這個概念，我決定拿我們的 59 篇部落格來試。

我們加了什麼：三步編譯法

Karpathy 的原始方案主要做「摘要 + 提取概念 + 建索引」。我們跑了一輪之後，發現純摘要有一個問題——兩篇觀點相反的文章，摘要後可能看起來一樣。摘要只壓縮資訊，不生產新知識。

我們在摘要的基礎上加了兩個步驟，形成「三步編譯法」：

第一步：濃縮

用剃刀法則處理每篇文章——「刪掉這條資訊，會影響理解嗎？」不會就刪。最後只留核心結論（不超過三條）和支撐每條結論的關鍵證據。

一篇 3000 字的文章，濃縮後通常剩 200 字左右。那 2800 字不是廢話，但它們是脈絡和細節，不是核心知識。

第二步：質疑

這是跟 Karpathy 方案最大的差異。對每條核心結論問四個問題：

• 這個結論依賴哪些前提假設？
• 換個產業、換個規模，還成立嗎？
• 資料來源可靠嗎？
• 有沒有沒提到的反例？

舉個我們自己的例子。有一篇文章說「導入 AI 開發流程後，專案時間從 2-3 個月縮短到 3-4 週」。質疑步驟指出：這個數據的前提是「團隊已經有 WordPress 開發經驗」。如果是一個對 WordPress 完全陌生的團隊，AI 加速效果會大打折扣，因為你連 AI 產出的程式碼對不對都無法判斷。

如果沒有質疑這一步，「縮短到 3-4 週」就會作為孤立事實留在知識庫裡，下次被引用時可能誤導判斷。

第三步：對標

跨領域找類似現象。這一步聽起來有點抽象，但實際跑出來的結果讓我們很驚訝。

我們編譯「透明時薪制合作流程」這篇文章時，對標步驟發現：固定報價 vs. 時薪制的結構性矛盾，跟軟體開發中瀑布式 vs. 敏捷的矛盾，是完全同構的。固定報價假設需求不會變，就像瀑布式假設規格書是完美的——兩者都在預測未來，而預測未來這件事，人類一直做不好。

這個洞察不在任何一篇原始文章裡。它是編譯過程中，AI 把兩個看似無關的領域放在一起比較後產生的。

59 篇文章編譯完，我們得到了什麼

六組 AI agent 平行處理，大約 40 分鐘跑完全部 59 篇文章。產出的東西超出預期：

• 107 個概念條目——從「AI 工具的累積效應」到「康威定律」到「冷啟動問題」，每個概念都有定義、關鍵數據點、前提與局限性、關聯概念
• 16 個方法論——像是「Spec Coding 方法論」「痛點量化驅動設計」「接案養產品雙軌模式」，把散落在不同文章裡的操作步驟整理成可複用的流程
• 59 篇編譯摘要——每篇都經過濃縮、質疑、對標三步處理

但最有價值的不是數量，是跨文章的關聯。

我們的文章橫跨六個分類：Claude Code 教學、技術分享、教學、工具評測、產品更新、公司公告。這些分類在部落格上是獨立的，但編譯後，概念之間出現了意料之外的連結。

「AI 工具的累積效應」這個概念，同時被 Claude Code 記憶系統、Skill 系統、Session 管理三個不同主題的文章引用。編譯後它們匯聚成一個觀點：AI 工具的價值不在單次使用，在於持續投入後形成的複利——但這個複利同時也製造了遷移成本。我們自己的文章裡就有這個張力：一邊說「累積效應讓你領先」，一邊說「工具選擇是工程判斷，隨時可以換」。知識庫裡直接標記了這個衝突。

五篇公告類文章（月度回顧、年度回顧、活動紀錄）看起來是最沒有「知識含量」的分類，但編譯後拉出了公司第一年的完整發展弧線：從 Vibe Coding 帶來的興奮、四款產品的連續失敗、WordCamp 的策略轉向，到最後務實選擇接案養產品。這條脈絡散落在五篇不同時間的文章裡，從來沒有人把它們串在一起看過。

為什麼這次知識管理沒有半途而廢

用過 Notion、Obsidian、飛書做知識管理的人大概都有同樣的經驗——前兩個月很勤快，然後就荒廢了。

原因很簡單：維護知識庫最繁瑣的部分——更新交叉引用、保持定義一致、標注矛盾——這些活的成本會隨著知識量增加而指數上升。十個概念之間可能有 45 種關聯，一百個概念就是 4950 種。人力維護不可能跟上。

LLM 把這個成本打到接近零。它可以一次修改十幾個檔案，不會忘記更新某個交叉引用，不會懶得檢查兩篇文章有沒有矛盾。

這才是 LLM Wiki 能持續運轉的真正原因——不是方法論多先進，而是維護成本終於低到可以忽略了。

知識庫反過來幫助寫作

建完知識庫之後，我們調整了寫作流程。現在每次寫新文章，在動筆之前會先查 Wiki：這個主題跟哪些既有概念相關？有沒有已知的衝突需要處理？有沒有跨域洞察可以作為獨特切入點？

效果很直接。寫這篇文章之前，Wiki 告訴我「AI 工具的累積效應」跟「內容再利用」兩個概念都跟 LLM Wiki 相關——知識庫本身就是一種累積型資產，而把部落格編譯成知識庫也是一種內容再利用。這些連結不是硬想出來的，是知識庫裡現成的。

寫完新文章後，我們會跑一次「編譯」，把新文章的知識回寫到 Wiki。知識庫就這樣持續滾動，每一篇新文章都讓整個知識網絡變得更密。

你的文章值得被編譯嗎

如果你也在經營部落格或寫技術文章，可以問自己一個問題：你有多少篇文章寫完之後就再也沒被引用過？

那些文章不是沒價值。它們的價值被「散落」稀釋了。每篇文章獨立存在，像一座座孤島。讀者看完一篇就離開，不會發現你在另一篇文章裡寫過一個完全互補的觀點。

LLM Wiki 做的事情，是把這些孤島連成一片大陸。

不需要很多文章才能開始。10 篇就夠了。重點不是量，是讓 AI 去發現那些你自己沒注意到的連結——「原來這兩篇在講同一件事」「原來這篇的前提假設已經被另一篇推翻了」。

那些連結，就是新文章的靈感來源。

常見問題

LLM Wiki 跟 NotebookLM 有什麼不同？

NotebookLM 是「即時檢索」——每次提問時 AI 現場搜尋你上傳的文件。LLM Wiki 是「預先編譯」——AI 先把所有資料整理成結構化的概念條目和交叉引用。兩者最大的差別在一致性：LLM Wiki 裡同一個概念只有一個定義，NotebookLM 則可能每次給你不同的整理結果。

不會寫程式也能建 LLM Wiki 嗎？

LLM Wiki 的核心是 Markdown 檔案和資料夾結構，不需要寫任何程式碼。你需要的是一個能跑 AI agent 的工具（像 Claude Code）和一個文字編輯器。編譯的過程完全由 AI 執行，你只負責把原始資料放進指定資料夾，然後下一句指令。

多少篇文章才值得建知識庫？

10 篇以上就有意義了。關鍵不是數量，而是主題有沒有交叉。如果你的文章都在談同一個狹窄的主題，編譯後的概念條目會比較少。但如果你像我們一樣橫跨技術、商業、工具評測等不同領域，概念之間的跨域連結會是最有價值的產出。

---

有類似的需求，或想進一步討論？歡迎聯絡我們，或加入我們的 LINE 官方帳號{target=“_blank”}聊聊你的專案。