选型会上最常问的一句：我们到底用官方 API，还是上第三方 RPA？
答案不是谁更「高级」，而是你的场景卡在哪。选错了，后面全是改造成本。
一句话对比
官方 API：规则清晰、生态正规，能力边界明确；很多团队会卡在外部客户群触达等场景。
第三方 RPA（如 QiWe API）：用自动化方式补齐官方不便覆盖的操作路径，适合外部群主动推送、部分群运营动作；属于第三方方案，稳定依赖设备在线、任务设计与使用习惯。
怎么选（务实表）
你的诉求 | 更常怎么走 |
|---|---|
内部应用、审批、通讯录、官方许可能力 | 优先官方 |
必须做外部客户群主动触达、群内运营自动化 | 评估 RPA/第三方 |
要和 SCRM/工单深度绑定 | 可能组合：官方管合规能力，RPA 补触达，中间层统一任务与映射 |
上 RPA 前要接受的现实
设备要在线、在群，任务调度要按号隔离
发送要有状态机，不能「调一下就当成功」
回调要快进快出，重活放后台
合规与客户体验：频率、内容、投诉路径要想清楚
文档为准：别凭想象对接未确认的参数
把 RPA 当成「万能官方升级版」，预期会落空；把它当成「特定场景的自动化通道」，才好评估 ROI。
组合架构怎么想
业务系统 / SCRM → 统一任务层（状态、去重、选号） → 官方能力（能走官方的走官方） → RPA 通道（外部群等触达）对业务侧暴露统一「发送任务」，底下走哪条通道可以替换，避免业务代码写死。
选型会上可以怎么拍板
开会别空辩「哪家更强」，直接拿场景清单打勾：
要不要外部客户群主动触达？要 → RPA 进入评估
内部审批/通讯录是否已有官方方案？有 → 官方继续用
团队能否接受「设备在线 + 任务状态机」运维？不能 → 先别上复杂群发
是否有统一中间层？没有 → 先做任务层，再接通道，避免业务写死某一侧
两周 POC 建议：选 1～2 个真实外部群，只跑文本通知 + 状态对账。跑不稳就别承诺「全公司群发」。
小结
官方 API 解决「正规能力怎么接」，第三方 RPA 解决「官方触达不到的自动化怎么补」。
先画清场景边界，再选型，比先买方案后改需求便宜得多。
方案说明见 QiWe API 官网
