平常開發或做專案，免不了依賴一堆開源套件、前端框架或好用的自動化工具。但很多時候，某個套件發布了重大版本更新、修補了嚴重安全漏洞，甚至改掉了關鍵語法，我們往往要等程式碼噴錯或看到社群討論才後知後覺。今天我們就用 n8n 打造一個專屬的 GitHub 哨兵，只要追蹤的開源專案發了新 Release，立刻自動幫我們抓出更新日誌重點並推播提醒。

第一站：串接 GitHub API 取得發布資訊
GitHub 本身提供了非常完整的公開 API。我們在畫布拉出一個 HTTP Request 節點，或者直接搜尋 n8n 內建的「GitHub」節點。如果只想監控公開的開源專案，甚至不需要複雜的授權，只要把請求對準該專案的 Releases 介面，填入擁有者名稱與專案名稱即可。這個節點跑一次，就會把該專案最近幾次的發布版本號、發布時間、標題以及長長的更新說明（Release Notes）全抓回來。

第二站：比對版本與去重機制
這個工作流我們通常會設定排程，比如每四到六小時檢查一次。為了避免每次排程一跑就把舊版本反覆推播，我們需要一個簡單的狀態記憶機制。可以使用 n8n 的靜態資料儲存功能，把上一次成功發送過的最新版本號記在流程裡。每次抓到新資料時，先檢查這個版本號是不是大於上次紀錄的版本。如果是老面孔就直接忽略，只有發現全新的版本號時，才放行往下游傳送，並更新記憶中的版本號。

第三站：讓 AI 解讀更新日誌
開源專案的 Release Notes 經常又臭又長，裡面夾雜著大量的 PR 編號、作者名單和琐碎的修復紀錄，讀起來相當費力。我們把這份原始說明丟進 AI 節點，下達具體的要求：「請閱讀以下開源專案的新版本發布日誌，整理成給開發者看的速讀摘要。請列出：1. 新增的亮點功能、2. 是否包含重大變更（Breaking Changes）與潛在影響、3. 修復的關鍵 Bug。請用繁體中文條列，剔除單純的排版或感謝詞。」這樣一來，原本眼花繚亂的更新清單，立刻變成了重點突出的升級指引。

第四站：推送到開發頻道
最後依然把處理好的資訊排版推送到常用的通訊軟體。推播內容包含專案名稱、新版本號、發布時間、GitHub 原始連結，以及 AI 整理好的那三點核心變更。特別是看到有 Breaking Changes 的標籤時，就能第一時間提醒自己手邊的專案要不要延後升級或趕快更新適應。明天我們走出既有的 API 框架，試著監聽社群平台或討論區上的動態，當特定關鍵字被提到時自動幫我們存檔。