兄弟，我太懂你这种卡壳的感觉了！我当初把Minimax改成Alpha-beta剪枝的时候，也踩过一模一样的“永远选第一个节点”的坑，折腾了大半天才搞明白问题出在哪。结合你的情况，大概率是最优候选节点的初始化或更新逻辑出了问题，下面给你拆解几个关键排查点：

1. 别一开始就把最优节点绑定到第一个子节点 #

很多人改代码的时候，会习惯性地把best_node初始化为第一个子节点，然后后续遍历的时候忘了正确替换——这是最常见的坑！

比如错误的写法：

def alpha_beta_max(node, alpha, beta):
    # 错误：直接把第一个子节点设为初始最优
    best_node = node.children[0]
    best_val = alpha_beta_min(best_node, alpha, beta)
    for child in node.children[1:]:
        val = alpha_beta_min(child, alpha, beta)
        # 这里如果判断条件写错，就会一直保留第一个节点
        if val > best_val:
            best_val = val
            best_node = child
        alpha = max(alpha, best_val)
        if alpha >= beta:
            break
    return best_node, best_val

正确的做法是先初始化一个“无意义”的最优节点，同时把估值设为对应玩家的最坏情况（Max玩家设为负无穷，Min玩家设为正无穷），然后遍历所有子节点，只要当前子节点的估值更优，就更新最优节点：

def alpha_beta_max(node, alpha, beta):
    best_val = float('-inf')
    best_node = None  # 初始化为None，不绑定任何节点
    for child in node.children:
        current_val = alpha_beta_min(child, alpha, beta)
        # 只要当前节点估值比现有最优好，就替换
        if current_val > best_val:
            best_val = current_val
            best_node = child
        # 更新alpha的时机要在更新最优值之后
        alpha = max(alpha, best_val)
        # 剪枝逻辑没问题，剪的是不可能更优的分支
        if alpha >= beta:
            break
    return best_node, best_val

2. 检查剪枝逻辑是否干扰了最优节点更新 #

你提到“多数运行符合预期，但始终选第一个节点”，说明剪枝本身没彻底崩，但更新逻辑没触发。要确认：

• 遍历子节点时，是不是每个节点都计算了估值？有没有因为错误的剪枝提前break，导致后面的节点根本没被评估？
• alpha和beta的更新时机是不是正确？比如要先更新best_val，再用best_val去更新alpha/beta，不然会导致剪枝条件提前触发，漏掉更优的节点。

3. 先回退到Minimax验证逻辑 #

把Alpha-beta的剪枝代码（if alpha >= beta: break和alpha/beta更新）注释掉，变回纯Minimax，看是不是还会选第一个节点：

• 如果还是选第一个，那问题根本不在剪枝，而是你原本的Minimax里的最优节点选择逻辑就有问题（比如更新条件写错了）；
• 如果Minimax能正常选最优节点，那就是你在适配Alpha-beta时，不小心改坏了原本的更新逻辑。

快速排查小技巧 #

在遍历子节点的时候，加几行打印日志：

print(f"当前子节点: {child}, 估值: {current_val}, 当前最优值: {best_val}, 当前最优节点: {best_node}")

这样你就能清楚看到，当出现估值更高的子节点时，best_node有没有被正确替换——大概率你会发现，要么更新条件没触发，要么初始值设错了导致后续的替换逻辑不生效。

内容的提问来源于stack exchange，提问作者Lich