你有沒有遇到過這種情況。

老闆安排一件事，你給新員工講了一遍。下一個人來了，又要從頭講一遍。

公司裡有一個銷售很厲害，成交率特別高，但他的經驗傳不下去。新來的銷售不知道怎麼學，成長很慢。

客戶問的問題翻來覆去就那幾類，但每次都要重新查資料、重新組織語言。

會議記錄、專案復盤、產品資料、客戶案例，每天都在產生，但真的要用的時候，翻遍電腦也找不到。

這是大多數中小企業的日常。不是不重視知識，而是實在沒有精力去整理。

通用 AI 懂世界，但不懂你的業務

很多人用過豆包、DeepSeek 或 ChatGPT。用完之後的感覺很一致：它說的是對的，但對你的業務沒用。

比如你讓它幫你回一個客戶問題，它給的答案看起來頭頭是道，但你一看就知道，這根本不是你們公司的產品、不是你們的服務方式、不是你們跟客戶說話的語氣。

它不了解你。

問題出在哪？市面上這些通用 AI 工具，背後的大模型是用公開資料訓練的。你可以把它理解成一個見多識廣但剛入職的人，他知道很多通用知識，但不知道你們公司自己的情況。

但你的企業有自己的一套東西。產品參數、客戶案例、服務流程、寫作風格，還有過去做對和做錯的事情。這些東西，AI 沒見過。所以它只能給你泛泛的、正確的廢話。

這篇文章要解決的就是一件事：讓 AI 拿到你的上下文，開始基於你的資料幹活。

讀完之後，你至少能拿走四樣東西：一個最小知識庫目錄結構，一套從安全任務開始跑通的流程，兩段可以複製的提示詞，以及一個選工具的判斷標準。

第一版不要求技術基礎，也不用先買一套複雜系統。先跑起來，才是關鍵。

知識庫的本質：為 AI 提供「專屬上下文」

很多人一聽到「知識庫」，腦子裡跳出來的是一個資料夾，或者一個文件管理系統。

AI 知識庫不是這個意思。

AI 知識庫，本質上是在給 AI 補上下文。什麼叫上下文？就是 AI 不知道的、關於你們公司內部的資訊——你們公司是做什麼的、產品有哪些、服務過哪些客戶、客戶常問什麼問題、過去哪些案例做得好、哪些做砸了、對外輸出的內容應該用什麼語氣。

這些東西合在一起，就是 AI 的上下文。

知識庫的本質是為 AI 提供專屬上下文

AI 最終的輸出品質，由三件事共同決定：模型本身的能力、你給它的上下文品質、你對它下的任務約束。

你用同一個模型，給它一堆泛泛的資料，它只能給出泛泛的答案。但你給它你們公司的產品資料、客戶真實問題、好的案例和明確的輸出規則，它就能給出像你們公司的人寫出來的內容。

知識管理從「全人工」轉向「人機協作」

過去做知識管理，整套流程基本都靠人。人整理資料，人檢索資料，人理解內容，人判斷哪些能用，再由人改寫輸出。每一步都要人來做。做過管理的人都知道，人的成本是最高的。

現在除了最後那一步——人來做判斷和校準——前面很多整理、檢索、初步改寫的動作，AI 都可以參與進來。

人主要做判斷。AI 輸出的東西對不對、好不好、能不能用，人來校準，再告訴它哪裡要改。

找到適合的起點：知識庫落地的五個階梯

聊到 AI 知識庫，經常會遇到兩個詞：向量數據庫和 RAG。

對普通人和中小企業來說，第一版通常還用不到這麼重的方案。

目前常見的實現方式有五種。它們不是五個並列選項，更像是從輕到重的五個階段。你在哪個階段，就選對應方案。

知識庫落地的五個階梯

第一種：直接投餵

最簡單的方式。把檔案直接上傳給 AI，讓它基於這些檔案來回答問題。

適合一次性、小規模、臨時性的任務。比如你有一份產品說明書，想讓 AI 基於它幫你寫一段介紹，直接丟給它就行。

但直接投餵的問題很明顯。每次都要重新傳，資料多了之後你不知道該傳哪份，也很難沉澱成長期系統。

第二種：目錄化知識庫（最佳起點）

這是我最建議普通人和中小企業先做的一步。

你要做的事情不是搭平台，而是先把手頭的資料分好類，放到不同的目錄裡。比如企業基礎資訊放一個目錄，產品服務放一個目錄，客戶問題放一個目錄，案例資料放一個目錄，輸出規則放一個目錄。

