中國象棋計算機博弈發展史研究報告

第十二章 皮卡魚（Pikafish）：NNUE時代的開源革命（2022–至今）

12.1 NNUE技術及其引入中國象棋

NNUE（Efficiently Updatable Neural Network，高效可更新神經網絡）最初由日本程序員Yu Nasu於2018年爲國際象棋引擎Stockfish開發的神經網絡評估架構。NNUE的標誌性特徵是：使用半整數線性網絡結構，每次走棋後僅需增量更新被影響的特徵，而非對整個棋盤重新進行網絡推理。

NNUE的主要創新點：

1. 增量更新：NNUE只更新被移動棋子在前後位置的特徵值，而非對整個棋盤重新計算，這使得特徵更新的計算量與棋盤大小無關，只與每次走棋影響的局部範圍相關。

2. 稀疏計算：NNUE將稀疏特徵的提取轉化爲全連接層的矩陣計算，巧妙地利用SIMD指令集（特別是AVX2）實現高效的批量推理。

3. 混合架構：NNUE作爲局面評估模型與Alpha-Beta搜索結合使用——評估由NNUE完成，搜索仍然使用傳統的PVS搜索。

NNUE從國際象棋遷移到中國象棋：

NNUE從國際象棋到中國象棋的遷移不是簡單的參數複製，而是需要解決以下適配問題：

棋盤尺寸差異： 國際象棋是8×8=64格，中國象棋是9×10=90個交叉點。這意味着中國象棋的輸入特徵維度大約是國際象棋的約1.4倍。

棋子類型差異： 國際象棋每方有6種棋子（王、後、車、象、馬、兵），中國象棋每方有7種棋子（帥/將、士/仕、象/相、馬、車、炮、兵/卒）。此外，中國象棋的"炮"具有獨特的跳喫規則，在國際象棋中沒有對應物。

河界差異： 中國象棋的"河界"將棋盤分爲紅方區域和黑方區域，兵/卒過河後的行爲發生變化，這需要在評估網絡中體現。

九宮格差異： 帥/將和士/仕的活動範圍限制在九宮格內，這影響了網絡輸入特徵的編碼方式。

12.2 皮卡魚的誕生與早期發展

皮卡魚（Pikafish）項目始於2022年，由用戶在開源平臺GitHub上創建。最初，它是由社區中一羣對Stockfish技術路線有深入瞭解的開發者共同推動的。

皮卡魚的名稱由來：

皮卡魚的名字來源於對"非卡魚"的諧音（“Pikafish"與中文"非卡魚"讀音相近），同時也與Stockfish的名字對應（Stockfish是鱈魚乾，Pikafish是另一種"魚”）。這一命名風格體現了項目與Stockfish的關係——基於Stockfish代碼庫進行中國象棋適配。

項目的起源與GitHub倉庫創建：

皮卡魚的GitHub倉庫最初以"official-pikafish/Pikafish"爲組織/倉庫名創建。創始團隊成員選擇匿名或使用化名公開參與，這在一定程度上是爲了避免與商業引擎知識產權的潛在糾紛。

早期版本的開發（2022年）：

皮卡魚的最早期版本（約2022年4-5月）主要是將Stockfish的代碼適配到中國象棋規則和棋盤上。這一階段的工作包括：

1. 棋盤表示從8×8改爲9×10
2. 棋子類型從6種/方改爲7種/方
3. 規則適配（將帥照面、炮的跳喫、兵過河等）
4. NNUE網絡結構的適配（輸入層大小調整）
5. UCCI協議支持（而非UCI協議）

社區貢獻者的加入：

皮卡魚項目很快就吸引了大量社區開發者的參與。這些貢獻者的背景多樣：

• 國際象棋社區中關注中國象棋的開發者
• 中國象棋軟件社區的愛好者
• 計算機科學領域的研究者和學生
• 對開源項目感興趣的程序員

12.3 NNUE網絡的訓練與數據集

訓練NNUE網絡需要大規模、高質量的中國象棋局面評估數據。皮卡魚的數據來源於：

1. 雲庫數據：使用中國象棋雲庫（chessdb.cn）中的大規模殘局庫和開局庫數據。雲庫提供了約2.5M的評估數據。

