"听懂"不是让机器人理解自然语言的每个字，而是让它能识别用户说的话对应哪个业务操作。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 含"查订单"→ 指令 QueryOrder；content 同时含"退款"和订单号 → 指令 CreateRefund；匹配不到走默认回复——用 Eyun 的 sendText 发"抱歉，暂时听不懂哦"。sendText 的具体参数格式可以直接查 Eyun 开发文档。大白话讲，规则引擎是指令翻译器——用户说"查订单"，它翻译成"执行 QueryOrder 指令"。

第3层：业务指令执行层

这一层是真正干活的地方。规则引擎输出指令 → 路由到对应执行器 → 调业务系统 API 拿结果 → 调 Eyun 的 sendText 发回用户。

按照 Eyun 开发文档的规范，sendText 必须传 wId（Eyun 实例 ID）、toUser（接收者 wxid）、content（消息内容）三个参数，缺一个都发不出去。大白话讲，业务执行器就是办事员——规则引擎说"去查订单"，执行器就真去查。

3层架构对比表

代码：3层框架骨架

@app.route("/eyun/webhook", methods=["POST"])
def cb():
    data = request.get_json()
    threading.Thread(target=handle, 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 开发文档。