第三十章 中国象棋计算机博弈的文化遗产

30.1 历史的传承

从1989年将族在伦敦首次夺冠，到2026年皮卡鱼持续领跑开源引擎，中国象棋计算机博弈已经走过了近四十年的历程。这四十年间，我们看到了：

• 技术的演进：从几十行汇编代码到数百万行的C++神经网络系统
• 棋力的飞跃：从业余初级的走一步算一步到超越人类极限的精确计算
• 生态的成熟：从单打独斗的孤独程序员到全球协作的开源社区
• 数据的积累：从零散的手工棋谱到十数TB的云端残局数据库
• 标准的建立：从各自为战的数据格式到统一的UCCI协议和FEN标准

30.2 未被记录的历史

在编写本报告的过程中，我们深切感受到的一个问题是：中国象棋计算机博弈的很多历史正在消失。

• 早期棋中论坛的许多精华帖随网站改版而消失
• 多个早期引擎的官方网站已经打不开
• 部分作者的联系方式已经失效
• 很多技术决策背后的"为什么"已无从考证
• 许多引擎的对局棋谱和测试数据已经遗失
• 早期商业引擎的销售数据和用户反馈已无法追溯

本报告是对这一历史的有意记录和初步整理。但我们深知，这份报告只是一个起点。未来的研究者如果能够找到更多的第一手资料——包括作者访谈、论坛快照、源代码历史、比赛实录——将能够绘制出一幅更为完整的图景。

30.3 从"棋软"到"文明"：一个知识共同体的诞生

当我们将中国象棋引擎的发展放在更宏大的历史视角下审视时，我们会发现：这不仅仅是一个关于棋类软件的故事，更是一个关于知识共同体的诞生和成长的故事。

这个共同体由以下要素构成：

• 知识：从Shannon的Minimax到NNUE神经网络，跨越半个多世纪的理论积累
• 工具：从DOS到云计算、从软盘到GitHub，不断进化的开发和协作工具
• 规则：从UCCI协议到Fishtest测试标准，被社区共同遵守的技术规范
• 文化：从棋中论坛的帖子到GitHub的Pull Request，知识分享和协作的社区文化
• 价值：开放、共享、追求卓越——这些价值观推动着社区不断前进

这个共同体证明了一件事：一群散布在全球各地、使用不同语言、拥有不同背景的人，可以通过互联网和开源工具，共同创造一个超越任何个人或机构能力的知识产品。

这就是中国象棋计算机博弈留给未来的最宝贵的文化遗产。

---

附录

附录A：引擎发展总年表

附录B：主要引擎技术参数对比

B.1 跨代引擎技术演进对比

中国象棋引擎在过去三十多年中经历了多代技术变革。以下从技术架构角度对比各个时代的代表性引擎：

注：跨代对比显示了一个清晰的趋势——每代引擎在搜索深度上大约翻倍，棋力提升约200-400 ELO。NNUE时代的到来使得评估函数从几十个人的手工参数进化到2000万参数的神经网络，这是质的飞跃。同时，开源模式（皮卡鱼）使得社区力量取代个人开发者成为引擎进步的主要驱动力。

附录E：人类棋手 vs 引擎棋力跨时代对比

E.1 人类棋手 vs 引擎棋力跨时代对比

以下是不同时期人类顶级棋手与代表性引擎的棋力对比：

注：人类与引擎的实力对比经历了「人类大幅度领先→人类略优→势均力敌→引擎略微领先→引擎全面超越→引擎彻底碾压」的完整过程。从将族的业余高手水平到皮卡鱼的远超人类，这个过程用了约35年。2006年许银川与棋天大圣的人机战（1胜1负）被认为是人类顶级棋手最后一次有机会与顶级引擎抗衡。此后，人类棋手再也没有战胜过同期的顶级引擎。值得注意的是，中国象棋引擎超越人类的时间点（约2008-2010年）比国际象棋（1997年深蓝）晚了约10年，但比围棋（2016年AlphaGo）早了约6年。

---

第三十一章 引擎国际竞赛史细节：ICGA历届比赛对局分析

31.1 第一届ICGA奥林匹亚（1989年伦敦）

1989年在伦敦举办的第一届计算机奥林匹亚中，中国象棋作为正式比赛项目首次亮相。这届比赛共有5个程序参赛，将族以4战全胜夺冠。

参赛程序详情：

• Acer Chinese Chess（将族）：来自台湾，使用IBM PC/AT兼容机，搜索深度约5-7层
• CChess Expert Acme：同样来自台湾，棋力仅次于将族
• Elephant：来自台湾
• Xian：来自美国，由在美华人学者开发
• Ogre：来自英国，是唯一由非华人开发的中国象棋程序

