客服知識庫該不該公開：把內部問答變成 AI 會引用的官方答案的六個步驟

客服知識庫可以公開，而且多數中小企業應該公開其中一部分。做法是先把內部問答分成「可公開、需改寫、不可公開」三類，再把可公開的答案寫成一題一頁或一題一段的官網內容，附上更新日期與負責單位。這樣 AI 搜尋才有一個清楚、可查證的來源可以引用。

很多公司的客服人員每天回答同樣的問題。運費怎麼算、保固怎麼申請、發票能不能改抬頭、預約可以改期幾次。這些答案寫在內部文件、LINE 記事本、客服系統的快速回覆裡。顧客看不到，搜尋引擎看不到，AI 助理也看不到。結果是顧客去問 AI，AI 只能拼湊論壇上的舊說法，或乾脆回答「請洽該公司客服」。

這篇是步驟教學。我用一個示範情境帶你走一遍：一家販售家用淨水設備、有安裝與定期換濾心服務的公司，客服內部有一份約兩百題的問答檔。以下六個步驟，是把這份檔案變成 AI 願意引用的公開知識庫的順序。示範情境只用來說明流程，不代表任何真實公司的數據。

為什麼內部知識庫鎖在後台，AI 就等於不認識你？

AI 搜尋功能回答問題時，需要能被抓取、能被理解的網頁內容。Google 在說明 AI 功能的文件裡寫得很直接：要出現在 AI 摘要或 AI 模式中，頁面要先能被索引，並符合一般搜尋的基本要求，沒有額外的特殊標記可以走捷徑。詳細說明可以看 Google 搜尋中心的 AI 功能說明。

客服系統的後台、需要登入的會員專區、PDF 掃描檔、圖片裡的文字，這些地方的答案對機器來說等於不存在。你的客服回答得再正確，也只在一對一的對話裡發生一次。公開知識庫的價值，是讓同一個正確答案在網路上有一個固定地址。

還有一個常被忽略的好處。AI 回答錯誤時，你很難去改 AI，但你可以改自己的頁面。有了公開的官方答案，你至少握有一個可以修正的源頭。

步驟一：把內部問答分成三類，先決定哪些能公開

打開客服問答檔，每一題加一個欄位，標上三種狀態之一。這一步最花時間，也最不能跳過。

分類	判斷標準	示範情境中的例子	處理方式
可公開	答案對所有顧客都一樣，不涉及個資與內部權限	濾心建議更換週期、安裝前需要準備什麼	直接進入步驟二
需改寫	答案正確，但寫法是內部語言或帶有例外處理	「系統卡單時請轉二線」這類內部流程	改成顧客看得懂的版本後再公開
不可公開	涉及個別顧客、議價空間、法律爭議、尚未定案的政策	特定經銷商的進貨折扣、客訴和解條件	留在內部，不上官網

分類時請客服主管與老闆一起看。客服知道哪些題目最常被問，老闆知道哪些承諾不能白紙黑字寫出來。兩個人的判斷要放在同一張表裡，不要各自決定。

步驟二：合併重複題目，一個問題只留一個標準答案

內部問答檔通常是多年累積的。同一件事可能有三種問法、兩個版本的答案，甚至彼此矛盾。示範情境裡，「濾心多久換一次」就有四題，答案分別寫六個月、半年到一年、依水質而定、依用量而定。

公開之前，每一組重複題目要合併成一個標準答案。標準答案的寫法是：先給結論，再給條件，最後給例外。例如先寫「一般家庭建議每六個月更換一次」，再寫「用水量大或水質硬度高的地區可縮短」，最後寫「實際週期以技師檢測結果為準」。

合併後的問答，最好在內部也同步更新。不然官網寫六個月，客服還在回半年到一年，顧客會覺得你們說法不一，AI 也可能抓到兩種說法。

步驟三：決定頁面結構，一題一頁還是一類一頁

公開知識庫有兩種常見結構。選哪一種，看你的題目深度。

• 一題一頁：適合答案需要三段以上說明、有步驟或圖示需求的題目，例如「如何自行更換濾心」。好處是每頁主題單一，標題可以直接寫成顧客的提問。
• 一類一頁：適合答案短、彼此相關的題目，例如「付款與發票」底下的八個小問題。每題用小標題分開，答案控制在三到五句。
• 混合結構：分類頁列出所有題目的簡答，簡答下方連到一題一頁的完整說明。題目超過一百題的公司多半會走到這一步。

