2026 年 10 月 25 日晚間，V2EX 上一位自稱轉型獨立開發的大齡工程師發文，分享他基於開源專案二次開發的一套垂直資訊過濾管道。他用 pgvector（PostgreSQL 的向量搜尋擴充套件，可以理解成讓資料庫比對內容相似度的工具）做語意去重，過濾掉不同媒體反覆報導同一件事的冗餘訊息，跑起來後每天只推 2 到 3 則高信噪比內容給自己。

技術細節是他的專業，但這篇貼文裡有幾個決定，其實和你我的日常很有關係。

他發現：一天超過 4 則推送，人就麻了

整篇分享裡最值得一般讀者留意的，是他刻意替自己立的規矩。他寫到，做資訊聚合最容易犯的錯，就是「覺得什麼都好，不停往羣裡塞」，實際自用下來發現單日超過 4 則，人對通知就會麻木。

於是他把頻率限制直接寫死在後端程式碼裡：每天最多 4 則，兩次推送之間至少隔 2.5 小時，晚上 23 點到早上 8 點半完全靜默，任務直接延到隔天早上。

這個數字是他個人的使用體感，屬於個案經驗，不是什麼大型研究的結論。但它和很多人對通知疲勞的感受是一致的：訊息不是越多越好，超過某個量之後，重要的訊息也會被你自動略過。

如果你自己也常常被各種 App 通知打斷，可以參考我們之前聊過的把 Mac 通知轉發到手機的工具與注意力照顧，裡面有幾個把通知權限拿回自己手上的具體做法。

在內容被演算法塞滿之前，先做實體層過濾

他的技術踩坑也有一個可以遷移的思路。他發現光靠向量相似度去重會出錯：閾值設太緊，會把只是同賽道的不同專案誤判成重複；設太鬆，又會漏掉換個標題的公關稿。後來他改成先做實體層的比對，例如把 GitHub 儲存庫名稱正規化、把網域摺疊，實體對得上就直接合併，對不上才進一步做語意評分，把純行銷稿在評分階段擋掉。

換到日常的資訊識讀，這個順序其實很實用：面對一則聳動的健康或產品消息，先看可驗證的硬資訊，來源是誰、有沒有具名、日期是哪天、原始出處在哪裡。這些對得上，再考慮內容本身的說法；這些都對不上，標題下得再吸引人，價值就很有限。

夜間靜默這一條，對身體最友善

他規定 23 點到 8 點半推送任務直接延後，這在工程上只是幾行程式碼，在生活上卻是對睡眠最基本的保護。睡前被手機通知或短影片勾住，是很多人晚睡的共同路徑。你不需要自己寫程式，手機內建的專注模式或勿擾模式就能做到類似的事，差別只在於你願不願意替自己設一條「門禁」。

如果你也是那種會為了等一個訊息、追一個更新而熬夜的人，可以看看先前寫過的開發者熬夜做 side project 的作息照顧，裡面有幾個還原睡眠節奏的小步驟。

一點提醒

他的管道設定是為自己的工作需求調的，每天 2 到 3 則對一般人的資訊需求來說未必要照搬。重點在那個原則：主動決定「一天要收多少」，而不是讓演算法和通知決定你何時看、看多久。你可以從最吵的那個 App 開始，關掉非必要通知，觀察一週，看看自己的專注和睡眠有沒有變化。這比任何工具都更值得先試試。