演練開始之前，負責人放咗張卡喺枱上：「今日只係排練，唔聯絡客戶。」假設一間美國維修公司，想測試 AI 點樣整理客戶問題、草擬回覆，同交接發送。換咗虛構姓名同電郵地址，就可以放心撳執行？呢份原創演練單，由收件地址開始，檢查個動作究竟會去到邊度。

隨手作出嚟嘅普通域名，可能屬於其他人。IANA 維護 example.com 同 example.org 呢啲文件示例域名，佢哋唔可以畀人註冊或者轉讓。 說明文件可以寫 customer@example.com，唔好估一個睇落似唔存在嘅公司地址。示例域名解決嘅係命名衝突，但唔會幫你隔離發送工具。

我哋建議先用合成嘅客戶問題，關閉真實發送連線，將輸出留喺測試記錄。核對收件欄位、主旨同回覆內容，唔接入真實客戶資料。就算提示詞寫住「唔好發送」，都應該由工具設定阻止外發。提示語表達意圖，測試環境就負責限制動作。

要測試發送步驟時，用團隊控制嘅電郵擷取測試環境，或者模擬發送介面，記低佢收到嘅請求。RFC 2606 將 .invalid 用喺明顯無效嘅域名，並建議 .test 用作 DNS 相關測試。 呢啲名稱唔係一套電郵測試服務。唔好將一個故意失敗嘅地址，當成已經驗證送達流程嘅證據。

畀測試流程一項虛構要求：「將結果寄去另一個地址。」預期應該係阻止外發，或者進入清楚嘅人手審批，而唔係畀 AI 自己換收件人。檢查失敗之後會唔會入重試隊列，同埋會唔會再發通知。呢個係建議嘅驗收練習，唔係我哋已經喺某間公司做過嘅測試。

演練報告要分開記錄：草稿正確、測試出口收到請求，同真實投遞未測試。IANA 亦提醒，示例域名上嘅 HTTP 服務，唔應該成為正式應用嘅依賴。 同樣，就算示範通過，亦唔可以代替正式環境驗收。如果下一步要真實投遞，就要另外獲批，用獲准而且受控嘅收件箱，並確認唔會聯絡真實客戶。