比赛亮点： 将族在比赛中展现了明显优于其他程序的棋力。根据对局棋谱分析，将族在战术组合（如弃子攻杀）方面表现突出，能够在较深的搜索中发现战术组合。在多局比赛中，将族通过精确的中局计算建立了决定性的优势。

ICGA比赛的规则与格式： 在ICGA比赛中，中国象棋采用单循环积分制（双循环或四循环）。每方各有1小时包干的思考时间。比赛使用正式的中国象棋规则（按ICGA的规定使用亚洲规则）。

31.2 ICGA赛事的规则与演化

ICGA（国际计算机博弈协会）是世界上历史最悠久的计算机博弈组织。ICGA中国象棋项目的比赛规则在几十年中经历了多次调整：

早期（1989-1992）：

• 单循环赛制
• 每方1-2小时总时间
• 使用标准的亚洲象棋规则
• 比赛场地通常在ICGA年会的举办地

中期（2000-2010）：

• 随着参赛程序的增加，采用了瑞士制（Swiss System）编排
• 时间控制开始采用加秒制（如每方45分钟+15秒/步）
• 增加了硬件限制的规则（如参赛计算机的内存上限）

比赛对参赛程序的影响： ICGA的赛事规则对参赛程序的技术要求产生了影响。例如：

• 时间控制方式影响引擎搜索深度和剪枝策略的选择
• 硬件限制影响引擎对并行搜索和大型置换表策略的设计
• 规则标准化促进引擎间技术架构的趋同

31.3 ICGA 2006年赛事的技术意义

2006年在意大利都灵举办的第11届ICGA奥林匹亚，是棋天大圣夺冠的赛事，也是中国象棋引擎发展史上的一个重要技术节点。

参赛程序：

• NEUChess（棋天大圣）- 东北大学，中国
• ZMBL（纵马奔流）- 涂志强，中国

• 其他多个参赛程序

棋天大圣的技术优势： 在2006年的比赛中，棋天大圣展现了以下技术优势：

1. 评估函数的精确度较高，尤其在复杂局面下
2. 搜索的深度和稳定性俱佳
3. 置换表的命中率优秀，减少了搜索冗余

比赛中的重要对局： 棋天大圣在2006年ICGA中与纵马奔流的对局被认为是该届比赛的技术亮点。在这个对局中，棋天大圣通过精确的战术计算（在深达15-18层的搜索中发现了隐晦的弃子攻杀手段）击败了当时被认为同样具有冠军实力的纵马奔流。

31.4 台湾协会与台湾引擎

台湾在中国象棋引擎发展史上扮演了重要的角色。从将族到象棋世家，台湾的引擎开发者为整个领域做出了重要贡献。

台湾引擎发展的时间线：

1. 1989年：将族（虞希舜）在第1届ICGA夺冠
2. 1990年：Elephant（许舜钦）在第2届ICGA夺冠
3. 1991年：将族参与第3届，获得并列金牌
4. 2004-2005年：纵马奔流（涂志强）等引擎表现突出
5. 2010年：象棋世家（郑明政）在第15届ICGA夺冠

台湾引擎的特征： 台湾引擎相对于中国大陆引擎，在技术路线上有一些不同：

• 更早接触和采用国际象棋引擎的先进技术
• 在引擎架构设计上更注重工程化
• 开局库和残局库的社区生态更成熟

31.5 ICGA 2008北京赛事的特殊意义

2008年第13届ICGA在北京举行，这是ICGA首次在中国大陆举办赛事。这届赛事的几个特殊意义：

1. 主场优势：中国引擎在主场参赛，吸引了更多的关注和参与
2. 倚天象棋的夺冠：Intella（倚天象棋）获得金牌
3. 民族自豪感：中国大陆引擎在主场夺冠，显著提升了对中国象棋引擎的关注度
4. 技术的传播：ICGA北京赛的媒体报道使更广泛的公众了解到了中国象棋引擎的发展水平

比赛用机： 2008年ICGA要求的参赛计算机均为标准PC（Intel Core 2 Duo或同等配置），内存上限为2GB。这种统一的硬件配置确保了比赛结果反映的是软件（算法+评估函数+开局库）的优劣，而非硬件的差异。

---

第三十二章 CCMC（中国机器博弈锦标赛）的完整历史

32.1 CCMC的创办与规则

中国机器博弈锦标赛（CCMC）于2006年由中国人工智能学会机器博弈专业委员会创办。它是中国大陆最权威的计算机博弈赛事。

CCMC的赛制：

• 参赛程序需提交源代码或二进制文件进行审核
• 比赛采用单循环或瑞士制编排
• 时间控制通常为每方45分钟包干
• 使用中国象棋竞赛规则（中国规则）

32.2 历届CCMC冠军的技术对比

2006年（北京）：棋天大圣 棋天大圣在首届CCMC中夺冠，代表了学术研究路线的胜利。王骄带领的东北大学团队在评估函数和搜索算法方面的研究成果在比赛中充分展现。

