開源壁紙歸檔 DailyWallpaperHub，自動把每日壁紙收進你的 GitHub repo

用 AI 摘要這篇文章：

ChatGPT Claude Perplexity Google Grok

DailyWallpaperHub 是一個放在 GitHub 上的開源專案，做的事情很明確：用 GitHub Actions 定時去抓 Bing 與 Unsplash 的每日精選壁紙，連圖、縮圖、metadata 一起 commit 回 repo，再呼叫一個你看得到 key 的視覺模型為每張圖生成一段約 500 字的故事文字，最後透過 GitHub Pages 把整庫壁紙變成一座會自己長大的線上畫廊。它跟一般「壁紙下載器」的差別在於：下載器把圖丟進你的下載資料夾就結束，DailyWallpaperHub 把整件事變成一個會持續累積、可被 Git 追蹤、可被搜尋的歸檔庫，而且全部跑在 GitHub 的免費額度上，不需要你養一台伺服器。

如果你過去為了「自動收集壁紙」寫過爬蟲、架過排程，後來多半因為機器續約、套件壞掉或單純忘記而停擺，這類專案就是衝著那個痛點來的。把收集這件事搬到 GitHub 還有一個附帶好處：你的壁紙庫和你的程式碼一樣有公開的提交紀錄，哪天抓取腳本被來源改版弄壞了，問題會在 commit history 裡現形，而不是默默斷流幾個月你才發現圖已經沒在更新。

它實際在做什麼：一條從抓取到歸檔的流程

整個機制可以拆成幾個不會互相覆蓋的環節，每一段對應 repo 裡看得見的檔案。

Pin

抓取：專案裡有三支 Python 腳本，分別對應 Bing（《fetch_bing_wallpaper.py》）、Unsplash（《fetch_unsplash_wallpaper.py》）與批次回補歷史日期（《batch_fetch.py》）。來源是可設定的，設定檔放在 《config/sources.yaml》，作者把它設計成「想接入新來源就加一組設定」的形式，而不是把來源寫死在程式碼裡。這個設計的好處是，當哪天 Bing 或 Unsplash 改了 API、或你想加入另一個壁紙來源，只要動 YAML 不必動主邏輯。

歸檔：抓回來的每張壁紙會以 docs/wallpapers/<來源>/YYYY-MM/YYYY-MM-DD/ 的路徑存進 repo，每個日期資料夾固定四個檔案：原圖 image.jpg、縮圖 thumb.jpg、結構化 metadata meta.json，以及 AI 生成的 story.md。把歸檔直接 commit 進 Git 倉庫是這個專案最關鍵的設計選擇，它代表你的壁紙庫自帶版本歷史，某一天的圖被抓錯或想回退，都能用 Git 指令處理。meta.json 裡放的是拍攝資訊、來源 URL、標題這類結構化欄位，這意味著整庫壁紙不只可以看，還可以用程式去撈、去過濾、去做你自己的搜尋介面。

生成故事：故事是用 OpenAI 相容介面的視覺模型生的，prompt 不寫死在程式碼裡，而是放在 《prompts/story_prompt.txt》 讓你替換。作者刻意把故事生成設計成非同步，圖片先進庫、故事之後補，這樣就算 LLM 那邊慢或暫時失敗，當天的壁紙還是看得到，不會被生成步驟卡住。想單獨補故事，可以跑 《scripts/generate_missing_stories.py》 只針對沒故事的日期補單。

發布與通知：《docs/index.html》 是一個有暗色模式的響應式前端，透過 GitHub Pages 直接服務，預設只顯示最近 10 天，舊資料仍在 repo 裡可查，數字可在設定檔調。如果你想把每日壁紙推進聊天群組，它也接了企業微信群機器人的 webhook，填一個 WEWORK_WEBHOOK 就能推。

排程與回補：自動排程寫在 .github/workflows/daily.yml，README 描述是每小時偵測一次更新。實際的 cron 觸發頻率你要自己打開那個 workflow 檔確認，因為 GitHub Actions 的免費額度對公開倉庫較寬鬆、對私有 fork 較緊，fork 成私有倉的人要特別留意排程密度會不會吃光每月額度。除了往前抓，《batch_fetch.py》 支援用日期區間批次回補歷史壁紙，意思是如果你想要一座「從某年某月開始」的歸檔庫，不必從零等它一天天累積，可以一次把過去一段時間的 Bing 與 Unsplash 壁紙補齊進 repo。回補時的故事生成成本一樣算在你自己的 LLM 額度上，所以補得愈多、花得愈多，這是一個會影響帳單的旋鈕。

