聊到微信群管理机器人，“自动拉群”是被点最多的需求，但大多数实现我都觉得做反了：把拉群当成一次接口调用——客户通过好友，机器人立刻发出群邀请，完事。结果呢？客户还不知道你是谁，就被拖进一个群里，第一反应是退出或者屏蔽；更有甚者机器人一天之内把同一个客户拉进三个群，第二天收获一个投诉。

问题出在哪？出在把“拉群”看成了动作，而它实际是一条链路：客户咨询 → 通过好友 → 打标签分层 → 在对的时机发出邀请 → 进群后承接。 “拉”只是中间一秒的接口调用，前面每一步的判断和后面的承接，才决定这个群留下来的是客户还是退群率。

这篇把这条链路完整讲一遍：每个环节怎么做、容易错在哪、风控卡点在哪。代码照例给流程骨架，策略比代码值钱。

先交代能力底座。我的机器人通道走 WTAPI——基于 iPad/Mac 协议的微信机器人接口服务，把消息、好友、群、朋友圈这些能力做成标准 HTTP API。说直白点：你的程序调用它给的网址，就能用这个微信号通过好友、打标签、邀请进群、设群公告，扫码登录、掉线重连这些协议层的活它来干。链路上的每个环节，都对应它文档里的具体接口模块。

链路全景：四个环节，各自的坑

四个环节里，最被低估的是第二个。展开说说。

分层：不筛选的拉群等于自杀式运营

我见过最多的翻车，是“新好友一律拉群”。客户分几种：来问价的、来售后的、同行卧底的、随缘加的。不加筛选全拉进同一个群，等于把你的价格体系和客户名单摊开给所有人看。

所以拉群的前置动作永远是打标签——而标签接口有一个必须刻进脑子里的细节：给好友打标签是覆盖语义，不是追加。调用一次打标接口，写入的就是这位好友的最终标签集，漏传一个原有标签，它就没了。正确写法永远是先读现有标签、合并新标签、再整体写回。这个语义踩过一次的人都不会忘，没踩过的建议现在就记住。

分层之后，拉群变成了“只对打了某类标签的人发出邀请”：售后咨询的人进售后群，买了课的人进课程群，报名活动的人才进活动群。群是分层的产物，不是新好友的默认待遇。

时机与节奏：两个必须克制的点

第一是邀请时机。通过好友后立刻拉群，体验极差。我的做法是先完成一次真人感的破冰——发一句跟客户来意相关的话，等客户回复之后再邀请。机器人视角这只是多一步状态判断，客户视角这是“先聊了两句才被拉群”和“扫码即进群”的区别。

第二是拉人节奏。建群和邀请都受风控约束，官方文档里对群发类能力明写了“请遵守风控频次”。落实到设计上就两条纪律：分批、间隔——邀请任务进队列分批执行，批次之间留随机间隔，而不是一口气把两百个人全塞进去。还有一个容易被忽略的硬约束：创建群聊时最少要选择两位好友，这是接口层的规则，单人群是建不出来的，业务流程里要按“凑人”设计。

争议问答

Q1：拉群都自动化了，还要人工干预什么？
自动化负责“标准路径”：识别来意、打标、按策略邀请。但两类情况必须留给人工：拿不准来意的新好友（宁可先不拉，等聊清楚），和批量异常请求（一天之内同一批头像相近的号申请好友，大概率是营销矩阵，拉进群是引狼入室）。自动化的价值不是替代判断，是把判断集中在少数关键点上。

Q2：进群之后该用什么触达，欢迎语还是群公告？
两个都用，但分工明确。欢迎消息解决“进群前三分钟”：一句欢迎加一句群规提示，即时但克制，一条就好——连发三条欢迎语和刷屏没有区别。群公告解决“长期承接”：群是干什么的、有什么规则、找谁求助，写在公告里，新成员随时能看到。公告还有个好处是不占聊天流——它待在公告位，不会像消息一样把正常聊天冲掉。这两类能力在平台文档的群聊接口模块里都有对应接口，公告只有群主或管理员能设置，机器人号本身得有管理员身份。

Q3：客户被拉进群后一直不说话，链路算成功吗？
算成功了一半。进群只是承接的开始，真正的指标是“进群后 48 小时内是否产生第一次有效互动”。所以我的做法是给承接装上观测：进群事件回调记一笔，第一次发言再记一笔，中间的流失就是你要优化的对象——多半是欢迎语写得差或者群公告没说清这个群的价值。

Q4：链路上这些接口去哪核对？
好友申请回调与通过、标签读写、建群、邀请进群、群公告，全部在平台文档站的对应模块里。建议动手顺序：先把回调收好友申请验通（收得准，链路才成立），再接标签和邀请，最后补公告。每接一个环节都用 filehelper 或者自己的小号先验一遍，别在真实客户身上调试。

流程骨架

代码只表达链路的环节顺序与状态判断，话术、队列、存储按业务补齐（代码仅做逻辑参考，正确代码请对照 API 文档调用测试）：

# WTAPI 接口平台 | 文档: https://weiti.apifox.cn
# 本文依赖:
#   - 好友申请回调与通过: 消息订阅收发 + 联系人/群聊接口模块
#   - 打标签: 标签接口 (覆盖语义! 先读现有标签, 合并后整体写回)
#   - 邀请进群: 群聊接口「邀请/添加 进群」; 建群时最少需要两位好友(文档原文)
#   - 进群承接: 设置群公告(需群主/管理员身份) + 单条欢迎消息
# 下一步: 先用小号跑通"申请→通过→打标→邀请"四步, 再谈批次节奏
# 官网: www.chuapi.com

def on_friend_request(new_friend_wxid, apply_msg):
    """好友申请回调线程。"""
    # 反例: 秒通过 + 秒拉群 —— 机器人特征拉满, 客户视角"扫码即被拖群"
    accept_with_natural_delay(new_friend_wxid)

    intent = classify(apply_msg)                  # 按申请留言初判来意
    if intent is None:
        queue_for_human(new_friend_wxid)          # 拿不准的留给人工, 宁可不拉
        return

    # 标签是覆盖语义: 必须读-合并-写回, 直接写新标签会把旧标签冲掉
    existing = read_labels(new_friend_wxid)
    write_labels(new_friend_wxid, existing | {intent.tag})

    queue_welcome(new_friend_wxid)                # 先破冰, 不发邀请
    # 反例: 通过好友立刻发群邀请 —— 时机错误, 退群率最高的做法

def on_first_reply(wxid, reply_text):
    """破冰得到回复后, 才进入邀请环节。"""
    if confirm_intent(wxid, reply_text):
        enqueue_invite(wxid, group=group_for(wxid))
        # 邀请任务进队列分批执行: 批次之间留随机间隔, 不做瞬时批量

骨架里的两个“反例”注释是这篇真正想留下的东西：秒拉群和直接写标签，是自动拉群里事故率最高的两个写法，都是能靠一行顺序调整避免的。

1. 本周就能做：把“申请留言分类 → 打标签”这两步跑起来，拉群先不动——分层做对了，后面每一步都顺。
2. 第二步：接邀请队列，用自己的小号验证“读-合并-写回”的标签流程，确认旧标签没被冲掉。
3. 第三步：补进群承接（公告 + 单条欢迎语），给“进群后首次互动”装上统计，两周后回头调话术。