企业官网建设流程全解析

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轮对话听起来很多，但实际分配下来是这样的：

可以看到，搜索模块花的时间最多。原因是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或6，AI的棋力会更强，但思考时间也会增加。

这里有一个权衡：搜索深度、评估函数质量、思考时间，三者需要平衡。对于五子棋来说，深度4加一个好的评估函数，已经能打败大部分休闲玩家了。如果你想挑战更强的对手，需要更深的搜索和更精细的评估。

6.3 性能数据：40分钟开发出来的AI跑得怎么样

我记录了一些性能数据：

这个性能对于本地运行的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不是降低了对人的要求，而是改变了要求——从“会写代码”变成了“会审查代码、会做工程决策”。