通知過載：Linear、GitHub 與 Slack
Linear、GitHub 和 Slack 通知讓工程團隊不堪重負？深入解析架構崩潰的原因，以及 5 個真正值得保留的訊號。
By Chris Calo · 2026-03-13
問題不在於你收到太多通知。問題在於你收到的數量恰好正確 – 來自三個不同的工具，關於同一個事件，在同一個時間。
每個 webhook 都正確觸發了。每個整合都精準交付了它承諾的內容。GitHub 通知你關於 PR 的事。Linear 通知你該 PR 關閉的 issue。Slack 通知你，因為某個人在某個時候（大概是你自己，三個月前，帶著對「可見度」的錯誤樂觀），把一個機器人連到了專案頻道。三個工具，三個通知，一個事件，而且全都完美按照設計運作。工程設計無可挑剔。體驗卻悲慘無比。
你的 Linear、GitHub 和 Slack 通知之所以令人崩潰，不是因為什麼東西壞了。正是因為什麼都沒壞。每個工具都忠實地執行著自己的通知契約，完全不知道其他工具的存在。沒有共用的事件匯流排（event bus）。沒有去重複化層（deduplication layer）。在整個技術堆疊的任何地方，都不存在「這個人已經知道這件事了」的概念。你承受的不是設定錯誤的痛苦。你承受的是把六個工具接入同一個工作流程，然後讓每個工具獨立地對著虛空大喊的邏輯終點。
"通知系統並沒有失敗。它成功過頭了，以至於把你給埋了。" – Chris Calo
這就是進步。
單一合併的解剖 – 重複通知的驗屍報告
讓我帶你走過一個事件 – 單一 PR 合併 – 並追蹤在通知層發生了什麼。不是因為這很不尋常，而是因為它平凡得令人沮喪。
一位隊友在 GitHub 上合併了一個 PR。以下是連鎖反應：
- GitHub 觸發 webhook 到你的通知收件匣。你對這個 PR 寫過 review，所以你是訂閱者。這是第一個通知。
- Linear 的 GitHub 整合偵測到連結的 issue，並自動將其狀態從「進行中」轉為「完成」。Linear 為所有關注該 issue 的人產生通知 – 其中包括你，因為你們在同一個團隊。這是第二個通知。
- Slack 機器人（就是你在那次盲目樂觀中連接的那個）在 #frontend 發布了合併摘要。如果有人用表情符號或留言回應那則訊息，Slack 就會產生討論串通知。這是第三個，甚至可能是第四個通知。
- CI 在合併的 commit 上執行。GitHub 又觸發了一個 webhook。如果 CI 通過了，你大概不在乎，但你還是會收到通知，因為 GitHub 的訂閱模式是二元的 – 你要嘛關注，要嘛不關注。這是第五個通知。
五個通知。一個事件。而且你就在討論這次合併的通話中，所以在任何通知到達之前你就已經知道了。
把這乘上一個六人團隊的每一個 PR、每一個 issue 轉換和每一次 CI 執行，在你甚至還沒算上真正的新訊號之前，你看到的是每人每天 30 到 40 個重複事件。通知系統並沒有失敗。它成功過頭了，以至於把你給埋了。
為什麼靜音只是對大出血的敷衍修補
標準建議是積極靜音。關閉 GitHub 電子郵件通知。將 Slack 設定為僅在直接提及時通知。取消關注 Linear 中除了指派給你的以外的所有 issue。這在通知界就相當於為了治療手腕骨折而把手錶摘下來 – 技術上你減少了手腕相關的複雜度，但你也失去了看時間的能力。
我試過靜音方案（當然試了 – 我們都試過，這是每個人最先嘗試的，緊接著是每個人第二個嘗試的，也就是一條不知為何讓情況變得更糟的 Zapier 串聯）。我搞得很激進：完全關閉 GitHub 電子郵件，靜音除了團隊工作頻道以外的所有 Slack 頻道，取消關注 Linear 中除了自己 issue 以外的一切。大約三天的天堂。
然後我錯過了兩個阻礙性的 PR 審查，因為討論發生在我靜音的頻道裡。需要我審查的工程師最後私訊了我 – 這只不過是多了幾個步驟的通知，再附帶一份「嘿，你有看到我的訊息嗎？」的消極攻擊能量。一週後，一個設計決策出現在 Figma 留言討論串中，完全改變了我正在建到一半的元件，而我直到 PR 被拒絕才知道。真有趣。
靜音的根本問題在於，它將靜態規則應用於動態情境。你上週二的通知設定不知道今天早上出現的緊急 bug。而你越積極地靜音，你認知上的盲區就越大 – 隊友們會用「只是確認你有看到...」的私訊來填補這些盲區。如果你有在記分的話，這意味著積極靜音並沒有減少你的通知。它只是把通知從機器人（不會評判你的）轉移到了人類（絕對會的）身上。
真正值得打斷你的 5 個訊號
在記錄了幾週的通知後（記在純文字檔裡，因為我就是那種你預料會寫一篇通知架構文章的人），一個模式浮現了。在大約每天 200 個 ping 中，真正需要在一個小時內採取行動的，落入五個類別：
- 有人被你阻礙了。 你負責的程式碼的 PR 審查請求、只有你能回答的問題、等待你意見的決策。這是唯一一個延遲會產生複合成本的類別 – 你每晚一小時不回應，就是別人無法工作的一小時。
- 你部署的東西壞了。 你分支上的 CI 失敗、合併後的錯誤激增、還原（revert）請求。「你的程式碼著火了」類別。
- 做出了影響你當前工作的決策。 設計變更、API 契約更新、產品端的優先級變動。這些很少見但錯過的代價很高（參見：上面我被拒絕的 PR）。
- 截止日期變了。 Sprint 範圍改變、demo 提前、相依性延遲。改變日曆的事件。
- 有人需要幫助，而你是對的人。 不是每一個 @channel。不是每一個 @here。而是你的專業知識真正相關的特定情況 – 即使如此，也只有在沒有其他人能回答時才算。
其他一切 – 狀態轉換、自動化機器人訊息、「聽起來不錯」的表情符號回應、你未關注分支的 CI 通過 – 都是最終可能有用的資訊，但不需要打斷你正在寫的函式。通知工業複合體已經說服我們這些全都值得同等的急迫性。但它們不配。
在每天 200 個通知中，大約只有 5 個類別真正值得打斷你正在做的事。其餘都是最終可能有用的資訊 – 但工具把一切視為同等緊急，這意味著沒有什麼是真正緊急的。
給被架構背叛者的分類框架
這是一個你今天就可以開始使用的框架 – 不需要工具，只需要紀律和大約 20 分鐘的設定。它無法解決架構問題（除了去重複化層之外，沒什麼能做到），但能在你評估長期方案時止血。
每天兩次掃描： 與其持續檢查通知，不如把它們分批成兩次掃描 – 一次上午中旬，一次下午中旬。每次掃描時，瀏覽你的 GitHub 通知、Linear 收件匣和 Slack 未讀，並將每個通知分入三個桶之一：
| 桶 | 規則 | 行動 | |--------|------|--------| | 立即行動 | 有人被阻礙、有東西壞了，或決策需要你 | 立刻處理 | | 批次處理 | 重要但不具時間敏感性 | 加入「稍後回應」清單，當天結束時處理 | | 封存 | 機器人喋喋不休、狀態更新、已解決的討論串、重複項目 | 標記為已讀，繼續過你的日子 |
在 Slack 中設定頻道層級的預設值： 對每個頻道做判斷：這是「立即行動」頻道（你團隊的工作頻道、事件頻道），還是「批次處理」頻道（一般公告、跨團隊更新）？靜音批次處理頻道，只在掃描時查看。是的，這技術上就是靜音，也就是我剛花了兩段嘲笑的做法 – 差別在於你仍然按排程查看它們，而不是假裝它們不存在。
使用 GitHub 的通知過濾器： 將 github.com/notifications?query=reason:review-requested 加入書籤 – 該 URL 僅顯示明確指派給你的 PR 審查，完全切斷了訂閱/CI 的噪音。對於電子郵件，GitHub 包含一個 reason header（review_requested、mention、subscribed、ci_activity），你可以據此過濾：自動封存「subscribed」和「ci_activity」，你不會遺失任何你真正需要的東西。GitHub 將這個有用的 metadata 埋在 email header 中而不是在通知 UI 公開，這告訴你他們在這些系統的消費端投入了多少心思。
這種方法無法捕捉具備情境的訊號（還記得那個摧毀我 PR 的 Figma 留言嗎？每天兩次掃描也抓不住它）。但它能減少 60% 到 70% 的噪音，足以在你判斷問題是否值得一個真正解方的同時，停止強迫性的 alt-tab 切換。
去重複化層真正需要做什麼
這就是架構上變得有趣的地方 – 也是我不再把這當作通知設定問題，而是開始當作分類問題來思考的地方。
天真的做法是關鍵字比對和 @提及偵測。如果出現你的名字，就呈現它。如果是指派給你的審查請求，就呈現它。這能捕捉明顯的情況，但完全錯過了具備情境的 – 像是一個沒人 @ 你的討論串中的設計決策，因為他們不知道你正在建的元件會受到影響。（那件事會困擾我好一陣子。）
你真正需要的是一個關聯圖譜：哪些任務是你的、哪些 PR 與哪些 issue 相關、哪些 Slack 討論串是關於哪些功能的、哪些人通常在哪些主題上需要你的意見。當一個新訊號抵達時 – 一個 Slack 訊息、一個 GitHub 事件、一個 Linear 轉換 – 你根據該圖譜對其進行分類。不是問「這有提到 Chris 嗎？」而是問「這是否影響了 Chris 正在積極處理、等待或負責的事情？」
分類需要分解成類似這樣的東西：
| 分類 | 意義 | 行動 | |---------------|---------------|--------| | 緊急 | 你阻礙了某人，或有東西壞了 | 立即呈現 | | 重要 | 影響你當前工作，但不具時間緊迫性 | 批次進入每日摘要 | | 資訊 | 知道就好，不需採取行動 | 需要時可供查詢 | | 噪音 | 重複項目、機器人喋喋不休、已解決的討論串 | 完全過濾掉 |
困難在於分類的信心程度不是二元的。一個你從未造訪的頻道中的 Slack 訊息，如果它引用了指派給你的 issue，仍然可能是緊急的。一個關於你幾個月沒碰過的 repo 的 GitHub 通知，如果有人剛重新開啟了一個你以為已修復的 bug，可能就很重要。你需要兩層協同運作：一個事件正規化層，將每個傳入的 webhook 針對複合鍵 – repo、issue ID、actor、事件類型 – 進行雜湊，並根據 TTL 的去重複視窗（基本上是最近事件指紋的滑動視窗）進行檢查；在其後方是一個即時的關聯圖譜，對應任務所有權、PR 連結、討論串參與者和最近的活動模式。你本質上是在建立整個團隊工作狀態的讀取模型，近乎即時地更新，並在每個入站訊號上查詢它。去重複層捕捉明顯的重複項目。圖譜回答更難的問題：「這對現在的你具體相關嗎？」
核心分類迴圈能很好地處理明確的情況，單單這樣就能大幅減少噪音 – 但真正模稜兩可的訊號（你沒有足夠信心去抑制，但也沒有足夠信心去呈現）仍然是一個未解決的問題。我們正在嘗試將這些批次放入一個「可能」的摘要中，但我不會假裝我們已經完美解決了。
當消防水柱停止噴射時會發生什麼
我沒料到的事 – 我真的以為好處只是「更少的 ping」 – 是當你的工具停止對你大喊時，你與它們的關係會發生多麼深刻的改變。
當每個通知都可能很重要時，你會對未讀數產生一種低度焦慮。帶有粗體頻道名的 Slack 側邊欄。GitHub 的鈴鐺。Linear 的收件匣。你強迫性地檢查，不是因為你期待什麼緊急的事，而是因為錯過某件事的代價感覺比檢查 50 件結果是噪音的事的代價還要高。我曾經在寫函式簽章和函式主體之間 alt-tab 到 Slack。不是有意識的決定 – 只是一種反射，就像你在紅燈時檢查後照鏡一樣。
這種先發制人的自我打斷可以說比通知本身更糟，因為在任何 ping 到達之前你就在打斷自己的專注。你活在一種永久的部分注意力狀態中，你能在寫的程式碼裡感覺到 – 更淺層的審查、更保守的架構選擇、走阻力最小的路徑而不是真正正確的方法，因為你不相信自己能有 45 分鐘不被打斷的時間來好好思考。
當消防水柱停止噴射時 – 當你相信重要的訊號會找到你而噪音不會 – 那種反射就會消退。不是立刻的，因為舊習慣很頑固。但在幾週內你會注意到，你在編輯器中待的時間更長了，沒有強迫性的 alt-tab。你開始完成完整的思考。你寫出更好的程式碼，不是因為你突然變聰明了，而是因為你不再為了一個從未要求你這樣做的通知系統，每小時自願進行 30 次情境切換。
cutting through inbox and channel noise notification fatigue the Slack notification strategy for busy teams 停止在通知中溺水。Sugarbug 依據關聯性對來自 Linear、GitHub 和 Slack 的每個訊號進行分類 – 並且只呈現真正需要你的內容。
Q: Sugarbug 能減少來自 Linear、GitHub 和 Slack 的過載通知嗎？ A: 可以。Sugarbug 透過 API 連接 Linear、GitHub 和 Slack，並依據急迫性與關聯性對每個訊號進行分類。它不會轉發每一個通知，而是只呈現需要你關注的 – 通常能將每天數百個 ping 減少到真正需要你的少數幾個。
Q: Sugarbug 能根據我正在進行的工作來排定 GitHub PR 通知的優先順序嗎？ A: Sugarbug 會建立涵蓋你任務、PR 和對話的知識圖譜。它知道哪些 PR 與你當前工作相關，會優先呈現這些 PR 的審查請求、合併衝突和 CI 失敗 – 同時悄悄將其餘的歸檔。
Q: Sugarbug 與 Slack 內建的通知設定有何不同？ A: Slack 的設定讓你可以靜音頻道或設定關鍵字，但無法理解跨工具的情境。Sugarbug 同時讀取 Linear、GitHub 和 Slack，因此它知道關於你提交的 PR 的 Slack 討論串是緊急的，即使它位於你已靜音的頻道中。
Q: 通知過載對工程團隊的真正代價是什麼？ A: Gloria Mark 在加州大學爾灣分校的研究指出，中斷後大約需要 23 分鐘才能恢復深度專注。除了 ping 本身之外，它們造成的強迫性檢查行為會使複雜工程工作所需的持續專注力變得支離破碎。
如果你的工程團隊通知已經從「保持資訊更新」越界到了「保持焦慮」，這大概是一個訊號 – 需要修復的是架構，而不是你的通知偏好設定。