為什麼想做這件事
靜態網頁有一個很常見的誤解，就是「靜態」代表死的、不能動的。但其實搭配 CI/CD 之後，它可以做到很多人沒想到的事情。
我想做一件事：讓這個網站的某個欄位，每個禮拜自動更新，不需要我手動寫任何東西。我的動機有兩個：
第一個是純粹想測試 GitHub Pages 這類靜態部署在自動化上能走多遠。從爬資料、呼叫 LLM、到最後 commit 進 repo 觸發部署，整條鏈可以完全在 GitHub Actions 裡完成，不需要任何後端伺服器。這件事本身就很有趣。
第二個是實用性：GitHub Trending 是我覺得目前還沒有被充分利用的資訊源。每週跑一次 top 15，用關鍵字篩掉不相關的，剩下的讓 LLM 幫我整理摘要，然後自動發布到網站上。這樣我不用每週主動去追，資訊會自己跑到我的網站來。
技術細節
起點是找到一個乾淨的 RSS 來源。GitHub 官方沒有提供 Trending 的 RSS，但有人做了：mshibanami/GitHubTrendingRSS，每天自動更新，週報的 URL 格式長這樣：
有了 RSS 之後，pipeline 的結構就很清楚了：
- 抓資料：用
feedparser解析 RSS，取前 15 筆 - 粗篩：用關鍵字過濾（gemini、claude、gpt、llm、ai 等），把跟個人網站主題不符的 repo 排掉
- 生成內容：把篩選後的 repos 一次送給 Gemini 2.5 Flash，要它用一個 prompt 同時生成每個專案的繁中介紹和整批的 tags
- 寫入 & 部署：把生成的 markdown 存到
content/news/，接著 git push，觸發現有的 Hugo deploy workflow
整個流程放在 GitHub Actions 裡，設定每週日台灣時間 12:30 跑一次。沒有任何常駐的伺服器，費用幾乎是零（Gemini API 這種用量的成本可以忽略不計）。
反思：跟 Claude 合作這件事
這次整個系統是我跟 Claude 一起搭起來的。
我的起點只有一個很粗略的想法：「我想每週爬 GitHub Trending，然後用 LLM 幫我整理」。至於 RSS 要怎麼 parse、GitHub Actions 的 YAML 要怎麼寫、cron 的時區設定在哪、GITHUB_TOKEN 為什麼不能觸發其他 workflow……這些細節我知道存在，但我沒有特別想深入研究。
結果就是：我專注在「這個東西要做什麼」，Claude 負責「這個東西怎麼做出來」。
不是說細節不重要。而是在這個時間點，我認為想法和知道某件事大致可行，比把所有細節自己弄清楚更有價值。
有一個簡單的測試：如果你能清楚說出「我想要 X，這件事應該可以透過 A → B → C 做到」，那你就已經站在一個能讓這件事發生的位置了，不管是自己做、找人做、還是跟 AI 做。
之前如果沒有 AI，這個想法可能會停在「想法」的階段，因為我不想花時間去研究 feedparser 的文件或是 GitHub Actions 的 permissions 設定。現在它真的跑起來了，而且整條 pipeline 我都看得懂，就算有什麼東西出問題，我也能判斷是哪一段的問題。
這是我目前覺得「跟 AI 合作」最順的模式：你負責方向感，它負責把方向變成可以動的東西。