相信很多人都已經開始用 AI 工具了。豆包、DeepSeek、ChatGPT，手機裏至少裝了一個。
但好多人可能體感上還是覺得 AI 不夠好用。
自己資料散落在不同地方：文章在收藏夾裏，文件在網盤裏，想法留在聊天記錄裏，筆記又放在不同的軟件裏。
每次需要 AI 幫忙，都要重新上傳資料、重新解釋背景。好不容易聊出一個不錯的結果，它又只能留在對話框裏。下次遇到相似的問題，還是要從頭開始。
這時候，就需要搭一個數據掌握在自己手裏的 AI 知識庫了。
那這個知識庫到底要怎麼搭呢？需要用哪些 AI 工具，資料該怎麼整理，需不需要懂技術呢？
過去幾個月，我一直在搭建和使用自己的 AI 知識庫。這個過程並不難，我今天就來給大家分享一下我的搭建思路。
一個存放文本文件的開放文件夾，一個可以操控這些文件的 Agent 工具，一份清楚的工作規則，再加上一個真實任務場景，就可以啓動自己的 AI 知識庫了。
AI 知識庫，搭的到底是什麼？
大家多少都會用到各種軟件來管理自己的信息。
有人用 Obsidian，有人用其他筆記軟件，也有人直接把文檔上傳到聊天窗口。
這些方式其實不分好壞，但它們都只是整套工作方式中的一部分。
更準確地說，AI 知識庫是一套由文本文件、閱讀軟件、Agent、規則和真實任務組成的工作方式。
文本文件負責保存資料和知識。Obsidian 或其他支持 Markdown 的軟件，方便人去閱讀、檢查和修改。WorkBuddy、Codex 這一類 Agent 工具，在獲得文件權限以後，可以讀取、整理、查詢和更新這些內容。
規則相當於給 Agent 的工作說明。它要知道去哪裏找資料，哪些文件只能讀，整理後的內容放在哪裏，回答問題時怎樣標明來源。
最後還需要一個真實任務來驗證知識庫是否真的好用。
這個任務可以是寫文章，可以是整理某個學習主題，也可以是覆盤一個項目。沒有實際用途，文件夾整理得再漂亮，也只是換了一個地方存資料。
搭建個人知識庫，只需要準備四樣東西
第一，一個開放的文本文件夾
開放，指資料以普通文件的形式存放。人可以直接打開，獲得權限的工具也可以讀取，內容不依賴某一款軟件。
文本格式可以用 TXT，也可以用 Markdown。
如果手上已經有很多 TXT 文件，不必爲了搭知識庫先全部轉換。
不過我更推薦 Markdown。
Markdown 本身也是普通文本，但它可以用標題區分層級，用列表整理要點，用鏈接連接不同頁面。人閱讀的時候更清楚，Agent 處理時也更容易識別文章結構。
更重要的是，Markdown 不依賴某一款筆記軟件。今天可以用 Obsidian 打開，以後換成其他支持 Markdown 的軟件，底層文件還在。
它不會自動把資料變成知識，但它是一個足夠穩定、足夠開放的載體。
第二，一個真實任務和一小批相關資料
知識庫要先服務一個明確的任務，再放入與它直接相關的資料。一開始，不需要把全部的資料都無腦灌進來。
如果準備做寫作知識庫，可以先放自己的舊文章、選題筆記和研究材料。如果準備整理一個項目，就先放項目文檔、會議記錄和覆盤。
資料先從非敏感內容開始。身份證件、私人聊天、客戶機密和其他高風險材料，先不需要導入。
第三，一個能夠操控文件的 Agent 工具
有了文件，還要讓 AI 真正進入這個文件夾工作。
可以從 WorkBuddy、Codex 等 Agent 工具裏選擇，這類工具的特點，就是看它能不能讀取指定文件夾，能不能按照規則整理和更新文件，修改之前能不能讓人檢查和確認。
Obsidian 在這裏承擔的是閱讀和檢查。Agent 工具負責幹活，閱讀軟件負責讓人看見結果。
第四，一份清楚的工作規則
Agent 能看到文件，不代表它自然就知道應該怎樣維護知識庫。
第一版先把必要邊界寫進一個 Markdown 文件，至少說清楚下面幾件事。
1. 原始資料只讀取，不覆蓋。 2. 整理出的知識頁面保存到指定位置。 3. 回答問題時標明使用了哪些來源。 4. 找不到或者資料不足時明確說明，不自行補全。 5. 遇到刪除、覆蓋和拿不準的內容，先詢問再處理。
規則的作用，是把一個通用的 AI 工具變成知道邊界的知識庫助手。
以後出現新的問題，再把對應規則補進去。完整的分類和規則體系可以根據實際使用逐步完善。
從0到1，用五個動作跑通
第一步，選擇一個真實任務
先回答一個問題，這套知識庫最近準備拿來做什麼？
寫作、學習和項目覆盤，選一個就夠了。
真實任務會反過來決定資料應該放什麼、Agent 需要怎樣整理、最後要輸出什麼。沒有任務，分類很容易越做越多，最後卻不知道怎麼用。
第二步，建立最小文件結構
在知識庫文件夾裏，先分出原始資料和知識頁面，再放入一份規則文件。
原始資料保存事實依據。知識頁面保存 AI 整理後的摘要、主題、比較和階段性結論。規則文件負責告訴 Agent 怎樣讀取和更新它們。
名字不需要照搬別人的模板，只要自己和 Agent 都能看懂就行。
一段可以直接複製的知識庫架構提示詞
如果不想自己從頭設計目錄和規則，可以把下面這段提示詞交給 WorkBuddy、Codex 或其他能夠讀取文件的 Agent 工具。先把方括號裏的內容換成自己的實際情況。
我想搭建一個個人 AI 知識庫，請根據下面的信息，幫我設計第一版的知識庫架構規範。 使用場景：[寫作 / 學習 / 項目覆盤 / 其他] 現有資料：[簡單說明資料類型和大致數量] 常見任務：[希望 AI 幫我完成的事情] 請按下面的要求設計： 1. 架構只保留第一版真正需要的內容，至少區分原始資料、知識頁面和規則文件，不要一開始加入複雜分類。 2. 說明每個目錄和文件分別放什麼、由誰維護，以及 Agent 是否可以修改。 3. 原始資料默認只讀，不刪除、不覆蓋。AI 整理出的內容保存爲新的 Markdown 文件。 4. 知識頁面需要保留來源。資料不足或存在衝突時，明確標註，不自行補全。 5. 修改、移動或刪除文件以前，先列出計劃，等我確認以後再執行。 最後請輸出： 1. 推薦的最小目錄結構。 2. 每個目錄和文件的用途。 3. 一份可以直接保存爲規則文件的內容。 4. 第一個適合用來測試知識庫的任務。 先只輸出方案，不要直接創建或修改文件。
拿到方案以後，先看看目錄是否符合自己的使用習慣，再讓 Agent 創建文件。第一版不需要設計得很完整，只要自己知道資料放在哪裏，Agent 也知道哪些內容能讀、哪些內容能改，就可以繼續往下走。
第三步，使用 Agent 工具讀取知識庫
把這個文件夾交給 WorkBuddy、Codex 或自己正在使用的 Agent 工具。
剛開始只開放當前知識庫目錄，不要直接給整個電腦的權限。第一次先讓它查看目錄和文件，說明現在有哪些資料、可能分成哪些主題、哪些內容存在權限或來源風險。
這一步的目標只是確認 Agent 能正確讀取，不急着改文件。
讀取失敗時，先檢查文件夾位置和授權範圍，不需要馬上研究更復雜的知識庫技術。
第四步，給它第一項具體工作
不要只說「幫我整理一下」。
把任務說具體一點。先讓 Agent 讀取指定資料，不修改原文件。
圍繞一個明確問題整理內容，在結論旁保留來源，並把結果保存成新的 Markdown 頁面。涉及刪除和覆蓋時，先徵求確認。
比如做寫作知識庫，可以讓它從現有文章中整理某個主題下已經表達過的觀點，再找出可以繼續寫的角度。
這樣得到的不只是一次回答，而是一份以後還能繼續更新的知識頁面。
第五步，把有價值的結果寫回去
很多人使用 AI 的結果沒有積累下來，就是因爲聊完即止。
一份有長期價值的回答，應該保存回知識庫。下次再提出相關問題時，Agent 先查已有頁面，再結合新資料更新，而不是重新生成一份彼此無關的答案。
做到這裏，第一版就算初步跑通了。
Agent 能根據已有資料回答一個真實問題，並返回來源。結果可以在 Obsidian 或其他軟件裏重新打開，下次還能繼續使用。
如果每次依然從頭回答，就檢查規則裏有沒有要求先讀取舊頁面、再把結果寫回。如果擔心誤改，就把原始資料設爲只讀，縮小授權範圍，修改前先預覽。
第一版搭完以後，知識庫怎麼慢慢迭代
接下來最有價值的動作，是讓它持續參與真實工作。資料進來以後讓 Agent 整理，遇到問題時先查知識庫，有價值的結論再寫回去。
用得多了，問題自然會出現。
文件變多以後不好找，可以統一文件名，增加目錄和索引頁。需要在不同主題之間來回查找時，再給頁面增加鏈接。
如果 Agent 反覆創建相似內容，就把查重寫進規則。重要結論經常找不到原始出處，就要求每次整理都保留來源。
我目前的知識庫也是在實際使用中一步步完善的。
隨着場景增加，我又慢慢補上人物、項目等頁面分類，以及來源和派生關係。資料變多以後，又增加了權限、查重和寫後檢查。
這些結構解決的是知識庫擴展以後出現的具體問題，第一版不必完整複製。
當目錄、文件名、索引和鏈接已經不夠用，持續出現漏找、誤找，或者需要從大量資料裏尋找語義相關內容時，可以繼續瞭解 RAG、向量檢索等方案。
這些是更進階的檢索方案。第一版先把目錄和規則理清，再用 Agent 跑一個真實任務。以後遇到具體問題，再增加對應的規則和能力。
更多遊戲資訊請關註：電玩幫遊戲資訊專區
電玩幫圖文攻略 www.vgover.com
