1. 项目概述给桌面游戏配一个AI主持人我图什么桌游跑团这事尤其是DD、COC这类规则厚重的TRPG卡点从来不在玩的那几个小时而在开团前。一个真人GM要备剧本、编NPC、设计遭遇战、翻规则书算数值遇上团里人时间凑不齐档案一放就是俩月。我身边不少朋友对跑团有兴趣但一听说要自己当GM直接打退堂鼓。我后来想明白缺的不是热情是一个能扛住备团琐事的“副驾”。Edge-DM这个项目就是我自己动手做的一个AI桌面游戏主持人。核心思路是用本地大语言模型承担GM的叙事和裁决职能配一套规则引擎和记忆系统让它能在没有真人主持的情况下完整跑起一场团。不是简单接个ChatGPT让它编故事而是把“AI判断规则计算状态管理骰子结算”全链路打通玩家只需要打开页面、操作角色、输入行动剩下的交给Edge-DM。目前我拿它跑了十几场虚构冒险六人团打过、单人团跑过、临时加入的新人也带过场面基本撑得起来。这个项目最适合三类人一是想入门跑团但找不到GM的新手二是习惯当GM但不想每场都背电脑翻书的懒人三是对“AI Agent落地到具体场景”感兴趣的技术玩家。如果你只想要一个会讲故事的聊天机器人那它超出预期如果你想要一个严格按规则书办事的工具人那它确实比真人刻板不少但它不累、不鸽、不迟到这三点直接把跑团最大的隐性成本打掉了。1.1 我当时遇到的真实痛点先说背景。我在的跑团群固定每周五晚上活动表面上有六个常驻玩家实际能到场的稳定三人。有人加班、有人陪对象、有人就是忘了导致GM每次都要临时改剧情把一队人从六人调整成三人战斗数值还要重算。最崩溃的一次是GM临时出差整团活动直接变成桌游闲聊局。我那段时间就在想能不能把GM的活拆开——叙事部分让AI自由发挥裁决和算数部分交给代码这样即使真人GM不在团员也能自己开团。后来我仔细盘了盘GM的日常工作读描述、扮演NPC、判定行动结果、管理战斗回合、推进剧情、记录状态。这六件事里叙事的量最大但规则判定的容错要求最高。纯用聊天式AI容易在数值上胡编纯写规则脚本又失去灵活性和沉浸感。Edge-DM做的就是混合路线规则机上强制走代码剧情和对话交给生成式AI。玩家这边看到的是一个正常在推进剧情的GM但它背后是几个模块在分工干活。1.2 Edge-DM解决什么问题肉眼看Edge-DM解决的是“没人愿意当GM”的问题。深一层看它解决的是“跑团工具链断裂”的问题。现在市面上的跑团工具要么是纯粹的电子桌板只有地图和骰子没有叙事能力要么是纯聊天AI能讲故事但没有规则概念更不会帮你维护角色卡。Edge-DM把这两件事焊在一起了。比如你说“我要潜行过走廊”它先走技能检定流程算出你的潜行值对抗守卫的察觉值成功才让你过失败就触发警报而不是像普通聊天AI那样直接替你编一个完美通关。另一个隐含价值是数据留在本地。所有对话、角色状态、剧情记录都存在自己的机器上不上传任何第三方的聊天服务。这对很多跑团群来说反而是刚需——毕竟团里的黑历史够写一本书了谁也不想被拿去当训练数据。我把推理模型也跑在本地断网状态下照样能开团出差路上单机房也不耽误。2. 架构设计与模型选型AI主持人为什么放在本地跑Edge-DM最核心的设计决策是把整个系统跑在边缘侧也就是自己的电脑上而不是云端API。这个选择从我个人的角度看几乎没悬念。跑团是一个长会话、多轮、状态密集的应用一场团动辄三四个小时对话轮次几百轮。云端接口按token计费跑一次团下来的成本我实测过按正常用量相当于两张电影票荒打团一个月比游戏本体还贵。本地推理虽然要一次性花钱买显卡但之后零边际成本想跑多少场跑多少场。另一个原因是延迟和隐私。跑团对话不是查资料玩家说完话GM得接话。云端接口的往返怎么也有两三秒还被网络波动牵制。人的耐心在等回应这件事上很低三五秒没回玩家就开始刷手机了。本地模型虽然绝对速度未必比云端快但没有网络抖动延迟稳定体感反而更顺。隐私就更不用说了玩家的角色卡、剧情走向全在自己硬盘上怎么折腾都行。2.1 边缘计算的取舍逻辑边缘计算不是没有代价。最明显的代价是模型能力的天花板本地能撑起的模型和云端那些几百B的大模型在语境理解和长文连贯性上有肉眼可见的差距。我在项目里做了个折中主场战斗判定和核心叙事用本地中等模型遇到需要长程规划或多步推理时切一个轻量agent模式让模型先列出决策树再沿着树展开。实践证明跑团需要的GM能力并不是“无所不知”而是“一致性”——只要设定和判定稳定玩家不会觉得AI比真人差。还有一点是关于可控性的思维转变。云端模型是黑盒你只能调参数不能插逻辑。本地部署的模型我可以在生成结果之后挂一层规则校验让代码检查AI输出的技能名、数值范围、状态名称是否符合当前规则集不匹配就直接打回重写。这在云端的标准API接口里几乎做不到除非自己包一层巨大的prompt逻辑。本地路线的“规则后置校验”这一招直接让AI GM的数值错误率从偶尔变成稀有事件。2.2 模型怎么选量化、显存和上下文选模型这件事我踩过几次坑。最初用的7B模型速度很快但规则理解和多角色扮演明显力不从心经常把NPC的话说串。后来换14B模型好了不少可显存占用直接翻倍。实测下来建议至少8GB显存起步16GB就比较从容。模型量化推荐Q4_K_M能在损失很小的情况下把显存占用压到可用范围。我当前的稳定组合是主推理用14B的Q4量化摘要和状态整理用3B的小模型两模型各司其职成本可控。上下文长度是另一个关键参数。最初我用4K上下文跑团到第二小时就开始出现“失忆”。后来换成32K上下文基本能撑完整场但显存又涨了不少。实操中我更推荐“分段存档总结压缩”的组合每跑完一个场景让3B小模型自动生成一段剧情摘要把原始对话归档进历史库只把摘要留在大模型上下文里。这样即使上下文只有16K也能维持全剧情的连贯性不会出现“刚救下的NPC转眼就忘了”的尴尬。模型规格显存需求能跑什么我的评价7B Q44-6GB短团、叙事为主台词容易崩不推荐当主GM14B Q48-12GB标准跑团主力能力/占用比最平衡32B Q416-24GB复杂规则多人团效果好但硬件门槛高3B Q42-3GB摘要、状态标签只适合做辅助主线扛不住2.3 具体工具链怎么搭Edge-DM后端用FastAPI推理走Ollama本地服务游戏状态存在SQLite前端是一个纯本地Web页面。选FastAPI没别的原因就是Python生态顺手后续接工具脚本方便。Ollama作为推理后端的好处是模型管理和API封装都很省心一条命令就能切换模型。前端没有选重型框架直接用原生的HTMLJS因为界面只有三块会话区、状态面板、骰子日志不需要什么复杂交互。工具调用的设计上也做了精简。GM需要的能力抽象成四个工具掷骰、规则查询、状态记录、场景生成。掷骰直接走真随机数生成器不经过模型规则查询用向量检索在规则文档里找条目状态记录写SQLite场景生成则调大模型的prompt模板。这套组合的好处是模型不直接接触数值核心只负责“说人话”数值和规则由代码兜底AI再怎么发挥也不会把规则讲到沟里去。3. 核心模块逐层拆解AI GM不是只会聊天的NPC很多人以为AI GM就是prompt写得好的聊天机器人实际完全不是这么回事。跑团场景对一致性的要求极高角色状态改没改、剧情分支触发没触发、前后规则是否冲突这些靠聊天方式根本顾不过来。Edge-DM真正区别于玩具级AI跑团工具的地方在于它的几个核心模块是围绕“状态一致性”来设计的。把GM职能拆成模块之后每条职责都有了专门的实现路径而不是全塞给模型去自由发挥。下面挑四个最关键的模块展开说基本覆盖了跑团中难度最高的部分。3.1 规则引擎把裁判权从AI手里抢回来规则引擎是整个系统我最得意的部分。它负责处理所有需要数值计算的动作攻击判定、伤害结算、技能检定、豁免骰。流程是这样的玩家在会话里说“我要用长剑砍那个地精”大模型先解析出意图把“攻击者”“目标”“武器”“动作类型”提取成结构化参数然后交给规则引擎。规则引擎查角色卡拿到攻击加值调武器数据拿到伤害骰再结合目标护甲算出成功率区间。为什么要把裁判权从AI手里抢回来因为大模型天生不擅长精确计算。我说“投一个d20加上敏捷加值3和熟练加值2结果要大于等于目标护甲等级15”它能做到七八成概率给对答案但剩下两三成的错误足够毁掉一场重要战斗。规则引擎用代码算骰子结果是确定的AI只负责把结果翻译成“你的长剑破空而去重重砍在盾牌上”这类描述。分工清楚之后游戏体验直线上升。具体的检定流程我设计成三步。第一步是意图提取把玩家的自然语言行动变成结构化请求第二步是规则匹配找到对应的计算流程和数值第三步是结果生成由AI基于真实结果写一段带氛围的叙述。这三步各有一个独立的服务模块中间用JSON串数据。哪怕模型在第一步把意图理解错了规则引擎也能通过参数校验拦下来提示玩家“你的角色没有这个技能”。3.2 NPC扮演与剧情连续性让每个角色都有“人设档案”剧情连续性是我早期最头疼的问题。大模型单独看每一轮对话都很正常但你跑三个小时后回头一看刚遇见的商人上一秒还穿着红披风下一秒就被说成蓝袍子更离谱的是把死掉的NPC又放了出来。问题根源在于模型没有长期记忆每一轮生成都像第一次见面。解决办法是给NPC建“人设档案”相当于给每个重要角色建一张资料卡包括外貌、性格、说话习惯、当前目标和已知信息。当剧情推进到某个NPC出场时系统先把档案注入到当轮的prompt里让模型基于档案生成台词。档案同时受到规则引擎更新比如NPC受伤了状态就直接写进档案下一轮AI自然会表现出受伤的姿态。这套机制比单纯拉长上下文有效得多因为档案是结构化数据没有语义损失模型拿到的信息永远是准确和最新的。剧情连续性的另一个关键是事件日志。每轮行动结束后系统会把“谁做了什么、结果如何”写进日志。到了剧情关键节点之前3B小模型自动跑一遍日志生成一段摘要然后把摘要放回上下文。这种“滚动摘要”的方式配合NPC档案基本解决了三小时以上团的长线失忆问题。我实测最长跑过五小时的团中间角色关系线没有断过。3.3 场景生成与战斗管理从“描述”到“状态机”场景生成模块负责把静态的文本描述变成一个可交互的状态机。比如玩家推门进了一个大厅AI生成了一段大厅描述但系统后台会同时生成这个场景的几个关键元素门、窗口、壁炉、可疑的雕像每个元素都有自己的状态和交互规则。玩家说“我要检查雕像”系统能直接定位到雕像元素并给出合适的检定流程而不是让AI临时瞎编。战斗管理是场景状态机的集中体现。开战后系统进入回合制模式每个角色有一个行动状态位轮到谁行动就高亮谁玩家只能操作自己的角色。系统会计算行动顺序追踪生命值变化处理状态效果如中毒、眩晕这类持续效果。AI在这个模块里只做一件事以GM的口吻描述每一次攻击和施法。数值结算全部走战斗状态机避免了大模型在回合制里算不齐进度的问题。战斗模块我做得最细的地方是“行动经济”的设计。每回合每个角色有标准动作、附赠动作和反应三种行动类型系统会在状态机上严格区分。玩家说“我要用一个附赠动作喝药水”系统会校验这个动作是否合法并消耗对应的行动槽。这套机制相当于给AI GM装了一套数值护栏让战斗策略真正有了规则感而不是各说各的。3.4 记忆与状态管理跑团数据的“存档系统”保存和读取跑团状态是Edge-DM的基础设施。每场团有独立的会话ID所有对话、骰点、剧情分支、角色状态都挂在会话下面。状态数据分成三层第一层是玩家角色卡包含属性和物品第二层是世界状态包括已探索区域、事件标记、NPC关系第三层是剧情摘要由小模型定期更新。玩家中途退出再进系统能把他的角色完整还原。跑团中断两天之后再来世界状态和剧情摘要也能精准加载玩家只要说“我们到哪了”GM就能基于摘要接着讲。这个存档系统我在设计时向电子游戏的存档机制靠拢而不是简单地把聊天记录存下来。因为聊天记录是流水账没法支撑状态恢复真正的状态快照才是有意义的存档。这里要特别提一下多玩家并发导致的“状态互相踩踏”问题。早期我直接让所有人共用一个文档结果两个人同时发言回合上下文互相覆盖GM前言不搭后语。后来改成消息队列机制玩家的指令先进待处理队列GM按队列顺序逐条消费处理每隔几条就把中间结果同步到状态面板。这个改动看似简单却是从“能用”到“能多人一起用”的关键分水岭。4. 实操全流程从启动服务到打完一场遭遇战上文聊了架构和模块这部分直接进入实操环节。我会走一遍从初始化部署到完整推完一场战斗的流程给出可以照抄的步骤和配置。如果你打算复刻建议先按我这份顺序搭跑通之后再根据自己的规则集做调整。4.1 部署与初始化把环境搭到能开团部署分几步。第一步是装好Ollama然后拉取两个模型主模型建议14B的Q4量化版辅助模型用3B。命令很简单ollama pull qwen2.5:14b-instruct-q4_K_M ollama pull qwen2.5:3b-instruct-q4_K_M第二步是准备规则文档。把规则手册的主规则原文件转成纯文本格式按章节切块建立向量索引。Edge-DM的规则查询模块依赖这部分数据没有索引它就只能靠模型记忆那规则准确率就没法保证了。第三步是初始化数据库。项目根目录执行一条命令就能建好所有数据表角色卡表、会话表、事件日志表、NPC档案表。然后启动前后端服务一个命令起推理后端另一个命令起Web界面python scripts/init_db.py docker compose up -d启动完成后浏览器打开本地地址能看到一个简单的欢迎页上面有“新建团”和“载入存档”两个选项。新建团时选择规则集、填写本团玩家数量系统会生成一个会话码其他玩家用局域网IP加会话码进入同一场团。4.2 玩家交互设计不用看说明书就能上手我对玩家端交互的核心要求是“像聊天软件一样简单”。玩家的操作框就是一行输入框你写什么GM就回什么。投骰子不需要记住命令直接说“我投潜行”系统会自动解析并执行检定。对规则不确定时玩家也可以用“GM攀爬绳索需要过什么检定”这种问句系统会自动查询规则文档并给出条目解释。状态面板放在右侧实时显示三块内容你的血量、装备和增益效果当前场景已知的NPC和物体本回合的行动槽剩余情况。这个面板不是装饰它是玩家做决策的依据。跑团老手看面板就能判断战术空间新手也不会因为不懂规则而完全抓瞎。对一些不愿频繁打字的玩家界面上还提供了一排快捷操作按钮点击就能执行攻击、闪避、搜索等常见动作系统会自动把按钮信息转成指令发给GM。系统还加了一个“主持人视角”给需要临时顶替真人GM的用户使用。开这个视角之后界面上会多一个“剧情大纲”标签可以看到系统根据事件日志生成的当前场景摘要以及GM可控的行动按钮发起遭遇战、投放NPC、推进时间。带团的老手可以把这个视角当作战术面板用随时接手AI的控场权这个设计我个人强烈建议保留——它让AI和真人之间形成互补而非替代关系。4.3 实测一场遭遇战从角色出手到结算全记录拿一场实际的遭遇战来说测试设置是这样的四人队伍在一座废弃矿坑里遭遇了三只洞穴蜘蛛。系统生成的初始描述是“潮湿的石壁上挂着蛛网微弱的光线中三双红色眼睛从隧道深处亮起低沉的嘶鸣声由远及近。”描述读感在线玩家反馈氛围到位。接着进入战斗初始化。系统自动计算了先攻顺序按敏捷加值排序然后在状态面板上列出了三个蜘蛛和四个玩家角色的行动顺序。第一个行动的是队里的游侠玩家输入“我张弓搭箭瞄准离我最近的蜘蛛射击。”系统提取出目标“最近的蜘蛛”调用攻击检定流程——投d20加上游侠的弓术加值和敏捷加值结果命中了伤害骰投出了7点。规则引擎把数值结果传给文本生成模块AI随后给出“箭矢破空正中蜘蛛的前腿关节绿色的体液喷溅而出它发出痛苦的嘶鸣。”后续每个角色的行动我都逐一跟踪对比。施法者放了一个火焰射线检定通过伤害结算完蜘蛛还剩一丝血战士上前补刀系统先走命中检定再走伤害估值最后给出斩杀结果。整个过程里最让我放心的是数值的一致性每一轮结算完状态实时更新下一轮AI的输出基于最新数据不会出现打了半天血量没变的说不过去的尴尬。打完遭遇战之后系统自动生成了战斗总结包括每人的总输出、受击次数和消耗资源并追加到剧情摘要中。玩家可以继续推进剧情也可以选择“短休”恢复状态。这一步结束整场遭遇战就算跑完了。4.4 一键存档与剧情摘要下回接着开的正确姿势一场团跑完或者中途暂停最重要的操作是存档。系统有自动存档和手动存档两种。自动存档每十分钟或者每完成一个场景跑一次手动存档在场景节点提供按钮。每次存档不只是记录角色状态还会把当前世界的进度、已知线索、NPC动向打包快照。中途退出不慌重开时选择读档所有东西都回到原样。剧情摘要功能我放在每次存档时自动跑。3B小模型把新的对话日志和上一次的摘要合并生成一份新摘要。实际跑下来这个过程每次耗时一两秒在可接受范围。摘要按照人物、地点、事件、目标四个维度组织线下读档后加一行“回顾我们上次到哪了”系统就会把摘要重新注入上下文AI GM立刻“想起来了”。从我被测试的情况看间隔一周后继续跑团剧情衔接表现基本没有衰减。5. 踩坑合集AI跑团最容易翻车的地方和对应解法跑团AI化最大的障碍不是生成质量而是那些细碎但致命的问题。这些坑我在开发过程中挨个踩过下面按典型性排个序每一条都附上排查思路和解决的方案希望后来者少走弯路。5.1 上下文遗忘跑着跑着GM“失忆”了表现玩家刚在第一幕埋的伏笔第三幕突然没影了或者NPC的旧仇在后续对话里被彻底忽略。原因可能有两种一是上下文长度不够二是重要信息被后续对话冲掉了。排查第一步是看当前上下文占用比例如果接近上限那基本就是长度问题如果占用不高但依然失忆说明关键信息没有进入上下文大概率是NPC档案或剧情摘要没有正确注入。解法分两层。第一层是结构记忆NPC档案和地图状态不走上下文直接走数据库查询需要时再注入第二层是滚动摘要定期把旧对话压缩成摘要重新写入。现在我的系统基本不会失忆偶尔出问题都在“角色持仓细节”上但这种通常不影响主线体验。需要注意的是摘要动作不要太频繁每次都会打断一句话别让它影响场面沉浸感。5.2 骰子幻觉AI自己替玩家把点数报了表现玩家问“能投骰子吗”AI没调工具直接回答“你投出了18成功”。这个问题在纯聊天方案里几乎是必然发生的因为模型太习惯直接生成完整答案了。解决思路是强制工具路由在prompt里明确任何涉及出数的动作都必须调用掷骰工具同时在系统层面拦截没有工具调用记录的出数描述。我实际用的方案是“先工具后文本”流水线玩家指令先进意图解析如果识别出检定意图直接触发规则引擎执行掷骰生成的数值放回上下文中AI的后续描述里只能引用这个数值。这样就算模型想编数它也无从编起。另外为了保险我在文本生成的校验层加了一道如果生成文本里的数字和掷骰结果不一致整句被打回重写。这个保险条看起来粗暴但实测很稳。5.3 规则判定前后矛盾同样的动作两次判定不一样表现第一次潜行判定用敏捷加值第二次同样的潜行判定却用了隐秘技能加值两者差了好几点。这种情况通常不是模型的问题而是规则引擎没有统一的“规则映射表”。不同系统的规则书对同一个动作可能有两种判定方式模型在不同的上下文上下文里选择了不同的路径。解决办法是给规则检索模块加“判定路由优先级”。简单说先查有没有直接的动作规则匹配有就直接用没有的话再看技能映射表从“潜行”这类动作映射到对应的主属性都没有才允许模型自由决定并明确标注。这样系统层面的判定路径是稳定的不管上下文怎么变走的是同一套映射。如果跑团过程中发现新的判定场景我会直接往规则映射表里增条目跑得越久规则越准。5.4 本地推理速度不足回合等待时间过长表现玩家发指令后GM迟迟没反应或者一句话分好几段慢慢蹦字。速度瓶颈通常不在模型本身而是显存带宽和上下文长度。上下文超过一定长度后每轮计算量会明显上升。解决方向有三一是显存足的话尽量把层全部卸载到GPU上二是控制上下文长度三是用更小的辅助模型做格式化和摘要任务把主模型的压力减下来。实操上还可以调整Ollama的并发参数。Ollama默认每次推理占用一个请求把并发开大一点能提高多玩家同时操作时的响应流畅度。但注意显存够不够别为了并发把卡跑崩了。我的经验是先把上下文控制在模型支持的八分之一左右速度问题通常能缓解一半以上。5.5 多玩家同时行动造成上下文串台表现两名玩家同时说话GM的回应混进了两人的行动内容或者前一人的行动还没结算后一人的行动已经开始处理。这个坑在多人团里最容易出现也是最影响体验的问题。本质上是异步输入没有同步机制。我的解决方法是引入“回合令牌”机制系统一次只处理一个玩家的指令处理完才轮到下一个。多玩家发言时按到达顺序排队并且在状态面板上清晰标注“当前处理XXX的行动”。玩家们在等待时可以看到处理进度知道不是自己被卡了而是系统在按节奏推进。这个机制把AI的“单线程脑”变成了多人协作的优势反而比真人GM同时应付多个说话的人更有序。问题核心原因我的解决手法上下文遗忘上下文长度不足/关键信息被冲掉滚动摘要NPC档案结构化注入骰子幻觉模型自由生成数值强制工具调用生成文本数值校验规则前后矛盾规则映射不统一判定路由优先级规则映射表响应速度慢上下文过长/并发配置不足控制上下文长度调整Ollama并发多玩家串台异步输入无同步机制回合令牌可视化处理进度6. 后续还能怎么玩把Edge-DM往更深处扩展稳定跑团这个目标达成之后我开始琢磨它还能怎么演化。目前一直在完善的方向有三个第一是导入更多不同的规则集目前主要跑奇幻风格想往克苏鲁、科幻方向拓展让不同风格的团都能用上同一套引擎第二是接入语音输入玩家讲话自动转文字发给GM这个对沉浸感的提升很直接第三是多智能体协同让GM助手、NPC扮演器、剧情规划器分别用独立模型实例跑再通过一个协调层汇总这样每个任务的模型都能更专精。还有一个比较有意思的方向是“团史生成器”每跑完一整场战役系统自动把整个故事线重构成一篇小说事件、对白、人物弧光都保留。跑团和创作其实是一体两面有了完整数据和AI生成能力这个扩展顺理成章。我现在已经把团史生成做成了每周跑团后最期待的一环玩家的冒险故事以文字形式沉淀下来回头翻的时候特别有仪式感。给想自己动手做一个同类东西的朋友一条建议第一版别贪多先做单机单人团。一个人、一条故事线、一个规则引擎跑通之后再慢慢加多人并发、NPC档案、语音这些功能。上来就搞多人团你会同时撞上本章里所有坑很容易被打击到放弃。按我这个顺序来每一步的成果都可以拿来用跑团群里的好评就是你继续开发的燃料。