中国象棋计算机博弈发展史研究报告

系统梳理中国象棋计算机博弈从 1980 年代到 2026 年的技术演进、代表引擎与社区生态。第十八章 engine-rule与引擎规则的工程化 → 第二十三章弈天棋缘与在线人机对战文化

☰ 目录

第十八章 engine-rule与引擎规则的工程化

18.1 规则的代码实现策略

在引擎中实现中国象棋的规则，需要解决多种复杂的边界情况。主要的规则实现策略包括：

1. 走法合法性验证：

引擎的着法生成器需要验证每一步走法是否符合中国象棋规则：

将帅不能面对面
将帅的活动范围限于九宫格
士的活动范围限于九宫格斜线
象的走法限于己方棋盘，不能过河，且需要避免塞象眼
马需要避免蹩马腿
炮的吃子需要在炮和目标之间有一个"炮架"
兵/卒未过河时只能前进，不能横走或后退；过河后可以前走或横走，但不能后退

2. 特殊规则处理：

长将： 同一方连续将军，将对方将帅移动后又回到原位。根据规则，长将是禁止着法。引擎需要检测这种模式并做相应处理。
长捉： 同一方连续以同一棋子威胁对方同一棋子。长捉也是禁止着法。引擎需要区分"长捉"和"长拦"、"长兑"等允许着法。
一将一捉： 一步将军、一步捉子交替出现。根据规则，这是禁止着法。
一将一闲： 一步将军、一步非威胁着法交替出现。根据规则，这是允许着法，将军方应变着。
二打一还打： 一方连续两次威胁着法，而另一方在中间有一次威胁着法的回应。引擎需要正确处理这种复杂循环。

3. 困毙（Stalemate）处理：

中国象棋中的困毙（一方无子可走且未被将杀）判定为负方。这与国际象棋中的"无子可动即和棋"规则不同。困毙检测需要引擎在搜索过程中正确处理缺乏合法走法的情况。

18.2 不同规则体系在引擎中的实现差异

亚洲规则和中国规则在循环着法的判定上存在以下差异：

规则类型	亚洲规则	中国规则
长将	禁止	禁止
长捉	禁止（但定义范围不同）	禁止
一将一捉	禁止	禁止
长拦/长兑	允许	允许（某些情况有争议）
二打一还打	打方变着	打方变着
将帅照面	禁止	禁止

引擎需要根据用户选择的不同规则执行不同的判定逻辑。通常，引擎通过UCCI选项让用户选择"亚洲规则"或"中国规则"。

18.3 规则实现中的常见陷阱

在引擎规则实现中，以下是一些常见的陷阱和边界情况：

1. 将帅照面的实现陷阱： 在某些环境下，将帅照面的检测需要特别注意——红帅和黑将处于同一列且中间没有其他棋子时，视为照面，这是禁止的。但是，如果在将帅照面的中间有棋子（即使是自己的棋子），则视为照面被阻断。

2. 炮的跳吃检测： 炮的跳吃需要精确检测"炮架"（炮和要吃目标之间的棋子）是否存在。炮架的检测逻辑是：炮与目标之间必须恰好有一个棋子（任何颜色）。这个逻辑在国际象棋中没有对应物，需要独立的实现。

3. 兵过河的边界情况： 兵过河后不仅可以前进，还可以横走。但是，兵过河后不能后退。兵在河界上的行为需要特别注意——一旦兵踏上了对方棋盘区域（第6-10行），即被视为过河。

4. 循环着法的棋谱记录： 在记录含有循环着法的棋谱时，需要特别标注每一步的类型（将军/捉子/闲着等），以便后续复盘时正确解析。

第十九章中国象棋棋谱编辑器与翻译对照工具

19.1 棋谱编辑器的功能演进

中国象棋棋谱编辑器从最早的纯文本格式发展到支持交互式的棋谱编辑和引擎分析。

文本编辑器阶段（1990年代）：

着法记录以文本格式保存（如中文数字：炮二平五、马8进7等）
缺乏图形界面支持
不能实时显示棋局状态

图形编辑阶段（2000年代）：

