4.3 Naive MCTS：用随机模拟代替评估函数

1.7 我们已经见过 MCTS 的四步循环。这一章把它真正用在围棋上——这是围棋 AI 第一个“能打”的范式，也是 capstone App 里 AI 的真身（对应 go/engine.py 的 MCTS）。

一、四步循环（回顾）

每想一步棋，就重复成千上万次下面这个循环，在脑中长出一棵搜索树：

重复很多次(直到超时):
  1. 选择 Select  : 从树根沿 UCT 挑“最值得看”的岔路，走到树边缘
  2. 扩展 Expand  : 在边缘加一个没试过的新着法结点
  3. 模拟 Simulate: 从这里【随机】把棋下到终局、数子定胜负
  4. 回传 Backprop: 把胜负沿走过的路径一路记账
最后: 选树根下【被访问最多】的着法走出去

二、模拟（playout）：评估从哪来

这是 MCTS 的灵魂，也是它和 α-β 最根本的区别：

随机模拟(局面):
  双方轮流【随机】落子(只避开“填自己的真眼”，否则棋永远下不完)
  一直下到双方都没好点可下 -> 数子 -> 返回谁赢

一个着法好不好，不靠人写的估值公式，而靠“从这里随机开打，赢的次数多不多”。这一步替代了围棋根本写不出的评估函数。

三、UCT：利用 vs 探索

每个岔路口怎么选？用 UCT 公式给每个候选打分，取最高：

UCT = 该着法胜率  +  C × √( ln(父访问数) / 该着法访问数 )
       └ 利用：越好越想继续看      └ 探索：越少试过越要给机会

只看胜率会死磕一条路、埋没好棋；探索项让冷门着法也有翻牌机会。C 调大更爱探索。这就是 MCTS 的 exploration / exploitation 权衡。

四、它能下，但下不强

把它跑起来：会提子、守规则、围空、正确终局——是合法的围棋，远胜纯随机。但棋力只到入门级，因为它太“naive”：

• 19×19 一盘随机模拟要几百手，纯 Python 每步只能跑几千次模拟，对 361 个候选点远远不够；
• 随机模拟太无脑，对死活、复杂战斗几乎没判断。

这正是 2006 年的起点（MoGo 等）。下一章看人们怎么把这套纯 CPU 的 MCTS 榨到极限。