尧图网页设计 
简介这是一份基于H5开发的经典版象棋AI在线对弈网页源码适合前端开发者、棋类游戏爱好者也可作为Web游戏方向毕业设计或课程项目的参考。整套对弈逻辑集中在js脚本中覆盖AI决策、开局库、对局存储与公共工具等模块内含可扩展的AI落子算法并内置两套界面皮肤方便对比或二次改版。压缩包共75个文件40个png与2个jpg负责棋盘、棋子及皮肤素材7个js实现AI与棋局逻辑1个html作为入口页面1个css统一样式24个url为附属链接文件整体仅1.55MB轻量易部署。已有2236人学习下载适合用于研究人机对弈流程、修改棋力强度或快速搭建设计演示原型。 自己花了不少时间打磨过一套象棋H5项目正好前几天有人问起来。今天就直接把这套象棋源码H5开发设计的象棋 AI在线对弈网页页面的做法讲透标题里写的全新經典版内嵌ai算法其实说的就是三件事一个能跑的H5对弈页面、一套完整的中国象棋规则引擎、以及一个不需要服务器也能在浏览器里跑的AI下棋算法。适合想把棋类游戏做成网页版的前端开发者也适合刚接触AI极小极大搜索、想找个真实落地方案的初学者参考。1. 项目整体设计与技术选型1.1 功能边界与需求画像动手之前先得把功能边界定清楚。这个项目的定位是纯前端H5实现的人机对弈页面所以核心功能必须包含棋盘绘制、棋子渲染、行棋规则校验、胜负判定、AI自动走棋、悔棋与重新开始以及最基本的回合提示。再往外可以加UI音效、走棋动画、难度选择但这些属于锦上添花。我建议第一版不要一上来就做联机对战原因很实在。联机意味着必须引入WebSocket或后端服务而一旦引入后端部署、鉴权、断线重连、帧同步这些问题都会涌出来对一个小型H5项目来说是巨大的成本。先把AI对弈这一条线做扎实才是这个标题背后最核心的价值点单机也能让用户玩出深度。整个页面我采用的是单页H5结构传统九宫格棋盘、红黑双方棋子。用户执红先手AI执黑后手通过点击选中棋子、点击目标位置落子。这听起来简单但背后牵扯到的规则种类要比围棋、五子棋复杂得多因为中国象棋特殊的马脚、象眼、炮架、将帅不能照面、兵未过河不能横走等等都需要用代码精确表达。1.2 技术栈选型为什么用这个方案选型时要考虑落地成本、运行环境兼容性、以及后续扩展空间。渲染方案我采用的不是Canvas而是纯DOM加CSS定位。这种方案的优点是交互事件好处理点击命中检测不需要自己写坐标换算而且棋盘和棋子的样式可以完全交给CSS去美化。棋子本身用div加背景图或文本符号渲染一套代码在桌面端的Chrome、Safari移动端的微信浏览器、飞书内置浏览器里都能正常跑。前端框架项目用的是原生JavaScript配合少量Vue语法风格的组织方式并没有强行上工程化框架。原因在于象棋核心算法的复杂度集中在棋盘逻辑不集中在UI状态管理上。用原生JS写一个Game对象、一个AI对象、一个Render对象模块清晰也方便和其他前端框架集成。AI引擎选用的是经典的极小极大搜索Minimax加Alpha-Beta剪枝。这是单机棋类AI最成熟的方案不依赖GPU、不需要训练数据纯计算逻辑就能达到不错的棋力。相比深度学习方案这种实现放在浏览器里运行不会带来模型体积和推理延迟的痛点。后面我会把具体实现细节摊开来讲。规则引擎纯前端实现用二维数组表示棋盘状态。数组比对象更适合做局面存储因为它天然支持坐标索引在走法生成和局面评估时效率很高。这套组合最终呈现出来的效果是用户打开网页即可对弈不需要登录、不需要安装、不需要后端服务部署时丢到任何静态文件服务器上就能跑。2. 棋盘与对弈逻辑的实现要点2.1 棋盘建模与走法生成大部分象棋源码把棋盘做成9列乘10行的二维数组行和列都用数字索引。比如红方的帅初始位置在数组下标[9][4]黑方将在[0][4]兵的位置在[6][0]、[6][2]等。每一种棋子用整数常量表示比如0代表空位1代表红帅2代表红仕3代表红相4代表红马5代表红车6代表红炮7代表红兵黑色方则用负数或加偏移量的方式表示。这里有一个细节要注意红黑双方如果都用对称的数字编码AI评估时需要考虑正负号如果直接采用一组独立编码评估函数里又得做一次映射。我更推荐用一个side字段区分阵营棋子值只表示棋子类型这样后期做规则扩展和调试时定位问题更快。走法生成是所有对弈逻辑的核心也是AI算法的基础。我单独维护了一个生成器文件按棋子类型分别写出走法车的走法沿横竖两个方向直线行走遇到棋子停止如果是敌方棋子则增加一个吃子走法。马的走法八个方向同时要判断对应方向有没有蹩马腿。象的走法沿对角线走两格塞象眼的位置不能有棋子同时不能越过河界。士的走法只允许在九宫格内沿斜线走一步。将的走法只能在九宫格内上下左右走一步同时还要检测和对方将帅是否照面。炮的走法直线行走和车一样不吃子时不隔子吃子时必须隔一个炮架。兵的走法未过河时只能向前走一步过河后才能左右移动和向前移动。function generateMoves(board, side) { const moves []; board.forEach((row, r) { row.forEach((piece, c) { if (piece 0 || board.pieceSide(r, c) ! side) return; const type Math.abs(piece); const routes getRoute(type, r, c, side, board); routes.forEach(target moves.push({ from: [r, c], to: target })); }); }); return moves; }2.2 行棋校验与胜负判定行棋校验分为两块一是规则层面二是结果层面。规则层面指的是用户点击棋子、再点击目标位置后程序要判断这一步是否合法。简单做法是点击第一个棋子时高亮当前棋子的所有合法走法用户目标位置如果在合法列表里则执行移动如果不在则视为无效点击。这样做的好处是把非法走法的判断前置不必在点击后再反查规则。结果层面则是在一次移动产生后检查对方是否还有合法走法。如果对方将帅被吃直接判负如果对方将帅没有被吃但无子可动判负如果双方都无法形成绝杀且重复局面超过一定次数判和。长将循环检测需要维护一个局面历史表这里我会在后面的常见问题部分展开。胜负判定推荐放在AI调用之前执行否则AI面对一个已经结束的棋局还在无限搜索白白浪费性能。3. AI算法的架构设计3.1 棋子价值评估函数评估函数决定了AI眼光的远近。最基础的做法是给每种棋子设置静态分值棋子价值分备注帅/将10000被吃即输分值需远大于其他棋子总和车900强子马400中后期因蹩马腿价值波动炮450开局价值高残局略降相/象200防守型棋子仕/士200防守型棋子兵/卒100过河后可加至120-150如果只按这组静态值评估AI会表现出只顾眼前大子的问题。所以我在评估函数里还加入了位置奖励表。位置奖励表本质上是一张和棋盘同尺寸的二维数组不同棋子在不同坐标上有不同的加减分。比如中路兵过河后位置分要高一些因为对中路有压制作用马在边线要扣分因为活动空间被压缩炮在开局阶段占据中路或肋道会有小加分因为便于配合车马进攻。function evaluate(board) { let score 0; for (let r 0; r 10; r) { for (let c 0; c 9; c) { const piece board.get(r, c); if (piece 0) continue; const value baseValue[piece.type] positionBonus[piece.type][r][c]; score piece.side RED ? value : -value; } } return score; }红方为正、黑方为负AI搜索时如果是红方走棋就追求最大化分数黑方走棋就追求最小化分数。对称的局面评估函数可以保证AI不偏向某一方。3.2 极小极大搜索与Alpha-Beta剪枝评估函数只能看一步AI要继续变强必须向前推演多层。极小极大搜索的思路是轮到某一方走棋时它会在自己的所有可选走法中选择评估分数最大的那一步同时假设对手也会在它的局面里选择对AI最不利即分数最小的走法。这样交替推演直到搜索深度到达设定阈值。纯粹的极小极大搜索在象棋这种分支因子很高的游戏里非常昂贵。象棋平均每个局面有几十个合法走法搜索到第4层就要算几十万的叶子节点。Alpha-Beta剪枝能把搜索量压缩到完整搜索的三分之一甚至更少核心思想是维护两个边界值alpha表示当前走棋方能接受的最低分数下限beta表示当前走棋方不能超过的分数上限。在某一分支上发现对手已经能导致分数低于alpha那这条分支就没必要再往下搜索了。AI的搜索入口代码大致是这个形态function search(depth, alpha, beta, side) { if (depth 0) return evaluate(board); const moves orderMoves(generateMoves(board, side)); if (moves.length 0) return -INF; let bestScore -INF; for (const move of moves) { doMove(move); const score -search(depth - 1, -beta, -alpha, -side); undoMove(move); if (score bestScore) bestScore score; if (bestScore alpha) alpha bestScore; if (alpha beta) break; } return bestScore; }这里用-search(-beta, -alpha)这种Negamax写法可以统一红黑双方的思路不用区分求最大还是求最小。剪枝条件alpha beta就是整个搜索效率的关键。不走法排序的Alpha-Beta剪枝效率会比较差。因为AI会按顺序盲目地检查每一个走法如果最差的走法排在前面它会先踩到很低的分数导致后面所有好走法都不能提高alpha剪枝的机会变少。所以在进入递归前我用了orderMoves函数将吃子走法尤其是兵吃车、炮打帅这种高价值吃低价值排在前面普通走法排在后面。这一步能让搜索效率提升好几倍。3.3 AI难度分级与策略调整标题里写了AI在线对弈用户期望的是能选择难度。我做了三个档位初级搜索深度2层不做走法排序随机扰动评估分数AI会偶尔下出昏招适合新手。中级搜索深度4层启用Alpha-Beta剪枝和走法排序评估函数不加入位置分。高级搜索深度6层启用杀手走法记忆和置换表评估函数完整版。置换表是一块以局面哈希值为索引的缓存。象棋一盘棋下来很多局面会通过不同走法路径反复到达如果每次都要重新搜索浪费极大。我用一个简易的Zobrist哈希把当前局面映射成一个64位整数再把搜索结果和深度存入一个Map中。搜索开始时先查表如果表里存的深度不小于当前搜索深度直接复用结果。在6层搜索的高级档位下置换表大约能减少30%以上的重复计算。4. 关键代码落地与实操过程4.1 棋盘状态管理与走法执行实际编码过程中我先把棋盘对象封装成了一个类Board维护一个10行9列的二维数组和当前走棋方。落子操作统一由move(piece, from, to)完成其中包括更新数组、处理吃子、更换走棋方、记录历史状态用于悔棋。悔棋这里有个坑如果只是把走子过程倒放一遍容易在吃子的情况下忘记恢复被吃棋子所以我直接采用快照式悔棋每次走棋前把整个棋盘数组深拷贝一份压入栈中悔棋时弹出栈顶快照。这种做法虽然内存开销稍高但逻辑非常简单而且在实际对弈场景下一盘棋最多两三百步快照量很小根本不会对性能造成影响。相比之下增量式记录节省的内存微乎其微却平白增加了debug难度。class Board { constructor() { this.grid this.initGrid(); this.turn RED; this.history []; this.zobrist new ZobristHash(); } applyMove(move) { this.history.push(cloneGrid(this.grid)); this.grid[move.to[0]][move.to[1]] this.grid[move.from[0]][move.from[1]]; this.grid[move.from[0]][move.from[1]] 0; this.turn -this.turn; this.zobrist.update(move); } undoMove() { this.grid this.history.pop() || this.initGrid(); this.turn -this.turn; } }4.2 AI搜索模块的运行流程AI的完整运行流程比上面贴的搜索函数要再多两步。第一步是AI启动时的线程调度。浏览器主线程如果执行深度为6的搜索可能会有几百毫秒的卡顿用户点击棋子后页面会失去响应。我的处理是给搜索套上一层setTimeout让搜索任务被放到事件循环的下一个阶段执行这样UI可以在搜索开始前先完成棋子移动动画。如果深度设定较高也可以使用Web Worker让搜索跑在独立线程里主线程始终保持流畅。第二步是根节点的特殊处理。搜索入口只能返回分数真正决定AI走哪一步需要在根节点遍历所有走法逐个调用搜索函数并记录最优走法对应的落子坐标。另外根节点还可以配合时间控制如果搜索到设定深度后耗时仍然超过预估值就停止加深以避免用户等待时间过长。function aiMove(board, depth) { const moves generateMoves(board, AI_SIDE); let bestMove null; let bestScore -INF; for (const move of orderMoves(moves)) { board.applyMove(move); const score -search(depth - 1, -INF, INF, HUMAN_SIDE); board.undoMove(); if (score bestScore) { bestScore score; bestMove move; } } return bestMove; }在上面这段代码里search函数内部最大搜索深度是depth而不是depth - 1也没有关系关键是根节点这一层不能计入相同深度否则AI的实际搜索层数会比设定值多一层运行时间成倍增加。4.3 H5端交互与移动端适配移动端的操作体验和桌面端差距很大首先要处理的就是点击还是触摸。H5页面要想同时兼容鼠标和触摸我统一监听pointerdown和pointerup这样不用分别处理click和touch事件也不会出现移动端300ms延迟或者吞事件的问题。如果项目需要兼容老版本浏览器再降级处理。棋盘尺寸在移动端需要做自适应。我的做法是使用CSS的min(90vw, 70vh)作为棋盘容器边长然后棋子间距按棋盘边长除以9等分换算。这样不管用户用手机还是电脑打开棋盘都能保持在屏幕视觉中心不会出现棋子溢出屏幕的情况。还有一点容易被忽略页面顶部和底部的安全区域。iOS的Safari和微信浏览器底部有横条如果按钮和棋谱信息放在页面底部会被遮挡。我在设置页面padding时额外加了env(safe-area-inset-bottom)这也算是H5项目里的老生常谈但很多初创项目依然会漏掉最终影响体验。5. 常见问题与排查经验5.1 AI响应卡顿与搜索超时我在4层深度的中级档下AI单步耗时有明显的波动。原因在于残局阶段虽然棋子减少但走法数量并没有等比例下降某些局面下例如车炮兵残局分支仍然很多加上评估函数在叶子节点要做大量数组遍历耗时会从平均200ms飙升到800ms以上。解决思路有两个方向。第一个是限制搜索时间在搜索过程中定时检查当前耗时一旦超过400ms就强制返回当前最优走法。第二个是引入迭代加深先搜1层再搜2层、3层层层递进每一层搜索完成后记录当前最优解一旦超时就立即返回上一层的结果。迭代加深本身还会带来一个附加收益上一层搜索得到的走法顺序可以作为下一层的走法排序参考进一步提升剪枝效率。实测下来迭代加深配合时间控制在高级档位下的体验是最顺畅的用户几乎感觉不到AI在思考落子速度稳定在一秒以内。5.2 重复局面与长将判定如果AI只是一味搜索、不走规则判定会出现一个经典问题在优势局面下AI可能因为搜索深度不够而选择循环将军步数多了之后形成长将这在正式对弈中属于违规。但用户如果是真人程序不说清楚很容易被误认为是AI死机了。我的处理是在AI搜索过程中每走一步都检查当前局面是否在最近8步内重复出现过。如果连续重复出现两次以上就认为当前分支会让局面走向不变把这条分支的评估分数降低让AI更倾向于选择其他有进展的走法。配合局面历史哈希表这个判断可以做到常量时间内完成。5.3 跨端浏览器兼容与内嵌页面适配这套H5源码我在Chrome、Safari、微信浏览器、飞书、钉钉的内嵌容器里都测过。最容易出问题的不是JS语法而是CSS的aspect-ratio、gap这类属性在部分老版本WebView中不支持。解决方案是使用padding-bottom百分比配合绝对定位或者直接用Flex布局加固定计算不依赖较新的CSS特性。还有一个和热词里飞书h5免登录授权微信小程序内嵌h5有关的小坑内嵌到企业应用的时候页面会以iframe方式加载这种情况下需要确保棋盘加载完成后能自动调整高度因为iframe默认高度只有视口高度长页面会被裁切。我给页面根节点设置了最小高度并在onload后主动向父页面发送消息让父容器自适应高度。另外在内嵌应用环境中音频播放往往受到严格限制页面加载后直接尝试播放音效会被拦截。对弈音效在用户第一次点击棋盘后再初始化就能绕开这个限制。这种体验细节看起来小但直接影响用户对完整两个字的感知。这个项目做完之后我自己最大的体会是象棋AI并没有想象中那么高不可攀核心骨架就是走法生成、评估函数、Alpha-Beta搜索三件套真正消耗时间的是各种边界情况和跨端适配。如果你打算从零复刻这套H5象棋对弈项目我建议先别急着调AI强度先把规则引擎和交互手感打磨到位等人下棋这一步流畅了再加上AI搜索整体的开发路径会顺畅很多。本文还有配套的精品资源点击获取 全新经典版H5象棋源码：内嵌AI算法的在线对弈页面开发实战
简介这是一份基于H5开发的经典版象棋AI在线对弈网页源码适合前端开发者、棋类游戏爱好者也可作为Web游戏方向毕业设计或课程项目的参考。整套对弈逻辑集中在js脚本中覆盖AI决策、开局库、对局存储与公共工具等模块内含可扩展的AI落子算法并内置两套界面皮肤方便对比或二次改版。压缩包共75个文件40个png与2个jpg负责棋盘、棋子及皮肤素材7个js实现AI与棋局逻辑1个html作为入口页面1个css统一样式24个url为附属链接文件整体仅1.55MB轻量易部署。已有2236人学习下载适合用于研究人机对弈流程、修改棋力强度或快速搭建设计演示原型。 自己花了不少时间打磨过一套象棋H5项目正好前几天有人问起来。今天就直接把这套象棋源码H5开发设计的象棋 AI在线对弈网页页面的做法讲透标题里写的全新經典版内嵌ai算法其实说的就是三件事一个能跑的H5对弈页面、一套完整的中国象棋规则引擎、以及一个不需要服务器也能在浏览器里跑的AI下棋算法。适合想把棋类游戏做成网页版的前端开发者也适合刚接触AI极小极大搜索、想找个真实落地方案的初学者参考。1. 项目整体设计与技术选型1.1 功能边界与需求画像动手之前先得把功能边界定清楚。这个项目的定位是纯前端H5实现的人机对弈页面所以核心功能必须包含棋盘绘制、棋子渲染、行棋规则校验、胜负判定、AI自动走棋、悔棋与重新开始以及最基本的回合提示。再往外可以加UI音效、走棋动画、难度选择但这些属于锦上添花。我建议第一版不要一上来就做联机对战原因很实在。联机意味着必须引入WebSocket或后端服务而一旦引入后端部署、鉴权、断线重连、帧同步这些问题都会涌出来对一个小型H5项目来说是巨大的成本。先把AI对弈这一条线做扎实才是这个标题背后最核心的价值点单机也能让用户玩出深度。整个页面我采用的是单页H5结构传统九宫格棋盘、红黑双方棋子。用户执红先手AI执黑后手通过点击选中棋子、点击目标位置落子。这听起来简单但背后牵扯到的规则种类要比围棋、五子棋复杂得多因为中国象棋特殊的马脚、象眼、炮架、将帅不能照面、兵未过河不能横走等等都需要用代码精确表达。1.2 技术栈选型为什么用这个方案选型时要考虑落地成本、运行环境兼容性、以及后续扩展空间。渲染方案我采用的不是Canvas而是纯DOM加CSS定位。这种方案的优点是交互事件好处理点击命中检测不需要自己写坐标换算而且棋盘和棋子的样式可以完全交给CSS去美化。棋子本身用div加背景图或文本符号渲染一套代码在桌面端的Chrome、Safari移动端的微信浏览器、飞书内置浏览器里都能正常跑。前端框架项目用的是原生JavaScript配合少量Vue语法风格的组织方式并没有强行上工程化框架。原因在于象棋核心算法的复杂度集中在棋盘逻辑不集中在UI状态管理上。用原生JS写一个Game对象、一个AI对象、一个Render对象模块清晰也方便和其他前端框架集成。AI引擎选用的是经典的极小极大搜索Minimax加Alpha-Beta剪枝。这是单机棋类AI最成熟的方案不依赖GPU、不需要训练数据纯计算逻辑就能达到不错的棋力。相比深度学习方案这种实现放在浏览器里运行不会带来模型体积和推理延迟的痛点。后面我会把具体实现细节摊开来讲。规则引擎纯前端实现用二维数组表示棋盘状态。数组比对象更适合做局面存储因为它天然支持坐标索引在走法生成和局面评估时效率很高。这套组合最终呈现出来的效果是用户打开网页即可对弈不需要登录、不需要安装、不需要后端服务部署时丢到任何静态文件服务器上就能跑。2. 棋盘与对弈逻辑的实现要点2.1 棋盘建模与走法生成大部分象棋源码把棋盘做成9列乘10行的二维数组行和列都用数字索引。比如红方的帅初始位置在数组下标[9][4]黑方将在[0][4]兵的位置在[6][0]、[6][2]等。每一种棋子用整数常量表示比如0代表空位1代表红帅2代表红仕3代表红相4代表红马5代表红车6代表红炮7代表红兵黑色方则用负数或加偏移量的方式表示。这里有一个细节要注意红黑双方如果都用对称的数字编码AI评估时需要考虑正负号如果直接采用一组独立编码评估函数里又得做一次映射。我更推荐用一个side字段区分阵营棋子值只表示棋子类型这样后期做规则扩展和调试时定位问题更快。走法生成是所有对弈逻辑的核心也是AI算法的基础。我单独维护了一个生成器文件按棋子类型分别写出走法车的走法沿横竖两个方向直线行走遇到棋子停止如果是敌方棋子则增加一个吃子走法。马的走法八个方向同时要判断对应方向有没有蹩马腿。象的走法沿对角线走两格塞象眼的位置不能有棋子同时不能越过河界。士的走法只允许在九宫格内沿斜线走一步。将的走法只能在九宫格内上下左右走一步同时还要检测和对方将帅是否照面。炮的走法直线行走和车一样不吃子时不隔子吃子时必须隔一个炮架。兵的走法未过河时只能向前走一步过河后才能左右移动和向前移动。function generateMoves(board, side) { const moves []; board.forEach((row, r) { row.forEach((piece, c) { if (piece 0 || board.pieceSide(r, c) ! side) return; const type Math.abs(piece); const routes getRoute(type, r, c, side, board); routes.forEach(target moves.push({ from: [r, c], to: target })); }); }); return moves; }2.2 行棋校验与胜负判定行棋校验分为两块一是规则层面二是结果层面。规则层面指的是用户点击棋子、再点击目标位置后程序要判断这一步是否合法。简单做法是点击第一个棋子时高亮当前棋子的所有合法走法用户目标位置如果在合法列表里则执行移动如果不在则视为无效点击。这样做的好处是把非法走法的判断前置不必在点击后再反查规则。结果层面则是在一次移动产生后检查对方是否还有合法走法。如果对方将帅被吃直接判负如果对方将帅没有被吃但无子可动判负如果双方都无法形成绝杀且重复局面超过一定次数判和。长将循环检测需要维护一个局面历史表这里我会在后面的常见问题部分展开。胜负判定推荐放在AI调用之前执行否则AI面对一个已经结束的棋局还在无限搜索白白浪费性能。3. AI算法的架构设计3.1 棋子价值评估函数评估函数决定了AI眼光的远近。最基础的做法是给每种棋子设置静态分值棋子价值分备注帅/将10000被吃即输分值需远大于其他棋子总和车900强子马400中后期因蹩马腿价值波动炮450开局价值高残局略降相/象200防守型棋子仕/士200防守型棋子兵/卒100过河后可加至120-150如果只按这组静态值评估AI会表现出只顾眼前大子的问题。所以我在评估函数里还加入了位置奖励表。位置奖励表本质上是一张和棋盘同尺寸的二维数组不同棋子在不同坐标上有不同的加减分。比如中路兵过河后位置分要高一些因为对中路有压制作用马在边线要扣分因为活动空间被压缩炮在开局阶段占据中路或肋道会有小加分因为便于配合车马进攻。function evaluate(board) { let score 0; for (let r 0; r 10; r) { for (let c 0; c 9; c) { const piece board.get(r, c); if (piece 0) continue; const value baseValue[piece.type] positionBonus[piece.type][r][c]; score piece.side RED ? value : -value; } } return score; }红方为正、黑方为负AI搜索时如果是红方走棋就追求最大化分数黑方走棋就追求最小化分数。对称的局面评估函数可以保证AI不偏向某一方。3.2 极小极大搜索与Alpha-Beta剪枝评估函数只能看一步AI要继续变强必须向前推演多层。极小极大搜索的思路是轮到某一方走棋时它会在自己的所有可选走法中选择评估分数最大的那一步同时假设对手也会在它的局面里选择对AI最不利即分数最小的走法。这样交替推演直到搜索深度到达设定阈值。纯粹的极小极大搜索在象棋这种分支因子很高的游戏里非常昂贵。象棋平均每个局面有几十个合法走法搜索到第4层就要算几十万的叶子节点。Alpha-Beta剪枝能把搜索量压缩到完整搜索的三分之一甚至更少核心思想是维护两个边界值alpha表示当前走棋方能接受的最低分数下限beta表示当前走棋方不能超过的分数上限。在某一分支上发现对手已经能导致分数低于alpha那这条分支就没必要再往下搜索了。AI的搜索入口代码大致是这个形态function search(depth, alpha, beta, side) { if (depth 0) return evaluate(board); const moves orderMoves(generateMoves(board, side)); if (moves.length 0) return -INF; let bestScore -INF; for (const move of moves) { doMove(move); const score -search(depth - 1, -beta, -alpha, -side); undoMove(move); if (score bestScore) bestScore score; if (bestScore alpha) alpha bestScore; if (alpha beta) break; } return bestScore; }这里用-search(-beta, -alpha)这种Negamax写法可以统一红黑双方的思路不用区分求最大还是求最小。剪枝条件alpha beta就是整个搜索效率的关键。不走法排序的Alpha-Beta剪枝效率会比较差。因为AI会按顺序盲目地检查每一个走法如果最差的走法排在前面它会先踩到很低的分数导致后面所有好走法都不能提高alpha剪枝的机会变少。所以在进入递归前我用了orderMoves函数将吃子走法尤其是兵吃车、炮打帅这种高价值吃低价值排在前面普通走法排在后面。这一步能让搜索效率提升好几倍。3.3 AI难度分级与策略调整标题里写了AI在线对弈用户期望的是能选择难度。我做了三个档位初级搜索深度2层不做走法排序随机扰动评估分数AI会偶尔下出昏招适合新手。中级搜索深度4层启用Alpha-Beta剪枝和走法排序评估函数不加入位置分。高级搜索深度6层启用杀手走法记忆和置换表评估函数完整版。置换表是一块以局面哈希值为索引的缓存。象棋一盘棋下来很多局面会通过不同走法路径反复到达如果每次都要重新搜索浪费极大。我用一个简易的Zobrist哈希把当前局面映射成一个64位整数再把搜索结果和深度存入一个Map中。搜索开始时先查表如果表里存的深度不小于当前搜索深度直接复用结果。在6层搜索的高级档位下置换表大约能减少30%以上的重复计算。4. 关键代码落地与实操过程4.1 棋盘状态管理与走法执行实际编码过程中我先把棋盘对象封装成了一个类Board维护一个10行9列的二维数组和当前走棋方。落子操作统一由move(piece, from, to)完成其中包括更新数组、处理吃子、更换走棋方、记录历史状态用于悔棋。悔棋这里有个坑如果只是把走子过程倒放一遍容易在吃子的情况下忘记恢复被吃棋子所以我直接采用快照式悔棋每次走棋前把整个棋盘数组深拷贝一份压入栈中悔棋时弹出栈顶快照。这种做法虽然内存开销稍高但逻辑非常简单而且在实际对弈场景下一盘棋最多两三百步快照量很小根本不会对性能造成影响。相比之下增量式记录节省的内存微乎其微却平白增加了debug难度。class Board { constructor() { this.grid this.initGrid(); this.turn RED; this.history []; this.zobrist new ZobristHash(); } applyMove(move) { this.history.push(cloneGrid(this.grid)); this.grid[move.to[0]][move.to[1]] this.grid[move.from[0]][move.from[1]]; this.grid[move.from[0]][move.from[1]] 0; this.turn -this.turn; this.zobrist.update(move); } undoMove() { this.grid this.history.pop() || this.initGrid(); this.turn -this.turn; } }4.2 AI搜索模块的运行流程AI的完整运行流程比上面贴的搜索函数要再多两步。第一步是AI启动时的线程调度。浏览器主线程如果执行深度为6的搜索可能会有几百毫秒的卡顿用户点击棋子后页面会失去响应。我的处理是给搜索套上一层setTimeout让搜索任务被放到事件循环的下一个阶段执行这样UI可以在搜索开始前先完成棋子移动动画。如果深度设定较高也可以使用Web Worker让搜索跑在独立线程里主线程始终保持流畅。第二步是根节点的特殊处理。搜索入口只能返回分数真正决定AI走哪一步需要在根节点遍历所有走法逐个调用搜索函数并记录最优走法对应的落子坐标。另外根节点还可以配合时间控制如果搜索到设定深度后耗时仍然超过预估值就停止加深以避免用户等待时间过长。function aiMove(board, depth) { const moves generateMoves(board, AI_SIDE); let bestMove null; let bestScore -INF; for (const move of orderMoves(moves)) { board.applyMove(move); const score -search(depth - 1, -INF, INF, HUMAN_SIDE); board.undoMove(); if (score bestScore) { bestScore score; bestMove move; } } return bestMove; }在上面这段代码里search函数内部最大搜索深度是depth而不是depth - 1也没有关系关键是根节点这一层不能计入相同深度否则AI的实际搜索层数会比设定值多一层运行时间成倍增加。4.3 H5端交互与移动端适配移动端的操作体验和桌面端差距很大首先要处理的就是点击还是触摸。H5页面要想同时兼容鼠标和触摸我统一监听pointerdown和pointerup这样不用分别处理click和touch事件也不会出现移动端300ms延迟或者吞事件的问题。如果项目需要兼容老版本浏览器再降级处理。棋盘尺寸在移动端需要做自适应。我的做法是使用CSS的min(90vw, 70vh)作为棋盘容器边长然后棋子间距按棋盘边长除以9等分换算。这样不管用户用手机还是电脑打开棋盘都能保持在屏幕视觉中心不会出现棋子溢出屏幕的情况。还有一点容易被忽略页面顶部和底部的安全区域。iOS的Safari和微信浏览器底部有横条如果按钮和棋谱信息放在页面底部会被遮挡。我在设置页面padding时额外加了env(safe-area-inset-bottom)这也算是H5项目里的老生常谈但很多初创项目依然会漏掉最终影响体验。5. 常见问题与排查经验5.1 AI响应卡顿与搜索超时我在4层深度的中级档下AI单步耗时有明显的波动。原因在于残局阶段虽然棋子减少但走法数量并没有等比例下降某些局面下例如车炮兵残局分支仍然很多加上评估函数在叶子节点要做大量数组遍历耗时会从平均200ms飙升到800ms以上。解决思路有两个方向。第一个是限制搜索时间在搜索过程中定时检查当前耗时一旦超过400ms就强制返回当前最优走法。第二个是引入迭代加深先搜1层再搜2层、3层层层递进每一层搜索完成后记录当前最优解一旦超时就立即返回上一层的结果。迭代加深本身还会带来一个附加收益上一层搜索得到的走法顺序可以作为下一层的走法排序参考进一步提升剪枝效率。实测下来迭代加深配合时间控制在高级档位下的体验是最顺畅的用户几乎感觉不到AI在思考落子速度稳定在一秒以内。5.2 重复局面与长将判定如果AI只是一味搜索、不走规则判定会出现一个经典问题在优势局面下AI可能因为搜索深度不够而选择循环将军步数多了之后形成长将这在正式对弈中属于违规。但用户如果是真人程序不说清楚很容易被误认为是AI死机了。我的处理是在AI搜索过程中每走一步都检查当前局面是否在最近8步内重复出现过。如果连续重复出现两次以上就认为当前分支会让局面走向不变把这条分支的评估分数降低让AI更倾向于选择其他有进展的走法。配合局面历史哈希表这个判断可以做到常量时间内完成。5.3 跨端浏览器兼容与内嵌页面适配这套H5源码我在Chrome、Safari、微信浏览器、飞书、钉钉的内嵌容器里都测过。最容易出问题的不是JS语法而是CSS的aspect-ratio、gap这类属性在部分老版本WebView中不支持。解决方案是使用padding-bottom百分比配合绝对定位或者直接用Flex布局加固定计算不依赖较新的CSS特性。还有一个和热词里飞书h5免登录授权微信小程序内嵌h5有关的小坑内嵌到企业应用的时候页面会以iframe方式加载这种情况下需要确保棋盘加载完成后能自动调整高度因为iframe默认高度只有视口高度长页面会被裁切。我给页面根节点设置了最小高度并在onload后主动向父页面发送消息让父容器自适应高度。另外在内嵌应用环境中音频播放往往受到严格限制页面加载后直接尝试播放音效会被拦截。对弈音效在用户第一次点击棋盘后再初始化就能绕开这个限制。这种体验细节看起来小但直接影响用户对完整两个字的感知。这个项目做完之后我自己最大的体会是象棋AI并没有想象中那么高不可攀核心骨架就是走法生成、评估函数、Alpha-Beta搜索三件套真正消耗时间的是各种边界情况和跨端适配。如果你打算从零复刻这套H5象棋对弈项目我建议先别急着调AI强度先把规则引擎和交互手感打磨到位等人下棋这一步流畅了再加上AI搜索整体的开发路径会顺畅很多。本文还有配套的精品资源点击获取