回答很順就可以驗收嗎？

不可以只看語句。需核對答案依據、來源版本、權限、業務規則，以及無答案與失敗時的處理。

準確率多少才算通過？

沒有適用所有流程的數字。先定義任務、測試集、判定方法和風險，分別約定門檻，重要錯誤另列必要條件。

依風險與授權決定。建議先驗證草稿與人工核准流程，確認身份、例外和失敗處理後，再評估哪些低風險步驟可自動化。

這是教學用的假設，不是真實測試成果，也不是建議只測 10 題。假設 9 個一般問答通過，第 10 個卻在未經核准時送出客服訊息；即使算式是 9 ÷ 10＝90%，仍不能通過本次「未核准不得送出」的必要條件。

必要條件失敗要修復並重測受影響流程；正式測試集還需涵蓋角色、資料版本與例外情境，不用這個小範例宣稱系統安全。

知識庫回答、客服草稿、文件欄位及訂單寫入各有不同完成條件。先列出一項任務需要哪些依據、哪些錯誤不能接受，以及何時必須轉人工。門檻由雙方依風險約定，不承諾通用的固定正確率；高風險資料修改不能用整體平均表現掩蓋。

以已授權且去識別化的樣本記錄問題、預期結果、來源版本、使用角色與判定理由。調整用樣本和驗收用樣本分開，避免只對展示題調整；約定抽樣方式、重測次數與模型及設定版本。答案可能不完全逐字相同，因此要訂可核對的內容標準，不能只比字串。

每項應留存測試輸入、角色、時間、結果及判定。以下是需要依專案改寫的檢查表，不是使用我們的示範頁就已通過安全驗收。

知識庫要核對來源與資料更新；客服要看草稿適用性、人工修改及是否正確轉交；文件要逐欄核對缺漏、格式、加總與重複匯入。若涉及訂單或金額，額外核對業務規則，不能只因欄位看起來完整就允許寫入。

記錄成功完成率、回答有依據比例、欄位錯誤、人工修改時間、轉人工原因、回應時間及實際用量；各指標定義與分母先寫清楚。保留未完成與失敗紀錄，不只統計成功案例。先與原人工流程比較，再決定擴大，不把小樣本試點的結果宣稱為所有情境的節省比例。

交付帳號權限、原始碼及部署文件的約定範圍、資料更新方法、操作與異常處理說明、用量監看、備份及回復方式。新增文件、替換模型或改串接時，要重跑受影響的測試。事前約定未達門檻的修正、複驗與停止程序；風險管理是持續工作，不是驗收一次就永久安全。