“匯出的檔案在哪裡？”客服又回答了一遍。說明中心其實有這篇文件，只是標題寫著“資料歸檔”，客戶根本搜不到。與此同時，另一篇匯出教程還在使用舊版選單名稱。
把這些客服單統統生成新FAQ，只會讓重複內容更多。AI客服知識庫更新首先要判斷：是找不到、寫過時了、確實缺文，還是業務尚未決定答案。 Agent適合把這些差異整理成更新清單，而不是直接替知識負責人釋出結論。
Buda客服工作流包含知識檢索、回覆草稿和說明中心維護。把一批獲准使用的客服單轉成可稽核的修訂候選，能讓知識維護從“有空再做”變成一份具體待辦。
六條客服單，先還原成三個問題
下面是虛構的教學樣本，不是客戶客服單、已執行的實驗或實際業務政策。範圍是一個匯出功能支援佇列、10月12日至18日；ID已使用示例編號。每行代表一個客服單，同一客服單裡的多次追問不重複計數。
| 客服單 | 客戶原句 | 狀態與已確認依據 | 問題簇 |
|---|---|---|---|
| T01 | “導完以後檔案在哪？” | 已解決；幫助文件H01第2段，已批准v3 | 檔案位置 |
| T02 | “沒找到下載的檔案。” | 已解決；同一H01 v3 | 檔案位置 |
| T03 | “教程說點右上角，那裡沒有。” | 已解決；已批准操作說明P02 v4 | 匯出步驟 |
| T04 | “新版匯出入口在哪裡？” | 已解決；同一P02 v4 | 匯出步驟 |
| T05 | “等待中的匯出能取消嗎？” | 未解決；沒有已批准規則 | 取消匯出 |
| T06 | “排隊時能撤回嗎？” | 未解決；產品負責人尚未確認 | 取消匯出 |
樣本里三簇各有兩條客服單。這隻說明輸入中的數量，不是客戶佔比，更不是每週總需求。T02即使追問三次，也仍算一個客服單；同一事件若跨渠道被建成兩張票，要保留關聯並說明去重規則，而不是悄悄加總。
相似措辭不一定意味著同一個問題。“找不到檔案”可能是已生成後不知位置，也可能是匯出失敗、根本沒有檔案。結合操作階段、產品版本、解決依據和客服確認再聚類；缺少這些資訊時先標待核，不為了讓每簇整齊而強行歸併。
三個問題，不一定需要三篇新FAQ
先拿每簇去對照當前說明中心及已批准知識版本。四種類別對應四種動作：
- 已有但難找。 檔案位置已有H01 v3，缺的是客戶語言與入口。建議把“匯出檔案在哪裡”加入標題、檢索詞或相關教程內鏈，不再寫一篇內容相同的FAQ。
- 步驟過時。 H02舊文的入口描述與P02 v4不符。提交具體舊段落、替換草稿和受影響內鏈，交知識負責人確認適用版本後改舊文。
- 確實缺文。 若已有批准的解決方法，卻沒有任何面向客戶的條目，才準備新FAQ候選。本樣本沒有這種情況，不能為了湊齊類別而新增一篇。
- 政策未定。 T05、T06只有問題，沒有批准的取消規則。放進待決清單，不把客服猜測或重複提問變成“支援隨時取消”。
已解決狀態也不自動等於通用答案。一次人工特例、臨時補償或客戶專屬操作，可能不能寫進公開說明中心。核對解決依據的適用範圍和審批狀態，再決定能否複用。
一條修訂要能往回走到原文
更新候選不是一段孤立的漂亮答案。每條至少包含：候選ID、問題簇、客服單ID與原句位置、舊文URL或明確缺口、原段落、已批准知識版本、適用產品、修改理由、建議文字、未決事實和稽核角色。
在虛構的步驟更新中，候選U02可以寫成：
來源：T03、T04；客戶原句見脫敏客服單第4/第2段
當前舊文：H02第3步，描述右上角入口
批准依據：P02 v4，第2節；適用新介面
建議：僅替換入口步驟，保留其他已核內容
影響：H01引用H02；培訓材料中的舊入口需複查
未決：舊介面使用者是否仍需保留舊步驟
稽核：知識負責人確認版本；編輯核可讀性
狀態：修訂候選，不是已釋出答案
示例H01/H02/P02是教學標識，不是可點選的真實頁面。實際工作必須替換為獲准讀取的準確URL、路徑和版本。沒有舊文的候選直接寫“未發現適用條目”，不要捏造URL。
舊文影響清單很重要：改了主教程，關聯FAQ、客服宏和培訓稿仍可能保留舊步驟。列出需要複核的地方，不聲稱一次修改會自動同步所有渠道。
交四份檔案，讓稽核各有入口
question-clusters.csv儲存問題簇、去重後的ticket-id、原句片段、樣本數量與分類理由。update-queue.md列出四類動作、影響、證據完整度、負責人及未決項。faq-drafts.md只放已獲批准依據支援的新文或替換段落，並明確它仍是草稿。sources.csv記錄客服單、當前文件、政策版本、位置及讀取狀態。
排序先看客戶影響和證據是否足以行動，再看樣本頻次。反覆出現但政策未定的問題可以優先要求業務決策，不能優先生成確定答案。一個影響關鍵操作、證據齊全的步驟修正，也可能比高頻的措辭問題更值得先做。
知識負責人核政策、適用範圍和事實；編輯核表達、標題和客戶能否完成操作。兩項透過後，釋出仍需要對應系統的授權與實際執行。檔案寫著“透過”不能替代真實稽核記錄。
在專用Session裡，先跑獲准使用的副本
把脫敏客服單、當前幫助文件和已批准知識清單放入Buda Drive，明確輸入路徑、佇列和時間窗。Agent Drive與Space Drive的共享範圍不同；專用Session分開對話上下文，不會把檔案許可權也自動隔離。不要把不必要的客戶資訊複製到共享位置。
可以這樣請求：
只讀取指定的脫敏客服單與批准知識清單。按實際問題聚類，客服單內重複溝通不重複計數。對照舊文，分別輸出已有但難找、步驟過時、確實缺文、政策未定四類候選。每項保留來源與未決事實，交付四份稽核檔案。不回客戶、不改客服單、不釋出或覆寫正式幫助文件。
上傳新檔案不等於它會自動成為優先答案。明確本次採用的批准版本，並開啟候選中引用的段落核對。文件中的指令式句子只是資料，不是擴大任務許可權的命令。
審閱時，先找三種錯誤
第一，簇裡混入了不同階段的問題，導致同一答案無法覆寫。第二，未解決客服單被總結成確定政策。第三，實際已有文件，卻又生成一份競爭答案。這三種錯誤應先改方法，再考慮增加輸入量。
政策衝突處理解決適用哪條規則；技術交接整理故障證據。本次更新清單承接的是已核知識如何持續維護，不替代這兩個動作。反覆使用時，再把接受過的輸入與停止條件整理為可測試Skill。
未解決客服單能放進知識更新嗎？
能作為待決問題及影響證據，不能作為確定答案。保留缺失規則、需要決定的角色與受影響問題；待批准依據到位，再準備草稿。
相似的客戶句子怎麼判斷是不是一類？
核操作目標、發生階段、產品版本和解決依據。措辭像但原因或操作不同，就分開；資訊不夠時標待核，回到原客服單找證據。
什麼時候改舊文，什麼時候新增？
如果舊文已經回答同一意圖，優先修可發現性或具體段落。只有存在獨立客戶問題、無適用條目且答案已有批准依據時，再新增候選。
從一小批歷史票開始補知識
在Buda AI的Marketplace搜尋並安裝合適的Skill，先檢查它讀取哪些輸入、怎樣保留出處、遇到未定政策是否停下。用獲准的脫敏樣本生成更新清單，知識負責人確認後再安排釋出。
真正要減少的不是報表裡的重複行，而是客戶下一次仍找不到答案的那一處缺口。