如何打造知識庫：文章、搜尋、權限與 AI 回答

知識庫是一座可以搜尋的答案資料庫：如何做某件事、如何解決某個問題、規則是什麼。要建立知識庫，你需要把文章歸納到幾個清楚的分類中、提供撰寫者真正會用的編輯器、設計能根據人們實際輸入的字詞找到正確文章的搜尋功能，並決定誰可以閱讀哪些內容：大眾、已登入的客戶，或只有內部員工。AI 應用程式建置工具可以在短時間內產出結構、編輯器與搜尋功能。真正讓知識庫有用的，是內容撰寫與長期維護，因此從第一天起就要設計得方便編輯，並能找出過時的文章。

先決定服務對象

同樣的功能可以服務非常不同的網站：

• 公開說明中心：服務客戶與潛在客戶。必須快速、可被搜尋引擎建立索引，並使用他們熟悉的語言撰寫。
• 僅限客戶的文件：需要登入，供付費客戶或合作夥伴使用。
• 內部知識庫：政策、流程，以及員工的操作指南。必須保持私密；搜尋與內容新鮮度比設計更重要。

大多數資料外洩都發生在同一個網站混合了公開與內部文章的情況。如果你兩者都需要，請為每篇文章設定清楚的可見性，或是分開經營兩個網站。

應用程式需要什麼

資料

有兩個欄位發揮很大的作用：負責人（誰負責確保這篇文章準確）與最後審閱時間（上次有人確認內容仍然正確是什麼時候）。兩者結合起來，就能列出六個月來無人檢查過的文章。

頁面

• 讀者端：首頁包含搜尋與分類、分類頁面、文章頁面（附目錄）、相關文章，以及「這篇有幫助嗎？」的提示。
• 編輯端：文章列表（可依草稿、過時、評分低等條件篩選）、附預覽的編輯器，以及修訂歷史。
• 管理端：分類、使用者與角色，以及搜尋無結果的報表。

權限

讀者只能看到他們有權限閱讀的已發布文章。編輯者可以建立與編輯文章，權限或許僅限於特定分類。管理員負責發布、封存文章並管理使用者。內部知識庫中，所有人都需要登入；公開的說明中心則只需要撰寫者登入。

決策與取捨

編輯器：Markdown 或富文本

Markdown 快速、可攜，而且與版本歷史搭配良好，但有些撰寫者會覺得不習慣。附有標題、清單、圖片、提示區塊與程式碼區塊的富文本編輯器則比較熟悉。無論選擇哪一種，都要以之後能匯出的格式儲存內容。

搜尋

如果同時搜尋標題、摘要與內文，並讓標題符合的結果排在前面，那麼資料庫的基本文字搜尋對於幾百篇文章來說已經足夠。超過這個規模，或是錯字與同義詞很重要（例如「發票」與「帳單」）時，請改用完整的全文搜尋或代管的搜尋服務。我們的新增搜尋功能指南介紹了各種選項。每一筆沒有結果的查詢都要記錄下來：這是免費的待寫文章清單。

AI 回答

如今常見的「提問」框，能根據你的文章作答。它的運作方式是找出最相關的段落，並要求語言模型只根據這些段落回答，請參閱什麼是 RAG。務必顯示來源文章、允許模型回答「我不知道」，並記住模型會自信地重複文章中任何過時的內容。請等文章內容已經整理妥當後再建置，不要提早做。

版本與審閱

保留修訂紀錄，讓你能看出是誰改了什麼，並可以還原。對於受規範的內容（人事政策、安全流程），請在發布前加入核准步驟。

一段有效的第一個提示詞

為 Parcelly 建立一個公開的說明中心，Parcelly 是一款為小型網路商店打造的運送標籤應用程式。首頁有一個大型搜尋框，以及六個分類（入門、列印標籤、物流商、帳單、退貨、疑難排解）。文章包含標題、摘要、以 Markdown 撰寫並可加入圖片與提示區塊的內文、分類、標籤、狀態（草稿、已發布、已封存）、負責人與最後審閱日期。文章頁面顯示目錄、相關文章，以及「這篇有幫助嗎？」的是／否選項，並可選擇留言。搜尋涵蓋標題、摘要與內文，標題符合的結果優先排序，並記錄每一筆查詢及其是否有結果。編輯區（需要登入，角色為編輯者與管理員）列出草稿、180 天內未審閱的文章，以及有用評分偏低的文章，並保留修訂歷史。每篇文章都有自己的頁面標題與 meta 描述，供搜尋引擎使用。設計要乾淨、沉穩、易讀，並以手機優先。

建置步驟

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 操作指南）。

如果需要起始提示詞，可以試試產品知識中心或團隊文件應用程式範本。

常見問題