图形界面允许用户用鼠标拖拽棋子走棋
支持棋谱的实时显示和编辑
支持注释、变着、分支记录
支持棋谱的导入和导出（XQF格式等，XQF由象棋演播室创始并成为事实标准）

引擎集成阶段（2010年代至今）：

棋谱编辑器与引擎深度集成
可以实时调用引擎分析棋局
支持最佳走法显示、变化分析、深度搜索
在线编辑器可以在Web浏览器中运行

19.2 翻译工具与多语言支持

随着中国象棋的国际化发展，棋谱的多语言翻译工具变得重要：

着法翻译系统：将中文着法（如"马8进7"）翻译为英文格式（如"N2+3"）或其他语言的描述。
局面描述翻译：将局面评估描述（如"红方稍优"、"黑方胜势"等）翻译为其他语言的对应描述。
FEI（棋谱格式）的国际化：使中国象棋FEN和着法格式可以被国际象棋界理解。

19.3 棋谱传输与共享机制

中国象棋棋谱的传输和共享经历了从文本复制到云端同步的演进：

FEN协议的共享： FEN的一个重要应用是在网络上共享特定的棋局局面。通过网络链接中的FEN参数，可以分享精确的棋局状态。例如，一个共享的棋局链接可能包含如下格式的参数：

https://example.com/analysis?fen=rnbakabnr/9/1c5c1/p1p1p1p1p/9/9/P1P1P1P1P/1C5C1/9/RNBAKABNR w

云同步功能： 现代的棋谱编辑器支持云端保存和同步功能，用户可以在不同设备上访问自己的棋谱库。

19.4 象棋演播室（XQStudio）

象棋演播室（XQStudio）主界面——中国象棋领域最具影响力的免费打谱软件，由开发者董世伟（网名"过河象"）于1998年创作

象棋演播室（XQStudio） 由开发者董世伟（网名"过河象"）于1998~1999年间创作，最初发布于水木清华BBS。首个Beta版于1998年12月面世，1999年2月发布1.0正式版。软件完全免费，以Delphi（Pascal）编写，最终版本为1.63（约2008年），后于2008年由作者在NewSMTH开源全部源代码。

作为中国象棋领域最具影响力的打谱软件，XQStudio支持棋谱记录、多分支变着（树形变化树）、逐步行棋注释、局面搜索、自动播放、多棋谱同时管理等功能。其以二叉树的左孩子右兄弟方式存储着法树，支持从第一步起即录入变着，因此一个XQF文件可存储整本布局教材，而非单一对局。

象棋演播室的棋谱编辑界面——支持多分支变着、注释和局面搜索

XQF文件格式 是象棋演播室的原生格式，包含10字节文件头标识、32字节局面编码、64字节文件注释以及按红黑轮流记录的行棋数据。2001年4月，作者以"过河象"名义正式公布XQF 1.0格式规范。XQF格式后来被象棋桥、象棋巫师、东萍象棋网（dpxq.com）、棋谱收藏站等大量软件和网站支持，成为事实上的中国象棋电子棋谱标准，至今仍是象棋裁判员、棋谱编辑者和布局研究者的常用工具。

象棋演播室的棋谱管理与分析功能——软件仅476KB，绿色免安装，兼容Windows全系系统

19.5 象棋桥（CCBridge / xqbridge）

象棋桥（CCBridge）主界面——中国象棋棋谱管理系统，被誉为"世界上最全的中国象棋棋谱库"

象棋桥（CCBridge，全称Chinese Chess Bridge） 是一款免费的中国象棋棋谱管理系统，由个人开发者制作，早期版本可追溯至2000年代中期，是继象棋演播室之后中国象棋软件生态中最重要的打谱软件之一。软件以C++开发，支持Lua脚本扩展，原生格式为CBR/CBF（单局谱）/CBL（棋库），同时兼容XQF格式。

