Google的AI Studio電子郵件建構模式：若不將其視為魔法，則非常有用
更新於 2025年10月24日
14 分鐘
關於「AI生成的電子郵件」這件事
關於AI生成的電子郵件，每個人都假裝他們想要原創性——直到他們看到開啟率。然後他們想要可預測性。這就是為什麼Google的AI Studio Build Mode很有趣：它不承諾天才；它承諾可重複的支架。這不是貶低。在電子郵件行銷活動中，支架——主旨行、預覽文字、內文、行動呼籲、變化和A/B測試紀律的節奏——十次有九次勝過一次性的「靈感」。
所以：如何使用Google AI Studio Build Mode來生成不像翻譯了兩次的冰箱手冊那樣的電子郵件行銷活動？訣竅是策略勝於神秘。你是總編輯；該模型是你的實習生，有無數的草稿。像那樣對待它，你就會沒事。把它當作交鑰匙的大腦，你就會發送一堆糊狀物。
「Build Mode」實際上做對了什麼
Google AI Studio是Google用於提示、測試和匯出模型驅動的片段（文字、工具、工作流程）的遊樂場。Build Mode是讓你停止隨意嘗試並開始製作可重複模式的部分：提示範本、參數控制、系統指令、輸入變數和評估。這是「寫一封電子郵件給我」和「運行我的電子郵件工廠」之間的區別。
在最好的情況下，Build Mode可以幫助你：
- 為行銷活動組件（主旨行、預覽文字、內文、行動呼籲、附筆）定義可重複使用的提示
- 控制語氣、長度和品牌約束（沒有表情符號、AP風格、美式英語）
- 乾淨地輸入產品、優惠和受眾變數
- 生成用於A/B測試的變體，而無需玩提示瘋狂填字遊戲
- 匯出到程式碼（Node、Python）或無程式碼/低程式碼工作流程，使其不會被困在瀏覽器標籤中
這不是魔法。這是水管工程。但良好的水管工程可以防止房子聞起來像昨晚的「創意腦力激盪」。
在接觸提示之前：決定電子郵件的用途
顯而易見，但不知何故總是跳過。每個可靠的電子郵件行銷活動都回答三個枯燥的問題：
- 你要寫給誰——以及他們已經知道什麼？回頭客需要輕推；潛在客戶需要關心的理由。
- 你想要的一個動作是什麼——以及是什麼讓它低摩擦？「立即購買」不同於「預約演示」不同於「下載指南」。
- 是什麼讓今天的這封電子郵件成為必要？「因為我們想發送一封」不是一個策略。將其與時間、庫存、功能發布或價格聯繫起來。
用簡單的英語寫下這三個答案。這些成為你的輸入變數。該模型無法構建你尚未決定的策略。
Build Mode設定：一個不會崩潰的範本
這裡有一個可行的結構，用於「如何使用Google AI Studio Build Mode來生成電子郵件行銷活動」，而沒有虛構的流行語。
- 系統指令：你是一位電子郵件文案撰稿人，為[Brand]撰寫簡潔、具體的行銷電子郵件。你遵循品牌風格。你優先考慮清晰度而不是炒作。你的寫作方式像人類，而不是機器人。
- 護欄：沒有表情符號。主旨行中沒有驚嘆號。主旨行≤45個字元。預覽文字≤70個字元。內文≤140個字。包括一個行動呼籲。適當時包括一個簡短的P.S.。美式英語。標題中採用AP大寫規則。
- 輸入（變數）：
- brand_name
- audience_segment (例如，試用使用者、流失的客戶)
- offer (例如，年度計畫20%的折扣，新功能)
- value_prop (具體的好處)
- constraint (截止日期、庫存、合規性聲明)
- tone (自信、友好、直接)
- proof (統計資料、推薦片段、社會認同)
- CTA_label (例如，開始免費試用)
- landing_url
- 輸出架構：具有鍵的JSON：subject, preheader, headline, body, cta_label, cta_url, ps, alt_subjects (5的陣列), alt_ctas (3的陣列)。
為什麼是JSON？因為你想直接將其傳送到你的ESP或腳本，而不是像中世紀的抄寫員那樣手動複製它。
用於行銷活動生成的基準提示
使用Build Mode的範本功能將其鎖定。類似於：
「為{{brand_name}}撰寫一封簡潔的行銷電子郵件，目標對象為{{audience_segment}}。優惠是{{offer}}。強調{{value_prop}}。如果相關，請提及{{proof}}。包括任何約束：{{constraint}}。語氣是{{tone}}。尊重所有護欄。以指定的架構輸出為JSON。」
然後將護欄和架構貼在它下面。保持它的枯燥和明確。模型喜歡清晰度；他們討厭氛圍。
主旨行：模型最好的派對技巧（用繩子拴住它）
主旨行是Google AI Studio Build Mode發揮作用的地方。你可以在一分鐘內產生50個足夠好的變體。但不要讓模型追逐點擊誘餌。兩個簡單的約束：
- 使主旨行字面化，而不是含糊其辭。「財務團隊的新帳單匯出」勝過「你的數字變得更容易了」。
- 上限為40-45個字元。行動裝置是存在的。
使用alt_subjects陣列進行測試。在Build Mode中，新增一個指令：「生成五個主旨行，這些主旨行在角度上有所不同：以利益為先、以時間敏感為先、以功能為先、以社會認同為先、以問題為先。」這給你帶來了多樣性，而沒有小丑。
預覽文字：每個人都忽略的第二行（直到他們不忽略）
預覽文字是模型漂移到絨毛的地方。使用結構修復它：「繼續主旨行；添加遺漏的細節。」示例：主旨：「將發票匯出到CSV。」預覽文字：「與QuickBooks的新集成；設定需要2分鐘。」沒有「解鎖」，沒有「旅程」，沒有「無縫」。如果你不會對同事說，就不要列印它。
不漫無邊際的內文
請記住，電子郵件是門鈴，而不是晚宴。內文應：
- 在第一句話中說明變更（有什麼新內容/有什麼在售/有什麼即將結束）
- 在第二句話中將變更與價值聯繫起來（具體的，而不是氛圍）
- 提供一個動作，一次
- 用10個字處理明顯的反對意見（價格、時間、風險）
告訴模型將段落保持在三行以下，並使用主動動詞。如果它開始說「賦能」，你就迷失了方向。
A/B變體：沿軸生成，而不是隨機生成
Build Mode可以整天生成變體，但重點是每次測試沿單個軸變化。建立一個名為test_axis的變數，其中包含枚舉：{benefit_vs_feature, long_vs_short, social_proof_vs_no_proof, urgency_vs_no_urgency, casual_vs_formal}。在你的範本中，添加：「創建兩個僅沿{{test_axis}}不同的變體。保持其他一切不變。」
你現在得到可測試的差異，而不是混亂的湯。
保護你免受傷害的護欄
- 禁止描述感覺而不是事實的形容詞：無縫、創新、革命性、令人愉快。替換為實際的東西：速度提高20%，無需信用卡，今天發貨。
- 禁止在主旨行中使用「發現」一詞。你不是印第安納·瓊斯。
- 要求每個承諾都有一個具體的名詞。「更快的入門」->「設定從30分鐘變為5分鐘」。
- 設定一個樣式規則：如果存在數字，請寫下數字。「百分之二十」看起來像法律術語。
將這些規則放在你的系統指令中，而不是你的希望和祈禱中。
如何逐步使用Google AI Studio Build Mode
這是大多數「操作方法」文章都會用螢幕截圖和氛圍跳過的部分。這是有效的順序。
- 在Google AI Studio中創建一個新的Build；選擇一個有能力的文字模型。如果你想要一致的主旨行，請勿以1.0的創造力溫度使模型過熱。從0.3-0.5開始。
- 將你的系統指令和護欄貼在「行為」或等效的指令部分下。這是你的房屋風格。
- 為brand_name, audience_segment, offer, value_prop, constraint, tone, proof, CTA_label, landing_url, test_axis創建輸入變數。
- 添加輸出架構示例——一個最小的JSON存根——以便模型理解形狀。
- 提供一個已完成的示例（少量）。示例輸入，示例輸出。保持簡短和原始。
- 生成一次，審查，然後添加拒絕模式：「如果優惠為空，請說「未提供有效優惠」並停止。」從不良資料中拯救你。
- 使用「評估」功能跨各種輸入運行一小批（5-20）。你正在測試範本，而不是發布。
- 當輸出穩定且枯燥（一件好事）時，匯出Build：程式碼片段或API呼叫。將其連接到你的ESP或用於人工審查的臨時Google工作表。
- 添加一個薄薄的檢查層：長度驗證器、垃圾郵件單字linter、品牌術語監控列表。這是你在「FREE!!!」抓住你的交付能力之前抓住它的地方。
這就是Build Mode作為工廠：提示、變數、架構、評估、匯出。沒有神秘主義。
個人化：真實，不令人毛骨悚然
有「嗨，{FirstName}，」，然後是實際的個人化。使用模型可以處理的輸入：
- 區隔變數細節：「14天中的第10天試用使用者」與「所有試用」相比。
- 使用痕跡：「導入了2個專案，尚未設定集成。」
- 行業術語翻譯器：「對於會計師，將「工作區」翻譯為「客戶檔案」。」
在Build Mode中，添加一個規則：「僅使用輸入中提供的事實進行個人化；永遠不要推斷個人詳細資料。」然後將個人化限制為一個句子或一個子句。真正的個人化減少了摩擦；虛假的個人化會引發警報。
語氣撥盤：設定一次，謹慎測試
行銷人員喜歡擺弄語氣，好像它是秘方。它不是。對於大多數B2B，將語氣設定為「直接」，對於消費者，設定為「友好」。如果你必須測試語氣，請將其作為跨其他相同變體的test_axis進行測試。請記住：語氣轉變可能會更改列表區隔的垃圾郵件標記。不要每週二都重新告訴ISP你是誰。
合規性：不要將責任外包給模型
CAN-SPAM、《通用資料保護條例》，通常的字母湯。Build Mode可以插入頁腳，但它不能擁有合規性。你的範本應包括實際地址、取消訂閱連結和資料許可語言的佔位符。然後你的系統應在發送時強制執行這些佔位符。「模型忘記了」不會給你的合規團隊——或監管機構留下深刻印象。
一個實際的例子（因為說說而已很廉價）
輸入：
- brand_name: Acme Analytics
- audience_segment: 第10/14天的試用使用者，導入了1個資料來源
- offer: 如果你在星期五之前升級，第一年可享受20%的折扣
- value_prop: 自動化的每週執行摘要；沒有手動儀表板
- constraint: 48小時截止日期；價格將在下個月上漲
- tone: 直接
- proof: 已被3,200家公司使用；平均設定時間7分鐘
- CTA_label: 開始你的升級
- landing_url:
- test_axis: benefit_vs_feature
預期輸出（簡寫）：
{
"subject": "每週摘要。零儀表板。",
"preheader": "在星期五之前升級，第一年可享受20%的折扣。",
"headline": "你的星期五報告，沒有星期五",
"body": "你已連接你的第一個資料來源。現在是有用的部分：Acme透過電子郵件發送每週執行摘要——無需構建儀表板，無需照顧圖表。大多數團隊在7分鐘內完成設定。在接下來的48小時內升級，你的第一年可享受20%的折扣。價格將在下個月上漲。如果它在一周內不適合，只需單擊一下即可取消。",
"cta_label": "開始你的升級",
"cta_url": "",
"ps": "已被3,200家和你一樣不喜歡幻燈片的公司使用。",
"alt_subjects": ["你的報告，沒有報告","跳過儀表板。保持信號","本週升級。更少的圖表，更多的答案","20%折扣，48小時：透過電子郵件發送報告","開啟每週摘要（7分鐘設定）"],
"alt_ctas": ["立即升級","領取20%折扣","完成設定"]
}
重點不是這是出色的寫作。重點是它是一致的、清晰的且易於測試。如果你的產品沒有每週發送摘要，也很容易拒絕——這就是為什麼你將模型建立在真實輸入中的原因。
Build Mode中的評估：讓機器（輕微地）自我評分
你可以在生成後添加基於規則的檢查。讓模型輸出一個自我檢查物件，例如：
- 主旨和預覽文字的字元數
- 如果觸發，則為禁止單字列表
- CTA_label是否與允許的選項匹配
- 是否存在所需的免責聲明
不要讓模型批准自己；只是讓它告發違規行為。然後一個簡單的腳本控制發送。愚蠢、可靠、安全。
以正確的方式（和快速的方式）進行A/B測試
如果你正在使用Google AI Studio Build Mode來生成電子郵件行銷活動，你將需要速度而沒有迷信。
- 樣本量第一，自我第二。不要在200次開啟時就宣布獲勝者。設定你的最小值。
- 每次發送測試一個軸。「主旨中的緊急與非緊急」是有效的。「緊急+表情符號+不同的優惠」是塔羅牌。
- 將獲勝者凍結到範本中。如果一個模式獲勝兩次，它將成為新的預設值，直到有其他東西擊敗它。
該模型是選項的來源，而不是判斷者。你的列表和你的收入決定。
資料衛生：AI的不性感雙胞胎
世界上所有的提示技巧都無法挽救混亂的輸入。在Build Mode運行之前：
- 驗證URL（沒有404）。該模型會很樂意將你的拼寫錯誤貼到100,000封電子郵件中。
- 驗證日期和截止日期（時區感知）。「今晚結束」是跨區域的訴訟磁鐵。
- 驗證優惠是否存在於你的帳單系統中。在以全價開帳單的電子郵件中「20%的折扣」是你如何樹敵的。
在模型之外自動執行這些檢查。那是你的工作。
Sider.AI 的適用範圍（以及不適用的範圍）
Sider.AI 很高興地位於編輯和迭代的通道中。如果Build Mode是你的工廠，那麼Sider是敏銳的編輯，他會告訴你主旨行長了五個字元，並且預覽文字是多餘的。它擅長在上下文中起草和收緊文案——包括重寫模型輸出以匹配你的真實聲音——而不會將每次變更變成另一個提示科學實驗。使用Google的Build Mode大規模生成結構化的行銷活動片段；使用Sider來提升它們，與語氣保持一致，並修剪多餘的部分。這種勞動分工實際上是有效的。
常見的故障模式（以及可以採取的措施）
- 隱藏優惠的「聰明」主旨行。相反：要字面化；讓預覽文字添加細微差別。
- CTA沙拉。一封電子郵件，一個動作。如果你需要兩個，請發送兩封電子郵件。
- 個人化噱頭。在主旨行中使用名字是一種絕望的舉動。個人化屬於相關性，而不是舞台藝術。
- 沒有證據的主張。如果你聲稱速度更快，請顯示數字或閉嘴。
- Franken-email。不要將變體A的主旨貼在變體B的內文和變體C的語氣上。一致性是一種特性。
稍後可以節省數小時的工具說明
- 像任何其他程式碼一樣，將你的Build Mode範本保存在版本控制中。比較這些單字。單字是產品。
- 維護禁止單字JSON和首選短語JSON。將兩者都輸入到系統提示中。
- 將表現最佳的主旨行保存在一個帶有標籤（利益、功能、緊急、季節性）的庫中。從獲勝者那裡播下新的世代。
- 記錄每個世代的輸入和最終發布的變體。當有人問「為什麼上週四的收入下降」時，你需要收據。
何時完全跳過AI
你不需要模型用於：
- 法律或高風險電子郵件（安全事件、具有合約影響的價格變更）。自己寫；進行審查。慢慢地。
- 核心敘事行銷活動（新產品發布、定義使命的故事）。稍後使用AI進行變體，而不是用於初稿。
- 交易電子郵件（收據、密碼重置）。這些應該永遠是枯燥和正確的。
AI是一種電動工具。你不會用圓鋸來塗抹吐司。
毫不後悔地部署到生產環境
一旦你的Build開始運作：
- 用一個小型服務包裝它，該服務採用CSV/JSON輸入並傳回經過驗證的JSON輸出。
- 為任何新事物添加人為迴圈步驟：新優惠、新受眾、新語氣。橡皮圖章熟悉的東西；仔細檢查奇怪的東西。
- 將最終副本與元資料一起儲存在你的ESP中：test_axis、變體、種子提示版本。未來的你會很感激。
關於實際重要的指標的說明
如果你的目標是提高開啟率，恭喜你，你可以用好奇心誘餌來玩這個遊戲。如果你的目標是收入或啟用，請衡量到這一點。追蹤：
- 點擊開啟率 (CTOR)——如果它很低，你的內文/CTA沒有兌現主旨行的支票。
- 登陸頁面上的轉換——如果它很低，也許電子郵件承諾的世界與URL提供的世界不同。
- 取消訂閱和垃圾郵件投訴率——不斷上升的數字意味著語氣或頻率下降。
Google AI Studio Build Mode可以大規模生成電子郵件行銷活動。它們是否良好取決於你是否衡量任何真實的事物。
最後的想法：枯燥是一種策略
在電子郵件中使用 AI 的宣傳通常帶有魔力般的色彩。但現實是流程。Build Mode 幫助您建立一個簡單、嚴格、可重複的系統，可以按需產生不差也不好的電子郵件 —— 然後讓您穩步地改進它們。這就是工作。如果說有什麼訣竅的話，那就是選擇不說什麼。把煙火留給社交媒體。在收件匣裡，清晰度才是王道。
如果您真的必須寫「解鎖 (unlock)」，請幫幫大家，至少解鎖一個可以使用的優惠券代碼。
常見問題解答
Q1: 如何使用 Google AI Studio 的 Build Mode 生成電子郵件活動，而不會聽起來像機器人？
從嚴格的範本開始：語氣、字數限制和禁用詞的規範，然後輸入具體的內容（優惠、證明、限制）。讓 Build Mode 輸出結構化的 JSON，用於主旨、預覽文字、正文和 CTA，並通過人工編輯，確保清晰度勝過陳詞濫調。
Q2: 在 Google AI Studio 中創建主旨行變化的最佳方式是什麼？
要求提供五個不同角度的主旨行替代方案 —— 優先考慮利益、優先考慮功能、緊急性、社會證明、問題 —— 並將長度限制在約 45 個字元。保持它們的直白；讓預覽文字承載細微差別，而不是使用誘餌。
Q3: 應該如何對 AI 生成的電子郵件內容進行 A/B 測試？
一次更改一個軸，使用 test_axis 變數（例如，urgency_vs_no_urgency），並保持其他所有內容不變。設定最小樣本量，並將獲勝者凍結到範本中，這樣您才能學習，而不僅僅是在玩老虎機。
Q4: 如果我正在 Google AI Studio 中建立活動，Sider.AI 在哪裡發揮作用？
使用 Google AI Studio 的 Build Mode 大規模生成結構化的活動元件，然後使用 Sider.AI 來收緊語言、強化語氣並減少冗餘。它是 Build Mode 生產線的編輯手術刀。
Q5: 我應該包含哪些規範，以確保 AI 生成的電子郵件合規且可送達？
要求包含頁腳元素（地址、取消訂閱）、禁止在主旨中使用垃圾郵件字詞、驗證 URL 和日期，並為主旨和預覽文字設定嚴格的長度上限。在模型之外自動執行檢查；不要依賴模型來記住法律。