然後告訴 AI，遇到什麼場景，去哪個目錄裡找什麼檔案。

不需要任何技術基礎，也不需要一開始就買系統。說到底，就是先把你電腦裡、飛書裡、網盤裡的資料變成一個 AI 能找到的資料區。

只要這一步做好，AI 的回答就會開始從「泛泛而談」變成「基於你的資料回答」。

第三種：索引型地圖

目錄化還有一個問題。很多檔案不是只能歸到一個類別裡的。一個客戶的成交案例，可能既跟銷售話術有關，又跟產品介紹有關，又跟新人培訓有關。

這時候與其糾結分類，不如換個思路：讓 AI 先把所有資料掃一遍，按主題畫一張索引地圖。比如跟行銷相關的主題關聯了哪些檔案，跟獲客相關的關聯了哪些檔案。然後 AI 順著這張地圖去找資料。

這不要求你把檔案分類分到完美，而是讓 AI 知道「要找什麼的時候該往哪走」。

第四種：RAG 和向量檢索

資料多到一定程度之後，目錄或索引都不夠精準，需要 AI 按語義去找資料。

RAG 的做法是，提前把你的資料按片段處理好，AI 來檢索的時候，不是匹配關鍵字，而是匹配語義——你的問題是什麼意思，它就去找意思最接近的那一段資料。

你現在不需要先懂它的技術細節。先知道一件事就夠了：它主要解決的是資料太多、目錄和關鍵字都不好找的時候，怎麼讓 AI 更精準地找到相關片段。

第五種：企業系統整合

企業級方案。比如你們公司已經有自己的內部系統、客服平台、文件系統，需要把知識庫能力嵌入到現有的系統裡。很多平台的右下角彈出一個 AI 客服按鈕，背後就是這種邏輯。

這五種路線，沒有誰比誰高級，只有適不適合你現在的階段。 對絕大多數普通人和中小企業來說，從第二種開始就夠了。

個人知識庫：先解決自己的輸出問題

說完框架，講一個我自己的案例。

我做的事情很簡單。我在電腦上建了一個目錄，把我每天產生的想法、日記、過往寫的文章、團隊開會的資料，全部放在裡面。然後我選了一個能讀取本地檔案的 AI agent 工具，讓它可以直接存取這個目錄。

現在我的工作方式是這樣的。要寫文章了，不是自己翻資料夾找素材，而是直接跟 AI 說我要寫什麼話題，它自己去目錄裡翻我過去寫過的相關內容和想法，給我整理出素材。

要復盤最近的狀態了，我就讓 AI 去讀我最近一段時間的日記，幫我找出這段時間反覆遇到的問題是什麼、進展怎麼樣。

還有一個讓我挺意外的功能是知識圖譜。AI 會自動把我不同筆記之間的關聯找出來，畫成一張圖。兩個看起來沒什麼關係的筆記，AI 可能通過一些潛在的主題把它們連起來。

放在以前，這個事情要做的話，我需要一篇一篇地去想「這篇筆記跟哪篇筆記有關係」。有了幾百條筆記之後，這個工作量大到根本不可能人工完成。

個人知識庫的價值不是收藏，而是輸出的時候能找到、能引用、能舉一反三。它不是幫你把資料歸檔，而是幫你把過去沉澱下來的東西，在你需要的時候變成能用的素材。

我現在怎麼搭的：LLM Wiki

我自己目前用的是一套叫 LLM Wiki 的做法。核心思路是：不只讓 AI 讀你的原始素材，而是讓 AI 自己維護一套索引系統。

具體來說，AI 會把你的原始素材（文章、筆記、會議記錄）先做摘要，然後按主題建立概念頁和實體頁，再用一個索引把所有頁面串起來。你可以把它想成 AI 幫你養了一個 wiki——原始素材是底層，wiki 頁面是上層，索引是導航。

我自己的 blog 知識庫就是用這個方式。270 多篇文章的原始內容在底層，AI 維護了 13 個概念頁和 12 個實體頁，加上一個總索引。寫新文章的時候，AI 不用一篇一篇翻原文，而是先查索引，找到相關的概念頁，再順著概念頁回到原始素材裡撈具體細節。

這個組合對應的是前面講的「索引型地圖」。

