5個AI代理寫國際象棋引擎：1200分打贏Stockfish的魔

我讓5個AI代理從零寫了一個國際象棋引擎。不是調API，不是抄開源代碼，是真正意義上的"白紙起高樓"——1個架構師畫藍圖，3個工程師并行施工，1個項目經理盯進度。

目標定得很具體：在1200 ELO（埃洛等級分，國際象棋衡量水平的標準單位）級別擊敗Stockfish，勝率至少50%。

48小時后引擎跑通了。但真正讓我坐直身體的，不是它真的贏了，而是整個協作過程中那些反直覺的發現。

架構師才是最貴的

我最初以為瓶頸在工程師——畢竟寫代碼的是它們。錯了。

第一次跑的時候，我偷懶讓架構師隨便畫了個草圖。結果三個工程師互相卡?。涸u估模塊等棋盤表示模塊完工，搜索模塊等前兩個都完工。理論上并行，實際上串行，三個代理輪流發呆。

修復方案很"不互聯網"：讓架構師多花時間，多用貴得多的Opus模型（Anthropic旗下能力最強的版本），明確指令——"分解工作時確保每個工程師能立即開工，無需等待他人輸出，接口必須預先定義"。

第二次的架構產出完全不同：清晰的模塊邊界、統一放在types.rs里的共享類型定義、每個工程師都能直接編碼的存根實現。三個工程師在幾秒內同時啟動。

在監督式AI代理執行中，規劃階段的質量決定了整個系統的吞吐量。

這像極了人類團隊的管理誤區——急著讓人寫代碼，結果返工成本更高。AI代理不會抱怨，但它們的git提交記錄會誠實反映混亂。

Markdown當任務板，意外地夠用

沒有Jira，沒有Notion，沒有花里胡哨的協作工具。任務板就是一個Markdown文件：

## To Do

- [ ] 實現棋盤表示（位棋盤）

- [ ] 實現走法生成（合法走法）

- [ ] 實現局面評估（子力+位置表）

- [ ] 實現搜索（帶迭代加深的Alpha-Beta剪枝）

- [ ] 實現UCI協議接口（通用象棋接口，讓引擎能與圖形界面通信）

- [ ] 編寫針對已知局面的集成測試

## In Progress

## Done

項目經理代理（同樣用Claude）負責解析這個文件，決定把任務派給誰。工程師完成后自己勾選，項目經理下一輪讀取狀態。

粗糙得像個玩笑。但正是這種粗糙，讓系統意外健壯——沒有復雜狀態機，沒有分布式鎖，一個文本文件就是唯一的真相來源。

我觀察到一個細節：當兩個工程師同時想認領同一任務時，項目經理會按輪詢順序分配，并在消息里寫明"由工程師-2處理，工程師-1繼續當前工作"。沒有沖突，沒有競態條件。

位棋盤：工程師-1的獨角戲

棋盤表示模塊的負責人拿到的是個經典難題：用64位整數表示整個棋盤，每個位對應一個格子，棋子位置用位運算操作。

這比數組表示快得多，但代碼可讀性極差。工程師-1（Claude Sonnet）生成的第一版有bug：王車易位的權限位更新邏輯錯誤，導致特定局面下會允許非法易位。

測試套件捕獲了這個問題。不是項目經理發現的，是預置的已知局面測試——輸入FEN字符串（福斯-愛德華茲記號，描述象棋局面的標準格式），驗證生成的走法列表與Stockfish一致。

工程師-1收到失敗報告后，在下一輪迭代中修復。整個過程沒有人類介入。

我檢查了它的git歷史：第一次提交是"實現基礎位棋盤結構"，第二次是"修復王車易位權限更新"，第三次是"添加邊界測試用例"。自我修正，自我完善。

走法生成：最臟的活，最穩的輸出

工程師-2負責合法走法生成。這是象棋編程中最繁瑣的部分——要考慮將軍、應將、兵的升變、吃過路兵、王車易位，每種情況都要生成所有合法變例。

它的策略很務實：先實現偽合法走法（不考慮是否送王），再用單獨函數過濾掉會導致自己被將死的走法。分而治之，降低認知負荷。

我注意到一個有趣的代碼注釋——代理自己寫的："http:// 注意：此處需檢查易位路徑是否被攻擊，不僅是落點"。這是從測試失敗中學到的教訓，被顯式記錄下來供后續迭代參考。

最終該模塊通過了全部200個已知局面的測試，包括一些刁鉆的排局：雙將局面、逼和陷阱、升變優先級。

評估函數：3個工程師的唯一交集

工程師-3的局面評估模塊是唯一需要讀取其他模塊輸出的部分——它要調用棋盤表示來獲取子力分布，但設計上保持了最小耦合。

實現很樸素：子力價值表（兵=100，馬=320，象=330，車=500，后=900，王=20000）加上簡單的位置加分（馬在中心更強，兵推進更遠更好）。

沒有神經網絡，沒有機器學習，純手工調參的啟發式。1200 ELO級別不需要更復雜的東西。

但這里出現了整個項目最有趣的協作細節：評估模塊需要知道"當前輪到哪方走棋"，而這個信息最初只在棋盤表示內部維護。工程師-3在第一次嘗試時直接訪問了內部字段，導致編譯失敗——模塊邊界被嚴格執行。

它向項目經理報告："需要棋盤表示暴露當前行棋方接口"。項目經理轉達給工程師-1，下一輪迭代中types.rs增加了相應方法。沒有撕逼，沒有站會，純文本驅動的需求流轉。

搜索與UCI：最后的拼圖

搜索模塊由工程師-1在完成棋盤表示后接手。Alpha-Beta剪枝帶迭代加深，標準實現，沒有驚喜。

UCI協議接口是個有趣的挑戰——它要讓引擎能跟Arena、Cutechess等圖形界面通信，接收"go depth 10"這樣的命令，返回"bestmove e2e4"。

工程師-2在完成走法生成后協助這部分，因為它最熟悉命令解析的細節。兩個代理的代碼在合并時出現了命名風格沖突：一個用snake_case，一個用camelCase。項目經理在代碼審查消息中標記了這個問題，要求統一為snake_case（Rust慣例）。

第二次提交就一致了。代理不會堅持個人風格，收到反饋就改。

對戰Stockfish：50.3%勝率

最終測試跑了100局快棋（每方5分鐘）。引擎在1200 ELO設定下對Stockfish取得50.3%勝率——剛好壓線達標。

我分析了輸掉的49局：大部分是殘局技術失誤，比如王兵殘局不會"對王"，車兵殘局不懂"制造通路兵"。評估函數的簡單啟發式在子力稀少時失效。

但這不是重點。重點是整個開發過程：5個代理，48小時，零人類寫代碼，產出可工作的復雜軟件。

最反直覺的發現是什么？監督成本。我原以為需要頻繁干預，實際上除了啟動命令和查看最終對戰結果，我只做了兩件事：調整架構師的規劃時間預算，以及在Markdown任務板里補充了兩個測試用例。

其余時間我在旁觀，像看一場編排精密的機械芭蕾。

代理們會犯錯，會自我修正，會在代碼注釋里記錄教訓。它們不會累，不會抱怨需求變更，不會為命名風格吵半小時。

但也不會主動問"我們為什么要做這個"，不會質疑目標本身的合理性，不會在遇到根本矛盾時拍桌子說"這需求有問題"。

這引出一個問題：如果給這5個代理更模糊的目標——"做一個好玩的象棋程序"——它們會產出什么？會自己定義"好玩"嗎，還是陷入無限循環的架構討論？