假設一家美國工作室用 AI 起草取件通知。審核畫面上的 HTML 版本寫“週五可取”，純文字版本卻保留舊稿的“週四可取”。這不是兩個客戶收到了兩封電子郵件，而是同一封電子郵件內有兩份內文。只審核漂亮的一面，可能漏掉另一份業務承諾。本文案例為假設，並非真實客戶事故。

MIME 的 multipart/alternative 用來提供同一資訊的不同表示，收件程式根據支援能力與偏好選擇版本。 Amazon SES 官方示例也展示了一封電子郵件同時包含純文字與 HTML。 因而驗收對象應是最終電子郵件中的每份內文，而不僅是編輯器裡的預覽。不要假設每位客戶都看到與你一樣的版本。

我們的建議是先固定取件日期、地址、訂單編號與下一步，再從同一份已確認內容產生兩種內文。AI 可以調整語氣，不能讓兩次獨立改寫各自決定日期。若 HTML 新增“請帶確認函”，純文字也要表達這項要求；字體和按鈕可以不同，客戶需要做的事不能不同。

把“查看取件說明”按鈕改成純文字時，除了保留名稱，還要保留可使用的網址。不要只刪掉 HTML 標籤，留下一個不能點選、也沒有地址的提示。檢查網址指向是否正確，但不要用真實客戶的私人存取連結作測試資料。這裡的重點是保留行動含義，不是追求逐字相同的排版。

本文用本機 Python 電子郵件解析器讀取合成電子郵件：先放入週四和週五兩個衝突版本，檢查可分別擷取並發現日期不同；再從相同事實產生兩個版本，核對日期和說明網址。這個實驗沒有寄出電子郵件，也不證明所有信箱都顯示正常。實際交付前仍應在獲准的測試信箱裡查看兩種格式與行動裝置上的顯示效果。

交給審核人的應有最終 HTML 預覽、純文字內文與關鍵事實核對結果。修改任何一版後，兩版一起重查。驗收可以很具體：“兩版均寫週五取件，地址一致，下一步與連結完整。”AI 幫你更快寫出電子郵件的價值，只有在不同閱讀方式下仍傳達同一個承諾時，才算真正交到客戶手裡。