如何建立知識庫：文章、搜尋、權限及 AI 解答

知識庫是一個可供搜尋的解答資料庫：如何做某件事、如何修正某個問題、某項規定是甚麼。要建立知識庫，你需要把文章歸納到幾個清晰的類別之下，提供撰寫者真正會使用的編輯器，設置能根據人們實際輸入的字詞找到正確文章的搜尋功能，並決定誰可以閱讀甚麼內容：公眾、已登入的客戶，或只限員工。AI 應用程式建立工具可以在短時間內產出結構、編輯器和搜尋功能。真正令知識庫有用的，是文章的撰寫和日常維護，因此由第一天起就應該設計方便編輯的功能，並能找出過時的文章。

先決定服務對象

同一套功能可以服務截然不同的網站：

• 公開幫助中心：服務客戶及潛在客戶。必須快速、可被搜尋引擎收錄，並以他們的語言撰寫。
• 只限客戶的文件：需要登入，供付費客戶或合作夥伴使用。
• 內部知識庫：載有員工的政策、流程及操作指南。必須保密，搜尋及資料是否新鮮比設計更重要。

最容易發生資料外洩的情況，就是在同一網站混合公開與內部文章。如果兩者都需要，請為每篇文章設定清晰的可見性，或分開運行兩個網站。

應用程式需要甚麼

數據

其中兩個欄位作用最大：負責人（誰負責確保文章準確）和 最後審閱時間（上次確認內容仍然正確的時間）。兩者結合後，你便可以列出半年來沒有人檢查過的文章。

頁面

• 讀者端：首頁設有搜尋及類別，類別頁面，文章頁面附目錄、相關文章，以及「這篇文章有幫助嗎？」的提示。
• 編輯端：文章列表可按草稿、過時、評分偏低等條件篩選，編輯器提供預覽，並保留修訂歷史。
• 管理端：管理類別、用戶及角色，並查看沒有結果的搜尋報告。

權限

讀者只能看到已發布、並且獲准查看的文章。編輯者可以建立和修改文章，權限或僅限於某些類別。管理員可以發布、封存文章及管理用戶。內部知識庫要求所有人都需要登入；公開幫助中心則只需要撰寫者登入。

決策與取捨

編輯器：Markdown 或富文本

Markdown 快捷、可攜，並且與版本紀錄配合良好，但部分撰寫者會覺得不習慣。富文本編輯器具備標題、清單、圖片、提示框和程式碼區塊，較為熟悉易用。無論選擇哪一種，都應該以日後能夠匯出的格式儲存內容。

搜尋

如果同時搜尋標題、摘要和內文，並讓標題相符的結果排在最前，那麼幾百篇文章用基本的資料庫文字搜尋已經足夠。文章數目更多，或拼寫錯誤及同義詞（例如「發票」與「帳單」）很重要時，就應使用正式的全文搜尋，或託管式搜尋服務。我們的 加入搜尋功能指南 會逐一介紹各個選項。記錄每個沒有結果的搜尋字詞，這就是一份免費的待寫文章清單。

AI 解答

現時常見的功能，是提供一個「提問」輸入框，從你的文章中作答。它的運作方式，是先檢索最相關的段落，再要求語言模型只根據這些段落作答，詳見 RAG 是甚麼。務必同時顯示來源文章、容許「我不知道」的回應，並謹記它會有信心地重複文章中任何過時的內容。請在文章質素穩定之後才建立此功能，而不是之前。

版本與審閱

保留修訂紀錄，讓你可以查看誰改了甚麼，並能夠還原。對於受規管的內容（例如人力資源政策、安全程序），應在發布變更前加入審批步驟。

一個行之有效的首個提示