2. 自對弈數據：皮卡魚通過在不同版本的引擎之間進行大量對局，收集棋譜數據。這些數據通過Fishtest框架進行管理。

3. 引擎互戰數據：使用皮卡魚與其他引擎（如旋風、名手）對戰產生的數據。

4. 棋譜庫數據：歷史上大師級人類棋手的對局數據。

NNUE網絡的訓練使用Python腳本（基於PyTorch或TensorFlow），訓練流程包括：

• 數據準備：將棋局轉化爲訓練樣本（局面+走法+評估值）
• 數據清洗：過濾低質量或異常數據
• 網絡訓練：使用GPU加速的訓練循環
• 量化轉換：訓練好的網絡轉化爲C++可加載的嵌入式格式

NNUE訓練數據的規模與質量：

NNUE訓練需要大規模的數據集。皮卡魚社區收集的訓練數據達到百萬級甚至千萬級盤面。數據覆蓋了：

• 從開局到殘局的各種局面類型
• 從優勢到劣勢的各種評估區間
• 從簡單子力配置到複雜多子結構的各種局面

訓練數據的質量直接影響NNUE的評估精度。皮卡魚社區在數據清洗和預處理方面做了大量工作，包括：

• 去除重複或相似局面
• 過濾明顯異常（如勝負已定局面的中間狀態）
• 平衡數據中不同局面對類型的分佈

12.4 皮卡魚的技術架構

皮卡魚的代碼架構基於Stockfish，但針對中國象棋進行了深度適配。其核心模塊包括：

1. 局面表示（Position Representation）：

皮卡魚使用位棋盤（Bitboard）表示棋盤狀態。每個棋子類型（7種紅方+7種黑方=14種）各自使用一個64位整數表示其位置。由於中國象棋棋盤只有90個交叉點，位棋盤中的高26位可以用於存儲其他狀態信息。

2. 着法生成器（Move Generator）：

皮卡魚的着法生成器高度優化，使用了：

• 預計算的棋子走法表
• 炮的"跳喫"檢測算法（需要檢查炮和要喫的目標之間是否有且只有一個棋子作爲"炮架"）
• 馬的"蹩馬腿"檢測
• 象的"塞象眼"檢測

3. 搜索算法（PVS搜索）：

皮卡魚使用了Stockfish的標準PVS搜索，配合以下剪枝技術：

• 空着裁剪（Null Move Pruning）：在非殘局階段大膽假設對方讓一手仍不輸
• LMR（Late Move Reductions）：對排序靠後的着法減少搜索深度
• SEE（Static Exchange Evaluation）：評估喫子交換序列的淨得失
• Razor裁剪、Futility裁剪等

4. Lazy SMP並行搜索：

皮卡魚使用Lazy SMP（Lazy Symmetric Multi-Processing）實現並行搜索。Lazy SMP的基本思想是：

• 多個搜索線程共享一個置換表
• 每個線程獨立執行搜索，不進行任務分配
• 線程之間通過共享置換表間接通信

Lazy SMP雖然硬件資源利用效率不如精確的任務分配策略，但實現簡單、可擴展性好，特別是在16線程以上的高核心數硬件上表現出色。

5. NNUE評估網絡：

皮卡魚的NNUE網絡結構基於Stockfish的HalfKP特徵集進行了中國象棋適配。HalfKP指的是使用"我方將帥位置 + 對方各棋子位置"作爲特徵，利用棋盤對稱性減少特徵數量。

最新版本的皮卡魚使用ATT++（Attention-based NNUE）架構，引入了注意力機制來提高網絡對大空間格局的建模能力。

12.5 皮卡魚的最重要更新版本

皮卡魚的發展歷程中有幾個重要的里程碑版本：

截至2026年，皮卡魚的發展仍在持續，社區保持着活躍的貢獻和更新。

12.6 Fishtest測試框架

Fishtest是皮卡魚社區使用的分佈式測試框架。Fishtest最初由Stockfish社區開發，用於在開源社區參與者貢獻的計算資源上運行大規模引擎測試。

Fishtest的工作原理：

1. 測試提交（Test Submission）：開發者向Fishtest提交一個補丁（patch），聲明該補丁預期會提升棋力。

2. 任務分發（Task Distribution）：Fishtest服務器將測試任務分解爲多組對局，分配給社區貢獻者的計算機。

