去年夏天，當 iOS 27 開發者測試版發布時，我們 ViviDiary 團隊眼睜睜看著通知開啟率直線下降。僅僅一週內，與我們每日提醒的互動率就下降了 42%。
我們並沒有遇到程式錯誤。我們的伺服器運作正常。我們面臨的是 Apple 處理用戶注意力方式的根本性轉變。
Apple Intelligence 的演進從根本上改變了推播通知的開發者 UX。Apple 的作業系統現在扮演著嚴格的編輯守門人角色，利用其大型語言模型 (LLM) 根據推斷的重要性來分類、摘要並經常隱藏警示。諸如全新的「通知摘要」和激進的「減少干擾」專注模式等功能，會主動降低一般性、重複性推播的優先級。
對於許多習慣追蹤器和健康應用程式來說，這是一場危機。但對我們而言，這是對我們產品哲學的終極驗證。
以下是我們如何調整雲端儲存的推播架構以在 AI 過濾機制下生存、我們斷然拒絕開發的功能，以及「為 Apple Intelligence 設計貼心通知」如何迫使我們打造出更好、更安靜的產品的坦誠分享。
Apple Intelligence 摘要問題
ViviDiary 的設計初衷是輕量化。我們的核心互動是 3 秒的簽到：選擇 5 個等級的心情（極佳、良好、尚可、低落、糟糕）、加上一些表情符號，就完成了。其他所有功能——備忘錄、語音筆記、照片以及我們的「專注」模組（日常習慣 + 待辦事項）——皆嚴格採取選擇性加入 (opt-in) 模式。新用戶開始時，除了心情記錄外，所有功能皆為關閉狀態。
因為我們優先考慮減輕受困擾用戶的認知負荷，所以我們的通知策略一直都很溫和。我們使用單一的「溫暖」語氣。我們不做壓力式的連續打卡、恐慌性通知，也不會發送「你今天錯過了」這種帶有罪惡感的提醒。
但 Apple Intelligence 本身並不了解你們應用程式的哲學。它只是讀取文字。
當 iOS 27 引入「通知摘要」時，它開始聚合我們溫和的提醒。如果用戶同時有每日習慣提醒和每週「鏡像」（模式發現）洞察，Apple 的 AI 會剝離我們精心設計的溫暖語氣，並將其簡化為機器人式的摘要：「關於記錄心情和每週模式的 2 則提醒。」
更糟的是，如果用戶啟用了 iOS 27 減少干擾專注模式，我們的通知經常被視為「非必要」而被埋在通知中心，完全繞過了鎖定畫面。
我們面臨一個選擇：想辦法鑽系統漏洞，或是想辦法與 AI 合作以提供真正的價值。
我們拒絕的做法：濫用「時效性」API
當面對參與度指標暴跌時，我們成長團隊的第一反應是可以預見的：「只要把通知標記為『時效性』就好了。」
Apple 在 APNs (Apple 推播通知服務) 負載中提供了一個 `Time Sensitive` 中斷等級。它專為共乘抵達、日曆活動或安全警示等事項設計。由於這些通知可以繞過「減少干擾」專注模式並浮現在摘要的最上方，許多應用程式立即開始濫用此標記來發送每日互動提醒。
我們在 TestFlight 版本中進行了內部測試。它確實有效——我們的通知突破了 AI 過濾器。但我們討厭這樣做。
以下是我們在產品上線前就否決該想法的原因：
- 這是敵對的 UX： 提醒記錄晚間心情對自我覺察很重要，但這並非緊急事件。當用戶明確要求 iOS 減少干擾時，劫持他們的注意力違反了我們核心的反注意力設計哲學。
- Apple 會懲罰這種行為： Apple 的文件明確指出，如果用戶頻繁關閉某個應用程式的「時效性」通知，作業系統將提示用戶完全關閉該應用程式的「時效性」權限。這是一種導致長期被靜音的短期甜頭。
- 這破壞了信任： 我們不使用紅綠燈進度 UI 或中斷連續打卡的罪惡感行銷。強行出現在鎖定畫面上，感覺就像我們極力避免的那種說教式、教練般的行為。
我們決定，如果我們想在 iOS 27 鎖定畫面上佔有一席之地，我們不能作弊。我們必須讓我們的 心情追蹤推播通知 變得無可爭議地相關。
重新設計我們的雲端儲存推播架構
為了讓我們的通知更聰明，我們必須重新思考觸發它們的方式。
在深入探討之前，先說明一下我們的架構：ViviDiary 使用 Supabase 和 Firebase Auth 進行雲端儲存。當我們談論處理數據以尋找最佳通知時間時，這是在我們的後端進行的。日記文字在任何外部或 AI 處理發生前都會經過嚴格的去識別化。我們的隱私來自於數據最小化和去識別化。我們對雲端堆疊完全透明，並且我們相信透明度是信任的基礎。
過去，如果用戶選擇加入我們的「專注」模組並設定「每日習慣」，我們允許他們選擇一個固定的推播通知時間（例如 8:00 PM）。
但固定的時間很笨。如果你通常在 8:00 PM 記錄心情，但週四你有晚課，直到 10:00 PM 才打開應用程式，那麼 8:00 PM 的通知就只是噪音。在 iOS 27 下，這些噪音會讓你被過濾掉。
我們更新了 Supabase 後端，以分析用戶「實際」完成習慣的時間戳記（去識別化後）。（請記住，ViviDiary 會自動計算匹配的表情符號簽到並將其連結到心情模式；沒有手動習慣記錄）。
我們建立了一個輕量級的 cron 作業，計算用戶簽到時間的滾動 7 天平均值，並按星期幾進行細分。我們的伺服器現在不再發送靜態的 8:00 PM 廣播，而是為用戶在該特定日期歷史上最容易接受的精確 15 分鐘窗口安排推播。
我們也將此與我們的 iOS 27 Apple 健康整合 連結起來。如果我們的後端偵測到用戶已經同步了符合其日常習慣的自動類別（如睡眠或步數），我們會完全「取消」該通知。為什麼要提醒他們記錄我們已經知道他們做過的事情呢？
無論用戶是使用我們的免費版（包含無限心情和表情符號記錄、3 個月的日曆存檔以及最多 3 個日常習慣）還是每月 2.99 美元的 Premium 方案，這種動態架構都以同樣的尊重對待他們的注意力。
製作 AI 彈性通知內容
搞定時間只是成功了一半。我們仍然必須處理 通知摘要開發者 UX。
Apple Intelligence 使用 AI 模型來讀取通知內容並產生摘要。我們透過廣泛的 A/B 測試發現，我們發送的文字「結構」直接影響了 AI 重寫它的方式。
這是我們在 iOS 27 之前的初始負載：
> 標題： 晚間簽到
> 內文： Clayee 在這裡！花 30 秒記錄你的心情，看看你今天過得如何。沒有壓力，隨時準備好都可以。
當 Apple Intelligence 將此與其他應用程式一起摘要時，它會輸出：
> 「ViviDiary 提醒你記錄心情。」
這太冷漠了。它剝奪了我們吉祥物 Clayee 的溫暖感。聽起來像是一項苦差事。
我們花了三週時間測試不同的語義結構，類似於我們在適應 Apple Intelligence 寫作工具時所做的工作。我們了解到 Apple 的摘要模型非常看重內文的前幾個字，並尋找關於「實用性」與「行銷」的上下文線索。
我們發現，提供高度具體、以用戶為中心的上下文可以防止 AI 扁平化語氣。我們從通用的提示轉向了基於觀察的動態內容。
這是我們今天使用的獲勝內容結構：
> 標題： 隨時為你準備
> 內文： 你通常在這個時間結束你的「閱讀」習慣。如果你想輸入晚間表情符號，Clayee 正在為你保留位置。
由於此內容包含特定變數（用戶實際的習慣名稱、上下文時間意識和低壓力的語言），Apple Intelligence 傾向於不加修改地通過它，或者更溫和地總結它：
> 「ViviDiary 註記這是你通常閱讀和記錄表情符號的時間。」
這種方法與我們在防止 AI 垃圾內容上的立場完全一致。我們不使用 AI 來產生虛假的同理心；我們使用精確、由人類編寫的模板，並填入準確的數據，確保當 Apple 的 AI 讀取它時，它能識別該內容為高訊號、低噪音的警示。
結果：更高的參與度，更少的噪音
當我們向 iOS 用戶群推出新的推播架構和 AI 彈性內容時，指標說明了一切。
我們的推播通知總發送量下降了 38%。我們發送的通知變少了，因為我們的伺服器取消了冗餘的提醒並等待最佳窗口。
然而，我們的互動率（用戶點擊通知或在發送後 10 分鐘內記錄心情）與 iOS 27 之前的基準相比增加了 28%。
更重要的是，我們的通知退出率——即追蹤用戶因感到厭煩而完全關閉警示的指標——降至每週 0.4% 的歷史最低點。
透過拒絕使用「時效性」漏洞，轉而進行分析去識別化數據以找到正確時機的艱苦工作，我們與 Apple Intelligence 試圖實現的目標完美契合：保護用戶的專注力。
下一步
我們目前正在研究如何為我們的每週「鏡像」功能優化通知。目前，「鏡像」會在每週日早上提供模式洞察。這是一個很好的反思時間，但我們正在探索我們的雲端後端是否能為這些洞察識別出更好的個人化窗口——也許等到我們偵測到「極佳」或「良好」的心情記錄後再發送每週摘要，確保用戶有足夠的情緒頻寬來回顧他們的模式。
Apple Intelligence 不是開發者的敵人。它是懶惰開發的敵人。透過迫使我們為每一個像素和提醒辯護，iOS 27 讓 ViviDiary 成為了一個更好、更安靜且更尊重的伴侶。
下次見，
Ethan
