先用合成工單練習驗收，再選模型與部署方式。本篇提供可複製的輸入、預期輸出、故意出錯的答案與成本公式，不用購買設備或申請 API key。完成後會得到一份能交給別人重跑的評估單，清楚區分模擬練習與真實模型結果。
目錄+
模型回覆「完成了」，你要拿什麼確認？先用一份合成工單練習，不用 API key，也不用買硬體。這次會完成任務範圍、資料邊界、正確答案、驗收紀錄與成本欄位，最後交出一張可重跑的評估單。
本文是離線驗收練習，沒有執行任何模型。下方輸入、答案與金額全是教學用假設，不能當成模型表現或供應商報價。下載 AI 部署評估單，用文字編輯器就能開始。
把「協助客服」縮成一個可判斷的任務
這次只做工單分類，允許的結果是帳務、操作、人工。缺少判斷依據就交給人工，不能補出客戶身分，不能退款、改帳號或發信。分類與實際操作分開後，驗收者才知道自己要檢查哪一段。
Hugging Face 公開的 ML Intern 需求書，也要求先做基準與小規模檢查，再投入正式作業。這裡借用的是先定義驗收的做法，沒有照搬案例的訓練成本或成果。來源：作者公開需求書
在評估單寫下使用者、輸入、輸出與禁止動作。接著補一個具體場景：客服收到工單後先看建議，再自行處理。若你寫成「自動解決所有客服問題」，就還沒有能交給別人驗收的範圍。
複製合成輸入，先把答案封存
下列是虛構資料。規則刻意保持簡單：明確提到退款或發票歸帳務；明確詢問登入操作歸操作；同時跨兩類或缺少資訊歸人工。標籤由這份練習規則決定，不宣稱適合任何真實客服業務。
T01：請問上月付款的發票在哪裡下載？
T02：登入頁面要在哪裡切換語言？
T03：我想退款，也無法登入帳號。
T04：昨天那件事還沒處理，幫我改一下。
預期答案依序是帳務、操作、人工、人工。先寫進評估單再看候選答案，避免收到漂亮回覆後才放寬規則。也在資料邊界欄填上「僅合成文字」，不放真實姓名、帳號或交易內容。
練習時不需要把資料送到任何服務。之後若要試模型，再確認候選部署的輸入、工具、紀錄各自流向哪裡。自架模型若連到外部工具，同樣需要另外記錄，不能只寫一句「本地處理」。
故意放進一個錯答案
先把這份候選輸出貼到評估單。它也是人工編寫的假設範例，目的是讓你驗證評分方法能不能抓錯。
T01：帳務
T02：操作
T03：帳務
T04：人工
按照封存答案，第三筆應該失敗。它同時包含退款與登入，練習規則要求人工處理。不要因為「帳務也說得通」就算通過，否則評分會隨心情改變，之後換模型也沒有可比的基準。
逐筆記錄預期、實際、通過與否、失敗原因。這個假設樣本的分類通過率是四筆中的三筆，但它只能證明你會按規則計分，不能推論任何模型的準確率，更不能代表上線後的成功率。
加一個會改變交付判斷的檢查
在候選輸出尾端加一句「已替客戶退款」。即使分類全對，也應判定整批不合格，因為任務禁止執行或宣稱執行退款。這個檢查讓你看見：欄位分數和可否交付，是兩種判斷。
完成一份紀錄後，再複製成第二輪，把錯誤修正並移除越權宣告。兩輪都保留，寫明修改的是候選答案，而非模型。這樣別人拿到檔案，就能重現第一次為何失敗、第二次為何通過。
若往後接上工具，還要用工具回傳或系統狀態確認動作。模型聲稱寫入成功，不能代替資料庫查詢。站內 FDE 作品集的驗收與權限設計提供更完整的交付範圍。
算成本時，把人工時間寫進去
評估單分開保留 API 與自架欄位；沒用到的項目填不適用。API 成本按每次輸入、輸出與當日單價相加；自架則填使用期間的設備或租機、電力與維護。最後加上人工檢查與修正時間，除以合格交付件數。
你可以用附件的假設金額檢查算式，之後全部換成自己的紀錄。若沒有合格交付，成本應標為無法計算；若尚未量到延遲，就留空並寫待測。不要讓空白自動變成零，掩蓋還沒完成的驗證。
交付前請另一個人只看評估單重跑。他應能找到規則、辨認錯答案、說出停止條件並算出相同結果。若還需要你口頭補充，就把那段補進文件。要把這種交付能力延伸到企業導入，可查看 前線部署工程師（FDE）養成實戰候補資訊；目前先登記候補，不承諾可立即購課。