象棋桥的核心优势在于强大的棋谱管理能力：内置八大类（杯赛风云、布局棋库、大师棋路、古谱棋书、华山棋库、排局赏析、棋研探秘、象棋丛书）超30万局棋谱，支持XQF、PGN、MXQ、CHE、CCM、CBR、CBF、CBL等几乎所有主流棋谱格式互转。独创拼音/数字键盘输入法（如p2p5或6225对应炮二平五），支持UCCI引擎人机对弈与局面分析，可按盘面、子力、开局、棋手等多维度高速检索——100万局中搜索盘面仅需0.3秒。版本历程从1.x到2.x，最终定格于3.0.4正式版。

与象棋演播室相比，象棋桥更偏向棋谱数据库管理与综合训练平台，而演播室侧重于纯谱面记录与轻度分析。象棋桥在变着查看、多格式转换、引擎集成方面显著优于演播室，但后者因源码公开在二次开发领域影响深远。象棋桥至今仍是许多老棋迷整理、研究棋谱的常用工具。

象棋演播室的变着树管理功能——以二叉树方式存储着法树，支持从第一步起录入多路变着

第二十章总结：中国象棋引擎发展的深层规律

20.1 从"棋力"到"智能"的重新定义

中国象棋引擎的发展历程，本质上是从"怎么让电脑走得更快更准"到"怎么让电脑理解得更好更深"的转变。

第一阶段（1980s-1990s）：棋力=计算速度

在这个阶段，引擎的棋力几乎完全由计算速度决定。在评估函数和搜索算法相对简单的条件下，每秒钟能搜索的节点数直接决定了引擎的水平。

第二阶段（2000s-2010s）：棋力=搜索效率+评估质量

搜索算法（PVS、各种剪枝、置换表、并行搜索）和评估函数的优化使棋力不再仅由计算速度决定。一个搜索效率高、局面评估准确的引擎可以在更低的速度下达到更高的棋力。

第三阶段（2020s-至今）：棋力=数据+网络+搜索

NNUE时代的"棋力"是由训练数据质量、网络结构设计和搜索算法综合决定的。

20.2 未来的发展趋势

开源引擎与商业引擎的竞争

皮卡鱼的成功已经证明，开源引擎可以在棋力上超越商业闭源引擎。未来开源引擎可能进一步扩大优势，特别是在NNUE训练（需要大量GPU算力）这个领域，开源社区可以通过众包模式获取远超单个公司的计算资源。

全球化协作

中国象棋引擎的社区正在从"华人社区"向"全球化社区"转变。非中文使用者（特别是国际象棋社区的开发者）对皮卡鱼等项目的兴趣在增加，这可能会带来新的技术视角和贡献。

教育价值

中国象棋引擎作为计算机博弈教学案例的价值将更加凸显。皮卡鱼开源的代码库是一个极好的学习资源——它展示了现代搜索算法、神经网络评估、分布式测试等技术的综合应用。

20.3 为什么中国象棋引擎没有出现"Deep Blue Moment"

一个值得深思的问题是：为什么中国象棋引擎没有出现过像国际象棋Deep Blue那样具有全球影响力的"里程碑事件"？

原因分析：

缺乏大型企业的投入：IBM为Deep Blue投入了数千万美元；中国象棋从未获得过同等规模的商业或政府投资。
学术关注度较低：国际象棋在AI研究中具有深厚的学术传统，而中国象棋在计算机科学领域的学术论文数量远低于国际象棋。
市场价值不明确：在中国，象棋软件的直接商业价值相对有限，很难吸引大规模资本投入。
普及度差异：国际象棋在全球范围的普及度远超中国象棋。Deep Blue的胜利被誉为"人类智慧面对机器的里程碑"，吸引了全球关注。
时机差异：中国象棋引擎的棋力在2010年代超越人类特级大师时，AI技术已经进入"深度学习时代"，公众对机器在棋类上超越人类的关注度已经下降。
身份认同因素：中国象棋有丰富的传统文化内涵，"电脑下棋"的接受过程比国际象棋社区更缓慢。

然而，这种"没有Deep Blue"的局面也带来了一个独特的结果：中国象棋引擎的发展更加"草根化"、社区驱动的特征更加明显。它证明了一个社区在缺乏大资本支持下，通过开放协作和持续优化，同样可以创造出世界级的软件产品。

