假設一間美國工作室用 AI 草擬取件通知。審核畫面嘅 HTML 版本寫「星期五可以取件」，純文字版本就留咗舊稿嘅「星期四可以取件」。唔係兩位客戶收到兩封電郵，而係同一封電郵入面有兩份內文。淨係審核靚嗰一面，可能會漏咗另一份業務承諾。本文例子係假設情境，唔係真實客戶事故。

MIME 嘅 multipart/alternative 用嚟提供同一項資訊嘅唔同表示方式，收件程式會按支援能力同偏好揀版本。 Amazon SES 官方例子亦展示，一封電郵可以同時包括純文字同 HTML。 所以驗收對象應該係最終電郵入面嘅每份內文，唔只係編輯器預覽。唔好假定每位客戶見到嘅版本，都同你一樣。

我哋建議先固定取件日期、地址、訂單編號同下一步，再用同一份已確認內容，產生兩種內文。AI 可以調整語氣，但唔可以由兩次獨立改寫，各自決定日期。如果 HTML 加咗「請帶確認函」，純文字都要講到呢項要求；字體同按鈕可以唔一樣，但客戶要做嘅事唔可以唔一樣。

將「查看取件說明」按鈕變成純文字嗰陣，除咗保留名稱，仲要保留用得嘅網址。唔好淨係刪走 HTML 標籤，留低一個撳唔到、又冇地址嘅提示。要檢查網址係咪指向正確位置，但唔好用真實客戶嘅私人存取連結做測試資料。重點係保留行動嘅意思，唔係追求逐字一樣嘅排版。

本文用本地 Python 電郵解析器讀取合成電郵：先放入星期四同星期五兩個有衝突嘅版本，檢查可唔可以分開擷取，並發現日期唔一樣；再由相同事實產生兩個版本，核對日期同說明網址。呢個實驗唔會寄出電郵，亦唔證明所有信箱都顯示正常。真正交付之前，仍然應該喺獲准嘅測試信箱，查看兩種格式同流動裝置上嘅顯示效果。

交畀審核人嘅，應該包括最終 HTML 預覽、純文字內文，同關鍵事實核對結果。改咗任何一版，兩版都要一齊重新檢查。驗收可以好具體：「兩版都寫星期五取件，地址一致，下一步同連結完整。」AI 幫你快啲寫好電郵嘅價值，要喺唔同閱讀方式之下，仍然傳達同一個承諾，先算真正交到客戶手上。