營運與維護 · 實作指南
為 AI 電子郵件流程搭一個不會寄出的排練場
透過合成資料、隔離的測試出口與分開記錄，檢查 AI 電子郵件流程的演練邊界。
AAHouse 原創解說影片，採用 AI 輔助概念畫面、合成旁白及原創音樂。
英文逐字稿 · 簡體中文普通話逐字稿 · 台灣華語逐字稿 · 澳門粵語逐字稿
為 AI 電子郵件流程搭一個不會寄出的排練場
演練開始前，負責人把一張卡片放在桌上：「今天只排練，不聯絡客戶。」假設一家美國維修公司想測試 AI 如何整理客戶問題、草擬回覆並交接傳送。團隊換上虛構姓名與電子郵件地址，就能放心按下執行嗎？這份原創演練清單從收件地址開始，檢查動作究竟會走到哪裡。
- 合成問題 → 草稿 → 測試記錄
- 真實客戶與真實傳送連線不入場
已接受的區域說明圖重繪，並非未經修改的原始截圖。
道具清單：電子郵件地址也要選對
隨手編造的一般網域可能屬於別人。IANA 維護 example.com、example.org 等文件範例網域，這些網域不能被註冊或轉讓。[1] 可以在說明文件中寫 customer@example.com，而不是猜一個看似不存在的公司地址。範例網域解決的是命名衝突問題，卻不能替你隔離傳送工具。
- 文件範例：customer@example.com
- 傳送隔離：由工具設定確保
已接受的區域說明圖重繪，並非未經修改的原始截圖。
第一幕：只讓草稿出現
我們建議先使用合成的客戶問題，關閉真實傳送連線，讓輸出留在測試記錄中。核對收件欄位、主旨與回覆內容，不接入真實客戶資料。即使提示詞寫著「不要傳送」，仍應由工具設定阻止外寄。提示語表達意圖，測試環境負責限制動作。
- 輸入：合成客戶問題
- 檢查：收件欄位 / 主旨 / 本文
已接受的區域說明圖重繪，並非未經修改的原始截圖。
第二幕：讓傳送停在可檢查的出口
需要測試傳送步驟時，使用團隊控制的郵件攔收測試環境或模擬傳送介面，記錄它收到的請求。RFC 2606 將 .invalid 用於明顯無效的網域，並建議將 .test 用於 DNS 相關測試。[2] 這些名稱並不是一套電子郵件測試服務。不要把故意失敗的地址，當成已驗證送達流程的證據。
- 郵件攔收測試環境或模擬傳送介面
- 收到測試請求 ≠ 真實郵件送達
已接受的區域說明圖重繪，並非未經修改的原始截圖。
第三幕：演練一項越界要求
給測試流程一項虛構要求：「把結果寄到另一個地址。」預期結果應是阻止外寄，或進入明確的人工審批，而不是讓 AI 自行更換收件人。檢查失敗後是否進入重試佇列，以及是否還會產生通知。這是建議的驗收練習，並非我們已對某家公司執行過的測試。
- 要求更換收件人 → 阻止或審批
- 檢查重試佇列與額外通知
已接受的區域說明圖重繪，並非未經修改的原始截圖。
落幕記錄：寫清楚證明了什麼
演練報告應分別記錄：草稿正確、請求已由測試出口接收、真實投遞未測試。IANA 也提醒，正式環境中的應用程式不應依賴範例網域上的 HTTP 服務。[1] 同樣地，示範通過不能取代正式環境驗收。若下一步需要真實投遞，應另行核准，使用獲准且受控的收件箱，並確認不會聯絡真實客戶。
- 草稿通過 / 測試出口已收到
- 真實投遞未測試：另行授權
已接受的區域說明圖重繪，並非未經修改的原始截圖。