Threads 留言抽獎看似只要把留言者丟進亂數工具，真正容易出問題的地方卻都發生在按下「抽出」以前：重複留言算幾次？截止後編輯算不算？被刪除的留言怎麼處理？主辦方如何證明名單沒有被動過？
可查核的重點不是讓流程看起來複雜，而是讓另一個人拿到同一份資料與規則時，能理解結果怎麼產生。
活動開始前先固定規則
至少公開以下資訊：
- 截止日期、時間與時區；
- 參加資格，例如是否限公開帳號或特定地區；
- 每個帳號有一個名額，還是每則有效留言各算一次；
- 是否要求關鍵字、標記朋友或回答問題；
- 主辦方、工作人員、機器人與已知重複帳號是否排除；
- 得獎者未回覆時的遞補方式與期限。
規則發布後若要修改，應保留變更時間與原因，不要直接覆蓋到看不出差異。
建立一份「截止快照」
截止後先保存原始留言清單，再進行清理。每筆至少保留留言 ID、帳號、時間、文字與原文連結；原始清單唯讀保存，另外產生一份符合資格的候選名單。
清理時記錄每一種排除原因，例如：
- 超過截止時間；
- 同帳號重複；
- 不符合指定格式；
- 主辦方帳號；
- 留言已無法讀取。
不要只留下最後 300 個有效帳號，卻無法解釋原本的 327 則留言去了哪裡。
抽選要能被說明，不一定能原樣重播
如果使用可指定種子的程式亂數，可以保存候選名單版本、抽選時間、亂數種子與抽出順序；如果使用密碼學亂數或第三方工具，通常無法靠同一個按鈕重播出完全相同的結果，就更需要保存當時的條件、合格人數、得獎名單與必要的操作畫面。
公布結果時不必公開所有人的個資，但可以揭露總留言數、有效名額、排除規則與抽選方式。可查核的目標，是讓人知道候選名單如何形成、當時抽出了誰，不是把「一定能抽出同一組人」當成公平的唯一證明。
查核不等於蒐集越多越好
只保存完成活動所需的欄位，設定刪除期限，也不要把參加者資料挪作未告知的行銷用途。可查核追求的是流程透明，不是無限期保留名單。
這套流程可以先用試算表完成。未來若交給工具自動化，也應保留同樣的原則：原始資料不覆寫、清理規則可說明、抽選條件與結果有紀錄。
脆稿如何協助整理抽獎流程？
脆稿已把留言抽獎納入正式功能。使用者可以從已同步的自有貼文選擇活動，透過官方 conversation 端點抓取頂層與巢狀留言，設定關鍵字、同帳號去重、排除自己的帳號與得獎人數，再用密碼學亂數抽選。每次會在本機保存貼文、時間、條件、合格人數與得獎名單，並可查看最近 10 筆紀錄。
這項功能只能處理自己帳號已同步的貼文；照使用說明完成 Threads API 連線後即可使用，沒有 username 的留言則無法列入候選名單。脆稿不保存可重播相同結果的亂數種子，也不會代替主辦方發送私訊或自動發布得獎公告，因此主辦方仍需自行公布截止時間、資格、遞補方式與必要的查核材料。
工具保存的是當次條件與結果，不代表 Threads 或脆稿替活動公平性背書。你可以先看脆稿的留言抽獎功能入口，再依活動風險決定是否另外保留畫面錄影或截止名單。