本地台账永远追不上平台
换过人、换过表、有人在后台直接手动发过——本地记录只覆盖一部分历史。只靠它去重，必然重复邀约。
达人邀约：把「翻后台、怕重复邀、发之前想确认一下」做成一条可回溯的线
邀约这条线最贵的不是发的动作，是**发错的代价**：重复邀约会损害账号与达人关系，而「已经邀过谁」这件事，本地记录几乎总是比平台少。
01
接手之前，卡在哪
筛选条件在两个地方，结果对不上
类目、粉丝量、客单价这些条件一部分在平台筛选器里，一部分靠人眼判断。两边口径不一致时，筛出来的人未必达标。
确认这一步最容易断
运营想在实发前看一眼名单，但看完再回去，流程经常已经跑偏——要么名单被重算过，要么顺延补进了本来不该发的人。
02
接手之后，怎么跑
按你的条件筛，条件写下来而不是记在脑子里
类目、达人层级、指标门槛作为参数固化，每一轮都按同一套口径跑，换人接手不会变形。
三道去重：本地台账、平台侧已邀、本轮内部
关键是第二道——**在平台自己的筛选里确认「未邀请」**，搜得到才算真没邀过。只靠本地台账去重是覆盖不到的。
出预览清单，等你点确认
预览里带上每个人命中的条件和去重依据，你能看出来为什么是这些人。
照你确认的那一份发，不顺延补人
名单一经确认就钉死。中途有人不可用就少发一个，**绝不自动补上第 N+1 个** —— 补人意味着发给了一个你没看过的人。
发完回平台核对状态
实发结果回写台账，下一轮的第一道去重因此才是准的。
03
哪里必须停下来等人
- 实发永远需要人点确认，预览不等于已发
- 确认过的名单钉死，不重算、不顺延补人
- 达标口径（指标门槛）由你定，不由它自己放宽
怎么验收
- 抽查预览清单里的人，回平台确认确实是未邀请状态
- 实发数量与确认的名单逐个对上，不多不少
- 跑第二轮时，第一轮发过的人不应该再出现
04
口径从哪来
06
常见问题
它是怎么操作后台的？有 API 吗？
有开放接口的走接口；没有的部分用真实浏览器带着你已登录的会话去操作，路径和人手点的一样。两条路都要经过同一个审批闸。
会不会误发给不达标的达人？
达标口径是参数，筛选在预览阶段就已经完成，你看到的名单就是要发的名单。加上「确认后不补人」这条，不存在名单被悄悄替换的情况。
一次能发多少？
上限由你定。它不会为了跑满而放宽条件——宁可这一轮少发，也不发给一个没达标的人。