原創虛構教學範例，未預填模型結果。
可編輯的起點
- 1 · 要檢查的資料
- 我的月訂閱被扣了兩次款。可以幫我核對這兩筆付款嗎？
- 2 · 你想問的問題
- 這屬於哪一類意見？
- 3 · 定義 2–6 個選項
- 故障或錯誤
- 功能建議
- 帳務問題
- 使用協助
- 正面回饋
- 其他
這些是模型判斷的機率，不是實測準確率或保證。「是／否」對應你寫的標準，選項機率只在你提供的選項內比較。
先識別衝突來自哪裡
標籤重疊可能意味著兩種不同問題：流程只需要一個去向，但類別定義含糊；或者輸入確實同時具有多個屬性。重新命名類別不能讓一則包含兩個問題的訊息只剩一個問題。
本教學使用本站原創回饋範本，不重現社區測試，也不聲稱某組標籤表現最好。
不只改名稱，還要改規則
需要指定一個負責人時，說明每個標籤包含與排除的情況，並明確同時符合兩個標籤時怎樣處理。採用客服團隊能夠解釋的政策。必要時加入範圍之外或人工複核選項；這只是給模型一個可選答案，不保證它一定發現不確定性。
如果目標是記錄所有符合的屬性，應在完整流程里分別做是非檢查。本站自訂編輯器可以逐個體驗，但不會把 Choice 變成多標籤輸出。
檢查混合問題和資訊缺失
用一則同時涉及付款異常和登入失敗的虛構訊息，比較兩條各自只包含一個問題的訊息。再試一則沒有具體細節的抱怨。先決定應該怎樣處理，再執行；修改措辭後要回看之前的錯誤案例。
機率最高的標籤仍然可能錯誤。機率接近可以提醒人工複核，但結果很確定也不能證明被遺漏的類別沒有必要。
明確下一步由誰決定
資訊不足時，應用可以請求澄清或轉人工，不應編造帳戶事實，也不能把建議類別當作退款權限。本教學沒有給出通用機率門檻。
回到回饋分類方案，或閱讀 Choice 與 Noul，明確自己需要一個去向，還是多個獨立屬性。
來源與延伸閱讀
本指南以官方文件及附有連結的社群回報為依據。社群觀察均註明原作者。
我們如何查核來源可編輯的起點載入這個範本