一套引擎跑九种玩法：棋牌规则引擎的抽象设计

“九种玩法要不要九个AI”是个伪问题：策略能力在牌类之间可迁移的部分有限，真正的成本差异在规则层——每个玩法的合法性判定、结算、流局处理都是独立的工程量。规则抽象做得好，新增玩法是配置加少量适配；做不好，每加一个玩法就是把整套系统复制一遍。

牌张编码必须在上游统一：扑克系用花色前缀加点数（S黑桃、H红桃、D方片、C梅花，如S13为黑桃K），麻将用花色加rank的tile id。统一编码的价值在下游：动作接口、事件流、审计日志、特征工程全部复用同一套词表，跨玩法的组件不需要任何转换层——转换层是隐性维护成本的温床。

// 扑克系：花色 + 点数（A=1 ... K=13）
"S13"  // 黑桃K
"H7"   // 红桃7
"D2"   // 方片2
"C11"  // 梅花J
// 麻将系：玩法前缀 + tile id（花色*9 + rank）
"scmj:36"  // 四川麻将 4筒
// 动作：所有玩法同一结构
{ "type": "discard", "tile": "scmj:36" }
{ "type": "play", "cards": ["S1","S10","S11","S12","S13"], "combo": "straight_flush" }

规则层的正确形态是声明式配置而不是if-else代码：番型表（牌型、番数、封顶）、结算参数（自摸加番、杠开、包牌）、流局规则（荒庄、听牌罚则、逃跑处理）各自独立成配置项，引擎按配置解释执行。地方细则的绝大多数差异——血战到底的缺门、上海麻将的计番细节、掼蛋的进贡还贡——都能落进这套配置，不需要改引擎代码。

策略模型必须只面对“合法动作集合”，不感知规则细节：规则引擎把当前局面翻译成候选动作列表加特征视图，模型在候选内打分，选中的动作再由规则引擎校验执行。这条接口是九种玩法（ddz2/ddz3/ddz4/shmj/scmj/gdmj/guandan/shengji/slots）共用的关键——换玩法换的是规则配置与动作生成器，模型侧只按玩法加载参数。

解耦不到位的表现是模型代码里出现玩法专属字段，那是一年后维护噩梦的起点。审查标准很具体：给模型喂特征的代码里出现任何玩法名字，就是解耦失败的信号，应当在合并前被拦下。

对外承诺“地方规则定制2-4周交付”，底气全部来自这套抽象：需求确认后，工程量收敛为规则配置编写、结算用例补齐、AI适配验证三段，配置与用例都能在既有玩法基础上增量完成。2-4周的口径意味着新玩法上线不必排进半年后的版本——这是中小团队选AI供应商时，最该写进合同验收的一项。