官网友情链接 wechatapi.net

个人微信二次开发系统规则数量增加以后，很容易出现“规则互相打架”。

全局规则说：

出现“退款”必须转人工。

账号规则说：

普通售后允许AI。

群规则又说：

该群所有问题优先机器人回答。

最终客户在某个群里问退款，到底执行哪一个？

如果系统只是按照“最后保存的规则”处理，很快会失控。

所以微信机器人需要明确的规则优先级和继承模型。

WechatApi 可以作为个人微信API接入层，把账号、群聊、客户和消息上下文带入业务系统。本地规则引擎则按照全局安全规则、业务线规则、账号规则、群规则和客户状态逐层计算最终策略。

一、不是所有下级规则都能覆盖上级

全局安全规则：

退款必须人工。

群运营不能配置：

退款自动回答。

这类规则属于：

hard_policy。

下级不能突破。

二、可以设计规则层级

系统安全；
租户全局；
业务线；
账号组；
账号；
微信群；
客户/会话临时状态。

从上到下逐层继承。

但不同字段有：

可覆盖；
不可覆盖。

三、一个具体例子

全局：

高风险禁止AI自动发送。

客服账号组：

普通售后AI候选。

账号A：

夜间AI关闭。

群G100：

普通FAQ允许自动。

客户C：

当前人工接管。

最终客户C在G100发普通FAQ：

人工接管优先。

机器人不发。

说明临时会话状态可以覆盖普通自动化，但仍然不能突破安全策略。

四、WechatApi 在这里的位置

WechatApi提供：

account_id；
group_id；
customer；
message。

规则引擎根据这些维度找到对应配置。

五、规则计算应该输出最终策略快照

例如：

reply_mode = human_only；
reason = active_handoff；
applied_rules = [global_v2, account_v5, group_v8, session_state].

这样可解释。

六、冲突规则需要检测

同一级：

R100说自动回复。

R101说转人工。

条件又完全重叠。

发布前提示：

conflict_detected。

不要等线上随机决定。

七、优先级要显式

例如：

risk = 100；
human_handoff = 90；
service_rule = 50；
faq = 20。

或者使用结构化层级。

关键是不能依赖数据库查询顺序。

八、账号规则继承

50个账号不需要复制规则。

客服组统一。

账号只覆盖特殊项。

这和多账号配置继承类似。

九、群规则

活动群允许活跃机器人。

售后群人工优先。

群规则继承账号组安全边界。

十、客户级状态

客户免打扰；
投诉保护；
人工接管。

这些属于动态状态。

每次执行时读取。

不是静态规则配置。

十一、规则版本

最终动作记录：

effective_policy_version。

以后知道当时哪套组合生效。

十二、灰度

新规则只对部分账号生效。

继承系统还要理解：

灰度版本。

不要让一个账号同时命中V1、V2。

十三、回滚

账号规则V5异常。

回V4。

群规则仍然在原层级继承。

不需要重新配置所有群。

十四、规则删除

删除账号覆盖。

结果应：

恢复继承上级。

不是功能直接变空。

后台明确显示：

“已恢复默认”。

十五、解释日志

机器人没有回复。

业务人员看到：

人工接管状态优先级高于群FAQ规则。

这比“规则未触发”更清楚。

十六、数据看板

冲突规则；
覆盖规则；
账号自定义；
群级覆盖；
被安全策略阻断次数。

帮助治理。

十七、权限

安全层只允许管理员。

业务线主管维护业务规则。

群运营只能配置允许覆盖的字段。

不能随意突破上级边界。

十八、总结

个人微信二次开发系统规则越来越多以后，真正难的已经不是“能不能配置一条自动回复”，而是不同层级的规则怎样同时存在又不互相打架。

WechatApi 可以把账号、群、客户和消息上下文带入规则引擎。

本地系统通过规则层级、硬策略、可覆盖字段、冲突检测和最终策略快照，让全局安全、业务线、账号、群和人工状态形成稳定优先级。

只有规则继承关系清晰，微信机器人才能在几十个账号、几百个群、上百条规则同时运行时仍然知道到底应该听谁的。