开元棋牌平台与棋牌AI策略研究实验环境

在开元棋牌平台上，几乎每一个新游戏的接入都是从同一个问题开始的：这套游戏的规则，写成人能看懂的文字容易，写成机器能跑的Environment却完全是另一回事。这篇文章想具体讲一下，从一段自然语言规则，到AI真正能训练的State、Action、Environment，中间到底发生了什么。

第一步：把文字规则拆成可判定的条件

规则说明书通常是叙述性的，比如"一方出完手牌即算获胜""某种特定组合可以优先于其他动作执行"。这类句子对人来说没有歧义，但对程序来说，每一句都要被翻译成可以用代码判断真假的条件：什么算"出完"，"优先"具体体现在判断顺序的哪一步。这一步做的是Natural Language Rules到Structured Rules的转换，本质上是把规则里所有隐含的判断逻辑显式地写出来。很多规则文本会省略一些"大家都懂"的细节，比如平局怎么算、极端局面（比如没有合法动作可走）怎么处理，这些细节在自然语言里经常一笔带过，但在Structured Rules里必须给出明确分支，不能有"未定义"的状态。

举个具体一点的例子会更容易讲清楚这一步在做什么：规则文本里"两家同时满足获胜条件时优先判定分值较大的一方"这类描述，看起来只是一句话，但落到Structured Rules里至少要拆成三个独立判断——怎么定义"同时"、怎么比较"分值"、以及分值也相同的情况该怎么处理。第三种情况经常是原始文本压根没提到的，只能靠团队内部讨论确定一个默认行为，并且要在文档里明确标注这是补充规则而不是原文规定。这类补充判断如果不显式记录下来，几个月后重新看Structured Rules的人根本分不清哪些是规则原文、哪些是当时临时拍板的默认值，后续想要追溯或者调整都会变得很困难。

第二步：定义Game State

规则结构化之后，下一步是决定Game State里到底要装什么信息。Game State要满足一个条件：拿着它加上规则，理论上就能推出接下来所有可能的走向。这意味着State不能只装"看得见"的信息，还要包含一些不直接展示、但会影响后续判定的内部信息，比如剩余牌堆的具体构成、某些还没揭晓的状态标记。State设计偏少，后面的State Transition会因为信息不足而没法正确推进；State设计偏多，会让Simulator变得笨重，也可能不小心把不该让AI直接利用的信息暴露出来。

实践中判断State设计是否够用，一个可行的做法是拿两局规则完全相同、但走向明显不同的对局，检查State序列在关键节点是否能被区分开——如果两个不同的局面在State表示里变成了完全一样的向量，说明这里漏了信息。另一个容易被忽视的选择是要不要把某些可以通过基础字段推导出来的信息也显式存进State，比如某种组合是否已经凑齐。理论上这类信息完全可以由AI自己从基础字段里推导出来，但推导过程如果足够复杂，直接把结果放进State能明显降低训练难度，代价是State变大、Simulator计算量上升，这是一个需要根据具体游戏权衡的工程选择，不存在放之四海而皆准的答案。

第三步：从Action Space到Legal Action

有了State，才能定义某一局面下"理论上可能出现的动作"，也就是Action Space。但Action Space往往是偏宽泛的全集，真正决定AI每一步能做什么的，是Legal Action——也就是在当前具体State下，过滤掉不满足条件之后剩下的那部分动作。这一步的实现质量直接决定了Simulator跑出来的对局像不像真实规则下的对局。规则里那些"某种条件下才允许""达到某个数量才能执行"之类的限定词，正是Legal Action判断逻辑里最容易漏掉的部分。

第四步：设计Reward，划定Episode边界

State和Action确定之后，还需要给AI一个学习信号，也就是Reward，以及一局游戏什么时候算结束，也就是Episode的终止条件。Reward看似只是"赢了给正分、输了给负分"，但稀疏的终局Reward往往不够用，需要在中间过程里加入一些过程性的反馈；而这些过程性Reward一旦设计得和真实目标不一致，就会让AI学会讨好Reward本身而不是学会真正有效的打法，这是另一个值得单独展开的问题。Episode终止条件也不只是"分出胜负"这一种情况，还包括平局、达到步数上限、双方都无法继续行动等边界情况，这些边界条件如果遗漏，Simulator可能会在某些局面下卡死，或者产出不符合规则的对局数据。

最后一步：拼成可以运行的Environment和Simulator

把Structured Rules、Game State、Legal Action、Reward、Episode终止条件全部实现出来之后，才算拼出一个完整的Environment，再由Simulator负责实际推进State Transition、产出一局一局的Episode数据。这个过程看起来是顺着往下走的线性流程，但实际做下来会发现，越到后面暴露出的问题往往来自越早期的疏漏——State少定义了一个字段，Legal Action的判断逻辑就补不上；Episode终止条件漏了一种边界情况，Simulator就可能在这种局面下产出错误数据而不报错。开元棋牌平台在处理新规则时，会刻意把这几步分开验证，而不是直接从规则文本跳到能跑的Environment，就是因为这个链条里任何一环出错，都不会在当时立刻显现，而是会在后面训练出来的策略里以很隐蔽的方式体现出来。

