一條早上九點的通知，先被排好了版：WorkBuddy 簽到機器人的訊息設計觀察

（本文回顧 2026 年 9 月 24 日發表於掘金的技術分享，近期在自動化工具社羣被重新轉貼討論。）

先從那段最有畫面感的文字看起。每天早上九點，微信會跳出一條訊息：

活動： 每日簽到 · 第 7 期 獲得積分： +100 連續簽到： 3 天 累計積分： 300

五行字，沒有多餘的問候語，沒有表情符號。這是一個部署在阿裏雲函數計算上的 Python 腳本，替使用者完成 WorkBuddy 每日簽到之後，透過 Server醬 推送的結果摘要。技術上它平淡無奇：一個純標準庫的腳本、一個定時觸發器、一個微信推送通道。但這五行字的排法，值得停下來看一眼。

訊息本身就是介面

大多數自動化腳本的輸出是工程師視角的：時間戳、HTTP 狀態碼、debug 訊息。這個腳本不是。它推送的內容經過一次篩選，只留下使用者真正會在乎的四個數字：這期活動是第幾期、今天拿到多少、連續了幾天、總共累積多少。

這個篩選動作，本質上是一種介面設計。簽到這個動作的原始回應，大概是一整包 JSON，裡面有欄位名稱、有狀態碼、有時間戳記。腳本把它翻譯成人話，而且是有層次的人話：活動資訊放在最上面作為語境，「+100」放在中間作為即時回報，「3 天」和「300」放在下面作為長期累積。即時滿足與延遲滿足，被同一則訊息裡的先後順序安排好了。

數字的寫法也有細節。「+100」前面那個加號，讓積分看起來像一筆進帳而非一個欄位值。這和遊戲結算畫面、超商點數 App 的顯示慣例一致，設計者未必有意借用，但結果踩在同一條認知路徑上：有加號的數字會被讀成獎勵，沒有加號的數字只會被讀成資料。

每天三秒的動作，被整段搬走了

原文章把這個腳本解決的問題拆得很清楚：手動簽到單次只要三秒，但它是每天都要執行的動作，真實成本在「得記得」「得有設備」「得自己確認成功與否」。三個成本都不是時間成本，是注意力成本。

從設計角度補充一點：這個腳本真正搬走的，是「主動 remembering」這個認知負擔，而它回饋給使用者的，是一條被動 receiving 的通知。前者要求你每天在正確的時間想起正確的事，後者只要求你掃一眼手機。整個使用者體驗的形態，從一個待辦事項變成一段每日晨間儀式的旁白。通知裡的「連續簽到： 3 天」尤其關鍵，它每天重新展示一次斷損風險，讓使用者對這套自動化系統產生持續的信賴感，而非設定完就遺忘。

零依賴是一種克制的造型

腳本本身也有可以「看」的地方。作者特別強調純 Python 標準庫、零第三方依賴，部署包只有幾 KB。這在工程上帶來實際好處，免 pip install、免 requirements.txt、無環境漂移。但在設計語言上，這是一種克制的造型選擇：能用系統自帶的材料完成，就不引入多餘的裝飾。好比一把只保留必要功能的工具刀，每個零件都有它存在的理由。

技術選型上用雲函數而非常駐伺服器，理由是每天只跑十秒的任務不值得養一臺機器。不跑不收費、自帶秒級準點的定時觸發器、失敗可接雲監控告警。這套取捨的邏輯，和產品設計裡「形式追隨使用頻率」的原則相通：使用者的注意力該花在訊息內容上，系統本身愈隱形愈好。

誰在設計這條訊息

值得分辨的是，這五行通知的視覺成果，其實由三方共同完成。介面端是微信的對話泡泡，字體、行距、底色都不是腳本能控制的；通道是 Server醬，決定了訊息以什麼身分、什麼速度抵達；腳本只負責內容的揀選與排序。這種「內容與容器分離」的處境，和早期簡訊時代的銀行通知很像：設計者能掌握的只有文字本身的順序與用詞，於是每一個字的取捨都變得重要。

對照著看，市面上正式產品的簽到結果頁，往往塞滿了分享按鈕、任務列表、廣告輪播。這條機器人通知反其道而行，只回報數字，因為它的使用者只有一個人，就是寫它、部署它的那位。當介面的受眾縮減到一人，所有為陌生人設計的冗餘都可以刪掉，剩下的就是這個乾淨的樣子。某種程度上，這是個人化介面的極端案例：受眾規模決定了資訊密度。

一點邊界

原文章在合規上寫得明白：方案只對自己帳號生效，用自己的憑證，本質是讓雲函數替你按一下簽到按鈕，不建議做多帳號或代刷。這條界線值得放在設計脈絡裡重讀一次：自動化工具的倫理位階，往往就體現在它為誰設計。為自己省下每天三秒，是一種個人效率工程；為多人批量複製，就變成平臺生態的破壞者。同一份程式碼，兩種截然不同的身分。

收個尾。這個專案最耐看的部分，不是雲函數或零依賴這些技術決策，而是那則通知被排出來的樣子。當一套系統把人的動作全部接管之後，人與系統之間只剩下每天早上那一眼。那一眼裡裝什麼、先看到什麼、哪個數字帶加號，就是這套自動化最終的介面。它只有五行字，但它被認真排過。