3. 對局運行（Game Execution）：每臺貢獻者的計算機運行指定數量的對局（通常使用標準測試時間控制：15秒+0.5秒或60秒+0.6秒等）。

4. 結果上報（Result Reporting）：每臺計算機將測試結果上報給Fishtest服務器。

5. SPRT檢查（Statistical Check）：服務器對累計結果進行SPRT（順序概率比檢驗），判斷補丁是"通過了"（ELO提升顯著）、“失敗了”（ELO變化不顯著或下降）還是"需要更多數據"。

SPRT的工作原理：

SPRT是一種統計假設檢驗方法，它持續累積數據，直到有足夠證據做出判斷。SPRT需要設定：

• H0（零假設）：補丁不改變棋力（ELO變化=0）
• H1（備選假設）：補丁提高棋力（ELO變化>0）
• Type I Error（α）：錯誤接受H1的概率
• Type II Error（β）：錯誤接受H0的概率

隨着測試對局數量的增加，SPRT計算似然比（Likelihood Ratio）並判斷其結果是否達到接受/拒絕的閾值。SPRT的優勢在於它能在儘早的時間點上做出判斷，避免不必要的測試對局。

Fishtest對中國象棋社區的影響：

皮卡魚引入Fishtest框架後，中國象棋引擎的測試方法論發生了質的飛躍：

• 從"憑感覺調參數"變爲"數據驅動的統計驗證"
• 每次修改都需要通過統計學顯著性檢驗才能被接受
• 測試數據公開透明，任何社區成員都可以查看

12.7 皮卡魚引擎使用的具體架構

皮卡魚基於Stockfish，使用了完整的PVS搜索架構。其核心搜索相關着法包括：

搜索框架：

• Main Search（主搜索函數）
• QSearch（靜態搜索/靜態度量搜索，僅考察喫子着法）
• RootSearch（根節點搜索，迭代加深的主函數）

剪枝技術：

• Null Move Pruning（空着裁剪）
• Razoring（粗略剪枝）
• Futility Pruning（無效剪枝）
• Late Move Pruning（延遲走法剪枝）
• SEE Pruning（靜態交換評估剪枝）
• ProbCut（概率裁剪，基於淺層搜索結果的裁剪決策）

着法排序：

• Hash Move（置換表最佳着法）
• Winning Captures（贏子喫子着法）
• Promotions（兵/卒升級，中國象棋中兵過河後的價值變化）
• Equal Captures（等價交換喫子着法）
• Killer Moves（殺手着法）
• History Moves（歷史啓發着法）
• Losing Captures（輸子喫子着法）
• Other Moves（其他着法）

12.8 皮卡魚各版本的測試數據

皮卡魚的所有版本改進均經過了嚴格的雙盲隨機對照測試（通過Fishtest平臺）。以下是幾個代表性版本的測試結果：

2022-10-22版本：

該版本改進了長時限對局（LTC, Long Time Control）的表現，並初步修復了殘局局面評估的誤判問題。NNUE網絡文件沿用了此前版本訓練的數據。

2022-12-26版本：

這是皮卡魚早期最重要的版本改進之一。新增特性包括：

• 60步規則和三重重複檢測（基本符合亞洲規則）
• WDL（Win/Draw/Lose）模型的引入
• 新的NNUE壓縮架構

測試結果：

• 對局數：1,548局
• 勝率：53.84%
• ELO提升：+26.20（95%置信區間：[15.87, 36.90]）

2024-08-31版本：

引入了全新的ATT++ NNUE網絡架構，帶來了棋力的顯著提升和網絡文件體積的減少。同時更新了循環規則邏輯。

2025-06-23版本：

重要的性能優化版本：

• 更大的L1緩存大小，在長時限對局中表現更好
• 引入mid-mirror輸入特徵編碼，改善了鏡像局面下的評估對稱性
• 改進了靜態搜索中的困斃檢測
• 優化了AVX512指令集的性能

12.9 皮卡魚的技術手冊與文檔生態

皮卡魚項目擁有相對完善的文檔體系，反映了其作爲成熟開源項目的工程水平：