20.4 中国象棋引擎发展的深层规律

回顾三十余年的发展历程，我们可以总结出中国象棋引擎发展的几个深层规律：

规律一：算法进步 > 硬件进步。 在同等硬件条件下，搜索算法的改进（从Minimax到Alpha-Beta再到PVS+各种剪枝、从手工评估到NNUE）带来的棋力提升远超硬件代际更迭的影响。

规律二：开源协作 > 个人闭源。 皮卡鱼在短短两年多时间内达到的棋力超越了许多团队多年的闭源开发成果，证明了开源协作的效率优势。

规律三：数据 > 代码。 在现代NNUE时代，训练数据和云库数据的重要性已经超过了引擎代码本身。谁能获取更多、更高质量的局面评估数据，谁就能训练出更强大的神经网络。

规律四：社区 > 算法。 从更宏观的视角看，社区的组织效率决定了引擎进步的速度。一个活跃的、开放的技术社区远比一个天才开发者更能推动技术的长期发展。

规律五：国际象棋路线 > 自主研发路线。 与从零开始自主研发相比，"站在Stockfish的肩膀上"进行中国象棋适配，可以极大地降低开发成本并缩短开发周期。皮卡鱼的成功证明了这条技术路线的有效性。

规律六：标准化 > 分散化。 UCCI和UCI协议的标准化、FEN格式的普及、Fishtest框架的引入——每一次标准化都显著推动了引擎生态的发展。

第四卷专题研究

第二十一章计算机博弈规则的演进：长将长捉检测的技术史

21.1 规则复杂性的技术影响

中国象棋的循环着法规则（长将、长捉、一将一捉、一将一闲、二打一还打等）是引擎开发中最困难的技术挑战之一。与国际象棋的三次重复规则不同，中国象棋的规则需要区分不同类型的循环着法，并判断哪些是"允许着法"、哪些是"禁止着法"。

规则体系的版本演变：

中国象棋的竞赛规则在过去数十年中经历了多次修改：

中国象棋竞赛规则（1999年版）：由中国象棋协会颁布，是第一个系统化的现代竞赛规则。
亚洲象棋竞赛规则：由亚洲象棋联合会颁布，与国内规则存在差异，主要用于亚洲国际赛事。
中国象棋竞赛规则（2011年版）：对循环着法的定义进行了修订，进一步明确了"长将"、"长捉"等概念的判定标准。

不同规则体系下的关键差异包括：

"长将"的定义和判罚
"长捉"与"长拦"的区分
"一将一捉"的判定标准
"二打一还打"的循环处理

引擎实现的挑战：

对中国象棋引擎而言，完美实现循环规则具有以下困难：

局面历史记录：引擎需要记录走法历史以检测循环。这需要存储每一步走法的详细信息（包括吃子情况），而不是仅靠局面哈希。因为吃子后的局面即使与以前的局面哈希相同，由于规则限制（吃过子的棋不能立即被吃掉等），判罚可能不同。
着法分类：引擎需要判断每一步着法属于"将军"、“捉”、“拦”、“将”、"献"等不同类型。其中"捉"的判断最为复杂——它需要评估该走法是否在下一回合形成了对对方棋子的威胁性捕捉。这本质上是一个"小搜索"问题：需要模拟对对方每枚棋子的保护情况，判断该棋子是否会被吃掉。
递归循环检测：在长将长捉局面中，可能形成复杂的递归循环，需要精确的状态机来判定。例如，可能出现"红方长将→黑方应将→红方继续长将→黑方继续应将"的复杂循环。
规则冲突：当引擎使用的规则（如亚洲规则）与在线平台使用的规则（如中国规则）不一致时，可能出现"引擎走法正确但平台判定违规"的情况。这在高水平自动对局中尤其常见。

实现方案的演进：

早期的中国象棋引擎（如将族、棋隐）使用简单的重复局面检测——发现三次重复即判和。这种方法虽然简单，但与正式比赛规则存在偏差。从技术角度看，这是"偷懒"的实现方式，但对于棋力有限的早期引擎来说，规则精度对实战的影响不大。

