同名會員生日祝福發錯人，我們怎麼修這個資料地雷

某天客服信箱多了一封抱怨信：會員收到別人的生日祝福，還附贈五百點會員積分，但積分進了別人的帳號。這是一家線上花藝訂閱平臺的真實案例，系統每天自動抓當天生日的會員名單，發送生日祝福訊息並附上會員點數，聽起來是很貼心的自動化，結果變成一場資料事故。

問題出在哪：系統只認名字，不認人

排程邏輯是這樣的：先撈出今天生日的會員，再拿會員姓名去對應通訊軟體的好友清單，找到同名好友就直接推播。邏輯寫的人當時只想到「如果同名好友有超過一位，系統無法判斷就跳過」，聽起來很嚴謹。但沒想到的是，會員主檔裡也可能有同名的人，而且生日不同。

於是A小姐的生日祝福被推給了通訊軟體裡同名的B小姐，B小姐還真的回覆了，五百點會員積分就這樣進了不相關的人的帳號。系統從頭到尾都覺得自己做得很對，因為它檢查的是「好友清單裡同名的人只有一個」，卻沒檢查「會員主檔裡有沒有其他同名的人」。

系統不會說謊，但它只會照你寫的邏輯騙自己。

止血不是刪資料，是先讓自己看得懂發生了什麼

發現問題後，第一件事不是急著改程式，是先把誤發的紀錄標記起來，原始狀態留一份備份，方便回滾。我們寫了一支SQL，先用「預覽模式」把可能誤發的名單列出來，人工確認過一輪之後，才真的執行標記動作。這支腳本可以重複執行、可以回滾、遇到錯誤資料庫會直接中止，不會硬幹下去。

• 先預覽再執行，永遠不要相信自己第一次寫的條件是對的
• 誤發的點數要不要收回，是業務決策不是技術決策
• 同名同生日的人視為重複註冊，生日不同的同名者才是真正的風險名單

真正的修法：多一層比對，別偷懶

最後的修法很直白：在用姓名去比對通訊軟體好友之前，先檢查會員主檔裡有沒有其他同名的會員。如果有，就不能只靠姓名判斷，要改用信箱或會員編號這種真正唯一的識別碼去比對，寧可少發一則祝福，也不要發錯人。查詢過程如果出現例外狀況，保守處理，直接當作「有風險」擋下來，不要冒險送出。

這種設計哲學其實很簡單：任何用「人類看得懂的資料」當唯一識別的系統，遲早會踩到雷。姓名、暱稱、電話都可能重複，只有系統內部產生的編號才靠得住。省下設計這一層防呆的時間，遲早要用客訴和回滾腳本還回來。

貼心的自動化，一旦少了防呆，就是精準的自動化事故。