考量到知識庫的建設與維護不是一朝一夕，有兩件事建議大家可以先做：Git 和「建設歷程」。

我說：「要有 Git」就有了 Git

一個 prompt 完成

「幫我在這個資料夾把 git 架起來：git init，把現有檔案加入並建立第一個 commit，commit message 用一句話說明這是知識庫骨架的初始版本。」

負責核准的你 = AI (Yes) 工程師

核准之後，AI 回報完成：

驗證

在同一個 Claude Code 視窗裡，以 ! 開頭的指令會繞過 AI（例如 !git log --oneline），直接以「你自己」的身分在這個 session 執行指令：

輸出結果，跟 AI 剛剛回報的 commit 訊息一致：

完成

為什麼要有 Git

也許有人會好奇我怎麼停在這邊了，怎麼不繼續接上 Github 把知識庫儲存在雲端？

因為存在雲端這個需求還沒有出現，現在知識庫還只是一個空殼，**為什麼要上雲端？**這個問題目前還回答不出來。

然後，不接上 Github這個決定背後是一個原則：「別試著解決還沒有出現的問題」，或者你可以說是馬斯克喜歡講的「第一性原則」，離題了。

有鑑於「個人知識庫」不斷增長與迭代的特質，初期我建議大家把 Git 設置好。

我說明一下為什麼 Git 很重要。

知識庫的天然需求

知識庫的其中一個特質，就是它是不斷的增長與迭代的造物，尤其是個人知識庫。

今天你突然想認真學做菜，找了一些網路食譜，整理進知識庫後開了新的專案叫做「學做菜」，此時知識庫做了一次增長。

明天你發現你下班後運動完根本就沒時間煮菜，最終決定整個專案取消，到這邊你做了一次迭代。

後天、大後天、大大後天，只要你還在使用並且維護知識庫，這樣的增長與迭代會不斷發生。

可以把建設知識庫比喻做「探索新大陸」。在你冒險的過程中，你會不斷地發現新大陸，隨著時間推移，舊有的路線會調整，可通行的道路也可能堵塞，總之。

對於「世界」(知識庫) 未來什麼樣子，此刻的你是不知道的，那麼地圖就很重要了。

有沒有地圖對於未來所有的決策都能起到作用，雖然說凡走過必留下痕跡，但是痕跡上有沒有更多訊息可以參考，很可能直接決定你這次冒險前往的是印度、還是印地安。

OK，Git 是一個最主要的「畫地圖的工具」，那麼具體 Git 要如何幫助我們呢？

好用一直用，Git 的兩個功能

快照（Snapshot）和 Commit message 是 Git 在知識庫起到作用的最關鍵的兩點。

快速簡單複習一下，快照是：每次提交修改（Commit）時，Git 都會建立一個「快照（Snapshot）」記錄當下所有檔案的樣子。

Commit message 就像是備註，說明：這次我改了什麼？很單純

快照讓檔案可以「比較」、Commit message 讓迭代不需要「重新理解」，我分別用一個例子說明。

還記得知識庫有一個 Lint 的功能嗎？當我們對知識庫做了修改之後，我們要讓 AI 幫忙掃看看異動有沒有矛盾/錯誤，然後有沒有孤兒頁面、raw/ 有沒有被誤改之類的。

這些「有沒有」的判斷基準，就是比較

當我們要讓 AI 幫忙判斷時，AI 最需要的就是基準，裝上 Git 後，從「上一個時間點」到「現在」，中間發生的事情就有紀錄，有紀錄就有依據，有依據就可以放手讓 AI 做，做壞了再回復。

第二個例子

「比較」看得出來什麼不一樣了，但是看不出來為什麼不一樣。

「這到底在改三小」，某次工程師小明看到 Merge Request 上顯示「289 項更動」。

這時候就需要 Commit message，每次提交都要附上說明，看不懂再改三小，可能看一下 Commit message 就懂了。

這兩個 Git 功能，到時候都是讓 AI 自動調用。

我還要建設歷程

其實 Git 裝好之後就很夠用了，大部分 LLM Wiki 的教學應該也會停在這邊，但是我的話會希望大家再補一個：建設歷程。

原因是：在大量的更動（尤其是建設初期）背景下，Commit message 往往無法提供更有價值的決策素材。

「比較」讓你知道什麼動了，Commit message 讓你知道「為什麼動」，然後就沒有然後了。

這邊我介紹一個東西，有聽過 Architecture Decision Record（ADR）嗎？

ADR——紀錄每次重要的架構決策，獨立寫一份簡短記錄，包含當時面臨的處境（Context）、最後選了什麼（Decision）、帶來什麼後果（Consequences）。

我是看了這篇才知道這個概念，有興趣的讀者可以看這篇文章。

透過 ADR 的方式去紀錄知識庫的建設歷程，這樣能充分補上「只知道為什麼現在長這樣」的缺口，變成「知道為什麼長這樣、還考慮過什麼」。

這樣做的話，改的人（通常是 AI）就能更快速更正確地去修改知識庫，我自己是受益匪淺，再次建議大家透過 Prompt 把這個建設歷程架設好。

補充：對於「怎麼紀錄」這點，你可以跟我不一樣，如果你有更好的方法希望你也能留個言讓我知道。

或者，覺得「我的知識庫不會有太多改動」、覺得麻煩的人，這步可以不做。

總之這裡提供一個範例。

建設歷程你給我過來

一個 prompt 完成

幫我在這個知識庫裡設置一份「建設歷程」記錄：新增一個獨立頁面，用來記錄這個知識庫自己的架構、schema、工作流程演變。以後只要討論中出現符合下面任一種情況，就主動幫我整理進這份記錄，內容收斂成三段——最初目的（為什麼要動、遇到什麼問題）、怎麼做（採用的方案，以及認真考慮過但最後沒選的替代方案與理由）、最後變成什麼樣（實際結果，含預期外的影響）：（1）改變了知識庫本身的結構或規則；（2）確立或修改了一種以後會重複套用的工作模式。單次操作、單篇內容的寫作進度、常規維護不算，不用記——判斷標準是「這件事以後會不會被引用套用，還是做完就沒了」。

AI 建立獨立頁面，順便補了兩筆——最初建立資料夾結構那次，以及這次新增這個機制本身（自己遞迴記自己一筆，順便當範例）：

完成後，AI 回報做了三件事：

• 新增建設歷程頁面
• 把判斷標準跟三段式格式寫進 CLAUDE.md
• 同步更新 index.md 跟 log.md。並主動提出一個疑問

驗證

打開實際生成的 wiki/建設歷程.md，兩筆紀錄都在，格式也照三段式跑：