統一通知維運 (Unified Notifications Ops)
當真正的問題不是缺少一個通知,而是通知系統本身四分五裂時,請使用此技巧。
目標是將分散的事件轉化為一個統一的維運操作介面,具備:
- 清晰的嚴重性分級
- 清晰的責任歸屬
- 清晰的路由規則
- 清晰的後續行動
使用時機
- 使用者希望在 GitHub、Linear、本地 Hook、桌面通知、聊天或電子郵件之間建立統一的通知通道
- CI 失敗、審查請求、問題更新與維運事件分散在不同的地方
- 目前的設定只是製造噪音,而非推動行動
- 使用者希望將重疊的通知分支或待辦事項提案整合為一個 ECC 原生通道
- 工作區已有 Hook、MCP 或已連接的工具,但缺乏統一的通知策略
偏好介面
從既有的內容開始:
- GitHub 議題、PR、審查、留言與 CI
- Linear 議題/專案狀態變更
- 本地 Hook 事件與工作階段生命週期訊號
- 桌面通知基本功能
- 已實際存在的連接式電子郵件/聊天介面
偏好使用 ECC 原生編排,而非建議使用者採用獨立的通知產品。
不可妥協的規則
- 絕不暴露 Token、金鑰、Webhook 密碼或內部識別碼
- 區分:
- 事件來源
- 嚴重性
- 路由通道
- 維運行動
- 當中斷成本不明確時,預設使用摘要優先策略
- 不要將每個事件都廣播到每個通道
- 如果真正的解決方案是更好的議題分類、Hook 策略或專案流程,請明確指出
事件管道
將通知通道視為:
- 捕捉 事件
- 分類 緊急程度與負責人
- 路由 到正確的通道
- 合併 重複項目與低訊號擾動
- 附加 下一步維運行動
目標是更少但更好的通知。
預設嚴重性模型
| 等級 | 範例 | 預設處理方式 |
|---|---|---|
| 關鍵 | 主要分支 CI 中斷、安全問題、版本封鎖、部署失敗 | 立即中斷 |
| 高 | 審查請求、失敗的 PR、阻擋負責人的交接 | 當日警示 |
| 中 | 議題狀態變更、重要留言、待辦事項變動 | 摘要或佇列 |
| 低 | 重複的成功事件、例行擾動、重複的生命週期標記 | 抑制或折疊 |
如果工作區沒有嚴重性模型,請在提出自動化之前先建立一個。
工作流程
1. 盤點現有介面
列出:
- 事件來源
- 目前通道
- 現有會發出警示的 Hook/腳本
- 同一事件的重複路徑
- 重要事項未被揭露的靜默失敗案例
標出 ECC 目前已擁有的部分。
2. 決定哪些需要中斷
針對每類事件,回答:
- 誰需要知道?
- 他們需要多快知道?
- 應該中斷、批次處理,還是只記錄?
使用這些預設規則:
- 針對版本、CI、安全與阻擋負責人的事件進行中斷
- 中訊號更新使用摘要
- 僅記錄遙測與低訊號生命週期標記
3. 在新增通道之前先合併重複
檢查:
- 同一個 PR 事件同時出現在 GitHub、Linear 與本地日誌中
- 同一失敗的重複 Hook 通知
- 應該總結而非直接轉發的留言或狀態擾動
- 沒有增加更好行動路徑的重複通道
偏好:
- 一個規範性摘要
- 一個負責人
- 一個主要通道
- 一個備援路徑
4. 設計 ECC 原生工作流程
針對每個真正的通知需求,定義:
- 來源
- 閘門
- 形態:即時警示、摘要、佇列或僅儀表板
- 通道
- 行動
如果 ECC 已有對應的基本功能,優先使用:
- 一個供維運分類用的 Skill
- 一個供自動觸發/強制執行用的 Hook
- 一個供委派分類用的代理 (Agent)
- 僅在真正缺少橋接時才使用 MCP/連接器
5. 回傳以行動為導向的設計
最後提供:
- 保留什麼
- 抑制什麼
- 合併什麼
- ECC 下一步應包裝什麼
輸出格式
目前介面
- 來源
- 通道
- 重複
- 缺口
事件模型
- 關鍵
- 高
- 中
- 低
路由計畫
- 來源 -> 通道
- 原因
- 維運負責人
合併
- 抑制
- 合併
- 規範性摘要
下一步 ECC 行動
- Skill / Hook / 代理 / MCP
- 下一步要建置的準確工作流程
建議規則
- 偏好一個強大的通道,勝過許多弱通道
- 中低訊號更新偏好使用摘要
- 當訊號應自動觸發時,偏好使用 Hook
- 當工作內容是分類、路由與以審查為主的決策時,偏好使用維運 Skill
- 當根本原因是待辦事項/PR 協調而非警示時,偏好使用
project-flow-ops - 當使用者首先需要來源盤點時,偏好使用
workspace-surface-audit - 如果桌面通知已足夠,不要發明不必要的對外橋接
良好的使用案例
- 「我們有 GitHub、Linear 與本地 Hook 警示,但缺少單一的維運流程」
- 「我們的 CI 失敗很吵,大家都忽略它們」
- 「我想要一個在 Claude、OpenCode 與 Codex 介面間統一的通知策略」
- 「弄清楚哪些應該中斷使用者,哪些應該放進摘要」
- 「將重疊的通知 PR 想法整合為一個規範性的 ECC 通道」
相關技能
workspace-surface-auditproject-flow-opsgithub-opsknowledge-opscustomer-billing-ops(當通知痛點是帳務/客戶維運而非工程問題時)