中期引擎（如旋风、名手）开始引入着法分类系统。引擎会分析每步走法的类型，对"长将"和"长捉"着法赋予不同的处理策略。这些引擎的规则处理模块通常包含：

一个循环着法的状态机
可以识别"将"和"捉"的着法分类器
基于规则的判罚逻辑

现代引擎（如皮卡鱼）实现了更为完整的规则覆盖。皮卡鱼的循环规则处理经历了几次重大更新：

最初版本：基础的三重重复检测
2022-12-26版本：引入60步规则，完善三重重复检测
2024-08-31版本：更新规则逻辑——“如果重复着法序列中出现将军着法，则不再被认为是捉着法序列”

皮卡鱼还允许用户通过UCI选项选择不同的规则体系（亚洲规则/中国规则），以适应不同平台的需求。

21.2 亚洲规则与中国规则的差异及引擎适配

亚洲规则和中国规则在中国象棋循环着法的判定上存在以下主要差异：

差异一：长将的判定

两种规则体系都禁止长将，但在具体判定方式上存在细微差异。亚洲规则对长将的界定范围在某些情况下比中国规则更宽泛。

差异二：长捉的判定

亚洲规则与中国规则在"长捉"的定义上存在分歧。例如，当一方用同一个棋子连续威胁对方的多个不同棋子时，两种规则可能有不同的判罚。

差异三：一将一捉的判定

对于"一将一捉"（一步将军、一步捉子交替出现），两种规则的判罚可能不同。

引擎适配策略：

为适应不同平台的规则要求，现代引擎通常提供规则切换功能。皮卡鱼通过UCI选项允许用户选择"亚洲规则"或"中国规则"。这种灵活性使得同一个引擎可以在不同平台上正确运行。

第二十二章 Zobrist哈希与置换表的中国象棋适配

22.1 Zobrist哈希在中国象棋中的实现

Zobrist哈希是棋类引擎中最常用的局面哈希技术。其原理是：为每个棋子在每个位置上的每种可能状态分配一个随机数，然后将局面中所有棋子的随机数进行异或（XOR）运算，得到一个固定长度的哈希值。

在中国象棋中，Zobrist哈希需要适配以下特殊需求：

棋子类型：7种红方棋子 + 7种黑方棋子 = 14种棋子类型
棋盘位置：9×10 = 90个交叉点
将帅照面：照面状态需要额外编码，通常通过哈希值的特定比特位表示
走子权：轮到谁走棋需要编码
循环信息：某些引擎将部分循环信息编码进哈希值

Zobrist哈希的优势在于其增量更新特性：当移动一枚棋子时，只需要将新旧位置对应的随机数从哈希值中异或掉，再异或上新的随机数即可。这个特性使得每次走棋后更新哈希值的计算复杂度为O(1)，与棋盘大小无关。

22.2 置换表中的中国象棋特殊处理

置换表（Transposition Table）通过缓存已计算局面的搜索结果来避免重复计算。在中国象棋中，置换表的使用面临国际象棋中没有的挑战：

循环着法规则：国际象棋的置换表中，遇到相同哈希值的局面可以直接返回结果（因为三次重复意味着和棋）。但在中国象棋中，相同局面三次重复不一定代表和棋——可能是"两打一还打"或"一将一捉"等复杂情况。
将帅照面对称性：在中国象棋中，同一局面从红方视角和黑方视角来看可能具有不同的对称性（因为将帅的走法限制不同），这影响了置换表的命中率。
河界不对称性：同样的棋子配置在河界两侧可能具有完全不同的战术含义，因此"镜像位置"的评估值不能直接互换。举例来说，一个车在红方一侧控制河界，与车在黑方一侧控制河界，战术价值并不对等。

置换表的大小与性能关系：

置换表的大小对引擎性能有直接影响。过小的置换表会导致频繁的哈希冲突和条目替换，降低缓存效率；过大的置换表则浪费内存并可能降低缓存访问速度。典型的中国象棋引擎的置换表大小在64MB到256MB之间，大型引擎可能使用512MB或1GB。