Blog · 2026-08-30
把簽到、派彩、抽獎做成全自動：會員 LINE 機器人的系統設計
從 LINE 身分歸戶、防重複的唯一鍵、派彩冪等入帳，到 systemd 自啟、外部告警、每 6 小時備份的上雲三件套，拆解一套不需要人工值班的會員機器人架構。
會員營運最吃人力的是重複動作：每天核簽到、對名單發獎、確認派彩到帳、再逐一私訊通知。人工做，慢又會漏，活動一放大客服直接被淹沒。這整條流程可以交給 LINE 機器人全自動跑——前提是幾個設計問題要先想清楚，不然自動化只是把錯誤加速。
歸戶：LINE 身分與會員帳號是兩套系統，先建對照表
LINE 官方帳號拿到的是平台核發的用戶識別碼，會員系統裡是另一套帳號體系，兩邊天生對不上。所有自動化的第一步，是把「LINE 識別碼 ↔ 會員帳號」這張綁定對照表建起來，而且要建得夠嚴：
- 綁定要驗證擁有權。不能會員在對話框輸入一個帳號就算綁定，要配一次性驗證碼或後台核可，否則任何人都能把別人的帳號綁到自己的 LINE 上。
- 唯一性用資料庫約束保證：一個 LINE 身分只能綁一個會員帳號，一個會員帳號也只能被綁一次。少了這兩條唯一約束，遲早出現一人多綁重複領獎，或熱門帳號被搶綁。
- 解綁、重綁一律寫入異動紀錄。出爭議時，這張紀錄是唯一能把事情講清楚的證據。
歸戶做穩之後，簽到、抽獎、派彩、推播全部掛在同一個會員身分底下，後面的自動化才有地基。
簽到與抽獎：防重複的鍵要選對，而且讓資料庫來擋
防重複最常見的失誤是鍵選錯層級。要防「同一會員一天簽到兩次」，唯一鍵就是會員加日期；要防「同一會員在同一檔活動重複抽獎」，鍵就是會員加活動。鍵沒對齊真正要防的東西，功能測試全綠照樣會漏。
三個實作重點：
- 擋在資料庫唯一索引，不是程式裡的 if 判斷。連點、網路重送、兩個請求同時進來，程式邏輯可能同時放行，唯一索引不會。撞鍵時回「今天已簽到」，對用戶是正常回覆，不是錯誤。
- 「一天」要明確定義時區。主機時間和台灣差幾個小時的話，午夜前後就會有人多簽或少簽一天。
- 防刷要立體，而且要假設一定有人來灌。我們做過一檔活動報名抽獎頁，IP 限流、黑名單、手機與 email 唯一鍵、指紋雜湊、人機驗證五層防刷全上，事後再做多維度清洗，從 142 筆報名稽核出約 118 筆真實名單，其餘是測試資料、亂填號碼、同網段批量與邀請自推。前端擋得住手滑，擋不住有心人，名單要能事後對出真偽。
派彩自動入帳：冪等比速度重要，入帳成功才推播
在 iGaming 這類場景，派彩是把活動彩金或回饋直接入到會員的遊戲錢包。全自動派彩的核心，是機器人後端呼叫會員系統的入帳介面，而且每一筆帶唯一單號——同一單號重送，系統回同一結果、不入第二次。這叫冪等，是自動派彩敢重試的前提。
- 最危險的不是失敗，是「不確定」。入帳請求逾時，錢可能入了也可能沒入，這種單不能盲目重試、也不能直接標失敗，要先查單確認狀態再決定下一步。失敗路徑沒設計好，自動化就是自動虧錢。
- 順序寫死：入帳確認成功，才發 LINE 推播通知到帳。推播重複頂多多收一則訊息，入帳重複是直接損失，兩邊的重試策略必須分開。
- 每筆派彩留單、排程對帳：機器人側的派彩紀錄與會員系統的入帳紀錄定時核對，差一筆就告警。全自動不是沒人看，而是只有異常才需要人看。
- 推播本身有成本與額度，到帳通知和行銷訊息要分級管理，別讓系統訊息把額度吃光。
上雲三件套：自啟、告警、備份，缺一件都不算上線
這種機器人是 24 小時收訊息的常駐服務，掛在辦公室某台電腦上跑就是單點風險。我們的標準做法是部署上雲端主機，配齊三件套：
- 開機自啟與崩潰自癒：systemd 設 Restart=always 並 enable，主機重開機服務自己起來，進程崩了自動重拉。同一套部署骨架的另一個系統實測，進程被強制殺掉後約 6 秒就被 systemd 接回。
- 外部監控告警：死掉的進程發不出「我死了」，告警不能靠服務自己回報，要用外部存活檢查，一掛就主動通知到手機。
- 資料自動備份：綁定對照表、簽到與派彩紀錄就是這套系統的命。我們把資料庫每 6 小時自動備份到雲端物件儲存，與主機分屬不同故障域，保留多份可回溯——主機炸了，最多掉幾小時資料，不是全部。
結語
簽到、綁定、派彩、抽獎，單看每個功能都不難；難的是把重複、逾時、搶綁、灌水、當機這些失敗路徑一次設計進去——全自動系統的品質，是由失敗路徑決定的。如果你的會員營運還卡在人工核名單、手動派彩，或想幫現有機器人補上防重複與備援，可以找我們聊聊，看哪個環節最值得先自動化。