為 Parcelly 建立一個公開的幫助中心。Parcelly 是為小型網上店舖而設的運單列印應用程式。首頁設有大型搜尋框，以及六個類別（入門、列印運單、物流商、帳單、退貨、疑難排解）。文章包括標題、摘要、以 Markdown 撰寫並可加入圖片及提示框的內文、類別、標籤、狀態（草稿、已發布、已封存）、負責人，以及最後審閱日期。文章頁面顯示目錄、相關文章，以及「這篇文章有幫助嗎？」的是／否選項，並可附帶可選填的留言。搜尋涵蓋標題、摘要和內文，標題相符的結果排在最前，並記錄每個搜尋字詞及是否有結果。編輯區（需要登入，角色為編輯者及管理員）列出草稿、超過 180 天未審閱的文章，以及有用評分偏低的文章，並保留修訂歷史。每篇文章都有自己的頁面標題及元描述，方便搜尋引擎收錄。設計要簡潔、平靜、易讀，並以手機優先。

建立步驟

1. 根據真實的客服問題，列出首批 20 至 30 篇文章，然後才開始建立。這份清單會決定類別。
2. 生成網站，並在手機上檢查閱讀體驗，包括每行的長度、標題和圖片。
3. 編輯器與角色。撰寫者需要無須找開發人員，也能新增和修改文章。
4. 搜尋功能，然後以客戶實際使用的字詞測試，包括拼寫錯誤的情況。
5. 意見回饋與搜尋紀錄。
6. 過時文章報告，根據負責人及最後審閱日期生成。
7. 公開網站的基本 SEO：獨一無二的標題和描述、簡潔的網址，以及網站地圖。參閱 為 AI 建立的網站如何做 SEO。
8. 在你的產品和客服回覆中加入連結，然後每週查看沒有結果的搜尋紀錄。
9. AI 解答，待內容扎實之後才加入。

常見錯誤

• 按部門而非讀者的任務來組織。
• 長文章同時涵蓋五項任務。每篇文章應只處理一項任務，標題要說明它能解決甚麼問題。
• 每篇文章沒有負責人。沒有人更新內容，而且第一個錯誤的解答出現後，信任度便會下降。
• 在公開文章中放入內部備註。應分開設定可見性，並在發布前審核。
• 搜尋只配對標題。讀者輸入的是問題徵狀，而不是文章名稱。
• 截圖沒有替代文字或說明。截圖很快會過時，因此也應用文字描述步驟。

何時選擇現成產品較合適

如果你的團隊已經習慣使用文件或維基工具，在該工具中建立內部知識庫通常是阻力最小的方法。我們的 Notion 與 Confluence 比較 涵蓋兩個常見的選擇。如果你使用的是服務台產品，其內置的幫助中心可以把文章與工單連結，並向客戶建議文章，這是難以自行重現的功能。文件網站生成工具適合與程式碼並存的開發者文件。

當你需要自己的結構或權限（例如按客戶、地點或角色劃分文章）、希望知識庫位於產品內部而非獨立網站上、需要維基無法強制執行的審核及審批步驟，或希望在不另外訂閱的情況下，以你的內容提供 AI 解答時，就應自行建立。它與 自訂服務台 配合得很好。

用 Mythex 建立

在 Mythex 中，你可以在對話中描述知識庫，系統便會在即時預覽中建立。文章、修訂紀錄和意見回饋會儲存在 Postgres 資料庫中，並在需要時由代理加入；圖片則放入專案的檔案儲存空間。編輯者登入使用你選擇的驗證方式，因為 Mythex 沒有內置的終端用戶登入功能。如需 AI 解答，你可以使用自己 AI 供應商的 API 金鑰，並以專案密鑰的形式儲存；用量會計入你的供應商帳戶，而不是 Mythex 點數（AI 指南）。Mythex 新建的應用程式預設為客戶端渲染的 React 單頁應用程式，對搜尋引擎較不友善，因此如果要建立公開的幫助中心，請要求使用適合靜態或伺服器渲染的設定，例如 Next.js（SEO 指南）。

如果想找起步提示，可以試試 產品知識中心 或 團隊文件應用程式 範本。

常見問題