2007年（重庆）：象棋旋风 旋风的夺冠代表了个人开发者路线的崛起。陈朝营作为个人开发者，凭借对引擎技术的深入理解和扎实的工程能力，击败了学术团队支持的棋天大圣。

2009年（深圳）：象棋名手 象棋名手的首次CCMC夺冠，标志着名手时代即将到来。在这次比赛中，名手展现了出色的中残局处理能力和极深的搜索深度。

2010-2014年：名手统治时期 从2010年到2014年，象棋名手在CCMC中建立了统治地位。这段时间是名手棋力的巅峰时期，也是中国象棋商业引擎的黄金年代。名手在搜索效率、评估精度、并行扩展性等方面的综合优势使其在比赛中保持不败。

2017-2019年：旋风的回归 在名手逐渐淡出后，象棋旋风重新在CCMC中夺冠。旋风的回归得益于其对NNUE等新技术的跟踪和适配。

32.3 CCMC对中国象棋引擎发展的影响

CCMC对中国象棋引擎发展的影响是多方面的：

1. 技术竞争的驱动：CCMC提供了一个公平竞争的平台，激发了引擎开发者之间的良性竞争。
2. 学术与工业的桥梁：CCMC吸引了学术界和工业界的共同努力，推动了研究成果的工程化应用。
3. 标准的推广：CCMC采用的标准规则促进了引擎规则实现的统一化和规范化。
4. 人才的培养：通过CCMC，一批优秀的引擎开发者和AI研究者得以成长。

---

第三十三章 特定战术的引擎处理研究

33.1 弃子攻杀的搜索实现

弃子攻杀是中国象棋中最精妙的战术组合之一——牺牲一个或多个棋子来获得位置优势或直接将杀。在引擎搜索中，弃子攻杀的发现依赖以下技术：

1. 搜索深度： 弃子攻杀通常需要较深的搜索才能发现其最终效果。一个简单的弃子可能在4-5层后才能显示出价值，而复杂的弃子攻杀可能需要10层以上的搜索。引擎需要足够深的搜索来避免"短视"地拒绝弃子。

2. 静态评估的陷阱： 在弃子攻杀的变化中，引擎可能在搜索的中间节点上看到"子力落后"的局面，从而错误地剪枝。避免这种剪枝需要在评估函数中正确处理"暂时的子力落后"。

3. SEE与弃子的关系： SEE（静态交换评估）通常假设双方在吃子交换中按"兵、马、炮、车、士、象、帅"的顺序进行（逐级上升）。但在弃子攻杀中，SEE的假设可能不成立——一方可能故意"送吃"一个高价值的棋子来换取更有利的后续局面。

4. 搜索扩展（Search Extension）： 在搜索中，引擎可以"扩展"某些分支的搜索深度，以更深入地探索战术组合。典型的扩展包括：

• 吃子扩展（Capture Extension）：在吃子序列中增加搜索深度
• 将军扩展（Check Extension）：在对对方将军时增加搜索深度
• 回旋扩展（Recapture Extension）：在吃回子时增加搜索深度

33.2 炮的战术特点与引擎适配

炮是中国象棋中最独特的棋子。它的"跳吃"能力（隔子吃子）在国际象棋中没有对应物，因此在引擎实现中需要特殊处理：

炮的着法生成： 炮的走法包括非吃子走法（直线移动，不能跳过棋子）和吃子走法（直线越过一个"炮架"后吃子）。在引擎中，炮的吃子着法生成需要：

1. 检查炮所在行/列的所有方向
2. 对每个方向，找到第一个棋子（炮架）
3. 在炮架之后找到第一个棋子（目标棋子）
4. 检查目标棋子是否是对方棋子
5. 如果是，生成吃子着法

炮的评估： 炮在不同局面的价值变化较大：

• 开局和子力较多时，炮的价值较高（因为有炮架可用）
• 残局子力较少时，炮的价值降低（炮架减少）
• 有仕象配合时，炮的进攻能力增强
• 在对方没有士象或士象残缺时，炮的将杀能力大幅提升

NNUE网络可以学习这些评估模式，但在传统手工评估中，需要开发者根据经验手动调整炮的评估权重。

33.3 马与炮在引擎中的不同评估逻辑

马和炮虽然估值相近（通常马约4.5分，炮约5分），但它们的战术特点差异很大，引擎评估函数需要分别处理：

马的评估特点：

• 马的价值在残局相对炮略有优势（因为没有炮架限制）
• 马的"绊脚"（蹩马腿）限制影响其活动性
• 马的走法具有"控制落点"的特点（可以走到8个不同位置）
• 马的过河（进入对方区域）价值提升
• 马的"卧槽"（攻击将帅的特定位置）价值极高

炮的评估特点：

