官网友情链接 wechatapi.net

微信机器人系统里，很多风险控制都会散落在不同模块。

规则系统检查风险。

任务创建时检查免打扰。

AI生成时检查人工状态。

群机器人检查冷却。

问题是：从任务创建到真正发送之间可能经过几秒、几分钟甚至更久。

期间客户状态可能变化。

所以任何客户可见消息在最终发送之前，都应该经过统一“发送前安全门”。

WechatApi 可以作为个人微信API接入层，负责最终消息发送。本地发送网关则在调用之前集中检查会话、客户、账号、内容、频控和任务版本。

一、为什么创建任务时检查一次不够

10:00创建AI任务。

客户当时正常。

10:00:03人工客服接管。

10:00:05AI生成答案。

如果没有最后检查：

仍然发。

所以必须以发送瞬间状态为准。

二、安全门可以检查什么

任务是否取消；
deadline；
会话是否人工接管；
客户免打扰；
服务保护；
消息是否撤回；
上下文版本；
账号健康；
发送频率；
内容版本。

全部集中。

三、一个具体例子

任务R100已经生成文本。

发送前：

conversation = human_handoff。

安全门返回：

DENY_HUMAN_ACTIVE。

任务状态：

cancelled_before_send。

不会真正调用WechatApi发送。

四、WechatApi 在这里的位置

WechatApi负责：

安全门通过以后执行动作。

业务系统不要让多个模块绕过安全门直接发。

统一出口非常重要。

五、人工消息是否也走安全门

可以走简化版。

例如：

账号健康；
关系是否有效；
权限。

但人工在明确权限下可能允许突破机器人频控。

策略不同。

六、硬规则和软规则

硬规则：

关系失效；
客户长期禁止营销；
任务取消。

绝对阻断。

软规则：

普通频控；
推荐发送时间。

可以由高权限业务动作覆盖。

七、内容审核版本

任务批准V3。

发送时发现content_version变V4。

安全门阻断：

VERSION_MISMATCH。

避免未审核内容发送。

八、客户跨账号去重

发送前发现同campaign已经从另一个账号成功触达。

阻断：

DUPLICATE_TOUCH。

这也是安全门一部分。

九、AI上下文版本

任务基于V20。

当前V22。

如果策略要求新消息必须重算：

阻断。

生成新任务。

十、群聊冷却

同群同规则还在冷却。

阻断公开发送。

但后台AI结果可保留。

十一、账号异常

规则、客户全正常。

但账号健康度critical。

发送门返回：

WAIT_ACCOUNT_RECOVERY。

不是直接失败。

十二、统一原因码

所有阻断返回结构化reason：

HUMAN_ACTIVE；
OPT_OUT；
EXPIRED；
CONTEXT_CHANGED；
RATE_LIMIT；
ACCOUNT_UNHEALTHY。

业务看板非常清楚。

十三、为什么统一网关比各模块自己检查好

规则系统可能忘记频控。

AI系统可能忘记免打扰。

统一安全门是最后一道兜底。

即使上游漏了一个判断，最终仍然能挡住。

十四、安全门本身要高可用

如果安全门服务挂了。

默认应该：

fail closed 还是 fail open？

客户可见高风险消息通常：

fail closed。

宁可暂缓，不要绕过风控。

十五、性能

安全门每条消息都会经过。

不能查询十几个慢数据库。

可以把关键状态：

会话；
免打扰；
账号健康

放高性能缓存。

但数据库仍是最终事实。

十六、日志

每次拒绝发送记录：

task；
reason；
状态快照。

以后能解释机器人为什么没回复。

十七、数据看板

安全门阻断数量；
人工接管；
免打扰；
频控；
版本冲突；
账号异常。

这些数据反映自动化边界是否合理。

十八、总结

个人微信二次开发里的自动回复链路越复杂，越不能依赖“每个模块都记得检查自己的风险”。

WechatApi 可以作为最终微信发送能力层，而本地系统应该在它前面建立统一发送安全门。

无论消息来自规则、AI、CRM还是补偿任务，真正发给客户之前都再次检查当前会话、免打扰、版本、频控、账号和任务状态。

这样上游即使出现延迟或状态变化，最后一刻仍然有机会阻止错误消息。

成熟的微信自动化，真正可靠的地方往往不是前面判断多聪明，而是最终发送之前还有一道绝不省略的安全检查。