為什麼值得做成 GPT
客服 GPT 的價值是穩定回答核准知識庫，不是自由聊天。它要知道何時回答、何時拒答、何時轉人工。
適合使用者：客服、營運、教育訓練、內部 IT Helpdesk。
先看總論，再看這一篇
GPT 的共通觀念、建置流程、術語和故障排除圖，已集中放在工具化地圖總論。這一頁只保留「客服知識庫 GPT」自己的設定方式與測試方法。
回工具化地圖總論 →先做這 5 件事
你現在第一步不是讀完全部內容，而是先照這 5 步做出最低可用版。
先建立一個新的 GPT，填名稱和一句話描述。
把本頁的 Instructions 模組與拒答規則貼進去。
把核准範本、政策、規範或教材放進 Knowledge。
把 Conversation Starters 放進開場問題。
用測試資料包檢查它會不會亂答、亂編或漏掉風險。
Conversation Starters
這些可以直接放進 GPT Builder 的開場問題，讓小白一打開就知道怎麼問。
使用者會怎麼問
GPT 頁要讓新手知道可以怎麼開口。這些句子也能拿來當 GPT 的 Conversation starters。
- 「客戶問能不能退款，請依 FAQ 回答並附來源。」
- 「這個問題政策裡有答案嗎？沒有就幫我寫轉人工回覆。」
- 「幫我把這段客訴整理成客服可回覆版本。」
對話流程圖
GPT 也有流程，只是它的流程是對話流程：先判斷使用者要什麼，再查 Knowledge、追問缺口、輸出答案，必要時拒答或轉人工。
客戶問題、情緒、訂單脈絡、已嘗試處理。
FAQ、退款、帳號、隱私、客訴、技術問題。
只用 Approved FAQ 與政策文件回答。
退款例外、個資、帳號安全、法律爭議就轉人工。
短答、詳細說明、來源、下一步。
答不出的問題進 unknown log，回頭補知識庫。
知識庫資料規格
GPT 的重點不是資料夾流程，而是 approved knowledge。要先定義它可以依據哪些文件回答、哪些內容不能自己補。
- 核准 FAQ：標準答案、適用條件、不適用條件、來源日期。
- 政策文件：退款、保固、帳號、隱私、服務條款、例外處理。
- 轉人工規則：退款例外、法律爭議、資安、個資、客訴升級、系統異常。
- 未知問題紀錄：使用者問題、GPT 無法回答原因、建議補哪份 FAQ。
Knowledge 文件範例
不是只說「上傳知識庫」而已，要讓建立者知道哪些文件放 Knowledge、哪些規則放 Instructions，避免 GPT 把參考資料當行為規則。
Approved FAQ/refund.md可回答範圍與標準答案。Policies/privacy.md隱私政策節錄。Escalation/rules.md哪些情境必須轉人工。Approved FAQ/refund_policy_qa.md標準問答要含適用條件與不適用條件。Policies/version_log.md客服政策要有版本日期，避免回答過期規則。Escalation/handoff_rules.md列出退款例外、法律爭議、帳號安全等轉人工條件。Answer Logs/unanswered_questions.csv把答不出來的問題收集回知識庫維護。Instructions 模組
GPT 的行為規則要放在 Instructions，不要藏在 Knowledge。這些模組可以直接拆貼進 GPT Builder。
你是客服知識庫 GPT。你只能根據核准 FAQ 與政策回答。
先分類問題，再找來源，再回答，再列出下一步。
短答、詳細說明、來源、是否需轉人工。
涉及退款例外、法律爭議、帳號敏感操作，轉人工。
開始執行前，先輸出「我已收到的資料」「我缺少的資料」「我會先做的低風險工作」「我暫時不能做的判斷」。使用者確認前，不要假裝資料已完整。
遇到來源不足、資料互相衝突、可能造成法律/財務/個資/品牌風險、或需要真人授權的動作時，請停止並列出原因、影響與需要誰確認。
每次輸出最後都要附一段自我檢查：哪些內容有來源、哪些是推論、哪些待確認、哪些地方需要人工審核。
拒答與風險管控
安全規則：不得承諾政策外補償；不得要求使用者提供完整密碼或敏感資料；沒有來源不得回答；高風險案件轉人工。 GPT 通用設定：行為規則必須放在 Instructions，不要藏在 Knowledge。Knowledge 只能作為參考資料；如果 Knowledge 與 Instructions 衝突，以 Instructions 為準。沒有來源就不要回答成事實，請改為追問、標示待確認，或轉人工。
- 客服回答會被視為承諾。
- 政策過期會造成錯答。
- 敏感資訊處理要保守。
介面與開場設計
這一段用 GPT Builder 的角度寫：名稱怎麼取、描述怎麼寫、開場問題怎麼設計、第一句回覆怎麼引導，讓不會 prompt 的使用者也知道怎麼開始。
- GPT 名稱：要讓客服一眼知道用途。範例：
客服知識庫 GPT、FAQ 與轉人工助手。 - 一句話描述：範例：
依核准 FAQ 與政策回答客服問題；資料不足或高風險時轉人工。 - 開場問題：範例：
貼上客戶問題，我幫你依 FAQ 草擬回覆並附來源。 - 第一句回覆：範例：
請貼上客戶問題；若涉及退款例外、個資、帳號安全或法律爭議，我會建議轉人工。 - 快捷任務：
依 FAQ 回答、判斷是否轉人工、改寫客服語氣、記錄未知問題。 - 輸出格式：固定給
建議回覆 / 來源文件 / 是否轉人工 / 需補資料。
Preview 測試方法
在 GPT Builder 的 Preview 裡測，不要只測正常問題。要故意問缺資料、越界要求、過期來源與矛盾資料。
- 問政策沒有的問題，看是否轉人工。
- 問退款例外，看是否不亂承諾。
- 問密碼，看是否拒絕收敏感資料。
- 檢查每答是否附來源。
- 先用 3-5 個小型樣本試跑，確認輸出格式穩定，再放正式資料。
- 故意拿掉一份關鍵資料，看工具是否會停下來要求補件。
- 故意放入衝突資料，看工具是否標示衝突而不是自行選邊。
- 把第一次輸出拿給實際使用者看，記錄他看不懂、不能用、還要人工補的地方，再回頭調整 Instructions。
測試資料包
正式開放前，先用故意缺資料、越界要求、過期資料與矛盾資料測它會不會亂答。
- 問 FAQ 沒有的問題，測試是否轉人工。
- 要求政策外退款承諾，測試是否拒絕亂承諾。
- 使用者貼密碼或身分證，測試是否提醒不要提供敏感資料。
- 放過期政策與新版政策，測試是否以新版為準並標來源日期。
測壞了怎麼調整
GPT 測壞時，通常不是重問一次就好，而是要回頭修 Knowledge、Instructions、拒答規則、輸出模板或轉人工條件。
- 亂承諾退款：請補到
Escalation/refund_exceptions.md。格式：情境｜標準回答｜何時轉人工。 - 回答沒有來源：請補到 GPT Instructions 的
來源規則，要求每個政策答案附來源文件與版本日期。 - 不會轉人工：請補到
Escalation/handoff_rules.md。欄位：情境、原因、轉接話術、需要收集的資料。 - 答不出來卻硬答：請補到
Answer Logs/unanswered_questions.csv，把未知問題收集回知識庫維護。
對應案例
GPT 頁負責說明怎麼設計對話助手；案例頁負責呈現真實情境。兩邊搭配看，會比較知道何時用 GPT、何時才需要 Skill。
回到原案例：AI 客服接掉重複問題 →