官方「群机器人 / 消息推送」走的是 Webhook，不是群成员身份。这会带来两个硬限制：

1. 仅内部群可用，客户群（外部群）没有添加入口
2. 即使内部群能推消息，@userid 往往没有会话强提醒

要在客户群里出现可点击、可提醒的 @，消息必须由已在该群内的企业微信账号发出。下面按账号级消息接口来接。

接口模型和必要 ID

一次指定 @，至少要凑齐 3 个 ID：

不要用昵称、备注名做主键。重名、改名都会对错人。

统一调用形态（POST + JSON）：

POST /api/qw/doApi
Content-Type: application/json
X-QIWEI-TOKEN: YOUR_TOKEN

{
  "method": "/msg/sendText",
  "params": {
    "guid": "{{guid}}",
    "toId": "{{roomId}}",
    "content": "请核对今天下午的发货单",
    "isNoNeedRead": true
  }
}

这只是把文本打进群。真正的 @ 还要带「提到谁」。能用 QiWe API 时，在消息模块里把被 @ 成员的 userId 一并传入（文本或混合文本接口均可，以后者为准更常见）。

被 @ 的 userId 从哪取

有两种取法，第二种更稳。

1. 拉群成员列表
按 roomId 取成员，落地保存 userId。适合固定角色：群主、值班账号、对接人。

2. 从消息回调反查
客户在群里发言后，Webhook 会带发送者 ID 和 roomId。自动回复时 @ 这个发送者，不需要自己维护全量成员表。

回调处理伪代码：

def on_group_message(event):
    room_id = event["roomId"]
    sender_id = event["fromUserId"]
    text = event.get("content", "")

    if "对账单" not in text:
        return

    send_text_with_mention(
        guid=GUID,
        to_id=room_id,
        content="对账单已生成，请查看",
        mention_user_ids=[sender_id],
    )

mention_user_ids 对应你实际接口里的 @ 字段名（有的叫 atlist，有的放在混合文本节点里）。字段名以消息模块文档为准，逻辑不变：群 ID 走 toId，人 ID 走 @ 列表。

和官方机器人的差异

群发通知不要用 @all 代替指定 @。客户群里 @ 全员容易被屏蔽，也和「点名某个人处理」不是同一需求。

联调检查

1. 先发一条不带 @ 的群文本，确认 code == 0 且 isSendSuccess == 1
2. 再带单个 userId 发 @，看消息气泡是否出现蓝色 @ 名字
3. 用两个测试号验证：被 @ 的人是否有提醒，未被 @ 的人是否无提醒
4. 换一个未在群内的 userId，确认接口失败或 @ 无效，避免静默发错

常见失败：

• toId 填了人 ID，消息跑到私聊
• 只写了 @张三 字符串，没有传 userId，界面无真实 @
• 执行账号已退群，或目标 userId 不在该 roomId 里

总结

客户群指定 @ 做不到，是因为走了官方机器人通道，不是字段没配好。
用群内账号发消息：toId = roomId，同时传入被 @ 成员的 userId，再从回调里取发送者，就可以把 @ 接到自动回复里。