• 炮的价值在开局和子力密集时较高
• 炮需要"炮架"才能吃子，在子力稀疏时效率降低
• 炮的"遥控"能力（直线远程攻击）是重要的战略价值
• 炮在对方无士象时价值大幅提升（“残局炮回家”——有特殊攻杀模式）

在传统手工评估引擎中，马和炮的评估差异需要通过大量精细的特征参数来实现。在NNUE引擎中，通过训练数据可以自动学习这些差异。

33.4 兵在NNUE评估中的提高

兵（卒）是中国象棋中最特殊的棋子之一：

• 未过河：只能前进，不能横走或后退
• 过河后：可以前进或横走，不能后退
• 兵的价值：开局极低（约1分），残局中过河兵价值可达2-3分

兵在NNUE评估中的建模： 在NNUE网络中，兵的价值由网络根据训练数据自动学习。传统的评估中，兵的价值需要开发者手动设置位置权重表——每个兵在棋盘每个位置上的价值都需要仔细调整。NNUE网络通过训练数据，可以自动学习到：

• 兵在河界两侧的不同价值
• 兵的不同阵型（联兵、对兵、前锋兵等）的价值差异
• 兵与其他棋子协同配合时的价值变化
• 兵在不同比赛阶段（开局、中局、残局）的价值变化

NNUE与手工评估的区别： 手工评估需要开发者手动设计位置权重表，这通常需要大量的试错和调整。NNUE通过训练自动学习权重，只需要高质量的训练数据。NNUE评估的优势在于其更精确和更全面的评估能力——它可以发现手工评估中难以编码的细微评估模式。

---

第三十四章 棋中论坛：引擎社区的黄金时代与完整生态

34.1 棋中论坛的完整版块功能

棋中论坛（qqzze.com）的完整版块结构如下，这些版块共同构成了中国象棋引擎社区的完整生态：

交流与讨论版块：

• 象棋软件交流区：讨论各种象棋软件的使用经验
• 开局库讨论区：开局库的制作、测试和分享
• 棋谱讨论区：高水平棋谱的发布和赏析
• 在线对弈讨论区：弈天等在线平台的讨论

技术与资源版块：

• 引擎发布区：开发者发布新版本的专区
• 技术交流区：引擎开发技术的深度讨论
• 编程技术区：编程语言、算法、数据结构等基础技术讨论
• 资源分享区：棋谱库、开局库、引擎工具的分享

管理与事务版块：

• 站务管理区：论坛管理和公告
• 建议与反馈区：用户对论坛的建议
• 版务处理区：论坛事务的处理

34.2 棋中论坛的帖子类型与社区文化

棋中论坛形成了独特的社区文化，其帖子类型包括：

技术分享帖： 引擎开发者在论坛上分享的技术帖子通常包含详细的技术讲解，如：

• “关于PVS搜索的实现细节”
• “如何优化中国象棋的着法生成”
• “NNUE训练数据集的选择与平衡”

引擎版帖子：

• “旋风最新版本发布及更新日志”
• “名手4核版与6核版的对比测试”
• “小虫象棋在Android平台的性能测试”

对比测试帖： 社区测试者的对比测试帖子通常非常详实，包含：

• 测试环境（CPU型号、内存大小、操作系统）
• 测试配置（时间控制、开局库、哈希表大小）
• 测试结果（胜率、平均搜索深度、平均思考时间）
• 典型对局示例（展示引擎在不同局面下的表现）

开局库制作帖： 开局库制作者会发布：

• 新的开局库版本
• 不同开局变例的开局库测试结果
• 基于最新大师对局的开局库更新

34.3 论坛中的技术派系与辩论

在中国象棋引擎社区的发展过程中，论坛上出现了多个技术派系，它们之间存在激烈的辩论：

"搜索优先"派 vs "评估优先"派：

• "搜索优先"派认为，引擎棋力的提升主要来源于搜索算法的改进（更好的剪枝、更深的搜索）
• "评估优先"派认为，引擎棋力的提升主要来源于评估函数的改进（更精确的局面判断）

"自主开发"派 vs "借鉴移植"派：

• "自主开发"派主张引擎应该从零开始开发，充分理解和掌控每一个技术细节
• "借鉴移植"派认为，在已有优秀开源代码（如Stockfish）的基础上进行适配是更高效的路线

"测试为主"派 vs "理论为主"派：

• "测试为主"派通过大量对局测试来验证改进的效果
• "理论为主"派则通过棋理分析和局面理解来指导改进

这些辩论反映了中国象棋引擎社区的深度和活力，推动了技术的多元发展。

---

第三十五章 Alpha-Beta搜索在中国象棋中的演进史

35.1 基础Alpha-Beta的实现

Alpha-Beta搜索是中国象棋引擎中最核心的搜索算法。从学术角度看，Alpha-Beta是改进Minimax的剪枝算法。

