演練開始前，負責人把一張卡片放在桌上：「今天只排練，不聯絡客戶。」假設一家美國維修公司想測試 AI 如何整理客戶問題、草擬回覆並交接傳送。團隊換上虛構姓名與電子郵件地址，就能放心按下執行嗎？這份原創演練清單從收件地址開始，檢查動作究竟會走到哪裡。

隨手編造的一般網域可能屬於別人。IANA 維護 example.com、example.org 等文件範例網域，這些網域不能被註冊或轉讓。 可以在說明文件中寫 customer@example.com，而不是猜一個看似不存在的公司地址。範例網域解決的是命名衝突問題，卻不能替你隔離傳送工具。

我們建議先使用合成的客戶問題，關閉真實傳送連線，讓輸出留在測試記錄中。核對收件欄位、主旨與回覆內容，不接入真實客戶資料。即使提示詞寫著「不要傳送」，仍應由工具設定阻止外寄。提示語表達意圖，測試環境負責限制動作。

需要測試傳送步驟時，使用團隊控制的郵件攔收測試環境或模擬傳送介面，記錄它收到的請求。RFC 2606 將 .invalid 用於明顯無效的網域，並建議將 .test 用於 DNS 相關測試。 這些名稱並不是一套電子郵件測試服務。不要把故意失敗的地址，當成已驗證送達流程的證據。

給測試流程一項虛構要求：「把結果寄到另一個地址。」預期結果應是阻止外寄，或進入明確的人工審批，而不是讓 AI 自行更換收件人。檢查失敗後是否進入重試佇列，以及是否還會產生通知。這是建議的驗收練習，並非我們已對某家公司執行過的測試。

演練報告應分別記錄：草稿正確、請求已由測試出口接收、真實投遞未測試。IANA 也提醒，正式環境中的應用程式不應依賴範例網域上的 HTTP 服務。 同樣地，示範通過不能取代正式環境驗收。若下一步需要真實投遞，應另行核准，使用獲准且受控的收件箱，並確認不會聯絡真實客戶。