我選 LLM Wiki 的原因很簡單：它夠簡單，而且完全不綁平台。 所有東西就是一堆 markdown 檔案放在本地資料夾裡，沒有專屬格式、沒有雲端鎖定、沒有月費。你想搬到任何地方都可以，因為底層就是純文字。任何 AI agent 工具只要能讀目錄，就能直接用。這對我來說是最重要的——我不想哪天換工具的時候，發現我的知識庫被鎖在某個平台裡匯出不來。

但坦白說，LLM Wiki 缺的東西也很明顯。 它太簡單了，簡單到很多你覺得理所當然的功能都沒有：

  • 沒有 UI。 所有操作都是靠 AI agent 指令完成的，沒有漂亮的介面讓你點選、拖拉、視覺化瀏覽。
  • 沒有即時搜尋。 你不能像 Notion 或 Obsidian 那樣打幾個字就跳出搜尋結果，要等 AI 去跑索引查詢。
  • 沒有多人協作。 就是一個人的本地目錄，沒有權限管理、沒有共享、沒有版本衝突處理。
  • 沒有自動同步。 新素材加進來之後，你要手動觸發 AI 去更新索引，它不會自己感知到有新檔案。
  • 沒有向量檢索。 純靠 AI 讀文字做語義理解，沒有 embedding 層，素材量大到幾千篇之後效率會下降。

所以它適合什麼人？適合素材量在幾百篇以內、主要是個人使用、不想被任何平台綁死的人。如果你需要團隊協作、需要 GUI、需要處理上萬篇文件，那 Notion AI、Mem、Capacities 這些有完整介面的工具會更適合。

但 LLM Wiki 的好處是它可以一層一層往上疊。 我自己規劃的演進路徑是這樣的：

  1. Gmail / Google Drive / 本地磁碟 → 這是你的 raw data 來源。提案在 Drive 裡、客戶信在 Gmail 裡、會議紀錄在 Docs 裡、檔案在硬碟裡。這些東西本來就在，只是散在各處。
  2. LLM Wiki（Obsidian） → 把 raw data 集中到 markdown 目錄，AI 建索引、做摘要、維護概念頁。這是目前我在用的階段。
  3. SQLite FTS5 → 當素材多到幾千篇，純靠 AI 讀文字太慢了，加一層 SQLite 全文檢索。FTS5 是 SQLite 內建的全文搜尋引擎，不需要額外裝什麼，資料庫就是一個本地檔案，依然不綁平台。AI 先查 SQLite 縮小範圍，再去讀原始素材，速度會快很多。
  4. UI 介面 → 最後才是加前端。有了前三層的基礎，UI 只是把查詢和瀏覽的體驗做好，不影響底層架構。

每一層都是本地檔案、開放格式、不綁平台。你可以停在任何一層，也可以隨時往上疊。這就是簡單架構的好處——它不會因為你選了某個工具，就把你鎖在那個生態系裡。

現在市面上能做類似事情的工具一海票。 Obsidian 加上 AI agent 插件、Notion AI、Mem、Capacities、Heptabase，甚至直接用 ChatGPT 的 Projects 功能把資料丟進去，都能達到「讓 AI 讀你的素材、幫你檢索和輸出」的效果。

重點不是你用哪個工具，而是你有沒有把素材集中到一個 AI 能讀取的地方，然後開始跑第一個場景。工具會一直迭代，但「把自己的上下文餵給 AI」這個動作，今天就能開始。

第一階段行動藍圖：今天就能建好的 5 個核心目錄

回到一個問題：你今天回去能做什麼？

先確認一個前置條件：你要有一些數位化的資料。Word、PDF、飛書文件、Excel、會議記錄、聊天記錄、案例、產品資料、文章草稿，都算。只要有東西在電腦裡，就可以開始。

其實很多人已經有了，只是沒意識到——你的 Google Drive 和 Gmail 就是現成的 raw data 資料庫。提案文件在 Drive 裡、客戶往來信件在 Gmail 裡、會議紀錄在 Google Docs 裡。這些東西散在不同地方，但加起來就是你最真實的業務上下文。你不需要從零開始整理，只需要把它們集中到一個 AI 能讀取的結構裡。

