把每天一次的點擊交給雲端跑：一份 Serverless 定時任務復盤，整理出自動化的四類通病

2026 年 9 月 24 日，掘金上一篇開發者復盤文章獲得社羣討論。作者把自己帳號在 Trae CN 客戶端上的每日簽到，改成部署在阿裏雲函式計算（FC）上的定時任務，每天上午 09:05 自動執行，完成後透過微信回報結果，通知標題直接附上當前可用積分。事情的起點很小：原本每天要打開客戶端手動點一次的動作，現在換成一支雲端函式代勞。但作者點出，路上踩到的坑幾乎都與平臺無關，而是任何定時任務自動化都會遇到的通病。這也是這份復盤值得整理的地方。

先看設計怎麼來的：三條約束倒逼出選型

需求本身很單純：每天固定時間跑一次、每次不到一分鐘、跑完要通知結果。把這句話翻譯成對運行環境的要求，就能排除掉一堆常見方案。

每天跑六十秒的任務，如果租一臺常駴 VPS，機器利用率不到千分之一；本地 cron 則依賴機器剛好在線；純 GitHub Actions 難以保證精確的時間窗口，也缺告警管道。函式計算剛好對上：不跑不花錢、自帶定時觸發器、失敗可接雲監控告警。

但 Serverless 不是白拿的，作者列出三條隨之而來的硬約束。第一，程式碼包要盡量單文件：標準 Python runtime 已內建 urllib、json、base64，不引第三方依賴就省掉打包這一步，少一層抽象就少一層線上事故。第二，執行時長是硬預算：他配了 300 秒超時，而這段預算要先分配給重試策略。如果重試是退避十次、每次間隔約 22 秒，光重試就喫掉約 220 秒，剛好卡在預算內。做重試之前先算預算，否則重試把超時喫光，反而變成另一種失敗。第三，沒有互動式除錯環境，能依靠的只有日誌和返回值，這讓可觀測性從加分項變成必需品。

他還記了一個新手最常卡住的操作細節：程式碼包本身不包含觸發器。只上傳程式碼的話，函式永遠不會自己跑，只有手動點測試才會動，因為根本沒設定時器。這與我們先前整理過的Cloudflare 轉發搭配 Resend 的零成本信箱方案是同一類思路：把幾個免費服務串起來取代常駴設備，關鍵都在弄清楚每個環節各自的責任邊界。

四類通病：平臺換掉，問題還在

作者把踩過的坑歸納成幾類，每一類都值得對照自己的經驗。

第一類是介面契約不可靠。社區部落格上現成的腳本，經常基於某個舊版本客戶端寫成，payload 或必要請求頭早已改變，直接抄的失敗率很高。他的做法是按固定流程去讀客戶端自己發出的請求，而不是相信別人轉述的版本。

第二類是服務端錯誤文案會騙人。照字面理解錯誤訊息，可能浪費一整天找錯方向。錯誤碼寫的是 A，實際發生的原因可能是 B，這在許多第三方介面上都不新鮮。

第三類是缺乏觀測手段造成的誤判。任務其實一直正常在跑，但當事人以為它掛了，原因只是沒有任何可靠的執行紀錄可查。雲端上的東西看不到畫面，日誌就是唯一的現場。

第四類最有趣：兩個任務都很健康，卻因為共享同一份憑據的每日通知額度，互相把對方的通知擠掉。這提醒了一件事，你以為該加冗餘的地方（例如多一個通知通道），往往根本不是瓶頸所在；真正的瓶頸藏在額度共享這種不顯眼的耦合裡。

合規邊界：技術可行不等於規則允許

這類文章最容易在邊界上含糊，作者在文前就先講清楚。他處理的是自己名下的帳號，用戶端自身產生的真實憑據，技術上等於換了一根手指去點那個按鈕。明確不做的包括：批量帳號、代理池、自動化註冊、繞過或偽造風控參數、修改服務端資料，以及對外提供代刷服務。文中出現的 token 與設備號全部是佔位示例，真實登入態只存在自己的環境變數裡，不進版本庫。

他對讀者的提醒也值得原樣保留：請遵守你所使用平臺的服務條款。技術可行不等於規則允許，如果平臺明確禁止自動化存取，就應該尊重它的規則。

所以呢：把這份復盤用到自己的工作裡

對每天在維運各種小工具的人，這份復盤的價值在於方法而非結論。評估要不要自動化一個每日動作時，先算三件事：任務的實際運行時長佔常駴資源的多少、失敗時靠什麼知道、重試預算會不會喫光執行時限。這三個數字算出來，選型往往就自己浮出來了。

而對照最近幾波開發者工具的討論，包含我們整理過的NotebookLM 免費版與付費版的額度差異，可以看出同一個趨勢：當工具的日常使用都變成「每天點一下、每次幾十秒」，把這些動作交給雲端例行程序的誘惑只會越來越大。屆時真正拉開差距的，不是誰會寫腳本，而是誰先想清楚契約、觀測與額度這三件事。平臺會換，這三件事不會。