企业官网建设流程全解析

1. 项目概述：给桌面游戏配一个AI主持人，我图什么

桌游跑团这事，尤其是D&D、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转眼就忘了”的尴尬。

2.3 具体工具链怎么搭

Edge-DM后端用FastAPI，推理走Ollama本地服务，游戏状态存在SQLite，前端是一个纯本地Web页面。选FastAPI没别的原因，就是Python生态顺手，后续接工具脚本方便。Ollama作为推理后端的好处是模型管理和API封装都很省心，一条命令就能切换模型。前端没有选重型框架，直接用原生的HTML+JS，因为界面只有三块：会话区、状态面板、骰子日志，不需要什么复杂交互。

工具调用的设计上也做了精简。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同时应付多个说话的人更有序。

6. 后续还能怎么玩：把Edge-DM往更深处扩展

稳定跑团这个目标达成之后，我开始琢磨它还能怎么演化。目前一直在完善的方向有三个：第一是导入更多不同的规则集，目前主要跑奇幻风格，想往克苏鲁、科幻方向拓展，让不同风格的团都能用上同一套引擎；第二是接入语音输入，玩家讲话自动转文字发给GM，这个对沉浸感的提升很直接；第三是多智能体协同，让GM助手、NPC扮演器、剧情规划器分别用独立模型实例跑，再通过一个协调层汇总，这样每个任务的模型都能更专精。

还有一个比较有意思的方向是“团史生成器”：每跑完一整场战役，系统自动把整个故事线重构成一篇小说，事件、对白、人物弧光都保留。跑团和创作其实是一体两面，有了完整数据和AI生成能力，这个扩展顺理成章。我现在已经把团史生成做成了每周跑团后最期待的一环，玩家的冒险故事以文字形式沉淀下来，回头翻的时候特别有仪式感。

给想自己动手做一个同类东西的朋友一条建议：第一版别贪多，先做单机单人团。一个人、一条故事线、一个规则引擎，跑通之后再慢慢加多人并发、NPC档案、语音这些功能。上来就搞多人团，你会同时撞上本章里所有坑，很容易被打击到放弃。按我这个顺序来，每一步的成果都可以拿来用，跑团群里的好评就是你继续开发的燃料。