在你的電腦上或企業文件系統裡，新建一個資料夾，就叫「知識庫」，然後建五個子目錄：

  • 01_企業基礎：公司介紹、品牌資訊、團隊結構、聯繫方式。
  • 02_產品服務：你們有哪些產品和服務，分別面向什麼人群，解決什麼問題，跟競品有什麼不同。
  • 03_客戶問題：客戶常問什麼，哪些問題重複出現，哪些是高頻高價值的。
  • 04_案例資料：過往做得好和做得不好的案例，成交記錄，服務過程。
  • 05_輸出規則：你希望 AI 用什麼語氣、什麼風格來寫東西，哪些句式不要用，哪些表達方式你們覺得對。

這五類不用一次整理完美。先把現有的資料扔進去就行。

第二階段行動藍圖：選對工具

選工具的核心標準就一個：這個工具能不能真正進入你的工作環境，讀取你的資料，並在你的授權下做事情。

通用聊天工具，不是不好，只是它的設計場景是對話，不是管理你電腦裡或企業系統裡的資料。

目前市面上有一類工具，叫做 AI agent 工具。它們的特點是：你能告訴它你的資料在哪，它能直接去讀、去整理、去改寫，而不是只在對話框裡等你投餵。

怎麼取捨？看你的使用環境。如果你的網路環境和帳號都沒問題，可以用成熟度較高的國際工具。如果你想要在國內使用起來更方便，可以考慮國內的 AI agent 產品。兩者都可以通過手機端操控——你用手機遠端連上部署了工具的電腦，照樣可以發指令、收結果。

另外，如果你的企業已經在用飛書，飛書文件加上多維表格是一個很好的企業資料底座。你不需要額外再搭一套文件系統，可以在已有的飛書體系上直接把知識庫建起來。

但工具說到底只是工具。知識庫能不能用起來，不取決於你選了哪款軟體。更關鍵的是，資料有沒有整理好，規則有沒有寫清楚，切入場景對不對，後面有沒有持續回饋。

第三階段行動藍圖：跑通第一個最小可行性場景

用結構化提示詞讓 AI 先幫你整理分類。如果你覺得自己資料太亂了，不知道從哪開始分類，可以讓 AI 先幫你分析所有檔案，給出分類建議。你來確認就好，不需要自己手動一個一個搬。

然後從一個具體場景開始測試。第一版可以只覆蓋一個最小場景，比如回答客戶問題、生成一段銷售話術、整理一篇文章的素材。跑通一個，再擴展到下一個。

如果你不知道測什麼，先選一個安全任務：拿 10 份不敏感的產品資料或過往公開內容，再拿 1 個真實但不涉及隱私的客戶問題，讓 AI 基於知識庫給出回答。這個任務足夠小，也足夠真實。

怎麼判斷你跑通了？

看三個標誌：AI 能說明它引用了哪些資料；它的輸出比通用問答更貼近你的真實業務；你可以通過回饋繼續修正它。

再按這個清單檢查一遍：

  1. AI 有沒有明確說自己參考了哪些資料？
  2. 回答裡有沒有出現你們自己的產品、案例或規則？
  3. 有沒有編造知識庫裡沒有的資訊？
  4. 這段回答能不能被銷售、客服或你自己稍微修改後使用？
  5. 你能不能把這次不滿意的地方寫回輸出規則？

實踐利器：兩個可以直接複製的提示詞

提示詞一：資料自動分類

複製前，把裡面的目錄路徑替換成你自己的真實路徑。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

我的知識庫根目錄在：[你的知識庫目錄路徑]

現在有一批待整理資料在：[待整理的檔案位置]

請你幫我做以下事情：

1. 讀取這些檔案的檔名和內容，理解每個檔案在講什麼。
2. 按照以下五個分類，給出每個檔案的歸屬建議：
   - 企業基礎
   - 產品服務
   - 客戶問題
   - 案例資料
   - 輸出規則
3. 如果一個檔案同時屬於多個分類，請標注主分類和關聯分類，並說明理由。
4. 列出你無法判斷歸屬的檔案清單，並說明為什麼。
5. 給出下一步整理建議，比如哪些分類下的檔案太多，是否建議再分子目錄。

注意：
- 不要刪除任何原檔案。
- 不要搬移任何原檔案。
- 不要改寫任何原檔案。
- 只輸出分類建議和整理清單，由我確認後再執行。

提示詞二：基於知識庫回答客戶問題

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

我的知識庫目錄在：[你的知識庫目錄路徑]

現在有一個客戶問了以下問題：
[貼上客戶問題]

請你基於知識庫裡的資料來回答。要求：