一个策略"能跑"和一个策略"表现好"是两件事，而"表现好"这个说法本身，如果不说清楚是在什么条件下测出来的，几乎没有意义。这篇文章想说清楚，为什么在开元棋牌平台上，Benchmark结果必须绑定规则版本、Opponent Pool和测试协议这三样东西，脱离这三样谈胜率是没法比较的。

规则版本不是小事

同一款棋牌游戏，不同版本之间的规则差异经常出现在一些容易被忽略的细节上：某种组合是否允许、某个特殊局面的判定优先级、平局的处理方式。这些差异对人类玩家来说可能只是"打法习惯不同"，但对AI来说，规则版本的每一处差异都可能对应Legal Action判断逻辑的不同分支。同一个模型，在规则版本A下训练、在规则版本B下测试，得到的胜率完全不能说明这个模型"强不强"，只能说明这两个版本的规则差异有多大。开元棋牌平台的做法是，每一次Benchmark测试都要先声明清楚用的是哪一个规则版本，版本变了，历史结果就不能直接拿来比。

这里容易踩的一个坑是规则版本号忘了随实现改动一起更新——工程师改了一处Legal Action判断逻辑，觉得只是"修了个小bug"，没有意识到这个改动其实等价于切换了规则版本，于是新旧代码共用同一个版本号跑Benchmark，结果两批数据混在一起分析，谁也说不清某次胜率变化到底是模型变强了还是规则判断变了。开元棋牌平台的做法是把规则版本号和Structured Rules的具体实现做绑定校验，只要判断逻辑相关的代码发生变化，版本号必须跟着变，否则测试流程会直接报错拒绝继续跑，避免不同规则实现下产出的数据被当成同一批处理。

Opponent Pool决定了胜率这个数字在测什么

胜率从来不是一个策略的固有属性，而是这个策略相对于某一批对手的相对表现。Opponent Pool里如果全是风格接近、水平接近的对手，测出来的胜率会偏乐观；如果掺杂了专门针对某类策略设计的对手，胜率可能会明显下降。同一个模型面对保守型对手池和面对激进型对手池，胜率可以有相当大的差距，这不是模型变了，而是分母变了。所以在报告一个Benchmark结果的时候，这个结果只有知道Opponent Pool以后才有意义——不说清楚对手是谁、对手的策略分布是什么，单独一个胜率数字基本没法用来做判断。

另一个容易被忽视的问题是Opponent Pool的构成方式本身也需要设计，而不是随手拿几个历史checkpoint拼凑起来。如果Opponent Pool里全部来自同一条训练脉络的历史版本，测出来的胜率本质上只反映了"打自己过去的版本打得怎么样"，遇到完全没见过的风格照样可能一败涂地——这种自己打自己的Opponent Pool容易产生虚高的胜率假象。比较扎实的做法是刻意在Opponent Pool里保留几类风格差异明显的对手，包括一些专门设计用来放大某类已知弱点的针对性对手，这样测出来的胜率才更接近这个策略真实的稳健程度，而不是只在一个封闭的小圈子里打得漂亮。

测试协议里藏着更多容易被忽略的变量

除了规则版本和Opponent Pool，测试协议本身也有几个必须固定的变量：Episode数量够不够多，少量Episode跑出来的胜率波动可能很大，几十局和几千局的结果置信度完全不是一个量级；随机种子会影响发牌顺序等随机过程，不固定种子的话，同一个模型两次测试就可能跑出不同结果；还有超时规则，如果对超时之后判负和判和的处理方式不一致，也会系统性地影响胜率统计。这些变量单独看都不起眼，但只要有一个没固定，测试结果就失去了复现的基础。这些变量记录起来的成本并不高，通常只需要在每次Benchmark运行时把Episode数量、随机种子、超时判定方式和前面提到的规则版本、Opponent Pool构成一起写进一份运行元数据里，但如果一开始没有养成这个习惯，等到需要复现某次结果、或者需要解释两次测试为什么胜率不一样时，往往已经找不回当时具体用的是什么条件了。

同一个模型，不同测试条件下可能像换了一个模型

把上面几点合起来看会更清楚：同一个训练checkpoint，如果分别在旧规则版本、小规模Opponent Pool、几十局Episode的条件下测一次，再在新规则版本、更大更均衡的Opponent Pool、上千局Episode的条件下测一次，两次报出来的胜率完全可能出现明显差距。这不代表模型退步或者进步了，只代表这两次测试根本不是在测同一件事。这里先不要看最终Win Rate——单独一个数字脱离了规则版本、Opponent Pool和测试协议，既没法和别的模型比，也没法和这个模型自己上一次的结果比。

Benchmark的意义在于可复现，不在于好看

在开元棋牌平台的Benchmark体系里，固定规则版本、固定Opponent Pool、固定测试协议不是为了让流程显得规范，而是这三样东西一旦固定下来，结果才具备横向比较和纵向追踪的基础：可以拿新模型和旧模型比，可以拿这个月的checkpoint和上个月的比。反过来，如果每次测试条件都在变，Benchmark报出来的所有数字都只是孤立的快照，没有办法沉淀成对策略真实水平的判断。