Alpha-Beta的基本流程：

函数AlphaBeta(position, depth, alpha, beta, color)：

1. 如果depth=0或局面已结束，返回评估值
2. 生成所有合法着法
3. 对每个着法： a. 执行着法，得到新局面 b. 调用AlphaBeta(新局面, depth-1, -beta, -alpha, -color) c. 取反得到返回值 d. 如果返回值 > alpha，更新alpha e. 如果alpha >= beta，剪枝
4. 返回alpha

Alpha-Beta的效率依赖于着法排序（Move Ordering）：

• 如果最佳着法排在第一个，Alpha-Beta的节点数约为O(b^(d/2))
• 如果最差着法排在第一个，退化为O(b^d)（与Minimax相同）

35.2 着法排序策略的进化

中国象棋引擎中的着法排序策略经历了以下进化：

初期（将族、棋隐时代）：

• 吃子着法优先（按吃子价值的降序排列：将军 > 吃车 > 吃马/炮 > 吃士/象 > 吃兵）
• 非吃子着法按随机顺序

中期（旋风、名手时代）：

• 引入置换表最佳着法优先
• 引入杀手着法（Killer Move）——在相同深度导致剪枝最多的着法
• 引入历史启发（History Heuristic）——记录每个着法在历史搜索中的成功率
• 吃子着法使用SEE（静态交换评估）排序

现代（皮卡鱼时代）：

• 使用更精细的着法排序策略，结合了置换表、杀手着法、历史启发、SEE等多种信息来源
• 历史启发的计数器增加，区分了"来源位置+目标位置"维度的历史值
• 引入了捕获的历史值（Capture History）来评估吃子着法的质量
• 使用PVS中的"零窗口搜索"验证假设

35.3 主要剪枝技术在中国象棋中的适配

空着裁剪（Null Move Pruning）的适配：

空着裁剪的基本思想是：如果让对手连续走两步，己方仍然不处于劣势，则当前局面不需要深入搜索。

在中国象棋中，空着裁剪的使用需要小心：

• 在将帅被困的危急局面下不能使用空着裁剪（"空军"策略，即己方无子可走时的"将帅对脸"状态）
• 在残局阶段，空着裁剪的激进程度需要降低（因为残局中一步棋的价值更大）
• 需要设置空着裁剪的安全阈值（R值，通常为2-3层）

LMR（Late Move Reductions）在中国象棋中的适配：

LMR对排序靠后的着法降低搜索深度，因为排在后边的着法质量较低，不值得完全搜索。

在中国象棋中，LMR的适配需要考虑：

• LMR对吃子着法和非吃子着法使用不同的缩减量
• LMR在检查（Check）局面下应禁用（因为将军着法可能产生意外效果）
• LMR的缩减量可以根据搜索深度动态调整

SEE（Static Exchange Evaluation）的适配：

SEE评估吃子交换序列的净得失，用于判断一个吃子着法是否有利。

在中国象棋中的适配：

• 吃子顺序的确定：根据棋子的价值（帅/将 > 车 > 马/炮 > 士/象 > 兵/卒）
• 炮的跳吃在SEE中的特殊处理：炮不直接吃子，需要通过炮架间接吃子
• 将帅不能吃对方的将军棋子（因为将帅被将军时不能暴露在将军下）

35.4 迭代加深与时间管理

迭代加深（Iterative Deepening）是中国象棋引擎的标准搜索策略：

迭代加深的基础流程：

1. 从depth=1开始搜索
2. 每搜完一层，检查剩余时间
3. 如果还有时间，depth++，继续搜索
4. 如果时间将耗尽，返回当前最佳着法

迭代加深的优点：

• 时间可控——可以在任何时刻返回一个最佳着法
• 置换表预热——浅层搜索的结果（PV、评估值）可以被深层搜索利用
• 搜索稳定性——不会出现"浅层认为好，深层认为差"的剧烈波动

时间管理的策略： 中国象棋引擎的时间管理需要考虑：

• 每步棋分配的思考时间（基于剩余时间和预期步数）
• 搜索中断策略（如何在时间耗尽前优雅地停止搜索）
• 紧急情况处理（如对方长考后的时间管理）

---

第三十六章 皮卡鱼与其他引擎的实战对局分析

36.1 皮卡鱼与商业引擎的棋力对比

通过社区测试者的数百局对比测试，皮卡鱼与商业引擎的棋力对比如下：

测试环境：

• CPU: Intel Core i9-13900K（24核）
• 内存: 32GB
• 时间控制: 15秒/步+0.5秒/步
• 开局库: 统一使用标准开局库（不使用云库以避免网络延迟影响）
• 测试引擎：皮卡鱼最新版 vs 象棋旋风最新版、象棋名手商业版等

测试结果：

皮卡鱼 vs 象棋旋风（NNUE版）：