1. 先判斷客戶真正關心的是什麼。
2. 給出一段簡短直接、可以發給客戶看的回答。
3. 如果需要，再給出更詳細的解釋，方便銷售或客服理解。
4. 列出你可以追問客戶的問題，幫助進一步了解他的需求。
5. 必須標注你的回答引用了哪些資料。
6. 如果知識庫裡沒有依據，請明確說「資料不足，不能確定」，不要編造。
7. 不要承諾知識庫裡沒有寫明的產品效果、價格、服務範圍或交付結果。
8. 最後列出需要人工確認的風險點。

這兩個提示詞跑順之後，可以再考慮把它們沉澱成 skill——就是把一套固定流程保存下來，下次不需要再手敲這麼長的提示詞。你只需要跟 AI 說「用客戶問答技能幫我處理這個客戶的問題」，它就會按你之前設定好的流程來執行。

但這不是第一天必須做的事。先把前面的問答跑通。

核心引擎：真正讓知識庫增值的是「持續反饋」

很多人在搭完知識庫之後，會產生一種錯覺——覺得這事已經搞定了。

搭起來只是第一步。後面更有價值的是持續回饋。

持續反饋循環

AI 回答錯了，你要記錄錯在哪裡。不是罵一句「AI 真蠢」就完了，而是把這次錯誤寫回規則文件裡，讓 AI 下次不再犯。

AI 寫出來的東西不像人說話，就是常說的 AI 味。怎麼辦？把你覺得不對的句式一個一個寫進輸出規則裡。比如哪些開頭你不喜歡，哪些詞太空，哪些句式太像 AI，哪些表達不像你們公司的語氣，都寫下來。AI 下次輸出之前，先讀這些規則，就會更接近你想要的表達。

某類內容發出去之後效果特別好，你要把這個好案例分析一下為什麼好，然後沉澱回知識庫。下次 AI 再生產同類內容的時候，就有了參照標準。

你可以把它當成一個很樸素的循環：資料先進去，AI 先試著用，人發現不對就改規則。下一次再遇到類似問題，它就少錯一點。

它不是一次性的整理工作，而是一個需要人持續參與、持續做判斷的系統。

避坑指南：實施前必須正視的三個現實

這篇文章講的是最小版本的路徑，不是萬能方案。

資料品質。 目錄化知識庫的精準度取決於你資料的品質和結構。如果你的資料本身就是一堆混亂的、沒有上下文的片段，AI 讀完之後也很難給出好答案。Garbage In, Garbage Out 這個原則在 AI 知識庫裡同樣成立。

資料安全。 企業的核心資料——客戶隱私、合約內容、財務數據——放進 AI 工具之前，必須搞清楚這個工具的資料處理方式。是本地運算還是雲端處理？資料會不會被用於模型訓練？這些問題在第一版測試階段可以用不敏感的資料繞過去，但企業正式使用之前必須面對。

場景適配。 切忌盲目照搬他人流程。找出你們企業當下最痛的環節——客服、培訓、行銷——作為唯一切入點。每個企業的情況不同，核心邏輯是通用的（先找痛點、先跑通一個場景、持續回饋），但具體的目錄結構、資料類型和切入場景需要你根據自己的業務來調整。

你的 15 分鐘行動挑戰

15 分鐘行動挑戰

第一，先建目錄，別急著買系統。 90% 的中小企業在知識庫這件事上卡住，不是因為沒有工具，而是因為資料還沒有整理到 AI 能用的狀態。先分類、先放進去、先跑一個場景，比挑選一個月工具更有用。

第二，價值不在收藏，而在輸出。 資料沉澱下來不是為了存著，是為了下次用的時候能找到、能引用、能校準。如果你建了知識庫但從來沒有在一個真實任務裡用過它，那它就是一個高級資料夾。

第三，持續反饋大於初始搭建。 第一版的知識庫一定是粗糙的。讓它變好的不是一次性的大整理，而是每次 AI 答錯的時候，你把修正寫回規則裡。這個循環轉起來，知識庫才真正開始有價值。

你今天就可以花 15 分鐘做一個最小測試：建一個資料夾，分五個子目錄，放 10 份不敏感的資料進去，複製上面的客戶問答提示詞，拿一個真實問題試一次。看 AI 有沒有引用你的資料，回答是不是比通用聊天工具更貼近你的業務。

以後重要的不是你會問一句 prompt。而是你每次做完一件事，都能把經驗、案例、規則留下來。下一次再遇到類似問題，AI 不是從網上重新猜一遍，而是從你的資料裡接著往下做。