AI知識庫怎麼做才可靠？建立有來源、例外與失效日期的FAQ答案卡
原內容日期：2026-09-19。本文為既有教學內容補發；範例依原文標示使用，實際權限與規則請以所屬組織核定資料為準。
文件明明存在，為什麼大家還是一直問？
多數公司的問題不是完全沒有文件，而是文件散落、版本不同，使用者也不知道哪一份才適用。
同一個帳號申請問題，SOP寫兩個工作天，舊上線Email寫原則上當天，群組中又有人說可以先借帳號。若把這些資料全部交給AI摘要，它可能拼成一個流暢卻危險的答案。
可信FAQ的第一步不是寫得像客服，而是建立來源權威順序。
先分正式規則、補充依據與個案說法
已核准且仍生效的政策與SOP，應是主要依據；正式手冊和決議可以補充；Email與群組內容只能描述當時做法，不能自動變成通用規則。
如果來源衝突，AI不應自行挑一個最方便的答案，而應並列差異，說明目前能回答到哪裡，並指定需要哪個角色確認。
答案要能執行，而不只是看懂
「請洽IT」不是完整答案。
使用者真正需要知道的是：誰可以申請、準備什麼、從哪裡開始、誰核准、時間從何時起算、怎麼知道完成，以及遇到例外要找誰。
因此，每張答案卡都要有短答案、操作步驟、完成證據與轉交條件。
適用範圍比答案本身更重要
一般帳號、高權限帳號與外部供應商帳號，不能共用同一個答案。內部員工的正常流程，也不能被直接套用在緊急、跨公司或涉及敏感資料的情境。
答案卡應同時標示適用與不適用情境。資訊不足時，AI先問必要的澄清問題，而不是立即產生完整步驟。
服務目標不等於保證
「資料齊全後兩個工作天」「通常兩天」「預計今天完成」代表不同性質。
FAQ要說明起算點、工作天或日曆天、缺件是否暫停，以及這是正式承諾、服務目標還是個案預估。否則AI很容易把一句友善回覆改寫成對所有人的保證。
不回答也是可信能力
成熟的知識庫需要四種路由：直接回答、先澄清、轉交人工與拒絕推測。
遇到高權限、財務、資安、個資或來源衝突時，轉交並不是失敗。相反地，若AI為了讓每題都有答案而發明規則，才會產生真正風險。
每張答案都要有失效條件
表單位置、負責單位、系統畫面與政策都會變。FAQ如果沒有負責人與複查日期，建立得越多，未來的過期風險越大。
答案卡應記錄來源版本、內容負責人、最後複查、下次複查與失效條件。政策改版後，也要能反向找出所有受影響的答案。
AI整理知識，人類確認權威
AI很適合將不同問法分群、比對來源、草擬答案卡與產生情境測試。但它不能替組織決定哪份文件正式生效，也不能發明緊急捷徑或權限規則。
好的企業FAQ，不只是讓同事少問一次，而是讓每次回答都一致、可追溯、可執行，也知道什麼時候必須把決定交還給人。
文章CTA： 收藏完整提示詞，先從團隊每週重複回答最多的10個問題開始建立可信答案卡。
逐步操作
步驟 1：先定義 FAQ 的範圍
不要一開始就說「建立公司知識庫」。先選一個可控範圍，例如：
- MES 帳號與權限申請
- 差旅報帳與退件處理
- 專案問題回報與升級
- 新人設備領用
- 供應商進廠申請
寫清楚包含、不包含、主要使用者與預期決策。
步驟 2：收集真實問題，不只看文件目錄
問題來源可以包括：
- 客服或 IT 服務台紀錄
- Teams、Slack、LINE 群組的常見詢問
- Email 主旨與往返內容
- 新人訓練中的提問
- 會議紀錄中的待釐清項目
- 搜尋關鍵字與找不到結果的紀錄
先去識別化，再替每個問題加上 Q-001 之類的編號。
步驟 3：把不同問法聚成同一個問題意圖
例如以下三句可能屬於同一群：
- 「MES 帳號要找誰開？」
- 「新人下週進廠，怎麼申請登入？」
- 「權限申請要多久？」
但「一般查詢權限」與「可修改主資料的高權限」不應硬合併。分群時要保留角色、權限層級與使用情境。
步驟 4：建立來源清單與權威等級
建議分為：
| 等級 | 說明 | 範例 |
|---|---|---|
| A 正式有效 | 已核准、已生效、仍適用 | 正式政策、現行 SOP、核准公告 |
| B 補充依據 | 可協助解釋，但不能推翻 A | 使用手冊、FAQ、正式會議決議 |
| C 情境參考 | 只描述某次做法 | 專案 Email、個案紀錄、群組回覆 |
| D 未確認 | 來源、版本或權責不明 | 口頭說法、轉述、無日期截圖 |
回答優先依 A，再用 B 補充。C 只能標示為個案做法；D 不得寫成正式規則。
步驟 5：確認文件是否真的有效
每份來源至少記錄：
- 文件編號與名稱
- 版本
- 生效日期
- 核准或發布角色
- 適用範圍
- 被哪份文件取代
- 內容負責人
- 最後複查日期
修改時間最新，不代表正式有效；檔名寫 final，也不代表已核准。
步驟 6：建立問題到來源的證據矩陣
| 問題編號 | 問題意圖 | 主要來源 | 支持段落 | 補充來源 | 衝突來源 | 證據狀態 |
|---|---|---|---|---|---|---|
沒有可靠來源時，答案應標示「目前文件未定義」，而不是由 AI 填補。
步驟 7：先寫一句短答案
短答案應在 1 至 3 句內回答：
- 可以或不可以
- 誰可以申請
- 從哪裡開始
- 最重要的限制
例如：
一般 MES 帳號由部門主管核准後交資訊部建立。服務時間從資料及核准齊全後起算；高權限與外部人員需額外審查。
不要在第一段塞滿所有例外。
步驟 8：補上可執行步驟與完成證據
每題至少說清楚：
- 開始條件
- 需要準備的資料
- 提交管道
- 核准角色
- 處理狀態
- 完成證據
- 查詢進度方式
「請找 IT」不夠可執行；「填寫表單並取得申請編號」才容易追蹤。
步驟 9：分開規則、目標時間與承諾
文件可能寫「通常兩個工作天」「服務目標兩日內」或「預計當天完成」。三者不一定是保證。
FAQ 應說清楚：
- 起算點
- 工作天或日曆天
- 目標或正式承諾
- 暫停計時條件
- 缺件如何處理
不要把個案中的「今天幫你開」改寫成所有申請都能當日完成。
步驟 10：列出例外、禁止事項與人工閘門
特別檢查：
- 高權限帳號
- 外部供應商或臨時人員
- 共用帳號
- 緊急申請
- 離職、調職與到期
- 財務、個資、品質或法規資料
- 系統異常時的替代流程
沒有正式例外規則時，FAQ 要說「請轉交指定角色判斷」，不能自行創造捷徑。
步驟 11：定義四種回答路由
- 直接回答： 正式來源清楚、風險低、使用者條件完整。
- 先澄清： 缺角色、地點、權限層級、日期或其他必要條件。
- 轉交人工： 涉及例外、核准、敏感資料或來源衝突。
- 拒絕推測： 沒有政策依據，或要求繞過權限與控制。
「不知道」不是失敗；不知道卻回答，才是知識庫風險。
步驟 12：建立完整答案卡
每張卡建議包含：
- 問題標題
- 常見問法
- 短答案
- 適用對象與情境
- 不適用情境
- 操作步驟
- 必要資料
- 完成證據
- 例外與禁止事項
- 需要澄清的問題
- 轉交對象與條件
- 正式來源、版本、段落
- 內容負責人
- 複查日期與失效條件
步驟 13：用情境題測試答案
至少測試：
- 一般員工正常申請
- 資料缺漏
- 高權限需求
- 外部人員
- 緊急但沒有核准
- 文件來源互相衝突
- 問題超出範圍
- 使用者要求繞過流程
測試目標不是讓 AI 每題都回答，而是確認它會在正確時機停下來。
步驟 14：設計更新與失效機制
觸發複查的條件包括：
- 正式政策或 SOP 改版
- 表單、網址、系統或負責單位變更
- 新角色、新權限或新例外出現
- 同一問題的人工轉交率突然增加
- 使用者回報答案無法執行
- 來源文件到達複查日期
答案卡不只要有建立日期，也要有下次複查與負責人。
步驟 15：發布前由來源負責人核准
發布前確認：
- 引用的是正式有效版本
- 步驟與目前系統一致
- 時間沒有被寫成不實保證
- 例外與轉交對象仍有效
- 沒有洩漏權限配置或敏感資料
- 答案卡不是用來繞過正式政策
- 對外或跨部門版本已做資訊分層
可直接複製的完整提示詞
【角色】
你是一位謹慎的企業知識管理與內部服務設計助理。你的任務是把正式文件、補充說明與真實常見問題整理成可追溯、可執行的 FAQ 答案卡。你不能發明政策、權限、期限、表單、網址、負責人或例外規則。
【任務】
根據我提供的問題紀錄與來源文件：
1. 將不同問法整理成問題意圖，但保留角色、情境與權限層級差異。
2. 判斷來源的權威等級、版本、適用範圍與是否仍有效。
3. 建立問題到來源段落的證據矩陣。
4. 產生包含短答案、操作步驟、例外、轉交與複查資訊的答案卡。
5. 找出來源衝突、文件缺口、過期風險與不能回答的問題。
6. 產生測試情境，確認回答何時應直接回答、澄清、轉交或拒絕推測。
【知識庫範圍】
- 主題：[例如：MES帳號與權限申請]
- 主要使用者：[一般員工／主管／資訊部／外部人員／其他]
- 包含：[流程、權限、異常或其他]
- 不包含：[填寫]
- 預期使用位置：[內部網站／客服手冊／AI助手底稿／新人手冊]
- 語氣：[專業、親切、簡潔]
【問題輸入格式】
問題編號｜日期｜提問者角色｜使用情境｜原始問題｜既有回覆｜來源管道
[貼上去識別化問題]
【來源文件格式】
來源編號｜文件名稱｜版本｜生效日期｜核准／發布角色｜適用範圍｜內容負責人｜取代關係｜相關段落原文
[貼上資料；不知道填「未知」]
【來源權威規則】
- A正式有效：已核准、已生效、仍適用的政策、SOP或公告。
- B補充依據：手冊、正式FAQ或會議決議，可補充但不能推翻A。
- C情境參考：Email、個案紀錄或群組回覆，只能描述當時做法。
- D未確認：口頭轉述、無日期截圖、版本或權責不明，不得作為正式答案。
- 組織自訂優先序：[若有請填；沒有則依上列]
【限制與判斷規則】
1. 只能使用提供的來源，不得用常識補寫公司政策。
2. 每個答案都必須引用來源編號、版本及支持段落；找不到來源時標示「目前文件未定義」。
3. 正式有效來源優先於補充與個案來源；修改日期最新不等於正式有效。
4. Email或群組中的臨時處理不得自動升級為通用規則。
5. 如果來源衝突，並列呈現，不自行選擇方便或較新的說法。
6. 區分正式規則、服務目標、預估時間、個案承諾與建議做法。
7. 提出者希望的時間不等於處理單位已承諾的期限。
8. 每題標示適用對象、開始條件、不適用情境與必要前提。
9. 步驟必須可執行；沒有提供表單名稱、網址或負責角色時填「待確認」，不得捏造。
10. 高權限、外部人員、共用帳號、緊急申請、財務、資安、個資、品質及法規事項必須標示人工審查。
11. 不得建議共用密碼、繞過核准、借用帳號或關閉安全控制。
12. 不得輸出密碼、API金鑰、內部主機資訊或可被濫用的權限細節。
13. 使用者條件不足時，先提出最多3個必要澄清問題。
14. 沒有可靠答案時，選擇轉交或拒絕推測，不為了完整而作答。
15. 每張答案卡必須包含內容負責人、最後複查日期、下次複查日期或失效條件；未知則標示待指定。
16. 不得把「已提交」寫成「已核准」，也不得把「已建立帳號」寫成「權限已驗證可用」。
17. 引用原文只保留支持判斷的最短必要片段，不暴露個資或機密。
18. 回答應分層：先給短答案，再給步驟、例外、來源與轉交方式。
19. 所有對外答案與正式政策變更都需來源負責人核准。
20. 使用繁體中文，避免法律式長句與無法執行的「請洽相關單位」。
【輸出格式】
一、資料完整性與範圍
- 實際讀取的問題數與來源數
- 缺少版本、生效日期、負責人或適用範圍的來源
- 目前可建立答案與不能建立答案的數量
二、主管摘要
限180字，說明可直接發布、需補證據、來源衝突及高風險人工審查的問題數量，並列最優先補件。
三、問題意圖分群
| 意圖編號 | 標準問題 | 常見問法編號 | 角色／情境差異 | 是否需拆題 | 原因 |
四、來源清單與權威判讀
| 來源編號 | 文件／紀錄 | 版本與日期 | 權威等級 | 適用範圍 | 有效性 | 判斷理由 | 待確認 |
五、問題－來源證據矩陣
| 意圖編號 | 主要來源及段落 | 補充來源 | 衝突來源 | 證據狀態 | 可否發布 |
六、可信FAQ答案卡
每題使用以下格式：
- 卡片編號：
- 標準問題：
- 常見問法：
- 30字內短答案：
- 適用對象與情境：
- 不適用情境：
- 開始條件：
- 操作步驟：
- 必要資料：
- 處理時間及性質（正式承諾／服務目標／預估／未知）：
- 完成證據：
- 例外與禁止事項：
- 最多3個澄清問題：
- 轉交條件與角色：
- 正式來源（編號／版本／段落）：
- 內容負責人：
- 最後複查／下次複查：
- 失效條件：
- 證據信心（高／中／低）及理由：
七、回答路由表
| 問題／情境 | 直接回答 | 先澄清 | 轉交人工 | 拒絕推測 | 理由 |
八、來源衝突
| 問題 | 來源A | 來源B | 衝突內容 | 目前可說到哪裡 | 建議確認人 |
九、知識缺口與待補文件
| 缺口 | 使用者因此無法完成什麼 | 風險 | 建議補件 | 建議負責角色 |
十、過期與複查清單
| 答案卡 | 複查觸發條件 | 下次複查 | 負責角色 | 未複查風險 |
十一、情境測試
| 測試編號 | 使用者情境 | 預期路由 | 預期回答重點 | 禁止回答內容 |
十二、新人版快速指南
用「先做什麼、準備什麼、如何知道完成、遇到例外找誰」整理成一頁。
十三、人工核准清單
列出答案發布、政策引用、敏感內容、轉交角色與複查日期的確認事項。
建議分兩輪執行
第一輪先輸出來源清單、權威判讀、證據矩陣與缺口，不急著寫完整答案。由文件負責人確認來源後，第二輪再產生答案卡與情境測試。
實際教學範例
情境：MES帳號與權限申請
團隊蒐集到以下資料：
| 來源 | 類型 | 內容節錄 |
|---|---|---|
| S-01 | 現行SOP v3.0，已核准 | 一般帳號需部門主管核准；資訊部於資料及核准齊全後兩個工作天內建立。 |
| S-02 | 上線通知Email，較早 | 請各部門把名單寄給專案經理，原則上當天協助開通。 |
| S-03 | 資安規範 v2.1，已核准 | 高權限與外部帳號須資安審查；外部帳號最長90日，禁止共用帳號。 |
| S-04 | 群組聊天 | 急的話先借同事帳號登入，之後再補申請。 |
常見問題：
- Q-01：新人MES帳號要找誰申請？
- Q-02：今天申請可以今天用嗎？
- Q-03：供應商進廠可以共用一組帳號嗎？
- Q-04：臨時要改主資料，能不能先開權限？
來源判讀
| 來源 | 等級 | 判讀 |
|---|---|---|
| S-01 | A正式有效 | 一般申請的主要依據 |
| S-02 | C情境參考 | 舊上線期間的個案安排，不能推翻現行SOP |
| S-03 | A正式有效 | 高權限與外部帳號的必要限制 |
| S-04 | D未確認且高風險 | 與正式資安規範衝突，不得作為答案 |
答案卡範例
卡片編號： FAQ-MES-001
標準問題： 新進員工如何申請一般MES帳號？
短答案： 由部門主管核准後交資訊部建立；兩個工作天的服務時間從資料與核准齊全後起算。
適用對象： 內部員工的一般操作權限。
不適用： 高權限、外部供應商、臨時共用帳號。
必要資料： 使用者匿名識別資料、部門、職務所需角色、生效日期及主管核准。
完成證據： 已取得個人帳號，且使用者完成首次登入與指定功能驗證。
例外： 緊急處理方式在現有正式文件中未定義，需由資訊部與權限核准角色決定。
來源： S-01 v3.0相關段落；高權限另依S-03 v2.1。
禁止事項： 不得借用或共用他人帳號。
內容負責人： 待依SOP確認。
失效條件： 申請流程、資訊部服務時間或權限政策改版。
四題正確路由
| 問題 | 路由 | 回答重點 |
|---|---|---|
| Q-01 新人申請 | 先澄清後回答 | 確認一般或高權限，再依S-01流程 |
| Q-02 當天可用 | 直接回答但不保證 | 正式依據是資料及核准齊全後兩個工作天；S-02只代表舊個案 |
| Q-03 供應商共用 | 拒絕並轉交 | S-03禁止共用，外部帳號需資安審查且最長90日 |
| Q-04 緊急高權限 | 轉交人工 | 不能先開後補；由核准與資安角色判斷，現有文件未定義快速通道 |
不好的AI回答
請把名單寄給專案經理，通常當天就能開通。若很急，可先借同事帳號使用，之後再補申請。
錯誤原因：
- 使用舊Email取代現行SOP。
- 把「原則上」改寫成服務保證。
- 採用未確認的群組做法。
- 違反禁止共用帳號的正式資安規範。
- 沒區分一般、高權限與外部帳號。
知識缺口
- 緊急高權限是否有正式快速審查流程？
- 一般帳號的正式申請表單名稱與位置？
- 兩個工作天若遇資料缺漏，是否暫停計時？
- 帳號建立後由誰驗證權限正確？
- 內容負責人與固定複查週期？
AI應將這些列為待補文件，而不是自行補答案。
常見錯誤、隱私與使用注意事項
常見錯誤
- 把最新檔案當現行規則： 修改時間不代表正式核准。
- 用舊Email覆蓋SOP： 個案安排不一定能重複使用。
- 為了每題都有答案而猜測： 知識缺口反而被隱藏。
- 只有連結沒有步驟： 使用者仍不知道怎麼做。
- 沒有適用範圍： 一般流程被高權限或外部人員誤用。
- 把服務目標寫成保證： 也沒有說明起算點與缺件條件。
- 未區分提交與完成： 申請送出不等於帳號已驗證可用。
- 忽略禁止事項： 正常答案可能被用來繞過安全控制。
- 沒有轉交條件： 所有例外都被丟給同一個人。
- FAQ沒有負責人： 過期內容無人更新。
- 只測正常問法： 面對誘導、模糊或越權問題時才出錯。
- 引用過長原文： 增加機密與個資洩漏風險。
資料隱私
- 問題紀錄先移除姓名、Email、帳號、電話與可識別事件細節。
- 不把密碼、權杖、內部主機、VPN設定或權限配置放入FAQ。
- 人事、薪資、醫療、申訴與績效問題不應由一般FAQ直接回答個案。
- 外部版本需移除內部表單、聯絡人與系統路徑。
- 小群組或特殊事件即使匿名，也可能重新識別個人。
- 使用組織核准的AI環境及資料保存規範。
使用注意事項
- AI整理出的來源等級仍需文件負責人確認。
- FAQ不能取代正式政策；兩者衝突時以正式有效來源為準。
- 建立聊天機器人前，先把答案卡做成人工可用版本。
- 高轉交率可能代表FAQ不清楚，也可能代表流程本身缺政策。
- 回答品質除了正確率，也要看錯答風險、轉交正確率與過期率。
- 政策改版時要反向找出所有受影響答案卡。
留言