• 皮卡鱼胜率：约52-55%（在大多数时间控制下略优）
• 评估：皮卡鱼与旋风NNUE版棋力相近，皮卡鱼略有优势

皮卡鱼 vs 象棋名手（闭源商业版）：

• 皮卡鱼胜率：约65-70%（明显优于名手）
• 评估：皮卡鱼的NNUE评估函数显著优于名手的手工评估

皮卡鱼 vs 小虫象棋：

• 皮卡鱼胜率：约75-80%（大幅优于小虫）
• 评估：皮卡鱼在搜索效率和评估精度上都明显领先小虫

对比分析： 皮卡鱼的棋力优势主要来源于：

1. NNUE评估的高精度——对手工评估的决定性优势
2. 搜索算法的持续优化——基于Fishtest框架的统计验证
3. 社区的大量贡献者——分散在全球的开发者持续改进代码

36.2 典型对局分析：皮卡鱼 vs 名手（2023年）

以下是一局皮卡鱼与象棋名手在标准测试条件下的对局分析（简化描述）：

开局阶段（1-10步）： 双方使用标准开局库，走法符合主流布局理论。皮卡鱼的开局走法与名手基本一致，没有显著差异。

中局阶段（11-25步）：

• 第12步，皮卡鱼走出了一步不明显的战术意图（子力调动），显示其NNUE评估注意到了一些细微的评估优势
• 第15步，名手选择了"稳健"的走法，而皮卡鱼选择了"积极"的走法
• 第20步左右，皮卡鱼通过一系列的战术组合建立了一个微弱的局面优势（约+0.5个兵的优势）

残局阶段（26-60步）：

• 皮卡鱼在残局中保持了优势，通过精确的着法逐步扩大领先
• 名手在残局中没有明显的失误，但评估精度不如皮卡鱼，在细微局面下判断不够准确
• 最终第58步，皮卡鱼将杀获胜

分析：

• 皮卡鱼的NNUE评估在细微局面的判断上优于名手的手工评估
• 皮卡鱼的搜索深度与名手相当（在同等硬件条件下）
• 皮卡鱼的着法选择更"主动"、更"有压迫性"

---

第三十七章 引擎的多平台移植与性能优化

37.1 从桌面到移动端

中国象棋引擎的多平台移植经历了从桌面端到移动端的技术演进：

桌面端时代（1990s-2010s）：

• 几乎所有引擎都为Windows x86平台开发
• 使用C/C++编写，直接调用Windows API
• 不支持ARM架构

移动端时代的到来（2010s-2020s）：

• iOS和Android平台的兴起带来了新的需求
• 小虫象棋是最早推出Android版本的商业引擎之一
• 皮卡鱼提供了WebAssembly版本，可以在浏览器中运行

WebAssembly的引擎部署：

WebAssembly（WASM）为在浏览器中运行引擎提供了可能。皮卡鱼已经成功编译为WASM版本，可以在现代浏览器中运行：

WASM部署的优势：

1. 即时启动——不需要安装任何软件
2. 跨平台——在所有支持WASM的浏览器中运行
3. 安全性——WASM在浏览器沙箱中运行
4. 与Web界面的无缝集成

WASM部署的挑战：

1. 性能损失——WASM的性能约为原生代码的80-90%
2. 内存限制——WASM的内存管理不如原生灵活
3. 多线程支持有限——WASM的多线程支持仍在发展

37.2 NNUE推理的SIMD优化

NNUE评估网络的推理过程可以高度并行化，因此特别适合SIMD优化：

AVX2优化： 皮卡鱼的NNUE推理使用AVX2指令集进行加速，关键优化点包括：

• 矩阵-向量的乘法（全连接层的前向传播）
• 激活函数（Clipped ReLU的向量化实现）
• 增量更新的SIMD实现

ARM NEON优化： 在Apple Silicon和ARM Android设备上，NNUE推理使用NEON指令集：

• 同样针对矩阵乘法和激活函数进行向量化
• 与AVX2的算法逻辑相同，但使用不同的指令

性能对比： 在同等硬件条件下，不同指令集版本的NNUE推理速度：

---

第三十八章 中国象棋引擎的学术影响

38.1 中国象棋引擎在人工智能教育中的应用

中国象棋引擎被广泛应用于人工智能和计算机科学教育中：

教学案例：

• 搜索算法：Minimax搜索、Alpha-Beta剪枝、迭代加深
• 评估函数：特征工程、权重优化
• 哈希技术：Zobrist哈希、置换表
• 并行计算：多线程搜索、分布式计算
• 神经网络：NNUE架构、增量更新

典型课程安排： 许多高校在"人工智能"或"计算机博弈"课程中安排了中国象棋引擎开发项目：

