这次我们来看一个挺有意思的本地 AI 项目Abby Steele。它的出发点并不复杂但架构很干净——用本地大语言模型Local LLM做人格和对话再通过国际象棋引擎Chess Engine提供真正的棋力。两者加起来就是一个不需要联网、能聊天、能下棋、能复盘分析的离线 AI 人格。先说最值得关注的点。第一全程离线运行对话和棋局分析都不依赖云端 API数据不出本机。第二它不是用 LLM 硬憋棋步而是把自然语言处理和棋力计算分开LLM 负责人格国际象棋引擎负责算棋再由一个中间层把两者协调起来。第三架构是模块化的模型引擎可以替换这意味着你不需要为这个项目去买高端显卡先用 CPU 跑一个小模型也能验证完整流程。这篇文章会带你拆解整个项目架构说明如何准备本地部署环境并且给出一套可执行的启动流程、功能测试方法和接口调用示例。不管你是想跑一个离线 AI 陪练还是想把 LLM 和传统引擎做能力互补这篇内容都可以直接参考。1. 核心能力速览能力项说明项目类型离线 AI 人格应用本地 LLM 国际象棋引擎组合核心组件本地大语言模型、国际象棋引擎、中间协调层运行模式完全离线数据不离开本机对话能力由本地 LLM 提供支持自定义人格设定棋力能力由国际象棋引擎提供通过 UCI 协议控制硬件要求取决于所选 LLM小模型可纯 CPU 运行启动方式命令行启动 HTTP 接口服务API 支持可提供 REST API方便对接其他工具批量任务支持批量棋局分析、批量对话评测适合场景本地 AI 助手、棋类陪练、LLM 工具调用研究、离线场景演示这里要明确一点这个项目的实际资源占用不由项目本身决定而是由你选的模型决定。LLM 部分可以用 1B、3B 这种小参数模型CPU 也能跑国际象棋引擎部分基本是纯 CPU 计算。所以这个项目本身的门槛很低真正需要评估的是你所选模型的资源需求。2. 适用场景与使用边界从实际使用角度来看Abby Steele 这类LLM 国际象棋引擎的组合适合下面这些场景本地 AI 陪练想练国际象棋但又不想在手机或网页端被算法记录对局数据可以用本地引擎做对弈。人格化角色研究想测试不同 system prompt 对 AI 人格稳定性的影响可以把这个项目当实验框架。LLM 工具调用示范让 LLM 通过工具调用去操作外部引擎这是比较典型的 Agent 入门案例。离线演示环境在展台、公司内网、无外网环境下做一个 AI 下棋展示不需要申请云端权限。棋局数据批量处理给大量棋谱生成文字复盘报告人工判断效率太低可以用这个管线自动化处理。不适合什么场景先说结论它不适合拿来当高水平棋类训练软件也不适合作为严肃的 AI 产品生产系统。原因很简单LLM 生成的复盘文本可能带有幻觉尤其在评估复杂局面时它给的解释可能和引擎评估值不一致另外中间层如果设计得不够严谨LLM 可能错误解读棋局状态。它的价值更多在于研究、演示和本地工具链整合。安全与合规边界也要提一下。使用本地模型时注意模型权重的开源许可协议不同模型允许商用和分发的范围不一样。如果这个AI 人格的设定参考了真实人物或商业角色需要确认是否涉及肖像权、名誉权和角色版权。涉及用户输入文本时注意不要采集不必要的个人信息训练或微调前需要把数据脱敏并取得授权。这一点对任何本地 AI 应用都适用项目本身不涉及网络行为但使用者自己要有数据治理意识。3. 本地部署环境准备部署一个 LLM 国际象棋引擎的离线应用本质上是把两块独立系统装进同一台机器再用代码串起来。所以前置条件分三块基础环境、LLM 运行时、国际象棋引擎。3.1 基础环境检查操作系统方面Windows、Linux、macOS 都可以跑但如果你要长期跑服务推荐 Linux进程管理和资源控制更省心。Python 3.10 以上是稳妥的选择因为后面写中间层需要用到较新的语法和依赖包。确认机器上有可用的 Python 和 pippython --version pip --version如果没有安装去 Python 官网下载对应系统的安装包。Windows 用户安装时记得勾选 Add Python to PATH。磁盘方面LLM 模型文件是主要占用者。几 B 参数的量化模型通常在 1GB 到 4GB 之间几十 B 的模型可能要 20GB 以上。建议给项目至少预留 10GB 空间如果计划尝试多种模型那按“每种模型文件 × 模型数量”来规划。3.2 LLM 运行时选择本地 LLM 的常见加载工具有好几类区别在于安装方式和资源占用。这里举两个典型选项Ollama安装简单命令行一条命令就能拉取模型并启动服务支持 OpenAI 风格的接口适合快速搭建。llama.cpp更底层一些对 CPU 推理优化较好适合需要精细控制参数和部署在老旧机器上的场景。两种工具选一个就行。如果按最简路径用 Ollama 会更顺。安装 Ollama 的通用方式是根据官方文档提供的安装脚本或安装包来操作。安装完成后服务默认监听本机的 11434 端口先确认服务状态ollama list如果你在这个阶段看不到任何模型说明还没有拉取模型。拉取一个小模型的命令模板如下ollama pull qwen2.5:3b这条命令会从模型仓库下载一个 3B 参数规模的模型到本地适合 CPU 跑。如果机器有 NVIDIA 显卡也可以选 7B 或更大一点的模型。具体拉取哪些模型以你实际网络和硬件条件为准。3.3 国际象棋引擎安装国际象棋引擎选择很多Stockfish 是最常见的开源选择。它的棋力很强而且支持 UCI 协议这意味着你可以通过标准文本命令和它交互不需要依赖任何专用 SDK。安装 Stockfish 的常见方式Windows从官网下载可执行文件或者通过包管理器安装。Linux/macOS用系统包管理器安装。以 Ubuntu/Debian 为例命令模板如下sudo apt update sudo apt install stockfish安装完成后先验证引擎能否正常运行。在命令行输入stockfish进入交互模式然后输入uci如果能看到引擎输出自己的 UCI 版本和选项列表说明引擎可用。stockfish uci quitWindows 用户如果下载的是 exe 文件需要把引擎路径记住后面在中间层代码里要用到。3.4 Python 依赖中间层代码推荐用 python-chess 库来处理棋局和 UCI 协议用 requests 或 httpx 来调用本地 LLM 的接口。安装命令pip install python-chess requestspython-chess 这个库封装了棋盘表示、走法生成、UCI 协议通信等功能不需要自己解析引擎输出能省掉不少开发量。到这里基础环境就准备好了。你可以先单独验证两块组件LLM 能不能正常对话国际象棋引擎能不能正常走棋。两个都正常后再进入接线阶段。4. 安装部署与启动流程这部分的重点是搭一个中间层把 LLM 和棋类引擎连起来。项目整体逻辑一条线用户走棋 - 棋盘状态更新 - 调用国际象棋引擎计算最佳应手 - 把局面和引擎分析结果交给 LLM - LLM 生成人格化的文字回复。4.1 目录结构规划建议按下面的方式组织项目文件后续扩展会比较舒服abby_steele/ ├── engine/ │ └── stockfish_bridge.py # 国际象棋引擎封装 ├── llm/ │ └── llm_client.py # LLM 接口封装 ├── core/ │ └── game_manager.py # 棋局状态管理 ├── app.py # HTTP 服务入口 ├── prompts/ │ └── persona.txt # 人格设定 ├── outputs/ │ └── .gitkeep # 输出文件目录 └── requirements.txt实际项目不一定要用这个结构但保持引擎层、LLM 层、控制层分离是对的。如果中间层代码和棋局逻辑混在一起后面换模型或换引擎会很痛苦。4.2 国际象棋引擎封装用 python-chess 启动 Stockfish并让引擎自己完成思考。下面是一个通用封装思路路径需要按你的实际环境修改import chess import chess.engine class ChessEngineBridge: def __init__(self, engine_pathstockfish, limit_time1.0): self.engine_path engine_path self.limit_time limit_time self.engine None self.board chess.Board() def start(self): self.engine chess.engine.SimpleEngine.popen_uci(self.engine_path) def reset_board(self): self.board chess.Board() return self.board.fen() def set_fen(self, fen: str): self.board chess.Board(fen) def get_best_move(self): result self.engine.play( self.board, chess.engine.Limit(timeself.limit_time) ) return result.move def analyse(self, fen: str, multipv: int 1): board chess.Board(fen) info self.engine.analyse( board, chess.engine.Limit(timeself.limit_time), multipvmultipv ) return info def close(self): if self.engine: self.engine.quit()这段代码把 Stockfish 封装成了一个独立服务。get_best_move返回引擎计算出的最佳走法analyse返回局面评估信息供后面 LLM 复盘使用。注意engine_path如果你是直接安装的 stockfish通常可以直接用命令名如果是下载的 exe 文件就写成完整路径。4.3 LLM 客户端封装调用本地 LLM 的接口最省事的方式是走 Ollama 提供的 HTTP 接口。它默认在http://127.0.0.1:11434/api/chat提供聊天补全能力。封装思路如下import requests class LLMClient: def __init__(self, base_urlhttp://127.0.0.1:11434, modelqwen2.5:3b): self.base_url base_url self.model model def chat(self, messages, temperature0.7, streamFalse): url f{self.base_url}/api/chat payload { model: self.model, messages: messages, stream: stream, options: { temperature: temperature } } response requests.post(url, jsonpayload, timeout120) response.raise_for_status() if stream: return response.iter_lines() return response.json()如果你用的是 llama.cpp 的 server 模式接口路径会不太一样但思路相同把本地模型的 HTTP 补全接口封装成客户端供上层调用。这里的model名称要和ollama pull时拉取的模型名一致。4.4 游戏管理器游戏管理器负责维护棋局状态协调引擎和 LLM 的调用顺序。核心流程如下用户输入走法比如 e2e4。管理器把走法更新到当前棋盘。如果用户走完由引擎计算应手并把应手也更新到棋盘。管理器把当前棋盘 FEN、双方最后几步走法和引擎评估值一起拼进 LLM 的 prompt。LLM 生成回复文本返回给用户。from engine.stockfish_bridge import ChessEngineBridge from llm.llm_client import LLMClient class GameManager: def __init__(self, engine_pathstockfish, modelqwen2.5:3b): self.engine ChessEngineBridge(engine_path) self.llm LLMClient(modelmodel) self.persona self._load_persona() def _load_persona(self): # 从 prompts/persona.txt 读取人格设定 with open(prompts/persona.txt, r, encodingutf-8) as f: return f.read().strip()这里人格设定是关键。Abby Steele 这个 AI 人格的性格、说话方式和行为风格都是由persona.txt里的 system prompt 决定的。你可以把它写成一个友好但犀利的国际象棋教练或一个沉稳安静的棋友取决于你的目标。4.5 启动 HTTP 服务为了让这个项目能被外部调用可以加一层 HTTP 接口。用 Flask 或 FastAPI 都行FastAPI 写起来更简洁自动带接口文档。先安装pip install fastapi uvicorn服务入口示例from fastapi import FastAPI, HTTPException from pydantic import BaseModel from core.game_manager import GameManager app FastAPI() manager GameManager() class MoveRequest(BaseModel): move: str class ChatRequest(BaseModel): message: str class ResetRequest(BaseModel): pass app.on_event(startup) def startup(): manager.engine.start() app.on_event(shutdown) def shutdown(): manager.engine.close() app.get(/health) def health(): return {status: ok} app.post(/move) def make_move(req: MoveRequest): try: result manager.handle_user_move(req.move) return result except ValueError as e: raise HTTPException(status_code400, detailstr(e)) app.post(/chat) def chat(req: ChatRequest): result manager.handle_chat(req.message) return result app.post(/reset) def reset(): manager.engine.reset_board() return {status: reset}启动命令uvicorn app:app --host 127.0.0.1 --port 8000启动后访问http://127.0.0.1:8000/docs可以直接在浏览器里调试接口。这里要特别说明上面的代码是一个可运行的骨架不是某一个具体仓库的完整实现。如果你在部署实际项目需要根据项目的真实目录、模型名、引擎路径做调整。5. 功能测试与效果验证服务跑起来之后不要急着做复杂场景先把功能一条条验证清楚。下面给出一套测试矩阵。5.1 健康检查测试目标确认服务进程存活接口可访问。curl http://127.0.0.1:8000/health预期输出{status:ok}如果这里返回失败优先看 Uvicorn 进程有没有起来8000 端口有没有被占用。5.2 基础对话测试目标验证 LLM 是否正常响应ABBY 人格是否生效。请求curl -X POST http://127.0.0.1:8000/chat \ -H Content-Type: application/json \ -d {message:你好帮我介绍一下阿比斯蒂尔这边怎么下棋}判断成功的标准返回结果包含自然语言回复且回复语气符合人格设定。如果你的回复里有我是 Abby Steele一个本地运行的 AI 棋手之类的自我介绍说明 system prompt 生效了。如果回复很机械或者和人格设定无关检查persona.txt里的设定是否在 messages 里作为第一条 system 消息传入。5.3 开局走棋测试目标验证用户走法能否被正确解析引擎能否正常应手。请求curl -X POST http://127.0.0.1:8000/move \ -H Content-Type: application/json \ -d {move:e2e4}预期返回包含用户走法已接受、引擎应手以及更新后的棋盘 FEN。判断成功的标准引擎返回了一个合法走法而且棋盘状态没有报错。常见失败原因走法格式不是 UCI 格式比如输入了 e4 而不是 e2e4或者引擎没有正常启动接口抛出Engine terminated unexpectedly。这通常是engine_path配置错误导致的。5.4 非法走法拦截测试目标验证非法走法能不能被正确拦截。请求curl -X POST http://127.0.0.1:8000/move \ -H Content-Type: application/json \ -d {move:e2e5}预期输出返回 400 错误提示非法走法。如果这里返回了 200说明游戏管理器里缺少合法性校验需要在上层加一个board.is_legal(move)的判断。def handle_user_move(self, move_str: str): try: move chess.Move.from_uci(move_str) except ValueError: raise ValueError(无效的走法格式) if move not in self.engine.board.legal_moves: raise ValueError(该走法不符合国际象棋规则) self.engine.board.push(move) # 后续逻辑这是很常见的坑实测时建议第一个就测这个场景。5.5 棋局复盘分析测试目标验证引擎分析结果能否被 LLM 转化成文字评价。这个测试稍微复杂一点需要手动设置一个局面然后调用分析接口。比如设置一个简单的局面让引擎给出前两个最佳变化from engine.stockfish_bridge import ChessEngineBridge bridge ChessEngineBridge() bridge.start() fen r1bqkbnr/pppp1ppp/2n5/4p3/2B1P3/5N2/PPPP1PPP/RNBQK2R b KQkq - 2 3 info bridge.analyse(fen, multipv2) for item in info: pv_moves [str(m) for m in item[pv]] score item[score].pov(chess.WHITE) print(f变化: { .join(pv_moves)}, 评估: {score}) bridge.close()如果这段代码能输出多个候选走法说明引擎分析链路正常。接下来把分析结果作为上下文交给 LLManalysis_text \n.join( f候选走法 {idx}: { .join([str(m) for m in item[pv]])} for idx, item in enumerate(info, start1) ) messages [ {role: system, content: 你是 Abby Steele一个国际象棋教练。}, {role: user, content: f这是当前局面分析结果请用通俗语言点评一下\n{analysis_text}} ] reply llm_client.chat(messages) print(reply[message][content])判断成功的标准LLM 输出的是对局面、候选走法的合理解读且没有幻觉出棋盘上不存在的棋子位置。如果 LLM 生成了与 FEN 矛盾的内容说明 prompt 里对局面的描述不够结构化需要把棋子坐标表列得更清楚。5.6 完整对局测试目标验证多轮交互是否稳定。操作步骤连续调用/move接口 10 到 20 次模拟一局完整对局。每次调用后检查引擎是否都能返回合法走法。棋盘状态是否持续更新。是否有内存溢出或响应超时。如果中途出现引擎无响应常见原因是 Stockfish 的进程被阻塞。可以在超时设置上做防护给engine.play加一个超时限制。6. 接口 API 与批量任务这个项目只要跑起来接口能力就有了关键是怎么把它用好。下面给出一个通用的 API 调用示例和批量任务设计思路具体参数需要对照你的实际服务地址调整。6.1 API 请求参数与返回结果以/move接口为例请求体是一个 JSON 对象包含字段move。返回结果建议包含{ user_move: e2e4, ai_move: e7e5, fen: r1bqkbnr/pppp1ppp/2n5/4p3/4P3/5N2/PPPP1PPP/RNBQK2R w KQkq - 0 3, reply: 这一步是经典开局应对黑方出马保护中心兵局面比较稳。 }如果从实际项目里看到的字段不同以实际为准。这里想强调的是字段设计要尽量自包含让调用方不需要再维护一份棋局状态。fen字段的返回意义就在这里客户端可以用它来干更多事情。6.2 Python 客户端调用示例import requests BASE_URL http://127.0.0.1:8000 def play_move(move: str): resp requests.post( f{BASE_URL}/move, json{move: move}, timeout30 ) resp.raise_for_status() return resp.json() if __name__ __main__: result play_move(e2e4) print(result[ai_move]) print(result[reply])这个客户端模式可以直接嵌到其他 Python 工具里比如做一个命令行下棋界面或者接入到 IM 机器人前提是你的网络环境允许且符合相关规定。6.3 批量棋局分析任务批量任务是这个项目很实用的能力。你可以在不修改上层服务的情况下写一个独立脚本批量处理棋谱文件。假设你有一批 PGN 格式的棋谱文件在inputs/目录下目标是逐局分析并生成复盘报告import os import chess.pgn def analyze_pgn_files(input_dir: str, output_dir: str): for filename in os.listdir(input_dir): if not filename.endswith(.pgn): continue filepath os.path.join(input_dir, filename) with open(filepath, encodingutf-8) as pgn_file: game chess.pgn.read_game(pgn_file) if game is None: continue board game.board() reports [] for move in game.mainline_moves(): board.push(move) reports.append({ fen: board.fen(), last_move: move.uci() }) # 按实际需求调用引擎分析和 LLM 生成报告 output_path os.path.join(output_dir, f{filename}.md) # 这里把 reports 写入文件批量任务设计时有三个要点加日志。每条任务开始和结束都要记录消息否则卡住了不知道停在哪一步。失败重试。调用引擎或 LLM 接口时可能会有偶发超时建议加上重试机制。控制并发。如果并发调用多个分析任务注意 CPU 资源和接口压力本地服务建议先串行跑跑通了再考虑并发。6.4 批量对话评测如果你要测试人格设定是否稳定也可以批量输入一组问题检查回复是否始终符合预期的角色设定。比如准备一组 20 条测试问题逐条调用/chat接口记录回复然后人工或规则化评估。这个流程能帮你在调 system prompt 时快速发现角色漂移问题。7. 资源占用与性能观察这个项目的性能观察点比较清晰因为它分成两个计算瓶颈LLM 对话和引擎计算。7.1 LLM 部分资源占用LLM 的资源占用取决于你选的模型大小和推理参数。观察方法用 Ollama 的话执行ollama ps查看当前加载的模型和内存占用。用任务管理器或top命令观察进程 CPU 占用率。用 NVIDIA 显卡时执行nvidia-smi查看显存占用。要特别注意LLM 服务通常会常驻内存模型越大占用的内存/显存越多。如果你在低配置机器上跑建议从 1B 到 3B 的模型开始。推理速度方面CPU 上小模型一般能接受但较大的模型响应会比较慢需要在接口超时时间上留足余量。7.2 国际象棋引擎部分资源占用Stockfish 这类引擎是纯 CPU 计算多核并行。引擎思考时间直接影响下一步响应速度。你可以通过limit_time参数控制引擎思考时长。对局模式每步限制 0.5 到 1 秒响应快棋力中等。分析模式每步限制 5 到 10 秒棋力更强适合复盘分析。调试时建议把limit_time调小先验证流程。7.3 显存降低技巧如果观察显存占用过高优先做三件事换更小的量化模型比如从 7B 换成 3B。减小 context 长度限制对话历史不用保留太长。关闭浏览器调试页面/docs接口调试完就关掉避免额外的内存消耗。7.4 端口冲突与进程残留本地部署最容易踩的坑是端口占用。先检查端口是否被别的进程占用# Linux / macOS lsof -i :8000 # Windows netstat -ano | findstr :8000如果端口被占用换一个端口启动即可uvicorn app:app --host 127.0.0.1 --port 8001另外Stockfish 进程在程序异常退出时可能残留。如果重启服务后提示引擎端口或进程冲突先查一下旧进程ps aux | grep stockfish确认后结束残留进程再重新启动。8. 常见问题与排查方法问题现象可能原因排查方式解决方案启动后app服务起不来端口被占用或 Python 依赖缺失看启动日志检查端口监听状态换端口执行pip install -r requirements.txt调用/chat接口超时模型过大或 CPU 推理慢观察 CPU 占用率和请求耗时换小模型调低num_predict增加接口 timeout调用/move返回非法走法用户输入走法格式错误检查请求体move字段是否是 UCI 格式前端或命令行先做格式校验引擎返回崩溃错误Stockfish 路径配置错误单独运行engine_path并输入uci测试修正可执行文件路径引擎走棋太慢limit_time设置过大查看引擎每一步耗时调小limit_timeLLM 回复和棋局无关prompt 里没有传入局面信息查看请求日志中 messages 里的局面描述在 prompt 中加入 FEN 和最近走法记录批量任务卡住某个棋局分析异常查看日志定位卡住的棋谱加入超时和失败重试单局失败不影响整体任务显存/内存持续增长多次请求后 LLM 上下文过长用ollama ps检查对对话历史做截断或定期重启服务这里面最隐蔽的坑是LLM 回复和棋局无关。很多情况下你以为把 FEN 传给 LLM它就能理解局面。实际上对于小参数模型来说一长串 FEN 字符基本没有语义可言它只能通过你附加的自然语言描述来理解局面。解决办法是不要把原始 FEN 直接丢给模型而是转换成自然语言描述比如当前是白方回合白方王在 e1后 d1黑方王 e8双方还没有换子LLM 才能理解局面。9. 最佳实践与使用建议9.1 先跑通最小闭环第一次部署时不要在早期就选大模型和高搜索深度。建议先用一个 1B 到 3B 的小模型加 0.5 秒的引擎思考时间跑通用户输入 - 引擎应手 - LLM 回复全流程。流程通了之后再逐步升级模型和参数。9.2 目录与配置管理模型文件、输入素材、输出结果要分开管理。项目根目录下建inputs/、outputs/、logs/三个目录日志单独放。模型由 Ollama 统一管理项目代码里不要提交模型文件。配置项比如模型名、引擎路径、思考时长最好集中放一个配置文件不要散落在代码里。可以用.env或config.yaml启动时读取。9.3 批量任务必须有日志和重试批量分析棋谱时每一局都要有独立的日志。格式建议[2025-01-01 10:00:00] [INFO] 开始分析 chess_game_001.pgn [2025-01-01 10:00:03] [INFO] 结束分析 chess_game_001.pgn生成了 40 条分析记录 [2025-01-01 10:00:03] [ERROR] chess_game_002.pgn 分析失败引擎超时失败任务不要直接终止整个队列而是记录错误后继续执行下一个任务。等全部跑完再集中处理失败项。9.4 接口服务要做访问限制如果这个服务要在局域网内给其他同学使用建议只监听本机地址或者在内网环境里加一层访问验证。不要在公网裸跑一个不带鉴权的接口服务。最简单的方式是把--host 127.0.0.1固定住需要外部访问时再显式改成可控的局域网地址并确认网络环境可信。9.5 合规使用提醒如果你要把这个项目的输出用于内容发布注意三点确认模型权重和引擎的许可证允许你的使用场景尤其注意商用限制。如果 AI 人格参考了任何现实中的角色或品牌需要先确认是否有授权需求。涉及他人棋谱、对局记录或个人文本时做匿名化处理。10. 总结与下一步Abby Steele 这个项目的价值不在于它有多强的棋力而在于它示范了一种典型的LLM 专用引擎组合架构。LLM 负责拟合人格和生成自然语言国际象棋引擎负责真实计算两者通过一个薄薄的中间层协同工作。这种思路可以迁移到很多场景LLM 调用代码解释器、LLM 调用数学计算器、LLM 调用 OCR 服务都是同一个模式。建议你第一次尝试时按这个顺序走先装好 Stockfish单独验证引擎能走棋。再装好 Ollama拉一个小模型验证它能对话。然后用文中的 Python 骨架把两者串起来开放/move和/chat两个接口。最后用一局完整对局作为验收测试。最容易踩的坑有三个引擎路径配对、走法格式校验、LLM 不理解原始 FEN。这三个都在前面的排查表里遇到问题按表格顺序查就行。后面想继续扩展的话可以考虑给项目加上语音对话模块把 LLM 输出接上本地 TTS或者加一个棋谱学习模式让 LLM 读取大师对局并结合引擎评估讲解思路。如果想把棋力再提升可以把 Lc0 这类神经网络引擎接进来或者让引擎在分析模式里输出多条候选走法再由 LLM 做综合讲解效果会好很多。 本地LLM与国际象棋引擎组合：构建离线AI棋手架构
这次我们来看一个挺有意思的本地 AI 项目Abby Steele。它的出发点并不复杂但架构很干净——用本地大语言模型Local LLM做人格和对话再通过国际象棋引擎Chess Engine提供真正的棋力。两者加起来就是一个不需要联网、能聊天、能下棋、能复盘分析的离线 AI 人格。先说最值得关注的点。第一全程离线运行对话和棋局分析都不依赖云端 API数据不出本机。第二它不是用 LLM 硬憋棋步而是把自然语言处理和棋力计算分开LLM 负责人格国际象棋引擎负责算棋再由一个中间层把两者协调起来。第三架构是模块化的模型引擎可以替换这意味着你不需要为这个项目去买高端显卡先用 CPU 跑一个小模型也能验证完整流程。这篇文章会带你拆解整个项目架构说明如何准备本地部署环境并且给出一套可执行的启动流程、功能测试方法和接口调用示例。不管你是想跑一个离线 AI 陪练还是想把 LLM 和传统引擎做能力互补这篇内容都可以直接参考。1. 核心能力速览能力项说明项目类型离线 AI 人格应用本地 LLM 国际象棋引擎组合核心组件本地大语言模型、国际象棋引擎、中间协调层运行模式完全离线数据不离开本机对话能力由本地 LLM 提供支持自定义人格设定棋力能力由国际象棋引擎提供通过 UCI 协议控制硬件要求取决于所选 LLM小模型可纯 CPU 运行启动方式命令行启动 HTTP 接口服务API 支持可提供 REST API方便对接其他工具批量任务支持批量棋局分析、批量对话评测适合场景本地 AI 助手、棋类陪练、LLM 工具调用研究、离线场景演示这里要明确一点这个项目的实际资源占用不由项目本身决定而是由你选的模型决定。LLM 部分可以用 1B、3B 这种小参数模型CPU 也能跑国际象棋引擎部分基本是纯 CPU 计算。所以这个项目本身的门槛很低真正需要评估的是你所选模型的资源需求。2. 适用场景与使用边界从实际使用角度来看Abby Steele 这类LLM 国际象棋引擎的组合适合下面这些场景本地 AI 陪练想练国际象棋但又不想在手机或网页端被算法记录对局数据可以用本地引擎做对弈。人格化角色研究想测试不同 system prompt 对 AI 人格稳定性的影响可以把这个项目当实验框架。LLM 工具调用示范让 LLM 通过工具调用去操作外部引擎这是比较典型的 Agent 入门案例。离线演示环境在展台、公司内网、无外网环境下做一个 AI 下棋展示不需要申请云端权限。棋局数据批量处理给大量棋谱生成文字复盘报告人工判断效率太低可以用这个管线自动化处理。不适合什么场景先说结论它不适合拿来当高水平棋类训练软件也不适合作为严肃的 AI 产品生产系统。原因很简单LLM 生成的复盘文本可能带有幻觉尤其在评估复杂局面时它给的解释可能和引擎评估值不一致另外中间层如果设计得不够严谨LLM 可能错误解读棋局状态。它的价值更多在于研究、演示和本地工具链整合。安全与合规边界也要提一下。使用本地模型时注意模型权重的开源许可协议不同模型允许商用和分发的范围不一样。如果这个AI 人格的设定参考了真实人物或商业角色需要确认是否涉及肖像权、名誉权和角色版权。涉及用户输入文本时注意不要采集不必要的个人信息训练或微调前需要把数据脱敏并取得授权。这一点对任何本地 AI 应用都适用项目本身不涉及网络行为但使用者自己要有数据治理意识。3. 本地部署环境准备部署一个 LLM 国际象棋引擎的离线应用本质上是把两块独立系统装进同一台机器再用代码串起来。所以前置条件分三块基础环境、LLM 运行时、国际象棋引擎。3.1 基础环境检查操作系统方面Windows、Linux、macOS 都可以跑但如果你要长期跑服务推荐 Linux进程管理和资源控制更省心。Python 3.10 以上是稳妥的选择因为后面写中间层需要用到较新的语法和依赖包。确认机器上有可用的 Python 和 pippython --version pip --version如果没有安装去 Python 官网下载对应系统的安装包。Windows 用户安装时记得勾选 Add Python to PATH。磁盘方面LLM 模型文件是主要占用者。几 B 参数的量化模型通常在 1GB 到 4GB 之间几十 B 的模型可能要 20GB 以上。建议给项目至少预留 10GB 空间如果计划尝试多种模型那按“每种模型文件 × 模型数量”来规划。3.2 LLM 运行时选择本地 LLM 的常见加载工具有好几类区别在于安装方式和资源占用。这里举两个典型选项Ollama安装简单命令行一条命令就能拉取模型并启动服务支持 OpenAI 风格的接口适合快速搭建。llama.cpp更底层一些对 CPU 推理优化较好适合需要精细控制参数和部署在老旧机器上的场景。两种工具选一个就行。如果按最简路径用 Ollama 会更顺。安装 Ollama 的通用方式是根据官方文档提供的安装脚本或安装包来操作。安装完成后服务默认监听本机的 11434 端口先确认服务状态ollama list如果你在这个阶段看不到任何模型说明还没有拉取模型。拉取一个小模型的命令模板如下ollama pull qwen2.5:3b这条命令会从模型仓库下载一个 3B 参数规模的模型到本地适合 CPU 跑。如果机器有 NVIDIA 显卡也可以选 7B 或更大一点的模型。具体拉取哪些模型以你实际网络和硬件条件为准。3.3 国际象棋引擎安装国际象棋引擎选择很多Stockfish 是最常见的开源选择。它的棋力很强而且支持 UCI 协议这意味着你可以通过标准文本命令和它交互不需要依赖任何专用 SDK。安装 Stockfish 的常见方式Windows从官网下载可执行文件或者通过包管理器安装。Linux/macOS用系统包管理器安装。以 Ubuntu/Debian 为例命令模板如下sudo apt update sudo apt install stockfish安装完成后先验证引擎能否正常运行。在命令行输入stockfish进入交互模式然后输入uci如果能看到引擎输出自己的 UCI 版本和选项列表说明引擎可用。stockfish uci quitWindows 用户如果下载的是 exe 文件需要把引擎路径记住后面在中间层代码里要用到。3.4 Python 依赖中间层代码推荐用 python-chess 库来处理棋局和 UCI 协议用 requests 或 httpx 来调用本地 LLM 的接口。安装命令pip install python-chess requestspython-chess 这个库封装了棋盘表示、走法生成、UCI 协议通信等功能不需要自己解析引擎输出能省掉不少开发量。到这里基础环境就准备好了。你可以先单独验证两块组件LLM 能不能正常对话国际象棋引擎能不能正常走棋。两个都正常后再进入接线阶段。4. 安装部署与启动流程这部分的重点是搭一个中间层把 LLM 和棋类引擎连起来。项目整体逻辑一条线用户走棋 - 棋盘状态更新 - 调用国际象棋引擎计算最佳应手 - 把局面和引擎分析结果交给 LLM - LLM 生成人格化的文字回复。4.1 目录结构规划建议按下面的方式组织项目文件后续扩展会比较舒服abby_steele/ ├── engine/ │ └── stockfish_bridge.py # 国际象棋引擎封装 ├── llm/ │ └── llm_client.py # LLM 接口封装 ├── core/ │ └── game_manager.py # 棋局状态管理 ├── app.py # HTTP 服务入口 ├── prompts/ │ └── persona.txt # 人格设定 ├── outputs/ │ └── .gitkeep # 输出文件目录 └── requirements.txt实际项目不一定要用这个结构但保持引擎层、LLM 层、控制层分离是对的。如果中间层代码和棋局逻辑混在一起后面换模型或换引擎会很痛苦。4.2 国际象棋引擎封装用 python-chess 启动 Stockfish并让引擎自己完成思考。下面是一个通用封装思路路径需要按你的实际环境修改import chess import chess.engine class ChessEngineBridge: def __init__(self, engine_pathstockfish, limit_time1.0): self.engine_path engine_path self.limit_time limit_time self.engine None self.board chess.Board() def start(self): self.engine chess.engine.SimpleEngine.popen_uci(self.engine_path) def reset_board(self): self.board chess.Board() return self.board.fen() def set_fen(self, fen: str): self.board chess.Board(fen) def get_best_move(self): result self.engine.play( self.board, chess.engine.Limit(timeself.limit_time) ) return result.move def analyse(self, fen: str, multipv: int 1): board chess.Board(fen) info self.engine.analyse( board, chess.engine.Limit(timeself.limit_time), multipvmultipv ) return info def close(self): if self.engine: self.engine.quit()这段代码把 Stockfish 封装成了一个独立服务。get_best_move返回引擎计算出的最佳走法analyse返回局面评估信息供后面 LLM 复盘使用。注意engine_path如果你是直接安装的 stockfish通常可以直接用命令名如果是下载的 exe 文件就写成完整路径。4.3 LLM 客户端封装调用本地 LLM 的接口最省事的方式是走 Ollama 提供的 HTTP 接口。它默认在http://127.0.0.1:11434/api/chat提供聊天补全能力。封装思路如下import requests class LLMClient: def __init__(self, base_urlhttp://127.0.0.1:11434, modelqwen2.5:3b): self.base_url base_url self.model model def chat(self, messages, temperature0.7, streamFalse): url f{self.base_url}/api/chat payload { model: self.model, messages: messages, stream: stream, options: { temperature: temperature } } response requests.post(url, jsonpayload, timeout120) response.raise_for_status() if stream: return response.iter_lines() return response.json()如果你用的是 llama.cpp 的 server 模式接口路径会不太一样但思路相同把本地模型的 HTTP 补全接口封装成客户端供上层调用。这里的model名称要和ollama pull时拉取的模型名一致。4.4 游戏管理器游戏管理器负责维护棋局状态协调引擎和 LLM 的调用顺序。核心流程如下用户输入走法比如 e2e4。管理器把走法更新到当前棋盘。如果用户走完由引擎计算应手并把应手也更新到棋盘。管理器把当前棋盘 FEN、双方最后几步走法和引擎评估值一起拼进 LLM 的 prompt。LLM 生成回复文本返回给用户。from engine.stockfish_bridge import ChessEngineBridge from llm.llm_client import LLMClient class GameManager: def __init__(self, engine_pathstockfish, modelqwen2.5:3b): self.engine ChessEngineBridge(engine_path) self.llm LLMClient(modelmodel) self.persona self._load_persona() def _load_persona(self): # 从 prompts/persona.txt 读取人格设定 with open(prompts/persona.txt, r, encodingutf-8) as f: return f.read().strip()这里人格设定是关键。Abby Steele 这个 AI 人格的性格、说话方式和行为风格都是由persona.txt里的 system prompt 决定的。你可以把它写成一个友好但犀利的国际象棋教练或一个沉稳安静的棋友取决于你的目标。4.5 启动 HTTP 服务为了让这个项目能被外部调用可以加一层 HTTP 接口。用 Flask 或 FastAPI 都行FastAPI 写起来更简洁自动带接口文档。先安装pip install fastapi uvicorn服务入口示例from fastapi import FastAPI, HTTPException from pydantic import BaseModel from core.game_manager import GameManager app FastAPI() manager GameManager() class MoveRequest(BaseModel): move: str class ChatRequest(BaseModel): message: str class ResetRequest(BaseModel): pass app.on_event(startup) def startup(): manager.engine.start() app.on_event(shutdown) def shutdown(): manager.engine.close() app.get(/health) def health(): return {status: ok} app.post(/move) def make_move(req: MoveRequest): try: result manager.handle_user_move(req.move) return result except ValueError as e: raise HTTPException(status_code400, detailstr(e)) app.post(/chat) def chat(req: ChatRequest): result manager.handle_chat(req.message) return result app.post(/reset) def reset(): manager.engine.reset_board() return {status: reset}启动命令uvicorn app:app --host 127.0.0.1 --port 8000启动后访问http://127.0.0.1:8000/docs可以直接在浏览器里调试接口。这里要特别说明上面的代码是一个可运行的骨架不是某一个具体仓库的完整实现。如果你在部署实际项目需要根据项目的真实目录、模型名、引擎路径做调整。5. 功能测试与效果验证服务跑起来之后不要急着做复杂场景先把功能一条条验证清楚。下面给出一套测试矩阵。5.1 健康检查测试目标确认服务进程存活接口可访问。curl http://127.0.0.1:8000/health预期输出{status:ok}如果这里返回失败优先看 Uvicorn 进程有没有起来8000 端口有没有被占用。5.2 基础对话测试目标验证 LLM 是否正常响应ABBY 人格是否生效。请求curl -X POST http://127.0.0.1:8000/chat \ -H Content-Type: application/json \ -d {message:你好帮我介绍一下阿比斯蒂尔这边怎么下棋}判断成功的标准返回结果包含自然语言回复且回复语气符合人格设定。如果你的回复里有我是 Abby Steele一个本地运行的 AI 棋手之类的自我介绍说明 system prompt 生效了。如果回复很机械或者和人格设定无关检查persona.txt里的设定是否在 messages 里作为第一条 system 消息传入。5.3 开局走棋测试目标验证用户走法能否被正确解析引擎能否正常应手。请求curl -X POST http://127.0.0.1:8000/move \ -H Content-Type: application/json \ -d {move:e2e4}预期返回包含用户走法已接受、引擎应手以及更新后的棋盘 FEN。判断成功的标准引擎返回了一个合法走法而且棋盘状态没有报错。常见失败原因走法格式不是 UCI 格式比如输入了 e4 而不是 e2e4或者引擎没有正常启动接口抛出Engine terminated unexpectedly。这通常是engine_path配置错误导致的。5.4 非法走法拦截测试目标验证非法走法能不能被正确拦截。请求curl -X POST http://127.0.0.1:8000/move \ -H Content-Type: application/json \ -d {move:e2e5}预期输出返回 400 错误提示非法走法。如果这里返回了 200说明游戏管理器里缺少合法性校验需要在上层加一个board.is_legal(move)的判断。def handle_user_move(self, move_str: str): try: move chess.Move.from_uci(move_str) except ValueError: raise ValueError(无效的走法格式) if move not in self.engine.board.legal_moves: raise ValueError(该走法不符合国际象棋规则) self.engine.board.push(move) # 后续逻辑这是很常见的坑实测时建议第一个就测这个场景。5.5 棋局复盘分析测试目标验证引擎分析结果能否被 LLM 转化成文字评价。这个测试稍微复杂一点需要手动设置一个局面然后调用分析接口。比如设置一个简单的局面让引擎给出前两个最佳变化from engine.stockfish_bridge import ChessEngineBridge bridge ChessEngineBridge() bridge.start() fen r1bqkbnr/pppp1ppp/2n5/4p3/2B1P3/5N2/PPPP1PPP/RNBQK2R b KQkq - 2 3 info bridge.analyse(fen, multipv2) for item in info: pv_moves [str(m) for m in item[pv]] score item[score].pov(chess.WHITE) print(f变化: { .join(pv_moves)}, 评估: {score}) bridge.close()如果这段代码能输出多个候选走法说明引擎分析链路正常。接下来把分析结果作为上下文交给 LLManalysis_text \n.join( f候选走法 {idx}: { .join([str(m) for m in item[pv]])} for idx, item in enumerate(info, start1) ) messages [ {role: system, content: 你是 Abby Steele一个国际象棋教练。}, {role: user, content: f这是当前局面分析结果请用通俗语言点评一下\n{analysis_text}} ] reply llm_client.chat(messages) print(reply[message][content])判断成功的标准LLM 输出的是对局面、候选走法的合理解读且没有幻觉出棋盘上不存在的棋子位置。如果 LLM 生成了与 FEN 矛盾的内容说明 prompt 里对局面的描述不够结构化需要把棋子坐标表列得更清楚。5.6 完整对局测试目标验证多轮交互是否稳定。操作步骤连续调用/move接口 10 到 20 次模拟一局完整对局。每次调用后检查引擎是否都能返回合法走法。棋盘状态是否持续更新。是否有内存溢出或响应超时。如果中途出现引擎无响应常见原因是 Stockfish 的进程被阻塞。可以在超时设置上做防护给engine.play加一个超时限制。6. 接口 API 与批量任务这个项目只要跑起来接口能力就有了关键是怎么把它用好。下面给出一个通用的 API 调用示例和批量任务设计思路具体参数需要对照你的实际服务地址调整。6.1 API 请求参数与返回结果以/move接口为例请求体是一个 JSON 对象包含字段move。返回结果建议包含{ user_move: e2e4, ai_move: e7e5, fen: r1bqkbnr/pppp1ppp/2n5/4p3/4P3/5N2/PPPP1PPP/RNBQK2R w KQkq - 0 3, reply: 这一步是经典开局应对黑方出马保护中心兵局面比较稳。 }如果从实际项目里看到的字段不同以实际为准。这里想强调的是字段设计要尽量自包含让调用方不需要再维护一份棋局状态。fen字段的返回意义就在这里客户端可以用它来干更多事情。6.2 Python 客户端调用示例import requests BASE_URL http://127.0.0.1:8000 def play_move(move: str): resp requests.post( f{BASE_URL}/move, json{move: move}, timeout30 ) resp.raise_for_status() return resp.json() if __name__ __main__: result play_move(e2e4) print(result[ai_move]) print(result[reply])这个客户端模式可以直接嵌到其他 Python 工具里比如做一个命令行下棋界面或者接入到 IM 机器人前提是你的网络环境允许且符合相关规定。6.3 批量棋局分析任务批量任务是这个项目很实用的能力。你可以在不修改上层服务的情况下写一个独立脚本批量处理棋谱文件。假设你有一批 PGN 格式的棋谱文件在inputs/目录下目标是逐局分析并生成复盘报告import os import chess.pgn def analyze_pgn_files(input_dir: str, output_dir: str): for filename in os.listdir(input_dir): if not filename.endswith(.pgn): continue filepath os.path.join(input_dir, filename) with open(filepath, encodingutf-8) as pgn_file: game chess.pgn.read_game(pgn_file) if game is None: continue board game.board() reports [] for move in game.mainline_moves(): board.push(move) reports.append({ fen: board.fen(), last_move: move.uci() }) # 按实际需求调用引擎分析和 LLM 生成报告 output_path os.path.join(output_dir, f{filename}.md) # 这里把 reports 写入文件批量任务设计时有三个要点加日志。每条任务开始和结束都要记录消息否则卡住了不知道停在哪一步。失败重试。调用引擎或 LLM 接口时可能会有偶发超时建议加上重试机制。控制并发。如果并发调用多个分析任务注意 CPU 资源和接口压力本地服务建议先串行跑跑通了再考虑并发。6.4 批量对话评测如果你要测试人格设定是否稳定也可以批量输入一组问题检查回复是否始终符合预期的角色设定。比如准备一组 20 条测试问题逐条调用/chat接口记录回复然后人工或规则化评估。这个流程能帮你在调 system prompt 时快速发现角色漂移问题。7. 资源占用与性能观察这个项目的性能观察点比较清晰因为它分成两个计算瓶颈LLM 对话和引擎计算。7.1 LLM 部分资源占用LLM 的资源占用取决于你选的模型大小和推理参数。观察方法用 Ollama 的话执行ollama ps查看当前加载的模型和内存占用。用任务管理器或top命令观察进程 CPU 占用率。用 NVIDIA 显卡时执行nvidia-smi查看显存占用。要特别注意LLM 服务通常会常驻内存模型越大占用的内存/显存越多。如果你在低配置机器上跑建议从 1B 到 3B 的模型开始。推理速度方面CPU 上小模型一般能接受但较大的模型响应会比较慢需要在接口超时时间上留足余量。7.2 国际象棋引擎部分资源占用Stockfish 这类引擎是纯 CPU 计算多核并行。引擎思考时间直接影响下一步响应速度。你可以通过limit_time参数控制引擎思考时长。对局模式每步限制 0.5 到 1 秒响应快棋力中等。分析模式每步限制 5 到 10 秒棋力更强适合复盘分析。调试时建议把limit_time调小先验证流程。7.3 显存降低技巧如果观察显存占用过高优先做三件事换更小的量化模型比如从 7B 换成 3B。减小 context 长度限制对话历史不用保留太长。关闭浏览器调试页面/docs接口调试完就关掉避免额外的内存消耗。7.4 端口冲突与进程残留本地部署最容易踩的坑是端口占用。先检查端口是否被别的进程占用# Linux / macOS lsof -i :8000 # Windows netstat -ano | findstr :8000如果端口被占用换一个端口启动即可uvicorn app:app --host 127.0.0.1 --port 8001另外Stockfish 进程在程序异常退出时可能残留。如果重启服务后提示引擎端口或进程冲突先查一下旧进程ps aux | grep stockfish确认后结束残留进程再重新启动。8. 常见问题与排查方法问题现象可能原因排查方式解决方案启动后app服务起不来端口被占用或 Python 依赖缺失看启动日志检查端口监听状态换端口执行pip install -r requirements.txt调用/chat接口超时模型过大或 CPU 推理慢观察 CPU 占用率和请求耗时换小模型调低num_predict增加接口 timeout调用/move返回非法走法用户输入走法格式错误检查请求体move字段是否是 UCI 格式前端或命令行先做格式校验引擎返回崩溃错误Stockfish 路径配置错误单独运行engine_path并输入uci测试修正可执行文件路径引擎走棋太慢limit_time设置过大查看引擎每一步耗时调小limit_timeLLM 回复和棋局无关prompt 里没有传入局面信息查看请求日志中 messages 里的局面描述在 prompt 中加入 FEN 和最近走法记录批量任务卡住某个棋局分析异常查看日志定位卡住的棋谱加入超时和失败重试单局失败不影响整体任务显存/内存持续增长多次请求后 LLM 上下文过长用ollama ps检查对对话历史做截断或定期重启服务这里面最隐蔽的坑是LLM 回复和棋局无关。很多情况下你以为把 FEN 传给 LLM它就能理解局面。实际上对于小参数模型来说一长串 FEN 字符基本没有语义可言它只能通过你附加的自然语言描述来理解局面。解决办法是不要把原始 FEN 直接丢给模型而是转换成自然语言描述比如当前是白方回合白方王在 e1后 d1黑方王 e8双方还没有换子LLM 才能理解局面。9. 最佳实践与使用建议9.1 先跑通最小闭环第一次部署时不要在早期就选大模型和高搜索深度。建议先用一个 1B 到 3B 的小模型加 0.5 秒的引擎思考时间跑通用户输入 - 引擎应手 - LLM 回复全流程。流程通了之后再逐步升级模型和参数。9.2 目录与配置管理模型文件、输入素材、输出结果要分开管理。项目根目录下建inputs/、outputs/、logs/三个目录日志单独放。模型由 Ollama 统一管理项目代码里不要提交模型文件。配置项比如模型名、引擎路径、思考时长最好集中放一个配置文件不要散落在代码里。可以用.env或config.yaml启动时读取。9.3 批量任务必须有日志和重试批量分析棋谱时每一局都要有独立的日志。格式建议[2025-01-01 10:00:00] [INFO] 开始分析 chess_game_001.pgn [2025-01-01 10:00:03] [INFO] 结束分析 chess_game_001.pgn生成了 40 条分析记录 [2025-01-01 10:00:03] [ERROR] chess_game_002.pgn 分析失败引擎超时失败任务不要直接终止整个队列而是记录错误后继续执行下一个任务。等全部跑完再集中处理失败项。9.4 接口服务要做访问限制如果这个服务要在局域网内给其他同学使用建议只监听本机地址或者在内网环境里加一层访问验证。不要在公网裸跑一个不带鉴权的接口服务。最简单的方式是把--host 127.0.0.1固定住需要外部访问时再显式改成可控的局域网地址并确认网络环境可信。9.5 合规使用提醒如果你要把这个项目的输出用于内容发布注意三点确认模型权重和引擎的许可证允许你的使用场景尤其注意商用限制。如果 AI 人格参考了任何现实中的角色或品牌需要先确认是否有授权需求。涉及他人棋谱、对局记录或个人文本时做匿名化处理。10. 总结与下一步Abby Steele 这个项目的价值不在于它有多强的棋力而在于它示范了一种典型的LLM 专用引擎组合架构。LLM 负责拟合人格和生成自然语言国际象棋引擎负责真实计算两者通过一个薄薄的中间层协同工作。这种思路可以迁移到很多场景LLM 调用代码解释器、LLM 调用数学计算器、LLM 调用 OCR 服务都是同一个模式。建议你第一次尝试时按这个顺序走先装好 Stockfish单独验证引擎能走棋。再装好 Ollama拉一个小模型验证它能对话。然后用文中的 Python 骨架把两者串起来开放/move和/chat两个接口。最后用一局完整对局作为验收测试。最容易踩的坑有三个引擎路径配对、走法格式校验、LLM 不理解原始 FEN。这三个都在前面的排查表里遇到问题按表格顺序查就行。后面想继续扩展的话可以考虑给项目加上语音对话模块把 LLM 输出接上本地 TTS或者加一个棋谱学习模式让 LLM 读取大师对局并结合引擎评估讲解思路。如果想把棋力再提升可以把 Lc0 这类神经网络引擎接进来或者让引擎在分析模式里输出多条候选走法再由 LLM 做综合讲解效果会好很多。