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

系統梳理中國象棋計算機博弈從 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。