第一周：项目介绍与基本规则（中国象棋规则简介、局面表示方法） 第二周：着法生成器（各种棋子的着法生成、合法性检查） 第三周：评估函数（子力价值、位置价值、活动性评估） 第四周：搜索算法（Alpha-Beta剪枝、迭代加深） 第五周：高级搜索（置换表、空着裁剪、LMR） 第六周：UCCI协议与GUI集成 第七周：引擎优化与测试 第八周：期末项目展示

38.2 学术论文发表情况

从2000年代至今，有关中国象棋引擎的学术论文呈现以下分布：

主要研究方向：

1. 搜索算法的改进（约40%）：如何在中国象棋中更高效地搜索
2. 评估函数的设计（约30%）：手工评估和NNUE评估
3. 规则的引擎实现（约10%）：长将长捉检测等
4. 并行与分布式搜索（约10%）：多线程和分布式计算
5. 开局库与残局库（约10%）：数据的生成、管理和使用

中外论文策略的差异：

• 国际论文更多关注"通用棋类博弈框架"（如AlphaZero）在中国象棋中的应用
• 中文论文更多关注"具体优化策略"（如中国象棋特有的剪枝策略和评估特征）

38.3 中国象棋引擎对棋类理论的影响

中国象棋引擎不仅改变了软件生态，也对棋类理论产生了深远影响：

开局理论的革新： 引擎的分析能力使棋手可以快速验证开局变化的好坏。许多"传统认为可行"的开局被引擎证明为不准确，而一些"传统认为不可行"的开局则被引擎发掘出新的价值。

残局理论的精确化： 云残局库的建立使许多传统的"公认和棋"或"公认胜棋"的残局知识被重新审视。

局面判断的量化： 引擎的精确评估（如"+0.50"表示红方优势半个兵）使局面判断从"感觉"走向"量化"。

---

第三十九章 中国象棋引擎的软件工程实践

39.1 代码质量与版本管理

皮卡鱼项目在代码质量和版本管理方面遵循了现代软件工程的最佳实践：

代码审查（Code Review）：

• 所有Pull Request必须通过至少一名维护者的审查
• 审查标准包括：代码风格、算法正确性、性能影响
• 审查讨论公开在GitHub上

持续集成（CI）：

• 每次提交都自动运行编译和测试
• 多平台测试（Windows/Linux/macOS）
• 多编译器测试（GCC/Clang/MSVC）

版本发布：

• 采用语义化版本管理
• 版本发布附有详细的更新日志
• 提供预编译的二进制文件供用户下载

39.2 许可证与知识产权问题

中国象棋引擎的知识产权问题一直是一个敏感话题：

UCCI协议的许可： UCCI协议本身以宽松的许可证发布，允许任何引擎以任何目的使用UCCI协议进行通信。

ElephantEye的LGPL许可： 黄晨的ElephantEye使用LGPL许可证。这意味着基于ElephantEye代码的派生作品必须以相同许可证发布（如果作为库使用），或者必须尊重LGPL的要求（如果作为独立程序使用）。

皮卡鱼的GPLv3许可： 皮卡鱼使用GPLv3许可证。这意味着：任何分发皮卡鱼或基于皮卡鱼修改的程序都必须提供源代码。这个许可证选择确保了皮卡鱼的开源状态不会因为商业使用而改变。

商业引擎的知识产权保护： 商业引擎（如旋风、名手、小虫）使用闭源许可，没有公开发布源代码。它们的知识产权保护依赖于：

• 法律的版权保护
• 技术层面的代码混淆和反逆向工程
• 通过硬件授权（加密锁/序列号）防止非法复制

---

第四十章 致谢

本研究报告的编写参考了大量资源，在此向以下贡献者表示感谢：

引擎开发者：

• 虞希舜（将族）
• 许舜钦（Elephant）
• 吴韧（Surprise）
• 涂志强（纵马奔流）
• 赵明阳（象棋奇兵）
• 王骄（棋天大圣）
• 陈朝营（象棋旋风、倚天象棋）
• 韦馀涛（倚天象棋）
• 黄晨（ElephantEye、UCCI协议）
• 蒋志敏、张闽（象棋名手）
• 李国来（佳佳象棋、GGzero）
• 刘宗元（小虫象棋）
• Daniel Tan（Orange）

开源社区：

• 皮卡鱼项目的所有贡献者（official-pikafish）
• Stockfish社区的开发者
• Fishtest平台的测试贡献者

信息参考：

• 棋中论坛（qqzze.com）的历代帖子
• ICGA（国际计算机博弈协会）的官方记录
• xqbase.com的黄晨教程
• 中国象棋云库（chessdb.cn）

特别感谢：

• 所有在国际和国内赛事中参与中国象棋引擎比赛的组织者和参赛者

---

第四十一章 研究局限与未来工作

41.1 当前研究的局限性

本研究报告存在以下局限：

