WebhockTransfer/.trae/documents/规则引擎逻辑重构计划.md

规则引擎逻辑重构计划：支持多级条件与流程编排

您说得非常对。目前的扁平化规则（单层 if-match-then-action）在处理“组合条件”时会导致规则数量爆炸，配置极其繁琐且难以维护。

核心问题：现在的结构是“单层匹配”，无法表达“先判断A，再判断B”的逻辑。 您的需求：

1. 第一层（事件分类）：先根据 event_define_no 判断业务类型（微信支付/退款/投诉），决定用哪个模板。
2. 第二层（渠道分发）：再根据 remark 判断归属（门店002/003），决定推给哪个渠道。

为此，我将对系统进行深度的逻辑重构，引入**“规则组（Rule Group）”和“条件链（Condition Chain）”**的概念，但为了保持用户界面的直观性，我设计了更符合您直觉的 “流程树（Flow Tree）” 方案。

方案设计：嵌套式规则引擎

1. 数据模型升级 (DB)

• ProcessingRule 表变更：
  • 新增 parent_rule_id (Integer, nullable): 允许规则嵌套。子规则只有在父规则匹配成功后才会执行。
  • 此变更实现了“树状结构”。

2. 核心逻辑升级 (Engine)

• 递归匹配：
  • 引擎首先查找所有 parent_id 为空的根规则。
  • 如果根规则匹配成功（例如 event_define_no == pay.wx_scaned）：
    • 执行根规则挂载的动作（例如：设置模板变量 pay_method="微信"）。
    • 继续检查其子规则。
  • 子规则（例如 remark == imcgcd03）匹配成功：
    • 执行子规则挂载的动作（例如：推送到 渠道003）。
    • 动作执行时，会继承父规则上下文中设置的变量（如模板ID或变量）。

3. 用户界面重构 (UI)

• 端点详情页：
  • 不再是扁平列表，而是树形展示。
  • 在每个规则卡片内部，增加“添加子规则”按钮。
  • 视觉上通过缩进或连线表示层级关系。
  • 支持拖拽排序（优先级调整）。

实施步骤

1. 数据库迁移：为 ProcessingRule 添加 parent_rule_id 字段。
2. 后端逻辑：重写 engine.py 的 process 方法，改为递归处理。
3. 前端交互：重写 endpoint_detail.html，使用递归模板渲染规则树。
4. 无损更新：编写 SQL 脚本或逻辑，确保现有数据平滑迁移到新结构（现有规则都视为根规则）。

这样，您的配置流程将变为：

1. 根规则：event_define_no == pay.wx_scaned
   • 动作：设置变量 pay_type="微信"（不需要指定渠道）
   • 子规则 A：remark == imcgcd02
     • 动作：推送到 渠道002（复用父级的模板设置）
   • 子规则 B：remark == imcgcd03
     • 动作：推送到 渠道003

这完美符合您的思维模型。