電子報範本的「響應式」，跟網頁的響應式設計是同一回事嗎？
概念相同（畫面依螢幕尺寸調整排版），但實作方式差異很大。網頁響應式設計可以放心使用 flexbox、grid 等現代 CSS 排版工具，因為瀏覽器的相容性已經相對一致；電子郵件的響應式設計必須用 table-based 排版打底,再用媒體查詢做手機版的樣式覆蓋，而且要清楚知道哪些郵件用戶端（尤其是 Outlook）根本不支援媒體查詢，會直接退回桌面版樣式。
換句話說，網頁響應式設計的目標是「在所有裝置上都完美」，電子郵件響應式設計的目標比較接近「在大多數裝置上完美，在少數頑固的用戶端上至少維持可讀」。
為什麼 Outlook 特別麻煩？其他郵件用戶端也會挑嗎？
Outlook 桌面版特別麻煩的根本原因，是它從 2007 年版本開始改用 Microsoft Word 的排版引擎渲染 HTML 郵件，而不是像其他郵件用戶端一樣用接近瀏覽器的引擎。Word 排版引擎原本是設計來排版文件的，不是設計來渲染網頁的，這導致許多現代 CSS 屬性（flexbox、部分 background 屬性、圓角 border-radius 等）在 Outlook 桌面版裡完全不生效或呈現異常。
其他郵件用戶端（例如 Gmail、Apple Mail）雖然也各自有一些渲染上的怪癖，但整體上比較接近標準瀏覽器行為，相容性問題的嚴重程度遠不如 Outlook 桌面版。這也是為什麼電子郵件設計圈子裡，Outlook 幾乎被當成一個獨立的相容性目標在對待。
深色模式的「自動反轉」問題，實際上會造成什麼具體的閱讀障礙？
最常見的情況是：設計師原本設定淺色背景（例如白色）搭配深色文字（例如黑色或深灰），這在淺色模式下閱讀完全沒問題。但如果郵件用戶端偵測到使用者開啟深色模式，自動把背景反轉成深色，卻沒有同步反轉文字顏色，結果就是深色背景配上原本的深色文字——兩者對比度趨近於零，文字幾乎完全隱形，讀者必須用手動選取文字的方式才能勉強看清楚內容。
這也是為什麼專業的電子郵件範本會額外撰寫深色模式專用的樣式區塊，明確告訴郵件用戶端「深色模式時文字要用這個顏色」，而不是把這個判斷交給用戶端的自動邏輯處理，因為不同用戶端的自動反轉邏輯並不一致，賭自動邏輯的結果很不可控。
我沒有前端背景，能用 AI 生成的電子報範本直接拿去用嗎？還是一定要工程師再檢查？
可以先用生成結果作為起點，但實際寄送前建議至少做兩件事：第一，用郵件測試工具（多數電子報平台都有內建的預覽功能，或用第三方的跨用戶端預覽服務）實際檢查在 Outlook、Gmail、Apple Mail 深色模式下的呈現，不要只用自己的信箱測試——你自己的信箱只能代表一種用戶端環境。第二，找一個非技術背景的同事幫忙讀一次完全沒有圖片載入的版本，確認文字內容本身是否還能讓人看懂重點。
生成結果已經處理了 table-based 排版、深色模式標記、圖片降級這些容易被忽略的技術細節，但「這份範本在真實用戶端裡看起來到底如何」，還是需要實際預覽驗證，不能只憑程式碼看起來合理就直接大量寄送。
電子報範本是設計輸出裡限制最多、也最容易讓人低估難度的一種類型。網頁設計可以放心用現代 CSS，但電子郵件用戶端的渲染引擎五花八門，其中最麻煩的是 Outlook 桌面版——它不是用瀏覽器引擎渲染 HTML，而是直接呼叫 Microsoft Word 的排版引擎，這代表很多在瀏覽器裡正常運作的 CSS（例如 flexbox、大部分的 padding 簡寫）在 Outlook 裡會直接失效或跑版。這次測試 Claude Design 生成一份電子報範本，重點是觀察它有沒有意識到這層限制，還是只是套用一般網頁的做法。
這次的輸入描述是產品週報電子報：頂部品牌 Logo、一段開場文字、三則新聞區塊（各自有標題、縮圖、摘要、閱讀更多連結）、底部包含取消訂閱連結的頁尾。特別要求的一點是「要能在深色模式下正常顯示」——這是這次輸出的重點測試項目。
拿到的輸出用的是傳統的 table-based 排版，而不是現代網頁常見的 div + flexbox。這個選擇乍看之下像是走回頭路，但其實是電子郵件模板設計裡的正確做法——因為 table 標籤是少數幾乎所有郵件用戶端（包含 Outlook）都能穩定渲染的排版方式，這是電子郵件設計裡一個反直覺但必要的限制。
深色模式在電子郵件裡的處理方式，跟網頁的 prefers-color-scheme 邏輯不完全相同。這次的輸出額外加入了針對深色模式的 meta 標籤與條件式樣式區塊，明確指定文字顏色在深色背景下要維持足夠對比度，而不是讓郵件用戶端自動反轉顏色——自動反轉是深色模式最常見的翻車原因之一，因為它可能把原本用心設計的淺色背景配深色文字的配色，反轉成深色背景配深色文字，導致內容完全看不清楚。這次輸出明確處理了這個問題，用固定的深色模式配色方案取代讓用戶端自動決定。
另一個容易被忽略但這次輸出有處理的細節，是圖片被封鎖時的降級呈現。很多郵件用戶端預設不自動載入圖片，這次輸出裡的每張縮圖都設定了 alt 文字，而且背景色不是純白（避免圖片未載入時出現一大片突兀的白色區塊），文字內容的順序也確保就算完全沒有圖片，讀者仍然能讀懂每則新聞在講什麼、該點哪裡繼續閱讀。
版面寬度設定在 600px，這是電子報設計裡公認的安全寬度——比這個寬，在部分郵件用戶端的預覽窗格裡會被截斷或出現水平捲軸。響應式的部分則是用媒體查詢讓三則新聞區塊在手機螢幕上從並排改為上下堆疊，但這個媒體查詢同時被註記為「Outlook 不支援，會退回桌面版排版」——這種誠實地標註已知限制，而不是假裝所有郵件用戶端都能完美適配，是這次輸出裡比較有價值的判斷。
如果你的電子報還在用網頁那一套設計邏輯硬套進電子郵件裡，這次輸出示範的判斷值得直接參考：用 table-based 排版取代 flexbox、明確設定深色模式配色而不是依賴自動反轉、確保圖片全部無法載入時內容依然可讀。電子郵件是少數幾個訂閱者主動選擇接收、通常在深色模式手機介面上閱讀的內容形式，一份在 Outlook 崩版或深色模式下看不清楚文字的電子報，等於直接讓相當比例的訂閱者看到一封故障的信。