第三十章 中國象棋計算機博弈的文化遺產

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作者） - 第十二章