强化学习有一个特点，会把这件事的风险放得很大：它不会去猜测试环境"应该"是什么样，它只会盯着训练环境实际给出的Reward和State，找到能把Reward拉到最高的那条路径。如果这条路径依赖的是环境实现里的一个漏洞，AI照样会学，而且往往学得比学"正确打法"更快。这篇文章想具体讲几种常见的环境实现错误，以及它们是怎么被RL利用成一整套只在错误环境里成立的策略的。

Reward Shaping错误：奖励了不该奖励的事

Reward Shaping本身是为了缓解稀疏Reward的问题，在终局输赢之外，给一些中间过程加上引导性的分数，比如某种局面进展给一点小奖励。问题在于，这类中间Reward一旦和真正的获胜目标不完全一致，就会给AI留出一条薅Reward而不是赢棋的路径。比如某个中间奖励本意是鼓励某种推进节奏，但如果实现上允许AI通过反复触发这个中间状态来重复拿分，AI大概率会找到这条路径，然后把大量精力花在刷这个中间Reward上，而不是提升真正的终局胜率。这类问题不容易在训练曲线上第一时间发现，因为累计Reward看起来在稳定上升，只有回头看具体对局记录才会发现AI在做一些奇怪的重复动作。

工程上一个比较有效的排查手段，是把每个Episode里各类中间Reward的累计贡献和终局Reward的贡献分开统计，而不是只看总Reward曲线。如果发现某类中间Reward在总Reward里占的比例持续走高、甚至逼近或超过终局Reward本身的量级，这通常是个危险信号，说明AI很可能已经把优化重心转移到刷这个中间信号上，而不是真正冲着赢棋去的。开元棋牌平台在训练流程里会定期抽取一批高Reward但胜负结果一般的Episode做人工回放检查，专门找这种Reward贡献和实际胜负脱节的情况，这比单纯盯着一条总Reward曲线更容易提前发现问题。

State遗漏信息：AI学会了利用漏洞而不是读懂局面

如果Game State的设计遗漏了某些本该影响判断的信息，比如某个应该体现在State里的标记没有体现，AI并不会因此变笨，它会转而去学习State里那些本不该有区分度、却因为实现问题产生了区分度的模式。举例来说，如果发牌或者摸牌的随机过程实现得不够干净，在State里留下了某种可以被观察到的规律，AI可能会学会利用这种规律去预判本应是随机的信息，训练出来的策略看起来胜率很高，但这个胜率完全建立在这个实现漏洞上，一旦换成随机性实现正确的环境，这部分优势会直接消失。

Legal Action判断错误：合法性边界成了策略空间的一部分

Legal Action的判断如果有错，比如把本不该允许的动作错误地标记成合法，或者在某些边界局面下动作合法性判断出现遗漏，RL会毫不犹豫地把这些本不该存在的动作纳入自己的策略。因为对RL来说，只要环境允许执行、执行完能拿到更高的累计Reward，这个动作就是有效的，它不会去判断这个动作在真实规则下是不是合法。这样训练出来的策略，一部分招法可能根本没法在规则正确的环境或者真实对局里使用，因为对手环境根本不允许这样的动作存在。

这类问题在局面数量较少、边界情况集中的场景里格外容易出现，比如一局游戏进行到最后几步、可选动作本身就所剩无几的时候，Legal Action的判断逻辑往往需要额外处理"资源耗尽后是否还有合法动作"这类特殊分支，实现时如果图省事直接复用了中局的判断逻辑，很容易在残局阶段错误地放行本不该存在的动作，或者反过来把本该合法的动作误判成非法。由于残局本身出现的频率相对较低，这类Bug可能要跑上相当数量的Episode才会通过统计上明显异常的胜率被发现，排查起来往往比中局阶段的Legal Action错误更耗时。

为什么这类问题特别难发现

这几类问题有一个共同点：从训练曲线上看，往往一切正常，甚至表现得比预期更好，因为RL确实在优化目标函数，只是这个目标函数背后的环境和设计者以为的环境不完全一致。这种偏差通常要等到把模型放到另一个环境实现、或者放到Benchmark的固定测试条件下重新评估，才会暴露出胜率明显下滑，或者具体对局里出现明显不合理的动作。这也是为什么环境正确性不能只在开发阶段验证一次就完事，而需要在整个训练链条里被反复对照检查。

环境是训练链条的地基

Reward Shaping、State设计、Legal Action判断，这些环境实现细节看起来是工程问题，离策略和智能这些词很远，但实际上它们才是决定AI最终学出什么策略的根本因素。开元棋牌平台在环境实现上花的精力，很大一部分正是用来堵这些容易被RL利用的漏洞，因为一旦环境本身有问题，不管上层用什么训练算法、调多少超参数，学出来的都只会是一套只在这个错误环境里成立的策略，而不是能在规则正确的环境或者真实对局中站得住的打法。