• README.md：項目概述、編譯指南、許可證說明
• AUTHORS：所有貢獻者的完整列表
• UCI & Commands Guide：UCI協議的完整命令參考
• Advanced Topics：技術深度討論，涵蓋NNUE評估、Fishtest測試、編譯優化等
• DeepWiki：第三方維護的深度技術文檔，涵蓋NNUE架構、特徵變換、搜索系統等

這種完善的文檔生態對於吸引新貢獻者和降低貢獻門檻至關重要。

12.10 皮卡魚對中國象棋研究的推動

皮卡魚的出現不僅僅是一個技術事件，它還極大地推動了中國象棋研究方式的變革：

研究民主化：

在皮卡魚出現之前，頂尖的分析工具需要數百到數千元購買（如象棋旋風、名手等商業引擎）。皮卡魚作爲免費開源引擎，使得任何有一臺普通電腦的愛好者都可以獲得世界級的分析工具。這大大降低了高水平象棋分析的門檻。

教育應用：

皮卡魚被廣泛應用於象棋教學場景。教練可以使用皮卡魚分析學生的對局、生成局面訓練題、模擬不同水平的對手。

文化保存：

皮卡魚的發展歷史本身就在爲中國象棋軟件社區積累一份開放的數字文化遺產。GitHub上的每一個Commit、每一次Issue討論、每一局測試對局，都在記錄着社區協作的歷程。

---

第十三章 其他NNUE時代的開源引擎

13.1 Orange引擎

Orange是一個由中國象棋社區獨立開發的NNUE開源引擎，由開發者Daniel Tan（主要作者）創建。Orange的特點是它並非基於Stockfish代碼庫改寫，而是從零開始實現的獨立引擎。

Orange的技術特點：

• 完整的UCCI協議支持
• 多層NNUE評估網絡（2層隱藏層，而非標準Stockfish NNUE的1層隱藏層）
• PVS搜索算法，包含現代搜索中常見的剪枝技術
• 可配置的訓練系統，支持自定義NNUE網絡訓練

Orange License：

Orange採用了自定義的開源許可證。根據項目的GitHub頁面聲明，Orange的代碼可以自由使用，但嚴禁修改引擎名稱後以"原創"身份重新發布。

Daniel Tan的研究工作：

Daniel Tan不僅開發了Orange引擎，還在學術層面研究了中國象棋NNUE的特徵設計。他與Neftali Watkinson Medina合作發表了論文《Study of the Proper NNUE Dataset》，探討了NNUE訓練數據集的特徵選擇問題。該論文在國際學術會議（IEEE Conference on Games 2024）上發表，表明中國象棋NNUE引擎的學術研究正在獲得國際認可。

13.2 Fairy-Stockfish的中國象棋支持

Fairy-Stockfish是Stockfish的一個衍生版本，專門用於支持各種國際象棋變體（Fairy Chess Variants）。Fairy-Stockfish在其變體支持中包含了中國象棋規則。

Fairy-Stockfish的中國象棋實現雖然主要是爲了國際象棋變體愛好者和研究者，但它代表了中國象棋在更大範圍的棋類博弈研究中的位置——中國象棋被視爲"國際象棋變體"的一種，可以與標準國際象棋共享技術框架。

Fairy-Stockfish的中國象棋支持不是其核心功能，而是作爲一系列變體支持中的一部分。但其存在說明中國象棋規則可以被納入國際象棋引擎的變體引擎框架中，爲跨領域的知識遷移提供了技術基礎。

13.3 其他社區驅動的開發

除了上述項目外，在皮卡魚之後還湧現了一些社區驅動的中國象棋NNUE嘗試：

象棋旋風（Cyclone-nn）：

象棋旋風在進入NNUE時代後也切換到了"Stockfish+NNUE"架構。旋風的NNUE版本在Fishtest測試平臺上被稱爲"Cyclone-nn"。Cyclone-nn代表了商業引擎從傳統架構向NNUE架構轉型的嘗試。

社區引擎的持續湧現：

在GitHub上，以"chinese-chess"、“xiangqi”、"cchess"等關鍵詞搜索，可以找到數十個不同規模的中國象棋引擎項目。這些項目中的多數使用了"Stockfish適配"路線，但也有一些探索了其他技術路線。

13.4 BitStronger和其他社區引擎