無論哪一種，每個答案的第一句都要能單獨成立。AI 引用時常常只截取一兩句，如果第一句是「這要看情況」，被截出去的就是一句沒有資訊的話。這個寫法原則，在 問答內容的結構化寫法 一文有更完整的段落範例。

步驟四：補上可查證的訊號，讓答案看起來有人負責

同樣一句「保固兩年」，寫在論壇和寫在官方知識庫，可信度不同。差別在於頁面上有沒有能讓人查證的訊號。每一頁至少放這幾項：

• 最後更新日期，並且真的在政策變動時更新
• 負責單位，例如「客服部」或「技術服務組」，不必寫個人姓名
• 適用範圍，例如「適用於二〇二四年後購買的機型」
• 相關政策的原始頁面連結，例如保固條款、退換貨辦法
• 找不到答案時的聯絡方式，並說明回覆時間

Google 對有幫助內容的說明，一再提到讀者要能看出內容是誰負責、為什麼值得信任。這份自我評估問題清單可以在 Google 建立有用內容的指南 找到，拿來檢查知識庫頁面很合用。

如果技術資源允許，可以替問答頁加上結構化資料，讓機器更容易辨識問題與答案的對應。實作順序可以參考 結構化資料從 Organization 到 FAQPage 的實作順序。結構化資料是輔助，不是前提。內容本身寫清楚，比標記重要。

步驟五：把知識庫接進網站，而不是放在孤島

很多公司把知識庫做成一個獨立子網域，或用客服系統內建的說明中心。這不一定錯，但要確認三件事：搜尋引擎能抓取、頁面有清楚的內部連結、官網主站有連過去。

示範情境的做法是這樣的。產品頁底下放「這款機型的常見問題」，連到對應的知識庫頁。服務頁的安裝流程段落，連到「安裝前準備」那一題。知識庫的每一頁，也反向連回產品頁與服務頁。這樣顧客不論從哪裡進來，都能在兩次點擊內找到答案。

上線後，用 Search Console 確認知識庫頁面有被索引。如果發現大量頁面「已檢索但未建立索引」，通常代表內容太薄或彼此太像，回到步驟二再合併一次。

步驟六：建立更新節奏，讓公開答案跟得上客服現場

知識庫最常見的失敗不是沒做，而是做完不更新。政策改了，客服知道，官網沒改。半年後 AI 引用的是舊答案，顧客拿著截圖來客訴。

我建議用一個很簡單的規則：客服每週回報一次「本週被問到、但知識庫沒有或答錯的題目」，由專人在下週內補上或修正。每季再做一次全面檢查，把已停售機型、已取消的服務標註清楚或下架。過期資訊的處理順序，可以參考 AI 引用舊價格與停售服務時的清理順序。

頻率	誰負責	要做什麼
每週	客服人員	回報新出現或答錯的題目
每週	內容負責人	補寫或修正上週回報的題目
每月	客服主管	抽查十題，確認官網與內部回覆一致
每季	老闆與客服主管	檢查政策變動、下架過期內容

公開之後，怎麼知道 AI 有沒有開始引用？

沒有一個工具能完整告訴你 AI 引用了你幾次。比較實際的做法是固定一組測試問題，每個月用幾個常見的 AI 助理問一次，記錄回答裡有沒有出現你的品牌、答案是否與官網一致、有沒有附上你的網址。

也可以在 GA4 裡觀察來自 AI 服務的轉介流量，但要小心解讀，因為不是每次引用都會帶來點擊。讀法上的陷阱，我在 GA4 的 AI 轉介流量八個常見誤判 整理過。

另一個值得看的訊號是客服量的變化。如果某一題公開後，客服被問到的次數變少，或顧客來問時已經先看過答案、問題變得更具體，這就代表公開答案在發揮作用。這個訊號比任何能見度分數都貼近營運。

適用與不適用的情況

適用的情況：產品或服務有固定規則、客服重複回答率高、顧客在購買前會先查資料的產業。例如家電、軟體訂閱、居家服務、教育課程、B2B 設備維修。

不適用或要非常謹慎的情況：答案高度個人化的服務，例如法律諮詢、醫療診斷、財務規劃。這類產業可以公開流程與一般原則，但個別答案不應該寫成標準答案。另外，政策還在頻繁變動、內部尚未統一說法的公司，請先把內部對齊，再談公開。公開一份互相矛盾的知識庫，比沒有知識庫更傷信任。

如果你想先評估自家客服問答有多少可以公開、該從哪一類開始，可以參考我們的 服務項目說明。