十個案例把通知變成輸入：iOS 27 通知自動化，先重算的是注意力的帳

2026年10月5日，少數派作者谷雨G2rain發布長文，以十個實作案例講解iOS 27新增的「通知自動化」。這項功能讓任何能發送系統通知的App，都可以作為快捷指令的觸發器，不再限於日曆、提醒事項、郵件、訊息等系統內建項目。

文章點出這項功能的實際分量：通知自動化表面上只是多了一個觸發條件，實際上是多了一整層可以參與篩選與處理的輸入。通知本身攜帶標題、副標題、正文等自訂內容，可以依App傳來的不同內容執行不同操作。這與我們先前分析的iOS 27正式版上線後的換機與流量效應屬於同一波系統更新，只是這次動的是提醒機制本身。

結構拆解：三個篩選欄位，一套近似判斷

依該文說明，通知自動化的基本邏輯是收到指定App通知時執行快捷指令，可透過三個欄位篩選：通知標題、副標題、正文。多條件必須同時滿足才會觸發。使用上有兩個工程細節值得注意。

第一，欄位對應需要觀察通知最終顯示結構。以微信為例，聯絡人備註落在標題、訊息內容落在正文。而快捷指令「顯示通知」操作中的欄位，與通知自動化的欄位定義存在錯位，作者建議直接看通知排版再決定篩選條件。

第二，已讀判斷是近似的。快捷指令無法真正判斷使用者打開App後是否讀取了訊息，只能把「打開App」當作預設已知悉，據此清理時間記錄。作者明確承認這不是真正的已讀檢測，僅是日常可用的粗略提醒機制。

此外有硬性前提：App必須開啟系統通知，且在鎖屏或通知中心至少選擇一種顯示位置，單選橫幅無法運行自動化。

影響推演：誰受惠、誰承壓

受惠最直接的是高頻通知的重度使用者。案例之一的邏輯是：特定聯絡人連續來訊且間隔超過30分鐘未回，即更換醒目桌布加強提醒，打開App後還原並清理記錄。這本質上是把「漏接重要訊息」的風險成本，從事後補救移到事前分層。另一個案例處理自訂App圖標後角標失效的問題，用通知自動化補回未讀提醒，屬於對蘋果自家功能缺口的民間修補，與先前用快捷指令實現各App獨立音量控制的路數一致：平臺沒做的，生態先用腳本補。

承壓的一方則是蘋果的通知治理責任。當通知從被動顯示變成可程式化的輸入層，垃圾通知、行銷推播的潛在破壞力同步放大，任何App都能觸發使用者的桌布更換或二次提醒，濫用空間取決於使用者自己設下的篩選條件嚴謹度。這與聚焦搜尋重建索引把算力記在用戶設備上是同一種帳務安排：蘋果提供機制，運行成本與維護成本落在端側使用者身上。

從需求分層看，這類功能的自然客羣是願意花17分鐘讀教學、再花數小時調腳本的進階使用者。多數用戶的通知行為不會因此改變，這也是快捷指令生態一貫的滲透率結構。

收束判斷

十個案例的價值不在於任何單一腳本，而在於示範了通知作為結構化資料的用途上限：分級提醒、延遲二次提醒、角標補償。蘋果把觸發器開放給所有App，等於把提醒的定價權部分下放給使用者。至於這層輸入最終被多數人採用，還是停留在少數派自己的工具箱裡，要看後續有沒有更低門檻的預設方案。在此之前，它是一項需要自付組態時間的免費功能。