BitStronger是一個基於ElephantEye代碼基礎改進的開源引擎。它在ElephantEye的LGPL許可下進行了多項改進：

• 評估函數的重新設計和優化
• 搜索算法的參數調整
• 更高效的局面表示和着法生成
• 對多核心支持的初步嘗試

BitStronger雖然棋力不及商業引擎，但它作爲ElephantEye的派生版，展示了開源協議帶來的"分叉-改進"模式的可行性——這是後來皮卡魚成功模式的早期實驗。

13.5 棋路Lite與皮卡魚生態

棋路Lite由開發者賀照雲於2022年10月創建，是最早將皮卡魚引擎封裝爲可用象棋軟件的項目之一。棋路Lite本身也使用GPLv3許可證發佈，是皮卡魚生態中的重要組成部分。

棋路Lite的貢獻在於：

1. 提供了一個可直接運行的用戶界面
2. 降低了普通用戶使用皮卡魚的門檻
3. 驗證了皮卡魚在移動端和桌面端的實用性
4. 爲後續基於皮卡魚的軟件（如象棋公社等）提供了參考

13.6 國際象棋社區的跨領域參與

近年來，一些國際象棋社區的開發者也參與了中國象棋引擎的研究。他們的參與帶來了不同的技術視角：

• 對NNUE特徵設計的貢獻：國際象棋NNUE的設計經驗（如HalfKP特徵集、增量更新策略）爲中國象棋NNUE提供了直接參考。
• Fishtest平臺的共享：皮卡魚的Fishtest平臺最初基於Stockfish的Fishtest代碼庫，兩者共享了許多基礎架構。
• 編譯優化技術的遷移：現代CPU指令集（AVX2、BMI2、AVX512、ARM NEON等）的優化經驗通過社區貢獻者從國際象棋社區遷移到了中國象棋社區。

13.7 開源與閉源的博弈：社區權力的轉移

中國象棋引擎的開源與閉源之爭經歷了三個階段的演變：

第一階段：閉源獨佔期（1980s–2000s初期）

在這個階段，幾乎所有引擎都是閉源的。開發者將引擎視爲個人知識產權和商業產品，源代碼不對外公開。唯一的例外是一些大學研究項目中產生的引擎（如棋天大聖），但其代碼也不對外公開發布。

這個階段的問題在於：

• 技術的傳播完全依賴開發者個人的公開意願
• 當開發者停止更新引擎時，其技術積累也隨之消失
• 後來的開發者無法借鑑前人的成果，不得不"重新發明輪子"

第二階段：開源探索期（2005–2020）

以ElephantEye的開源爲標誌，部分開發者開始嘗試開源模式。黃晨選擇LGPL許可證的決策非常明智——既保證了代碼的自由使用，又允許商業項目在滿足許可證條件下使用代碼。

但這個階段開源引擎的棋力仍然遠低於商業引擎（通常差距在500-1000 ELO以上），因此開源引擎主要被用作學習工具而非實戰武器。

第三階段：開源顛覆期（2022–至今）

皮卡魚的出現徹底顛覆了力量格局。當開源引擎第一次在棋力上超越或持平商業引擎時，整個社區的權力結構發生了根本性變化：

• 從"商業驅動"轉向"社區驅動"
• 貢獻者從"個人愛好者"擴展到"全球開發者"
• 技術決策從"作者獨裁"轉向"社區共識"

這一變化的深遠影響仍在持續發酵中。

---

第十四章 雲計算與數據革命

14.1 中國象棋雲庫的誕生與架構

中國象棋雲庫（chessdb.cn）是中國象棋領域最具影響力的在線數據庫項目。它提供了大規模的開局庫和殘局庫查詢服務，是中國象棋引擎和界面工具中不可或缺的基礎設施。

雲庫的誕生：

中國象棋雲庫由一系列社區貢獻者共同建設和維護。它最初的想法來自於對中國象棋開局庫和殘局庫"各自爲戰"局面的不滿——每個引擎都有自己的開局庫，但相互之間無法共享和更新。

雲庫採用服務端-客戶端架構：

• 服務器端：存儲開局庫和殘局庫數據，提供Web API接口
• 客戶端：通過兵河五四等界面工具連接雲庫，查詢棋局數據

雲庫的數據規模：

