AI 程式開發工作流中的推播通知：可靠交付的工程實踐

Claude Code 處理一個複雜任務可能需要幾分鐘甚至幾個小時。如果沒有通知，你要麼盯著終端機看，要麼隔一會兒回來檢查一下，祈禱自己沒有錯過什麼重要的事情。這兩種方式都不尊重你的時間。

推播通知讓 Tactic Remote 成為了一個工作流工具，而不僅僅是遠端檢視器。本文介紹我們如何建構通知系統、與 Claude Code hook 的整合、交付可靠性工程，以及我們從真實開發者中觀察到的使用模式。

核心洞察

Tactic Remote 中推播通知的價值不在於「你的手機震動了」，而在於通知改變了你與 AI 程式開發代理互動的時間和方式。你不再需要同步地監控終端機，而是獲得了非同步的任務管理能力：

1. 從 Mac（或 iPhone 應用程式）啟動一個 Claude Code 任務。
2. 離開座位。去泡杯咖啡，參加會議，通勤回家。
3. 當任務完成、遇到錯誤或需要你審批時，手機會通知你。
4. 你在幾秒內完成審查和回應，然後繼續做之前的事情。

我們稱之為「看手機，不看桌面」的工作流。這與 CI/CD 通知的心智模型一致——你不會盯著建置流水線看，你等它告訴你結果。

Claude Code Hook 整合

通知系統由 Claude Code 的 hook 機制驅動。Hook 是使用者可設定的腳本，Claude Code 會在其生命週期的特定節點執行這些腳本。Tactic Remote 的 Mac 伴侶應用程式註冊了三種事件類型的 hook：

任務完成 — 當 Claude Code 完成請求處理時觸發。Hook 會擷取結束狀態、所做變更的摘要，以及終端機輸出的最後幾行。

需要審批 — 當 Claude Code 遇到需要人工確認的操作時觸發（專案目錄外的檔案寫入、Shell 命令、網路請求等）。Hook 會擷取待處理操作的描述和唯一的審批 ID。

錯誤 — 當 Claude Code 遇到致命錯誤、工具故障或 API 逾時時觸發。Hook 會擷取錯誤訊息和相關上下文。

每次 hook 呼叫都會向 Mac 伴侶伺服器發送結構化的 payload，由其決定通知路由、建構 APNs（Apple Push Notification service）payload 並透過我們的通知中繼服務分發。

通知類型的實際應用

每種通知類型都針對特定的互動模式設計：

任務完成通知 包含任務摘要和狀態指示器（成功或部分完成）。點擊通知會直接開啟 Tactic Remote 應用程式並跳轉到已完成工作階段的終端機檢視，方便你查看輸出。

審批通知 具有最高優先順序。它們包含操作描述（「Claude 想要在專案目錄中執行 rm -rf build/」）並直接在通知橫幅上呈現「批准/拒絕」操作。在 iPhone 上，你可以不開啟應用程式就回應審批——長按通知即可看到內嵌操作。我們的遙測資料顯示，62% 的審批是透過通知操作完成的，無需完全開啟應用程式。

錯誤通知 包含錯誤類別和截斷的訊息。它們是可操作的——點擊後會開啟工作階段檢視，你可以查看完整的錯誤上下文並決定是重新啟動還是修改任務。

交付可靠性

APNs 並不保證推播通知的送達。Apple 的文件指出通知是「盡力而為」的，可能因裝置電量管理、網路狀況或速率限制而被丟棄。對於一個開發者工具來說，錯過一則審批通知意味著任務停滯，「盡力而為」是不夠的。

我們在 APNs 之上疊加了多層可靠性機制：

伺服端狀態追蹤。 Mac 伴侶伺服器為每則通知維護一個交付台帳。每則通知都有唯一 ID、時間戳記和交付狀態（待發送、已發送、已確認、已過期）。

用戶端確認。 當 iPhone 應用程式接收並顯示通知後，會向 Mac 伴侶伺服器發送確認回執。如果 30 秒內未收到確認，伺服器會重新發送。

指數退避重傳。 未確認的通知會在 30 秒、60 秒和 120 秒間隔後重試。三次失敗後，通知被標記為可能無法送達，並在 Mac 伴侶的狀態介面中標註。

應用程式內同步。 當 iPhone 應用程式開啟（或從背景恢復）時，會向 Mac 伴侶查詢所有未確認的通知並在通知中心顯示。這可以捕獲 APNs 完全丟棄的任何通知。

去重。 重傳機制帶來了重複送達的風險。每則通知攜帶一個唯一 ID，iPhone 用戶端會進行追蹤。重複的通知會被靜默丟棄——你不會看到同一個審批請求兩次。

在實際使用中，我們的交付成功率（從通知發送到通知確認）在 beta 使用者群中 10 秒內達到 97.3%，60 秒內達到 99.6%。

通知去重細節

去重值得特別關注，因為它影響使用者信任。如果開發者看到同一個「批准檔案寫入」通知兩次，他們會質疑自己是否已經批准過了。如果他們看到一個自己已經批准的操作的審批通知，他們會質疑自己的批准是否已被接收。

我們的去重在兩個層面運作：

傳輸層。 每則通知有一個在重傳中保持不變的 UUID。iPhone 用戶端維護一個包含最近 500 個已見 UUID 的滾動視窗。任何攜帶已見 UUID 的通知在顯示前即被丟棄。

語意層。 特別針對審批通知，用戶端會檢查審批 ID 是否已經被處理。如果你透過第一次通知送達批准了操作，而後續重傳到達時，即使其傳輸 UUID 不同（這在伺服器為重試產生新推播 payload 時可能發生），重傳也會被抑制。

開發者實際使用模式

經過四個月的 beta 資料，清晰的模式已經浮現：

通知高峰時段 是使用者當地時間上午 9-11 點和下午 2-4 點——對應程式開發工作階段的開始和午餐後的高效時段。

審批通知的平均回應時間 為 12 秒。P95 為 47 秒。這意味著即使在尾部延遲下，人工審批也只為任務執行增加不到一分鐘——為安全保障付出的代價很小。

最常見的通知驅動工作流：啟動一個多步驟重構任務，離開座位去開會，在會議中透過通知操作批准 2-3 個檔案操作，回來後發現任務已完成。

通知量：活躍使用者每天收到的通知中位數為 8 則。重度使用者（P95）約 30 則。我們在調查中沒有觀察到通知疲勞——可能是因為每則通知都代表一個可操作的事件，而不是狀態更新。

靜音模式：15% 的使用者設定了「專注模式」規則，在特定時段批次處理非審批通知。審批通知始終會立即送達，不受專注模式影響，因為停滯的審批會阻塞整個任務。

下一步計畫

我們正在開發幾項通知改進：

• 帶程式碼預覽的豐富通知 — 審批通知直接在通知上顯示 diff 預覽，讓你無需開啟應用程式即可做出知情的批准/拒絕決定。
• 通知分組 — 將快速連續的任務完成通知（在多工作階段工作流中常見）批次合併為一則摘要通知。
• 自訂通知音效 — 為完成、審批和錯誤設定不同的聲音提示，讓你無需看手機就能透過聲音分流。

關於通知設定選項，請參閱通知設定指南。關於驅動此系統的 Claude Code hook 參考，請參閱 Hook 整合。