1. 为什么我决定用本地35B模型从零搓一个五子棋AI先说结论我用一个本地部署的35B MoE模型通过53轮对话、大约40分钟从零把一个能跑的五子棋AI写出来了。不是调API不是云端服务就是本地跑。整个过程没有手写一行核心逻辑代码全部靠对话驱动模型生成、我审查、再迭代。这件事的背景是这样的。我平时做AI Coding相关的工程实践手头经常要验证各种模型在真实开发任务里的表现。之前用云端大模型做代码生成效果确实不错但有两个问题一直让我不舒服一是数据要出去二是网络抖动的时候整个工作流就断了。所以我一直在折腾本地模型的部署和开发工作流。这次选五子棋AI作为验证项目原因很简单——它足够小规则清晰但又不至于简单到没有挑战性。它涉及棋盘状态管理、胜负判定、搜索算法、评估函数这几个核心模块正好能覆盖一个完整小项目的主要环节。关键词里提到的35B模型、MoE架构、本地模型、AI Coding这几个词基本概括了我这次实验的全部要素。35B指的是模型参数量级MoE是混合专家架构本地模型意味着整个推理跑在我自己的机器上AI Coding则是我使用模型的方式——不是让它补全代码而是让它作为开发伙伴我提需求、它出方案、我审查、它修改。适合谁看这篇内容如果你正在考虑把本地模型引入自己的开发流程或者你对AI辅助编程的实际边界感兴趣再或者你只是想看看一个35B的MoE模型到底能不能干正事那这篇东西应该对你有用。我不会讲太多理论主要说我实际怎么操作的、遇到了什么问题、哪些地方和预期不一样。先交代一下我的环境。机器是一台工作站显卡显存足够加载这个35B的MoE模型。这里有个细节值得展开MoE架构的模型并不是所有参数都需要同时进显存。MoE的核心思想是模型里有很多个“专家”子网络每次前向传播只激活其中一小部分。所以35B的总参数量实际推理时激活的可能只有几B。这也是为什么MoE模型在本地部署时对显存的要求比同等参数量的稠密模型低不少。但注意这不意味着你可以无限降低显存——路由网络、共享层、KV Cache这些还是要占空间的。我实测下来这个35B MoE模型在量化到4bit之后显存占用大概在20GB出头留出KV Cache和上下文的空间24GB显存的卡基本能跑起来。加载模型我用的是LM Studio。这个工具的好处是图形化界面加载本地模型很方便支持GGUF格式的量化模型而且自带一个兼容OpenAI API的本地服务端。这意味着我可以用任何支持自定义API地址的客户端来跟模型对话。关键词里有人问“lm studio如何加载本地模型”我简单说一下下载好GGUF文件之后在LM Studio的模型目录里放好界面上直接选模型、调参数、点加载就行。关键参数是上下文长度和GPU offload层数。上下文长度我设的是8192够用GPU offload层数拉到最大让能上显卡的层都上显卡剩下的在CPU上跑。这样推理速度最快。还有一个热词是“ollama部署本地模型”。Ollama我也用过它的优势是命令行操作适合脚本化。但这次我选LM Studio是因为它的对话界面更顺手而且我可以随时看到token生成速度。两者各有场景不是非此即彼。好背景交代完了。接下来我按实际开发过程把整个53轮对话拆开讲。2. 五子棋AI的模块拆解与对话策略设计2.1 为什么先让模型做模块拆解而不是直接写代码很多人用AI写代码的习惯是打开对话框输入“帮我写一个五子棋AI”然后等着模型吐出一大段代码。我试过这种方式结果通常不理想。模型会给你一个能跑的脚本但里面的结构往往是扁平的——所有逻辑塞在一个文件里棋盘表示、搜索、评估混在一起。这种代码能演示但没法维护更没法迭代。所以我的第一轮对话不是让它写代码而是让它做模块拆解。我的原话大概是“我要用Python从零实现一个五子棋AI请你先不要写代码而是把这个项目拆解成若干个模块说明每个模块的职责和模块之间的接口。”模型给出的拆解是这样的棋盘模块负责棋盘状态的表示、落子、撤销落子、判断某位置是否为空。规则模块负责胜负判定包括横、竖、两个斜方向五连。评估模块负责对当前局面打分用于搜索时的叶子节点评估。搜索模块负责极小化极大搜索加Alpha-Beta剪枝返回最佳落子位置。主程序模块负责游戏循环、人机交互、调用搜索模块。这个拆解中规中矩但有一个点我觉得值得注意模型主动把“规则模块”和“棋盘模块”分开了。很多新手写五子棋会把胜负判定直接写在棋盘类里但分开之后规则模块可以独立测试棋盘模块也可以复用于其他棋类。这是一个好的工程习惯模型在没有我提示的情况下做到了。2.2 接口设计让模型先定契约再填实现拆解完模块之后我让模型定义每个模块的接口。这一步很关键。如果你直接让模型写实现它可能会在实现过程中随意改变函数签名导致模块之间对不上。先定接口相当于先画好图纸再施工。模型给出的接口定义包括Board类__init__(size)、place(row, col, player)、undo(row, col)、is_empty(row, col)、get_winner()。Evaluator类evaluate(board, player)返回一个浮点数。Searcher类search(board, player, depth)返回(row, col)。这里有一个细节get_winner()我原本以为会放在规则模块里作为一个独立函数但模型把它放到了Board类上。我思考了一下觉得这样也合理——胜负判定需要遍历棋盘放在棋盘类里可以方便地访问内部状态。但这也意味着棋盘类承担了规则职责耦合度略高。不过对于这个规模的项目可以接受。接口定好之后我让模型逐个模块实现。每实现一个模块我就跑一次测试。这里我犯了一个错误我一开始让模型一次性把五个模块全实现了结果代码量太大我审查不过来而且出了问题不好定位。后来我改成一次只实现一个模块测试通过再进入下一个。这个节奏调整之后效率反而更高了。2.3 对话轮次的分配53轮是怎么花掉的53轮对话听起来很多但实际分配下来是这样的阶段对话轮次主要内容模块拆解与接口设计约5轮确定模块划分、接口签名、数据结构棋盘模块实现与测试约8轮实现Board类、写单元测试、修复边界问题规则模块实现与测试约7轮实现胜负判定、测试各种连珠情况评估模块实现与调优约12轮设计评估函数、调整权重、验证评估合理性搜索模块实现与调优约15轮实现Alpha-Beta、调整搜索深度、优化性能主程序与联调约6轮游戏循环、人机交互、整体测试可以看到搜索模块花的时间最多。原因是Alpha-Beta剪枝的实现有很多细节容易出错比如剪枝条件写错、搜索深度控制不当、评估函数和搜索的配合有问题。这些都需要反复调试。评估模块花的时间也不少。五子棋的评估函数设计是一个经验活模型一开始给的权重方案比较粗糙我通过让它分析具体棋型来逐步调整。比如活三、冲四、活四这些棋型的分数应该怎么给模型给了一个初始方案我根据实际对局效果做了微调。3. 棋盘与规则模块模型写出来的代码到底能不能用3.1 棋盘表示的选择二维数组还是位棋盘模型一开始用的是二维数组表示棋盘board[row][col]0表示空1表示黑子2表示白子。这是最直观的方式也最容易理解。但我问模型“有没有更高效的表示方式”模型提到了位棋盘——用两个整数或长整数分别表示黑白双方的落子位置每个bit对应一个格子。位棋盘的优势在于操作快。判断某位置是否为空、落子、撤销落子都可以用位运算完成比数组索引快很多。而且胜负判定可以用移位和与运算来批量检查不需要循环。但位棋盘的问题是代码可读性下降。对于这个项目棋盘是15x15用两个64位整数不够225个格子需要四个64位整数或者用Python的大整数。Python的大整数天然支持任意位数所以可以用一个整数表示整个棋盘。模型最终给出的方案是用两个Python整数一个表示黑子一个表示白子。我实际测试下来位棋盘在搜索深度较大的时候确实有性能优势。但如果你只是想快速验证算法逻辑二维数组更直观。我的建议是先用二维数组把逻辑跑通确认算法正确之后再考虑换成位棋盘优化性能。不要一上来就追求最优表示那样容易在调试上花更多时间。3.2 胜负判定的边界条件模型第一次写漏了什么胜负判定看起来简单——检查横、竖、两个斜方向有没有五连。但实际写起来有几个容易漏的边界条件。模型第一次给出的胜负判定代码在检查斜方向的时候只检查了从左上到右下和从右上到左下两个方向但检查的起始点没有处理好。具体来说它在检查某个方向时从当前落子位置出发向两个方向延伸计数。这个思路是对的但它在边界处理上出了问题当落子靠近棋盘边缘时延伸会越界。比如棋盘是15x15索引0到14。如果落子在(0, 0)向左上方向延伸时row-1和col-1都会变成-1在Python里这不会报错但会访问到数组的最后一个元素负索引导致错误的判定结果。模型没有考虑到这一点。我让模型修复这个问题它给出的方案是在延伸之前先检查边界。修复后的代码逻辑是对于每个方向先向正方向延伸计数再向负方向延伸计数每次延伸前检查坐标是否在棋盘范围内。这样就不会越界了。这个坑很典型。Python的负索引在某些场景下很方便但在棋盘遍历这种场景下就是一个陷阱。如果你用其他语言比如C或Java越界会直接报错反而更容易发现。Python的“宽容”在这里变成了隐患。3.3 单元测试让模型自己写测试用例我让模型为棋盘和规则模块写单元测试。模型生成的测试用例覆盖了以下场景空棋盘上没有赢家。横向五连、竖向五连、两个斜方向五连分别判定为赢。四连不算赢。六连算赢因为五子棋规则通常是五连或以上都算赢。棋盘边缘的五连也能正确判定。这些测试用例质量不错但有一个遗漏它没有测试“落子后撤销再判定”的场景。我补了一个测试在棋盘上落子形成五连然后撤销其中一子再判定应该没有赢家。这个测试通过了说明撤销逻辑和胜负判定逻辑是一致的。让模型写测试的好处是它会覆盖一些你容易忽略的情况。但坏处是模型写的测试往往偏向“正常路径”对异常路径和边界条件的覆盖不够。所以我的做法是模型写基础测试我补充边界测试。两者结合覆盖率才够。4. 评估函数五子棋AI的“棋感”从哪来4.1 棋型识别活三、冲四、活四的分数怎么定五子棋AI的评估函数本质上是对棋盘上各种棋型进行打分然后加权求和。棋型包括五连已经赢了分数应该是无穷大。活四两端都空的四连下一步必成五连分数极高。冲四一端被堵的四连下一步能成五连但对手可以堵另一端分数较高。活三两端都空的三连下一步能变成活四分数中等。眠三一端被堵的三连分数较低。活二两端都空的二连分数较低。模型一开始给的分数方案是五连100000活四10000冲四1000活三1000眠三100活二100眠二10。我看了之后觉得有几个问题活三和冲四的分数一样这不太合理。冲四的威胁比活三更大因为冲四下一步就能成五连而活三下一步只能成活四。所以冲四的分数应该高于活三。我让模型调整它改成了五连1000000活四100000冲四10000活三8000眠三1000活二800眠二100。这个方案更合理一些。但具体数值其实没有标准答案需要根据实际对局效果来调。这里有一个经验评估函数的分数不需要绝对精确但相对关系要对。也就是说五连的分数必须远大于活四活四必须远大于冲四冲四必须大于活三以此类推。只要相对关系正确具体数值可以在一定范围内浮动。4.2 评估函数的性能瓶颈为什么全盘扫描太慢模型最初的评估函数是每次调用时扫描整个棋盘统计所有棋型的数量然后加权求和。这个做法在搜索深度较浅的时候没问题但当搜索深度增加时评估函数的调用次数呈指数增长全盘扫描的开销就变得不可接受了。我让模型优化评估函数。模型给出的方案是增量评估不每次扫描全盘而是只评估当前落子位置周围一定范围内的棋型变化。因为落子只影响周围几个格子的棋型远处的棋型不会因为这一步落子而改变。增量评估的实现比全盘扫描复杂需要维护一个棋型计数的缓存每次落子或撤销时更新缓存。但性能提升很明显。我实测下来在搜索深度为4的时候增量评估比全盘扫描快了大约3到5倍。不过增量评估有一个坑缓存的更新逻辑必须和落子/撤销逻辑严格对应。如果落子时更新了缓存撤销时没有正确恢复缓存就会和实际棋盘状态不一致导致评估结果错误。模型第一次实现增量评估时撤销逻辑就写漏了一个棋型的恢复。我通过对比“全盘扫描结果”和“增量评估结果”发现了这个问题。修复之后两者结果一致。4.3 评估函数的对称性黑棋和白棋的评估要对称吗这是一个容易被忽略的问题。五子棋里黑棋先手白棋后手。从规则上讲黑棋有先手优势。但在评估函数里我们通常希望评估是对称的——也就是说如果棋盘上黑棋有一个活三白棋也有一个活三那么评估分数应该抵消。模型一开始的评估函数是对称的它分别计算黑棋的棋型分数和白棋的棋型分数然后相减。这样做的好处是评估值有明确的含义正数表示黑棋优势负数表示白棋优势。但这里有一个细节五子棋里黑棋有禁手规则比如三三禁手、四四禁手如果考虑禁手评估函数就需要对黑棋和白棋区别对待。不过我的这个项目没有实现禁手规则所以对称评估就够了。如果你要实现禁手评估函数会复杂不少。5. 搜索算法Alpha-Beta剪枝的坑比想象中多5.1 极小化极大搜索的基本框架搜索模块的核心是极小化极大搜索加Alpha-Beta剪枝。基本思路是假设对手总是会选择对你最不利的走法你选择能让你利益最大化的走法。搜索树交替进行“最大化层”和“最小化层”最大化层选择分数最高的子节点最小化层选择分数最低的子节点。模型给出的搜索框架是正确的但在实现细节上出了几个问题。第一个问题是搜索深度。模型一开始设的深度是6我跑了一下发现每一步要等好几秒。对于五子棋来说搜索深度6已经比较深了但评估函数的精度不够深搜反而可能因为评估误差累积而做出错误决策。我把深度降到4速度明显提升棋力也没有明显下降。后来我做了个实验深度4加好的评估函数对深度6加粗糙的评估函数前者胜率更高。这说明评估函数的质量比搜索深度更重要。第二个问题是候选走法的生成。模型一开始生成所有空位作为候选这导致搜索树的分支因子很大15x15的棋盘有225个空位。我让模型优化只考虑已有棋子周围一定范围内的空位。因为五子棋的有效走法通常都在已有棋子附近远离棋子的空位价值很低。这个优化把分支因子降到了原来的十分之一左右搜索速度大幅提升。5.2 Alpha-Beta剪枝的实现细节什么时候可以剪Alpha-Beta剪枝的核心是在搜索过程中如果发现某个分支的结果已经不可能影响最终决策就跳过这个分支的剩余部分。具体来说在最大化层如果当前节点的分数已经大于等于beta就剪枝在最小化层如果当前节点的分数已经小于等于alpha就剪枝。模型第一次实现的剪枝逻辑在最大化层用了 beta在最小化层用了 alpha。这个逻辑是对的。但它在传递alpha和beta参数的时候出了错在递归调用时它没有正确更新alpha和beta的值。具体来说在最大化层alpha应该更新为当前找到的最大分数在最小化层beta应该更新为当前找到的最小分数。模型漏掉了这个更新导致剪枝效果大打折扣。我通过统计搜索的节点数发现了这个问题。修复之前搜索深度4要访问大约50万个节点修复之后节点数降到了大约5万。差了十倍。这个坑很隐蔽因为即使剪枝逻辑写错了搜索结果仍然是正确的——只是慢而已。如果你不统计节点数可能根本发现不了。5.3 搜索顺序对剪枝效率的影响Alpha-Beta剪枝的效率高度依赖于搜索顺序。如果先搜索好的走法剪枝就能更早发生访问的节点数就更少。理想情况下如果每次都能先搜索最优走法Alpha-Beta的时间复杂度可以从O(b^d)降到O(b^(d/2))其中b是分支因子d是搜索深度。模型一开始没有对候选走法排序按空位的自然顺序搜索。我让它加上排序先用评估函数对候选走法做一个快速评估按评估分数从高到低排序然后依次搜索。这个改动让节点数又降了大约一半。更进一步可以用历史启发式或杀手启发式来优化搜索顺序但这些对于这个规模的项目来说有点过度设计了。简单的评估排序已经够用。5.4 搜索的迭代加深为什么需要它迭代加深是一种搜索策略先搜索深度1再搜索深度2再搜索深度3以此类推直到达到目标深度或时间限制。看起来这样做很浪费——深度1到深度3的搜索好像白做了。但实际上迭代加深有两个好处一是可以随时中断搜索返回当前最优解二是浅层搜索的结果可以用来优化深层搜索的走法排序。模型一开始没有实现迭代加深直接搜索到固定深度。我让它加上迭代加深这样我就可以设置一个时间限制比如每步最多思考2秒时间到了就返回当前找到的最优解。这对于实际对局体验很重要——你不会希望AI每步都想半天。迭代加深的实现需要注意每次加深搜索时要保留上一层搜索的最优走法把它作为下一层搜索的第一个候选。这样下一层搜索可以更快地触发剪枝。6. 联调与实战AI到底能不能下棋6.1 主程序的设计人机交互的细节主程序模块负责游戏循环显示棋盘、接收用户输入、调用搜索模块、落子、判定胜负。模型给出的主程序比较简洁但有几个细节需要调整。第一个是棋盘显示。模型用字符画的方式显示棋盘黑子用“X”白子用“O”空位用“.”。这个显示方式在终端里够用但不够直观。我改成了用Unicode字符“●”和“○”看起来更清楚。第二个是输入处理。模型一开始只接受“行 列”格式的输入比如“7 7”。我加上了输入校验如果输入格式不对提示用户重新输入如果输入的位置已经有棋子也提示重新输入。这些细节虽然小但影响使用体验。第三个是胜负判定后的处理。模型一开始在判定胜负后就直接退出程序。我改成了询问用户是否再来一局这样可以连续测试。6.2 实战测试AI的棋力到底怎么样我让AI和自己下了几局也让我自己和AI下了几局。整体感觉是AI在搜索深度4的情况下能识别基本的活三、冲四威胁会堵对手的活三也会尝试制造自己的活三。但它有时候会做出一些“短视”的决策比如为了堵一个活三而放弃了自己制造冲四的机会。我分析了一下原因评估函数的权重可能还需要调整。冲四的分数虽然高于活三但差距可能不够大。另外搜索深度4可能不够看到冲四之后的后续变化。如果把深度加到5或6AI的棋力会更强但思考时间也会增加。这里有一个权衡搜索深度、评估函数质量、思考时间三者需要平衡。对于五子棋来说深度4加一个好的评估函数已经能打败大部分休闲玩家了。如果你想挑战更强的对手需要更深的搜索和更精细的评估。6.3 性能数据40分钟开发出来的AI跑得怎么样我记录了一些性能数据指标数值搜索深度4平均每步思考时间约0.8秒平均每步访问节点数约3万模型生成代码总行数约600行对话总轮次53轮总耗时约40分钟这个性能对于本地运行的AI来说是可以接受的。0.8秒的思考时间不会让用户等太久3万节点的搜索量在现代CPU上跑起来也很轻松。值得一提的是整个开发过程中我没有手写任何核心算法代码。所有的代码都是模型生成的我负责审查、测试、提出修改意见。这让我对AI Coding的实际能力有了更直观的认识模型能写出结构合理、逻辑正确的代码但需要人来把控方向、发现细节问题、做工程决策。7. 本地模型做AI Coding的真实体验与边界7.1 本地模型和云端模型的差异在哪里这次用本地35B MoE模型做开发和之前用云端大模型做开发体验上有几个明显差异。第一个差异是响应速度。本地模型的推理速度取决于你的硬件。我的配置下生成速度大约每秒20到30个token。云端模型通常更快但受网络影响。对于代码生成这种需要较长输出的任务本地模型的等待时间会更明显。第二个差异是上下文长度。本地模型受限于显存上下文长度通常比云端模型短。我设的是8192对于这个项目够用但如果项目更大、代码更多可能就不够了。云端模型动辄128K甚至更长的上下文在处理大项目时有优势。第三个差异是数据隐私。本地模型的所有推理都在本地完成代码和数据不出机器。这对于一些对数据敏感的场景很重要。第四个差异是成本。本地模型没有按token计费的问题跑多少次都行。但硬件投入是一次性的而且电费也是成本。7.2 MoE架构在代码生成任务上的表现MoE架构的特点是推理时只激活部分专家所以速度快、显存占用相对低。但在代码生成任务上MoE的表现和稠密模型相比如何我的体感是对于这个五子棋项目35B MoE模型的表现是够用的。它能理解模块化设计的要求能写出正确的算法逻辑能根据我的反馈修改代码。但在一些需要深度推理的地方比如Alpha-Beta剪枝的参数传递它第一次写错了。这说明MoE模型在复杂逻辑推理上可能不如同等参数量的稠密模型。不过这只是我的个人体感没有做严格的对比实验。而且模型的表现很大程度上取决于提示词的质量和迭代方式。我通过多轮对话逐步引导最终得到了可用的代码。7.3 AI Coding的边界哪些事模型做得好哪些事需要人来做通过这次实验我对AI Coding的边界有了更清晰的认识。模型做得好的地方生成结构化的代码框架。实现标准算法如极小化极大搜索、Alpha-Beta剪枝。写单元测试。根据错误信息修复bug。解释代码逻辑。需要人来做的地方定义项目目标和模块划分。审查代码的工程合理性。发现边界条件和隐藏bug。做性能优化决策。调整评估函数的权重。判断搜索结果是否合理。简单来说模型是一个执行力很强的“初级工程师”你给它明确的任务它能完成得不错。但它缺乏工程判断力需要你来把控方向和质量。7.4 给想尝试本地模型开发的人几条建议如果你也想用本地模型做AI Coding我有几条建议。第一选一个支持良好API的工具。LM Studio和Ollama都行关键是能让你用熟悉的客户端来对话。我用的是LM Studio的本地API配合一个支持自定义API地址的对话客户端。第二模型选择上代码生成任务建议选参数量在30B以上的模型。太小的模型在复杂逻辑上容易出错。MoE架构的模型在显存有限的情况下是不错的选择。第三对话策略上先定接口再写实现先写测试再写功能。这样能减少返工。第四不要期望一次成功。53轮对话听起来多但平均每轮也就几十秒。迭代是正常的工作方式。第五保持审查习惯。模型生成的代码一定要自己看一遍尤其是边界条件和异常处理。模型在这些地方容易出错。第六性能优化不要过早做。先把功能跑通再考虑优化。我一开始就让模型用位棋盘结果调试花了很多时间。后来改成先用二维数组跑通再换位棋盘效率高多了。最后说一个我自己的体会本地模型做AI Coding最大的价值不是替代人而是加速迭代。你有一个想法模型帮你快速实现你审查、提意见、它修改。这个循环比你自己从头写要快尤其是对于你不太熟悉的领域。但前提是你要有足够的判断力来审查模型的输出。如果你自己都不懂那就没法判断模型写得对不对。所以AI Coding不是降低了对人的要求而是改变了要求——从“会写代码”变成了“会审查代码、会做工程决策”。