根據雲庫官方網站的信息，截至2026年，雲庫的數據規模極爲龐大：

• 開局庫（Opening Book）：包含約2,000,000條開局走法
• 殘局庫（Endgame Tablebase）：
  • DTM版本（Distance to Mate，將殺距離）：15.71 TB
  • DTC版本（Distance to Conversion，轉化距離）：2.08 TB
  • 合計超過17 TB

雲庫的數據質量：

雲庫的數據質量通過以下機制保證：

1. 自動驗證：每次數據更新後自動運行正確性驗證
2. 社區審覈：社區成員可以報告錯誤或不一致
3. 版本控制：數據版本可追溯，支持回滾

14.2 雲庫的使用對引擎棋力的影響

雲庫的出現改變了引擎在開局和殘局階段的表現。使用雲庫的引擎在開局階段可以：

• 精確選擇最佳開局走法（基於雲庫中數百萬局的高水平對局統計）
• 避免走出已經證明不利的開局變例
• 學習雲庫中的新變化（包括大師級別的理論創新）

在殘局階段，雲庫使得引擎可以在已知殘局中走出精確的"最優走法"，包括最短將殺路徑。

雲庫對引擎實戰表現的提升：

雲庫數據的引入對引擎棋力的提升是顯著的。在使用雲庫前後，同一引擎的勝率可能提升5-10個百分點（在同等硬件和搜索設置下）。這種提升主要體現在：

• 開局階段的非戰鬥減員減少（避免走出劣勢開局）
• 殘局階段的"精確性"提升（在優勢和均勢殘局中不走彎路）

14.3 雲殘局庫

殘局庫生成原理

中國象棋殘局庫採用**回溯法（Retrograde Analysis）**生成：

1. 從終局開始：枚舉所有一方將殺或困斃對方的局面（勝利局面）。
2. 逆向推演：從勝利局面反向推理，找出所有能夠到達勝利局面的前一步局面。
3. 標註距離：將每個局面標註爲"勝"或"和"，並標註勝利所需的最少步數（DTM, Distance to Mate）或最少喫子步數（DTC, Distance to Conversion）。
4. 迭代擴展：不斷增加子力，逐步構建更復雜的殘局。

回溯法（Retrograde Analysis）的詳細過程：

回溯法的起點是"基本終局"——那些子力最少、結果已經確定的局面。例如，單將（帥）對單將（帥）的局面幾乎總是和棋（除非一方被將殺或困斃）。從這些基本局面出發，算法逐步添加棋子，計算更復雜局面的結果。

具體步驟：

1. 枚舉子力組合：確定要計算的子力組合（例如"車馬士對車雙象"），枚舉該組合下所有可能的棋子佈局。
2. 標註基本局面：在所有佈局中，標註那些已經是將殺或困斃的局面（基本勝利局面）。
3. 逆向推演第一輪：對於每一個"非基本局面"，檢查是否存在一步走法能夠到達已標註的勝利局面。如果存在，將該局面標註爲"勝"並記錄最優走法。
4. 逆向推演第二輪：檢查是否存在所有對手走法都通向"勝局面"的非基本局面……如此循環，直到所有可標註的局面都已被處理。
5. 剩餘局面標註：經過完整的逆向推演後，仍然無法標註的局面即爲"和局"或"未知"。

回溯法爲什麼極其耗費計算資源：

殘局庫計算的複雜度隨子力數量呈指數增長。以單車對士象全爲例：

• 需要考慮車（紅方）的所有可能位置：90個交叉點
• 將（紅方）的所有可能位置（九宮內）：約10個位置
• 士（紅方）的2枚棋子的所有組合位置
• 象（紅方）的所有組合位置
• 對方棋子同樣需要考慮

對於"車馬士相對車雙象"這樣的高難度殘局，可能的局面數量可以達到數十億甚至數萬億級別。這是爲什麼雲庫的殘局庫已經達到15.71 TB（DTM版本）的原因。

殘局庫與實戰的關係：

殘局庫對實戰的影響是革命性的。在殘局庫覆蓋的範圍內，引擎可以：

• 精確知道每個局面的勝負結果
• 在任何局面下走出最優走法
• 精確計算將殺所需的最少步數
• 在勝勢局面中不走任何彎路，直接以最短路線取勝