看得見的證據：repo 裡的每日歸檔

光讀 README 容易覺得「這種自動收集專案通常跑兩天就荒廢」，所以值得直接看倉庫本身。在 repo 的 docs/wallpapers/ 底下，日期子資料夾一路排到 2026 年 8 月初，每個日期都真的帶有 image.jpg、thumb.jpg、meta.json 與 story.md 四個檔案。README 上方的壁紙索引也列出了從 2026 年 7 月底到 8 月初的每日條目，附了縮圖與原圖連結。這代表那條排程目前確實在跑，而不是一份只有構想沒有產出的骨架。

Pin

不過要提醒一個實際狀況：README 列出的官方 demo 自訂網域，我實際用工具跟著重新導向走過去時，拿到的是 HTTP 403。GitHub Pages 的 github.io 原始網址沒有自訂網域那一層，通常不會受同一個 403 影響，想看實際畫面的人可以自己點 github.io 網址或直接看 repo 的 docs/ 目錄試試。這不是專案壞了，而是自訂網域那一層的設定或地區限制問題，但確實會讓第一次想預覽的人吃閉門羹。

AI 故事到底生成什麼，值不值得開

故事生成是這個專案跟「單純壁紙下載器」拉開差距的地方，也是會花你 LLM 額度的地方，所以單獨看清楚。

按照作者在 README 的描述，每段故事大約 500 字，內容是圍繞該張壁紙的地理與文化背景寫的，例如一張地景照會衍生出該地點的地理資訊、拍攝背景、相關文化脈絡。實際故事品質我沒有逐篇讀過，無法幫你背書它寫得好不好，這要你自己 fork 跑一輪、挑幾篇看才知道。能確定的是：prompt 是你自己改的，模型是你自己選的，所以你不喜歡某種語氣或長度，可以調 《prompts/story_prompt.txt》 與模型參數，而不是被迫接受作者預設的風格。故事和圖是分開存的這個設計也值得留意，story.md 是獨立檔案而非塞進圖的 metadata，代表你之後想全部重生、換模型重跑一遍，不會動到原圖歸檔，這對「先收集、之後再決定要不要加故事」的人是友善的。

這一點和把提示詞結構化拆解的 awesome-gpt-image-2是同一類思路：把 prompt 從程式碼裡拉出來變成可替換、可版本控制的獨立資產，對長期維護一個生成流程來說是健康的設計。代價是你要對 prompt 工程有一點概念，完全不碰 prompt 的人會覺得多了個要照顧的檔案。如果你完全不想花 LLM 額度，跑腳本時加 --skip-story 就會只抓圖、不生故事，歸檔功能照常運作，只是少了那段文字。

跑完整功能，你要先準備三把 key

這是決定你要不要 fork 的關鍵段落。專案程式碼本身是免費的，但「免費」只算到 GitHub 託管那一層，幾個會用到外部服務的功能都要你自己的 key：

• LLM_API_KEY 與 LLM_BASE_URL、LLM_MODEL_NAME：故事生成用的視覺模型，走 OpenAI 相容介面，所以你可以接 OpenAI、也可以接任何相容的供應商。這一把是會花錢的，每次生故事都會吃你 API 額度。
• UNSPLASH_ACCESS_KEY：Unsplash API 的存取金鑰，Unsplash 免費層就有，但要自己申請。
• WEWORK_WEBHOOK：企業微信群機器人的 webhook 網址，只想看線上畫廊、不想推訊息的話可以不填。

換句話說，這個專案的「零成本」指的是不用租 VPS、不用買資料庫、不用管 SSL，全部託管在 GitHub Actions 的免費額度與 GitHub Pages 上；但 LLM 呼叫的成本是跟著你的使用量走的，壁紙愈多、故事愈長，你的 API 帳單就愈高。作者把 key 全部留在你手上的設計是好事，代表沒有一個隱藏的中繼伺服器在替你呼叫，你的資料不會經過第三方轉手，這對在意隱私與成本透明的人是加分的設計。

