主评估入口：Evaluate(pos, vlAlpha, vlBeta)
│
├─ 1. 基础层：PreEval 已初始化
│     vlWhite = 红方棋子位置价值之和
│     vlBlack = 黑方棋子位置价值之和
│     存入 pos.vlWhite / pos.vlBlack
│
├─ 2. 搜索节点类型判断
│     if 当前深度 == LIMIT_DEPTH          → 叶子节点
│         return SearchQuiesc(pos, vlAlpha, vlBeta)   // 进入吃子延伸
│     else
│         goto 静态评估链
│
├─ 3. 静态评估链（逐步累加 + 可剪枝）
│     vl = pos.Material()                 // 子力基准
│     if vl + MARGIN1 ≤ vlAlpha or vl - MARGIN1 ≥ vlBeta
│         return 截断值                   // 浅层剪枝
│
│     vl += pos.AdvisorShape()            // 士象形状
│     if vl + MARGIN2 ≤ vlAlpha or vl - MARGIN2 ≥ vlBeta
│         return 截断值
│
│     vl += pos.StringHold()              // 牵制威胁
│     if vl + MARGIN3 ≤ vlAlpha or vl - MARGIN3 ≥ vlBeta
│         return 截断值
│
│     vl += pos.RookMobility()            // 车机动性
│     if vl + MARGIN4 ≤ vlAlpha or vl - MARGIN4 ≥ vlBeta
│         return 截断值
│
│     vl += pos.KnightTrap()              // 马陷阱
│
├─ 4. 兵过河奖励（源码在 Evaluate 末尾）
│     for 每方
│         for 每只兵
│             if 已过河
│                 vl += SIDE_VALUE(sdPlayer, 1)   // 红+1 黑-1
│
├─ 5. 返回最终静态值
│     return vl
│
└─ 5'. 叶子节点替代路径（Quiescence）
      SearchQuiesc(pos, vlAlpha, vlBeta)
      ├─ 只生成吃子 / 将军等“高波动”走法
      ├─ 递归调用静态搜索直至平静
      └─ 返回平静局面评估值

preeval的PreEvaluate()函数和evaluate的Evaluate()函数是什么关系

🔍 1. 调用时机

🔍 2. 数据依赖

// PreEvaluate() 产出
PreEval.ucvlWhitePieces[pt][sq]   // 红方 pt 类棋子在 sq 的“位置价值”
PreEval.ucvlBlackPieces[pt][sq]   // 黑方同上
PreEval.vlAdvanced                // 中残局倾向偏移分

// Evaluate() 直接使用
vl += PreEval.ucvlWhitePieces[pt][sq];   // 直接查表，不再计算

🔍 3. 职能边界

🔍 4. 伪代码对照

////////// preeval.cpp //////////
PreEvaluate(pos):
    μ ← 计算中残局因子
    for pt in 0..6:
        for sq in 棋盘:
            PreEval.ucvlWhitePieces[pt][sq] ←
                (μ*MidTable[pt][sq] + (66-μ)*EndTable[pt][sq]) / 66
    PreEval.vlAdvanced ← 根据剩余子力给偏移分


////////// evaluate.cpp //////////
Evaluate(pos, α, β):
    vl ← pos.Material()                 // 1. 子力
    if 剪枝: return vl
    vl ← vl + PreEval 已算好的位置值    // 2. 直接查表（PreEval 成果）
    if 剪枝: return vl
    vl ← vl + AdvisorShape()            // 3. 动态附加题
    vl ← vl + StringHold()
    vl ← vl + RookMobility()
    vl ← vl + KnightTrap()
    vl ← vl + 过河兵奖励
    return vl

✅ 一句话总结

PreEvaluate() 把“昂贵但不变”的位置价值提前算好并制成表；
Evaluate() 在搜索时“秒查这张表”作为基础，再实时加上“便宜但变化”的动态因素。

那么为什么他们最后的值要累加，而可以在各自的运算中有不同的子力值体系？

✅ 一、量纲本质不同

三者单位都是“评估分”，但来源不同、用途不同，就像温度、湿度、风速都可读数，却不需要数值上对齐。

✅ 二、使用场景与更新频率

✅ 三、累加合法性：只是“线性加权”

vl = Material()                      // 子力差
   + PreEval 表值                     // 位置差
   + AdvisorShape()                   // 形状差
   + ...

• 所有项都是“差值”（红 - 黑），因此量纲一致。
• 线性可加性是 Alpha-Beta 搜索的基本假设。
• 系数无耦合：PreEval 的“车=90”与 MVV-LVA 的“车=4”永不相遇，不会出现在同一算式。

✅ 四、形象比喻

你不会把“地段溢价”与“保底面积价”拿来比大小，但它们可以加在一起算总房价。

✅ 五、一句话总结

“位置价值”“动态特征”“交换性价比”三类分数来源不同、用途不同、更新频率不同，只因它们都表示‘红方减黑方的优劣’，所以可以在最终评估中线性累加；而它们各自的子力值体系互不干扰，因为永远不会出现在同一算式里。”

inline int Evaluate(const PositionStruct &pos, int vlAlpha, int vlBeta) {
  int vl;
  vl = Search.bKnowledge ? pos.Evaluate(vlAlpha, vlBeta) : pos.Material();
  return vl == pos.DrawValue() ? vl - 1 : vl;
}

✅ 逐行拆解

✅ 形象比喻

你手里只有一杯液体：

• 要么装的是 矿泉水（Material）
• 要么装的是 糖水（Evaluate 全链）

绝不会把矿泉水和糖水倒在一起喝，只是用同一个杯子装其中一种而已。

✅ 一句话总结

这行代码是“二选一”而非“相加”：
开知识就返回完整评估分，关知识就返回子力差；两者永不同时出现，因此不存在量纲冲突。

局面评价函数接口干什么用的？

✅ 一句话职责

“给搜索一个数，告诉它当前局面红方比黑方好多少分，且这个数必须能安全地与 α、β 做比较。”

✅ 为什么必须存在这一层“接口”

✅ 伪代码视角：搜索框架怎么看它

function AlphaBeta(pos, depth, α, β):
    if depth ≤ 0:
        return Evaluate(pos, α, β)   // ← 仅此一句，万事大吉

    for mv in 生成走法():
        pos.MakeMove(mv)
        val = -AlphaBeta(pos, depth-1, -β, -α)
        pos.UndoMakeMove()
        ...

• 有没有用 PreEval 表；
• 有没有加形状分；
• 有没有做静态搜索；
• 返回值为什么比 DrawValue 小 1。

✅ 再通俗一点

搜索是裁判，只问“谁领先多少分”；
Evaluate 是计分板，把复杂规则翻译成裁判能懂的数字。

✅ 总结

1. 封装：把多种评估源包成“一行调用”。
2. 统一量纲：返回的分数可直接与 α、β 比较。
3. 可控开关：通过 bKnowledge 一键切换“快速子力”与“全知识”。
4. 防冲突：微调和棋值，避免与搜索约定值撞车。