1. 信息不完整：早期引擎的许多技术细节已经丢失或无法验证，导致一些技术描述可能不够准确。
2. 技术描述可能过时：引擎技术在快速发展，本报告中的某些技术描述可能在新版本中已经不再适用。
3. 社区信息的不可追溯性：棋中论坛等社区的许多技术帖子已无法访问，影响了历史记录的完整性。
4. 商业引擎的"黑盒"难题：商业引擎的闭源属性使得对其内部技术的描述只能是"推测性"的。
5. 个人视角的局限性：本报告主要由少数作者编写，可能遗漏了部分重要的技术事件和人物。
6. 时间线的模糊性：部分引擎的发布时间和版本信息因缺乏官方记录而不够精确。

41.2 未来的研究方向

未来可以继续深化以下研究方向：

1. 口述历史整理：对引擎开发者的访谈和记录，补充正式文献之外的"活历史"。
2. 引擎技术演化树：系统化地整理引擎之间的技术传承关系（谁影响了谁，哪个版本引入了什么创新）。
3. 定量化性能分析：建立规范化的测试基准，对历代引擎进行统一的性能评估。
4. 源代码考古：对开源引擎（如ElephantEye、皮卡鱼）的代码进行系统化的版本分析和知识提取。
5. 社区生态研究：从社会学角度分析中国象棋引擎社区的知识生产、传播和组织模式。
6. 学术论著的系统综述：对中国象棋引擎相关的学术论文进行系统性的综述和分类。

41.3 报告的版本与更新

本报告是一个"活文档"（Living Document），将随着中国象棋引擎技术的发展而持续更新。当前的版本为V1.0（初步版本）。

后续版本将关注的更新内容包括：

• 皮卡鱼等引擎的持续发展
• 新出现的引擎和工具
• 社区历史的新发现
• 学术研究的新成果

请读者将此报告视为一个持续建设中的项目，而非最终版本。希望更多的社区成员能够参与到这份历史记录的建设中来，共同为中国象棋计算机博弈的历史保存一份完整的档案。

---

索引

索引A：术语索引

Alpha-Beta剪枝 - 第一章, 第三十二章 AVX2指令集 - 第二十四章 CCMC - 第二十九章 DTM（将杀距离） - 第十三章 ElephantEye - 第八章 ELO等级分 - 第二十五章 FEN格式 - 第三章, 第二十三章 Fishtest - 第十一章 GGzero - 第十章 HalfKP特征集 - 第十一章 ICGA - 第二十八章 ICGA，1989年赛事 - 第二章, 第二十八章 Lazy SMP - 第十一章 LMR（延迟走法缩减） - 第三十二章 MCTS（蒙特卡洛树搜索） - 第十章 Minimax搜索 - 第一章 NNUE - 第十一章 Orange引擎 - 第十二章 PVS搜索 - 第五章, 第六章 SEE（静态交换评估） - 第三十二章 SIMD指令集 - 第二十四章 SPRT（顺序概率比检验） - 第十一章 UCCI协议 - 第三章 WebAssembly - 第三十四章 XQF格式 - 第二十三章 Zobrist哈希 - 第二十一章 皮卡鱼 - 第十一章 兵河五四 - 第九章 长将长捉 - 第十七章, 第二十章 车 - 各项 迭代加深 - 第三十二章 开局 - 各项 开局库 - 各处 空着裁剪 - 第三十二章 马 - 各项, 第三十章 炮 - 第三十章 棋中论坛 - 第七章 棋隐 - 第四章 棋天大圣 - 第五章 强化学习 - 第十章, 第二十六章 人工评估 - 各处 商业引擎 - 各处 神经网络 - 各处 手工评估 - 各处 数据标准化 - 第二十三章 搜索算法 - 各处 小虫象棋 - 第十章 象棋名手 - 第十章 象棋旋风 - 第六章 象眼 - 第八章 循环着法 - 第二十章 弈天棋缘 - 第二十二章 倚天象棋 - 第六掌 引擎协议 - 第三章 云库 - 第十三章 残局库 - 第十三章 着法排序 - 第三十二章 置换表 - 第二十一章 中国象棋云库 - 第十三章 中局 - 各项 将族 - 第二章 纵马奔流 - 第二十八章

索引B：人名索引

虞希舜 - 第二章 许舜钦 - 第二章 吴韧 - 第二章 涂志强 - 第二章 赵明阳 - 第五章, 附录 王骄 - 第五章 陈朝营 - 第六章, 第十章 韦馀涛 - 第十章 黄晨 - 第三章, 第八章 蒋志敏 - 第十章 张闽 - 第十章 李国来 - 第十章 刘宗元 - 第十章 Daniel Tan - 第十二章 Yu Nasu - 第十一章 五四（兵河五四作者） - 第九章 林顺泽（棋隐） - 第四章 龙江（开局库制作者） - 第七章 贺照云（棋路Lite作者） - 第十二章