开始前需要什么
- 准备已登录且有操作权限的 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 吗？
有开放接口的走接口；没有的部分用真实浏览器带着你已登录的会话去操作，路径和人手点的一样。两条路都要经过同一个审批闸。
会不会误发给不达标的达人？
达标口径是参数，筛选在预览阶段就已经完成，你看到的名单就是要发的名单。加上「确认后不补人」这条，不存在名单被悄悄替换的情况。
一次能发多少？
上限由你定。它不会为了跑满而放宽条件——宁可这一轮少发，也不发给一个没达标的人。