開始前需要什麼
- 準備已登入且有操作權限的 TikTok Shop 店鋪，以及明確的目標邀請任務。
- 提供候選創作者、指標門檻與單輪上限；平台限制與帳號權限仍然適用。
創作者邀約：把「翻後台、怕重複邀、送之前想確認一下」做成一條可回溯的線
Fiitx 可為 TikTok Shop 創作者邀約去重、核驗平台狀態並產生待確認名單，區分可邀約、已邀請與無法確認。人員確認後依該名單執行，不自動補入未確認的創作者；成功與否以平台回覆為準，帳號權限與平台限制仍然適用。
接入條件與可核驗輸出
會拿到什麼
- 去重後的預覽名單，區分可邀約、已邀請與無法確認，交由人員審核。
- 確認後依該名單執行；衝突、失敗或找不到的對象分別列出，不自動補人。
適用邊界
- 預覽不等於傳送成功；平台狀態未知時需要複核，不能直接視為未邀請。
- 下方以虛構測試資料模擬平台狀態，未登入店鋪或發送實際邀約，也未驗證平台介面可用性。
公開驗證範例
使用虛構資料，由 Fiitx 現有計算模組產生。不是客戶資料、交付實錄或節省工時的實測；只驗證下列規則。
範例核驗日期:
| 創作者帳號 | 核驗狀態 | 下一步 | 實際傳送狀態 |
|---|---|---|---|
| demo_alpha | 可邀約 | 等待確認 | 未傳送 |
| demo_beta | 已邀請 | 排除 | 未傳送 |
| demo_unknown | 無法確認 | 人工複核 | 未傳送 |
如何核對
- demo_alpha 在候選與 handle 重複出現，合併為一位，進入待確認名單。
- demo_beta 已邀請而排除；demo_unknown 狀態未知、等待複核。全部列的實際傳送狀態均為未傳送。
01
接手之前，卡在哪
本地台帳永遠追不上平台
換過人、換過表、有人在後台直接手動送過——本地紀錄只涵蓋一部分歷史。只靠它去重，必然重複邀約。
篩選條件在兩個地方，結果對不上
類目、粉絲量、客單價這些條件一部分在平台篩選器裡，一部分靠人眼判斷。兩邊口徑不一致時，篩出來的人未必達標。
確認這一步最容易斷
營運想在實際送出前看一眼名單，但看完再回去，流程經常已經跑偏——要麼名單被重算過，要麼順延補進了本來不該送的人。
02
接手之後，怎麼跑
按你的條件篩，條件寫下來而不是記在腦子裡
類目、創作者層級、指標門檻作為參數固化，每一輪都按同一套口徑跑，換人接手不會變形。
三道去重：本地台帳、平台側已邀、本輪內部
關鍵是第二道——在平台自己的篩選裡確認「未邀請」，搜得到才算真沒邀過。只靠本地台帳去重是涵蓋不到的。
產出預覽清單，等你點確認
預覽裡帶上每個人命中的條件和去重依據，你能看出來為什麼是這些人。
照你確認的那一份送，不順延補人
名單一經確認就釘死。中途有人不可用就少送一個，絕不自動補上第 N+1 個 —— 補人意味著送給了一個你沒看過的人。
送完回平台核對狀態
實際送出結果回寫台帳，下一輪的第一道去重因此才是準的。
03
哪裡必須停下來等人
- 實際送出永遠需要人點確認，預覽不等於已送
- 確認過的名單釘死，不重算、不順延補人
- 達標口徑（指標門檻）由你定，不由它自己放寬
怎麼驗收
- 抽查預覽清單裡的人，回平台確認確實是未邀請狀態
- 實際送出數量與確認的名單逐個對上，不多不少
- 跑第二輪時，第一輪送過的人不應該再出現
04
口徑從哪來
06
常見問題
它是怎麼操作後台的？有 API 嗎？
有開放介面的走介面；沒有的部分用真實瀏覽器帶著你已登入的工作階段去操作，路徑和人手點的一樣。兩條路都要經過同一個簽核閘。
會不會誤送給不達標的創作者？
達標口徑是參數，篩選在預覽階段就已經完成，你看到的名單就是要送的名單。加上「確認後不補人」這條，不存在名單被悄悄替換的情況。
一次能送多少？
上限由你定。它不會為了跑滿而放寬條件——寧可這一輪少送，也不送給一個沒達標的人。