業務流程 · 實作指南
AI 電郵有兩份內文：唔好畀兩版作出唔同承諾
核對同一封電郵嘅 HTML 同純文字內文，確保日期、地址、下一步同連結傳達同一個承諾。
AAHouse 原創解說影片，採用 AI 輔助概念畫面、合成旁白及原創音樂。
英文逐字稿 · 簡體中文普通話逐字稿 · 台灣華語逐字稿 · 澳門粵語逐字稿
一封電郵，兩種講法
假設一間美國工作室用 AI 草擬取件通知。審核畫面嘅 HTML 版本寫「星期五可以取件」，純文字版本就留咗舊稿嘅「星期四可以取件」。唔係兩位客戶收到兩封電郵，而係同一封電郵入面有兩份內文。淨係審核靚嗰一面，可能會漏咗另一份業務承諾。本文例子係假設情境，唔係真實客戶事故。
- HTML：星期五可以取貨
- 純文字：星期四可以取貨
- 衝突嘅係承諾，唔只係樣式
說明圖重繪 · 合成資料，唔係實際業務結果
先將兩份內文放埋一齊
MIME 嘅 multipart/alternative 用嚟提供同一項資訊嘅唔同表示方式，收件程式會按支援能力同偏好揀版本。[1] Amazon SES 官方例子亦展示，一封電郵可以同時包括純文字同 HTML。[2] 所以驗收對象應該係最終電郵入面嘅每份內文，唔只係編輯器預覽。唔好假定每位客戶見到嘅版本，都同你一樣。
- 同一封電郵 → HTML 內文
- 同一封電郵 → 純文字內文
- 收件人未必見到審核人嗰個版本
說明圖重繪 · 合成資料，唔係實際業務結果
一次確認事實，再產生兩種排版
我哋建議先固定取件日期、地址、訂單編號同下一步，再用同一份已確認內容，產生兩種內文。AI 可以調整語氣，但唔可以由兩次獨立改寫，各自決定日期。如果 HTML 加咗「請帶確認函」，純文字都要講到呢項要求；字體同按鈕可以唔一樣，但客戶要做嘅事唔可以唔一樣。
- 先確認：日期 / 地址 / 訂單編號 / 下一步
- 再產生：HTML + 純文字
- 兩個版本都保留：請帶埋確認函
說明圖重繪 · 合成資料，唔係實際業務結果
按鈕冇咗之後，仲做唔做到下一步
將「查看取件說明」按鈕變成純文字嗰陣，除咗保留名稱，仲要保留用得嘅網址。唔好淨係刪走 HTML 標籤，留低一個撳唔到、又冇地址嘅提示。要檢查網址係咪指向正確位置，但唔好用真實客戶嘅私人存取連結做測試資料。重點係保留行動嘅意思，唔係追求逐字一樣嘅排版。
- HTML：查看取貨說明 → 目標網址
- 純文字：查看取貨說明 + 完整網址
- 唔好淨係保留按鈕上面啲字
說明圖重繪 · 合成資料，唔係實際業務結果
做一個刻意出錯嘅本地樣本
本文用本地 Python 電郵解析器讀取合成電郵：先放入星期四同星期五兩個有衝突嘅版本，檢查可唔可以分開擷取，並發現日期唔一樣；再由相同事實產生兩個版本，核對日期同說明網址。呢個實驗唔會寄出電郵，亦唔證明所有信箱都顯示正常。真正交付之前，仍然應該喺獲准嘅測試信箱，查看兩種格式同流動裝置上嘅顯示效果。
- 衝突例子：星期四 ≠ 星期五 → 偵測到
- 一致例子：日期相同 → 通過
- 一致例子：說明網址相同 → 通過
- 冇寄電郵，亦冇驗證實際電郵軟件點顯示
說明圖重繪 · 合成資料，唔係實際業務結果
交接嗰陣，唔好淨係交張截圖
交畀審核人嘅，應該包括最終 HTML 預覽、純文字內文，同關鍵事實核對結果。改咗任何一版，兩版都要一齊重新檢查。驗收可以好具體：「兩版都寫星期五取件，地址一致，下一步同連結完整。」AI 幫你快啲寫好電郵嘅價值，要喺唔同閱讀方式之下，仍然傳達同一個承諾，先算真正交到客戶手上。
- 最終 HTML 預覽
- 最終純文字內文
- 日期、地址、下一步同連結嘅核對結果
說明圖重繪 · 合成資料，唔係實際業務結果