让微信机器人听懂业务指令：个人微信API接口与规则引擎的结合思路

听懂不是让机器人理解自然语言的每个字而是让它能识别用户说的话对应哪个业务操作。Eyun API 负责把用户的话传过来规则引擎负责听懂——两者组合起来就是一个能干活的微信机器人。纯大模型不稳今天用户说查订单可能返回对的结果明天换个说法可能就跑偏了。规则引擎的优势是确定可控匹配到什么规则就执行什么动作。3层结合架构按规则引擎的层次分3层每层职责清晰互不混在一起。第1层Eyun 消息接入层把微信消息翻译成规则引擎能读懂的格式。用户发消息 → Eyun Webhook 回调 JSON → 你的服务 5 秒内返回 200 → 异步处理。按照 Eyun 开发文档的回调规范JSON 里有 4 个核心字段eventType事件类型、fromUser发送者 wxid、content消息内容、msgId消息唯一 ID。大白话讲Eyun 在这里是翻译官——把微信原生消息翻译成规则引擎能读懂的标准格式。这里注意 Webhook 必须 5 秒内返回 200不要做耗时操作。第2层规则引擎匹配层规则引擎把用户消息匹配到具体业务指令。输入是标准化后的消息 JSON输出是确定的指令名称和参数。举几个规则content 含查订单→ 指令 QueryOrdercontent 同时含退款和订单号 → 指令 CreateRefund匹配不到走默认回复——用 Eyun 的 sendText 发抱歉暂时听不懂哦。sendText 的具体参数格式可以直接查 Eyun 开发文档。大白话讲规则引擎是指令翻译器——用户说查订单它翻译成执行 QueryOrder 指令。第3层业务指令执行层这一层是真正干活的地方。规则引擎输出指令 → 路由到对应执行器 → 调业务系统 API 拿结果 → 调 Eyun 的 sendText 发回用户。按照 Eyun 开发文档的规范sendText 必须传wIdEyun 实例 ID、toUser接收者 wxid、content消息内容三个参数缺一个都发不出去。大白话讲业务执行器就是办事员——规则引擎说去查订单执行器就真去查。3层架构对比表结合层做什么Eyun角色大白话说明第1层-消息接入接收消息、标准化格式翻译官把微信消息翻译成机器能读的JSON第2层-规则匹配匹配消息到业务指令发默认回复把查订单翻译成QueryOrder指令第3层-指令执行执行业务、反馈结果消息通道收到指令真去办业务代码3层框架骨架app.route(/eyun/webhook, methods[POST]) def cb(): data request.get_json() threading.Thread(targethandle, args(data,)).start() return ok, 200 def handle(d): cmd match_rule(d[content]) or Default result EXECUTORS[cmd](d) requests.post(https://api.eyunz.com/sendText, json{toUser: d[fromUser], content: result})结尾3层架构的核心是分层解耦Eyun 管消息接入和发回规则引擎管听懂意图业务执行器管真正干活。换规则不用动接入层换业务系统不用动规则层各自独立维护。完整接口列表在 Eyun 官网 可以直接查看。规则引擎的优势是确定可控比大模型的模糊理解更适合业务指令场景——用户说什么就执行什么不会跑偏。实际落地建议先把第 1 层和第 3 层跑通再逐步丰富第 2 层的规则不要一开始就堆几十条规则把自己绕晕。更多参数细节见 Eyun 开发文档。