因为几周内，一些人会用“AI DM”这个2,000字输入要求 chat 讨论的回应，而我在这个项目的第一月份就被说服了，可以这么做。但我做不到。这次我分享我的结果，希望谁也不用再犯同样的错误了。

长期角色扮演游戏提示不可以做的事情有如下几点：

你无法在提示中强制执行规则，只能请求它们。模型被训练来积极配合，对于超过30或40个回合的提示，系统内写的任何规则都会悄悄放松。技能槽又恢复了。生命值也降低了。死去的NPC又走进来了。

数字由模型生成不是随机的，而都是有逻辑的，符合后续行为要求。问你Roll一个d20，你会拿到一个数字，和模型认定后面应该发生什么一致的数字。玩家会在第一个小时内发现这个。

上下文窗户不是内存。总数和压缩会导致世界感觉不充实。向量检索可以接近，但不精确。NPC重新命名了自己。

最终我成功运用的方法是：

叙事者：一个LLM。它完全承担了叙述和工具调用的工作。它不决定结果，而是提出它们。

规则引擎：约有24个Python模块。滚动、战斗、牌术、升级、角色构建、条件、派系、任务、定时事件。每一条工具调用的路由都经过这里进行验证，确认SRD的相关规则，返回结果。如果叙事者尝试作非法行为 (如无技能槽下施展牌术)，引擎会拒绝它，让叙事者在下个回应下处理这个问题。

状态：以YAML来存储的磁盘文本，每个行动的锁定，可能被导出序列化，为了便于修复使用。每个行动的SQLite数据库，用于储存会话历史。

滚动协议：玩家手动进行滚动并发送予服务端并作为保留符号使用，叙事者不再写出d20。不确定性来源于NPC滚动的随机数，这是一个确定的随机数发源，它会记录下来用来追溯。

协调者：一个速率较快的二次模型。每个叙事者的回应后，它会读取回应和当前状态，对叙事者描述但是没有工具调用的状态变化进行抽取，例如“oblin跌倒”或“你会发现一枚戒指”。这些状态变化会在锁下进行验证和应用到状态上。没有这一个，剧情和信息会发生分离而此功能就可以保持它同步。

志上：以一行一行的事件日志方式组织的文本，允许快速搜索。自动生成 ~400字的场景回顾文本，直至每次 ~30次回应，每次滚动都可以节省空间。

我仍在继续改进中：对战平衡的问题。规则引擎知道CR数学公式，但叙事者仍然有时轻描淡写一个似乎已经有致命危险而产生的冲突，有时又一句话一个致命的突然致命的危险。哪怕知道它不会害怕杀死玩家，但这也在玩家身上有太多的权力了。

这个问题还在继续中，望得到帮助和你的提议！在游戏的整个过程中我都非常愉快，这使我很高兴。