中國象棋雲庫的殘局庫規模：

根據雲庫官網（chessdb.cn）的數據，截至2026年：

殘局庫的子力組合覆蓋範圍包括：

• 全子力（所有7種棋子）：極限情況
• 多子力組合：車馬炮、車雙馬、雙車等
• 少子力組合：車兵、馬兵、炮兵等
• 基礎殘局：單缺象、單缺士、馬勝單士等

14.4 雲庫對社區的影響

雲庫不僅改變了引擎的使用方式，也改變了中國象棋社區的協作模式。具有以下特徵的協作方式得以實現：

1. 數據共享：社區成員可以共同擴充和完善開局庫和殘局庫數據。
2. 自動更新：引擎無需手動更新開局庫，所有數據同步通過雲庫自動完成。
3. 版本管理：數據版本可追溯，支持回滾和分支。
4. 開放API：第三方工具可以通過API接口查詢和參與數據維護。

14.5 NNUE評估 vs 傳統手工評估深度對比

NNUE評估的引入是中國象棋引擎歷史上最具革命性的技術變革之一。以下從技術實現細節和實際效果兩個維度進行深入對比：

注：NNUE並非完美無缺。它需要大量的高質量訓練數據、強大的GPU進行訓練以及支持AVX2等SIMD指令集的CPU進行高效推理。在低端硬件上，傳統手工評估仍然具有速度優勢。但總體而言，NNUE帶來的棋力提升是決定性的，目前所有頂級引擎均已轉向或正在轉向NNUE架構。值得注意的是，NNUE與手工評估並非互斥——最佳實踐是NNUE評估爲主，手工評估作爲輔助或兜底。

---

14.6 中國象棋引擎商業模式與授權方式對比

中國象棋引擎的商業化模式經歷了從盒裝軟件到在線授權再到開源免費的演變。不同的商業模式反映了市場環境、用戶需求和技術條件的變化：

注：中國象棋引擎的商業化一直面臨用戶基數小、付費意願弱、盜版嚴重的三重挑戰。盒裝軟件時代因互聯網盜版而終結，在線授權模式雖有改善但仍面臨破解和共享問題。開源模式（以皮卡魚爲代表）提供了一個全新的方向——通過社區協作降低開發成本，通過Fishtest框架實現分佈式質量保證，依靠GPLv3許可證防止閉源商業濫用。目前的趨勢是：頂級棋力引擎走向開源，商業引擎通過附加服務（開局庫、雲庫、技術支持）實現差異化。

14.7 三大技術路線對比：PVS+手工評估 vs MCTS vs NNUE

中國象棋引擎的發展歷程中出現了三條主要的技術路線。理解三者的優缺點是把握引擎技術演進方向的關鍵：

注：三條路線的競爭已經基本明朗——PVS+NNUE是當前無可爭議的最優方案。MCTS路線在圍棋中取得巨大成功（AlphaGo/Zero），但在中國象棋中未能超越PVS+NNUE，主要原因是中國象棋的分支因子（約40）遠低於圍棋（約250），使得PVS的剪枝效率遠高於MCTS的採樣效率。傳統PVS+手工評估路線雖然在2010年代統治了引擎界，但手工評估的精度天花板已經被NNUE徹底突破。

第十五章 中國象棋AIGC引擎與AI技術的融合

15.1 AIGC對中國象棋的影響

AIGC（生成式人工智能）對中國象棋的影響主要體現在兩個層面：

AI輔助內容生成： 高質量的中國象棋引擎分析不再需要專業軟件，皮卡魚等開源引擎的社區版本提供了遠超人類水平的高質量棋局分析。

教育與訓練： 藉助引擎API和大數據分析，象棋教育工具可以生成個性化的訓練計劃，根據學習者的水平自動調整訓練難度和內容。

15.2 引擎API與在線分析平臺的整合

引擎能力的開放使得各種在線平臺可以集成棋類分析功能。典型的架構包括：

用戶（Web/Mobile APP）
→ 前端（React/Vue界面）
→ 後端（API Server，如Nginx）
→ 引擎容器（運行皮卡魚等引擎）
→ UCCI協議通信
→ 引擎計算引擎（並行搜索+NNUE評估）

這種架構的實現需要解決以下技術問題：

