【实用程序】AI后端驱动的文字MUD江湖游戏设计
前言：AI驱动的文字江湖
传统的文字MUD（多用户地牢）游戏，所有场景、对话、剧情都由策划预先写好。玩家探索时，游戏只是“检索并显示”固定文本。这种方式的局限很明显：世界是静态的，NPC是复读机，剧情发展缺乏弹性。
而AI驱动的MUD，核心变化在于从“检索”转向“生成”。游戏世界不再是一张固定的地图和固定的台词，而是一个鲜活的、会根据玩家行为动态演变的江湖。大语言模型（LLM）负责叙事与对话，规则引擎负责战斗与数值判定，两者各司其职，共同营造出“人在江湖，身不由己”的沉浸感。
下面，我们将从架构到细节，逐步拆解这套方案。
第一章：整体架构——江湖的骨架
游戏采用经典的客户端-服务器模型，但核心大脑换成了AI。下图展示了数据与控制的流向：
架构解析：
- 网关层：统一接管所有连接，WebSocket 用于实时交互，HTTP 用于非实时接口（如登录、查询历史）。
- AI驱动层：双核心并行。LLM 负责“讲故事”，规则引擎负责“判定理”。两者配合，既保证了叙事的丰富性，又确保了数值的公平与稳定。
- 数据层：三类数据库分工明确。Redis 存热数据（会话、最近交互），PostgreSQL 存结构化永久数据（账号、装备、技能），向量数据库存非结构化的长期记忆（重要剧情事件，用于后续检索召回）。
第二章：AI能力分配——让LLM和规则引擎各司其职
很多初学者容易犯一个错误：让LLM包办一切，包括伤害计算、技能冷却等。这会导致两个问题：一是LLM经常算错数，二是容易“出戏”（比如NPC突然说出离谱的伤害值）。
正确的做法是分离叙事逻辑与确定性逻辑。
2.1 LLM的职责：叙事与对话
LLM不负责“判定”，只负责“描述”和“生成”。以下是主要场景：
| 功能 | 触发时机 | 核心输入 | 输出示例 |
|---|---|---|---|
| 场景描述 | 玩家进入新地点 | 地点ID、天气、时辰、在场NPC | “暮色四合，扬州城青石板路泛着微光……” |
| NPC对话 | 玩家与NPC交互 | NPC性格、好感度、玩家名声 | “少侠，这枚镖银可否帮我还给福威镖局？” |
| 事件推演 | 玩家做出选择后 | 玩家属性、随机种子、历史事件 | “你推开破庙门，烛光下见一人正翻看泛黄书册……” |
| 剧情生成 | 主线/支线触发 | 玩家等级、江湖大势 | 动态生成寻仇、奇遇、门派任务等 |
| 物品描述 | 获得或查看物品 | 物品类型、稀有度 | “此剑名‘寒霜’，剑刃隐隐透出蓝光，触之生寒。” |
2.2 规则引擎的职责：确定性与校验
所有与数值、概率、状态相关的逻辑，都交给规则引擎。它就像江湖的“物理定律”——稳定、可预测、无歧义。
# 战斗伤害计算示例——规则引擎负责，绝不让LLM插手classCombatEngine:defcalculate_damage(self,attacker,defender,skill):base_damage=skill.damage+attacker.attack defense=defender.defense counter_factor=self.get_attribute_counter(attacker.element,defender.element)random_factor=random.uniform(0.85,1.15)# 随机波动final_damage=int(base_damage*(100/(100+defense))*counter_factor*random_factor)returnmax(1,final_damage)# 至少造成1点伤害defget_attribute_counter(self,att_elem,def_elem):# 金克木、木克土、土克水、水克火、火克金counter_map={...}returncounter_map.get(<