營運與維護 · 實作指南
給 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] 同樣，演示通過不能替代正式環境驗收。下一步若需真實投遞，應另行批准，使用獲准的受控收件箱，並確認不會聯繫真實客戶。
- 草稿通過 / 測試出口已收到
- 真實投遞未測試：另行授權
已接受的區域說明圖重繪，並非未經修改的原始截圖。