另外還有兩個選用設定值得知道：IMAGE_REPO 讓你把圖另外推到一個專門的映像檔倉庫，靠 GitHub 的 CDN 加速取圖，適合壁紙一多、主 repo 體積變大的情境；作者也在 README 提到可選擇接騰訊雲 COS 做大規模圖片分發，這是給要把這套畫廊正式對外服務、流量變大時的後路。對個人典藏來說，這兩個都可先不碰。

授權邊界：程式碼是你的，壁紙不是

這裡是最容易踩雷、也最該在動手前看清的地方。專案程式碼採 MIT 授權，你可以自由 fork、改、商用你的程式碼；但 README 明確寫著壁紙版權屬於微軟 Bing 與 Unsplash，專案定位是「供學習交流」。

這條線的實際意義是：你 fork 出來的歸檔庫，程式碼是你的，但裡面的圖不是你的素材。把它們當作個人桌面背景、私下欣賞沒問題；一旦想拿來做商業簡報背景、社群貼文、網站素材甚至再授權給別人，你就脫離了 Bing 與 Unsplash 的使用條件，要自己回頭去讀這兩個來源的授權條款。Bing 每日壁紙的版權多半屬於原攝影師或微軟授權，Unsplash 的免費圖雖然相對寬鬆，但它的 API 條款對「再次大量散布原圖」也有限制。想把這座歸檔庫當作商用素材庫的人，這個專案不是你的答案。

誰適合 fork、誰先繞過

適合的情境蠻具體：你是一個會看 GitHub Actions YAML 不會頭痛的人，想要一份長期累積、可被 Git 追蹤的個人壁紙收藏，又不想為了它租一台會忘記續費的伺服器。同類型的「開源自動收集儀表板」做法，在把全球事件收進同一面板的 Situation Monitor那類專案也看得到，邏輯相近：把外部資料源排程抓進一個自己掌控的介面。如果你本來就在找免費可商用的圖庫素材而不是壁紙歸檔，Skitterphoto 這類 CC0 可商用圖庫會更貼近你的需求，授權問題也單純得多。

建議先繞過的人：把壁紙當商業素材的人、不想管任何 API key 的人、以及期待「一鍵安裝就有漂亮桌面桌布輪播」的純使用者。這個專案的價值在歸檔與可訂製的故事生成，不在當一套桌布軟體，前者要動手，後者你要的是別種成品。

還有一種人也建議緩一緩：想把這套畫廊正式對外開放服務、流量會衝上來的人。GitHub Pages 與 GitHub Actions 的免費額度是針對個人與中小流量設計的，一旦對外服務的請求量變大，你會撞到 Pages 的頻寬軟上限與 Actions 的每月額度，這時才需要回頭接前面提過的騰訊雲 COS 或獨立映像檔倉庫。個人典藏、小群組分享這個量級一般不會撞到免費額度上限，想做成對外服務之前，先想清楚你的流量與成本誰來吸收。

第一步與要注意的紅線

如果你想試，最小路徑是這樣：先把 repo fork 到自己帳號，在倉庫的 Settings → Secrets 裡把 LLM_API_KEY、LLM_BASE_URL、LLM_MODEL_NAME、UNSPLASH_ACCESS_KEY 填進去（WEWORK_WEBHOOK 視需要），再到 Settings → Pages 把來源設成 main 分支的 /docs 資料夾，然後手動觸發一次 .github/workflows/daily.yml 看它跑不跑得起來。README 的部署說明就是照這個流程寫的，本地端想先驗證抓取腳本可以裝 《requirements.txt》 後跑 python fetch_bing_wallpaper.py --skip-story，先把生成故事的 LLM 成本關掉、單純看抓取與歸檔是否正常。

再把紅線講一次，因為它比功能本身重要：fork 出來的壁紙歸檔，程式碼你擁有，圖你不擁有，AI 生成的故事文字則視覺模型輸出的內容屬於你使用該模型時的授權範圍，要另外看你的 LLM 供應商條款。把它當作一個會自動長大的個人典藏來用，從 repo 結構看是順手的選擇，至於長期穩定性要你自己跑一陣子驗證；把它當作免費素材來源，授權那一關你過不了。