1. 引擎進程的管理（啓動、停止、超時控制）
2. 併發請求的排隊和調度
3. 引擎和GPU資源的分配
4. 結果緩存的策略

15.3 中國象棋領域AI技術的展望

中國象棋領域的AI技術展望包括：

1. 更輕量化的部署： 隨着NNUE網絡的持續優化和硬件效率的提升，可以在輕型ARM設備甚至瀏覽器端運行接近頂級棋力的引擎。WebAssembly（WASM）技術的應用使得在瀏覽器中運行完整引擎成爲可能。

2. 個性化分析： 基於大語言模型的技術，可以實現自然語言層面的棋局分析和交互。用戶可以用自然語言提問引擎分析的問題（如"這裏我應該怎麼走？“或"這個局面的關鍵在哪裏？”），引擎通過分析棋盤後返回自然語言的解釋。

3. 交叉領域的研究： 中國象棋引擎技術與強化學習、遷移學習、少樣本學習等AI子領域的交叉研究有着廣闊前景。中國象棋的特殊性（不同規則的循環着法處理、炮的獨特性等）爲AI技術提供了有趣的研究課題。

4. 實時對弈分析： 隨着雲計算和邊緣計算的發展，實時的高水平對弈分析將普及。未來的在線對弈平臺可以在每步走棋後立即提供大師級別的分析，包括最佳走法、關鍵變例、戰術組合等。

---

第十六章 殘局庫檢測：數據校驗與準確性問題

16.1 數據庫殘缺檢測

在中國象棋雲庫的發展過程中，出現了一些殘局庫數據殘缺和錯誤的問題。這些問題來源於：

1. 生成算法的侷限性：回溯法雖然理論上可以準確計算所有殘局，但在面對極複雜局面時，由於計算資源限制，可能存在遺漏或錯誤。

2. 存儲錯誤：在後臺存儲和管理十幾TB的數據過程中，可能出現存儲錯誤或數據損壞。

3. 不同規則體系統一的問題：亞洲規則和中國規則在循環着法的處理上存在差異，殘局庫可能只適配了某一種規則。

16.2 數據修正的社區協作

殘局庫的數據修正主要通過社區協作完成。當社區成員使用引擎分析時發現殘局庫數據與預期不符（如應贏的殘局顯示爲和棋），會向雲庫管理員報告。

數據修正流程：

1. 用戶報告可疑局面
2. 管理員驗證錯誤是否存在
3. 如果確認錯誤，啓動重新計算流程
4. 將修正後的數據發佈到雲庫
5. 驗證修正結果

這種社區參與的糾錯機制在大規模數據維護中非常重要——自動生成的數據不可能100%正確，人工複覈和社區反饋是保證數據質量的關鍵環節。

---

第十七章 殘局與棋譜的藝術價值

17.1 經典殘局對引擎開發的挑戰

中國象棋有着豐富的經典殘局藝術，如"蚯蚓降龍"、“七星聚會”、"千里獨行"等。這些殘局的特點是子力少但變化複雜，通常包含精妙的戰術組合和深刻的局面判斷。

經典殘局對引擎的挑戰在於：

1. 戰術組合的深度：某些經典殘局需要在極深的搜索後方能發現正確走法
2. 評估的精確度：小優勢局面的精確評估需要極高精度的評估函數
3. 全局視角：某些殘局需要全局而非局部的局面理解

17.2 現代引擎對經典殘局的表現

現代NNUE引擎（如皮卡魚）對經典殘局的表現已經顯著優於傳統手工評估引擎。NNUE評估網絡可以學習到經典殘局中的模式識別和戰術判斷，即使沒有顯式的規則編碼：

• 對於"蚯蚓降龍"這樣的精深殘局，現代引擎可以快速發現正確走法
• 對於"七星聚會"這樣的大規模殘局，現代引擎可以給出準確的分析和變化

17.3 棋譜數字化與文化保存

中國象棋的棋譜數字化工作對文化保存具有重要意義：

1. 傳統棋譜的電子化：將歷史上的大師棋譜和經典殘局譜錄入電子系統
2. 引擎分析的標註：使用引擎對歷史棋譜進行深度分析，發現新的變化和註解
3. 棋譜數據庫的建設：建立公共的、可搜索的棋譜數據庫

---