OpenMythos实战：像管理代码一样管理你的世界观设定

先讲个我自己的事故。第三卷细纲写到一半读者私信来问“第一卷里那位古神不是已经在大战中陨落了吗怎么第三卷开头还活着当幕后黑手你是要写轮回还是吃书”我翻遍设定集发现那条“陨落”记录在2021年7月版设定文档里两年后的我早就改了剧情走向但旧文档一直躺在网盘里从未有人更新。那一刻我就意识到写长篇世界观的作品最大的风险不在灵感枯竭而在你根本管不住自己之前写过的设定。那之后我开始认真寻找能像管理代码一样管理世界观的工具OpenMythos就是这个方向上我很欣赏的一整套开源方案。它把神话、传说、种族、谱系这类东西从“一本会被翻烂的设定文档”改造成“带结构、带校验、带版本控制的数据系统”。这篇内容就是我对它的完整拆解它到底解决什么问题、核心数据模型怎么设计的、真实怎么用它跑通一个世界观项目以及我实际用下来踩过的坑。适合网文作者、游戏文案、跑团主持人和做IP运营的朋友尤其是被自己历史设定反杀过的人。1. 设定文档为什么会失控OpenMythos要解决的四个老问题1.1 碎片化同一事实在不同文件里有三个版本做过长线创作的人都懂一个内容项目的设定会分布在非常多的地方初稿里的角色小传、大纲备注、某个群里讨论出的补充设定、发布平台上读者问答时随口定的规则。它们之间没有同步机制也谈不上谁覆盖谁。我见过最典型的状况是一个神明在角色卡里写“已陨落”在势力关系表里却仍然作为“现任神王”挂在那里而两份文件由同一个人写产出时间只隔两周。单看每一份都对放一起就是逻辑事故。OpenMythos会把所有这类事实统一收拢成图谱里的节点和关系同一个实体只有一份记录所有相关描述都挂在它下面。从源头上消灭了“多份文件互相矛盾”的可能。1.2 线性文档装不下网状因果世界观的本质是网不是线。A是B的父亲B是C的师父C又转世成了A的仇人这种几代人之间的螺旋结构用Word大纲基本画不出来最多写一串“详见第X章”然后没人真的去看。更麻烦的是因果链某个预言必须在某个仪式后生效某把剑必须在某次战争中被折断才能让后文的反转成立。这类依赖关系藏在大量文本里人工复查的成本非常高。OpenMythos的图谱模型天然就是为这种网状关系设计的节点是实体边是关系跨跳数的查询和推演交给图算法去做人类主要负责定义规则。1.3 没有人告诉系统“什么算矛盾”大多数作者做设定检查靠的是记忆力。记性好的人能扛一两百万字记性中等的人在第二部就开始吃书。问题是让系统帮你检查你得先把“什么算矛盾”告诉系统这就是规则配置。OpenMythos让我很舒服的一点是它把“设定校验”做成了类似代码测试的东西。你写一条规则“角色不能在自己死亡日期之后参与事件”然后系统会跑全图找出所有违反这条规则的记录。相当于给世界观写了单元测试以后每次更新设定跑一遍检查所有隐藏冲突都会暴露出来。1.4 从源头约束到持续校验传统做法是“写完再检查”OpenMythos的哲学是“录入时就约束”。你在录入一个新事件时系统会要求它关联至少一条来源、一个时间点或明确的“时间未知”标记、参与实体。这些约束让脏数据很难混进来比事后清理省力得多。这套思路本质上就是软件工程里的“类型系统”和“约束检查”迁移到创作领域。刚开始会觉得繁琐但一旦形成习惯世界观的稳定性会产生质变。2. 神话图谱的数据抽象实体、关系、事件与溯源2.1 实体类型怎么设计才不僵化OpenMythos不是把所有东西都塞进一个“角色”类型里。它默认提供了一批基础类型神祇、人、地点、器物、事件、组织、概念比如“禁忌”“命运”这类抽象存在同时允许你自定义。我的建议是一开始不要扩太多先用默认类型跑跑着跑着发现某类东西频繁出现再抽出来。比如我发现“神器”的设定非常多就从“器物”里拆出子类型“神器”加上了“持有者”“铸造者”“当前状态”字段。这种按需演进的方式比一开始就设计二十种类别更靠谱。2.2 关系是图谱的灵魂方向的约定与反关系实体本身是名词真正组成世界的是关系。parent_of、mentor_of、enemy_of、reborn_from、killed_by、wields……每一条关系都是一张有向边。这里有一个非常关键的实操细节关系的方向必须全团队统一。比如“A是B的父亲”你既可以用parent_of指向B也可以用child_of指向A如果不同人录入时各写各的查询就会乱套。OpenMythos支持定义反关系我建议在schema里明确成对声明例如parent_of的反关系是child_of系统会帮你补齐反向边查询时双向都能用。2.3 事件作为一等公民时间线不是附在角色身上的很多世界观管理工具把事件当成角色卡里的一个字段OpenMythos不一样事件是独立的节点类型。这场战争、那次陨落、某个预言它们有自己的时间、地点、参与者、后果和来源。角色的经历只是“与事件关联”而非“拥有事件”。这种设计的优势在于你可以单独推演时间线。比如“炽阳神陨落”这个事件关联了时间、波及范围、后续继承关系。当你想知道“云泽君在烈山之战时处于什么状态”系统可以直接沿时间线定位不用你手动翻文档。3. 一致性校验和时间线推演把设定当成代码来测试3.1 规则引擎与“设定单元测试”OpenMythos的校验规则本质是一组可执行的逻辑判断。你可以用YAML写规则也可以直接用内置规则语言。下面是两条我项目里一直在用的规则示例rule: id: death-after-participation description: 角色不能在自己死亡之后参与事件 when: - $deity is ParticipantOf $event - $deity.death_date exists - $event.date exists - $event.date $deity.death_date action: warn message: {{$deity.name}} 在死亡日期 {{$deity.death_date}} 之后参与了事件 {{$event.title}}rule: id: self-parent-loop description: 任何实体不能成为自己祖先 when: - $entity is AncestorOf $entity action: error message: 检测到祖先环路实体: {{$entity.name}}跑完检查后系统会输出一份报告按实体、规则、严重级别分组。我每次更新设定后都会跑一遍基本20秒内能完成一次全图扫描。这比人工一遍遍读文档高效太多。3.2 时间线推演与环路检测图结构比较擅长的问题有血缘谱系推算、因果链梳理、阵营关系可达性、预言应验链路校验。比如“燧皇”和“渊海之主”之间隔了几代、谁是谁的祖先直接跑可达性分析就能出答案。环路检测更是救过我一命。有一次我写一个“时间循环”设定设计得越来越绕最后系统报错某个古神成了自己的祖父。单凭脑补我根本发现不了这种问题但环路检测一秒就抓出来了。这条经验是越复杂的设定越需要形式化检查人脑的注意力上限比你以为的低。3.3 多分支世界观的版本管理如果你的故事涉及平行宇宙、时间穿越、不同轮回线OpenMythos的分支功能就派上用场了。它支持在同一个图里划分多个“时间线区域”用时间线标记隔离数据而不是把不同分支的设定放在不同文件里。我的做法是主线分支叫canon每个if线叫branch-xxx。校验规则可以只跑canon分支也可以指定跨分支校验专门检查“哪些实体可以跨时间线影响”。这样处理多世界线设定比建一堆“xxx平行版角色卡”干净得多。4. 从零跑通一个最小可用的OpenMythos实例这一节我会给一套我实际整理过的最小可运行配置。OpenMythos不同版本的命令细节可能略有差别但核心流程是大致一致的初始化项目、定义schema、灌入数据、跑校验、导出内容。4.1 安装与初始化我用Docker跑过也用CLI直接跑过。如果只是想体验Docker最省事docker run -d --name openmythos \ -p 7450:7450 \ -v $(pwd)/mythos-data:/data \ openmythos/server:latest日常创作我更喜欢CLI方式仓库里直接建项目openmythos init my-first-world cd my-first-world初始化后目录里会出现几个关键文件openmythos.yaml是全局配置schema/放本体定义entries/放设定数据rules/放校验规则dist/是导出目录。整个项目就是一个普通的文本仓库可以用Git盯版本。4.2 写schema用YAML定义你的世界规则在schema/schema.yaml里定义实体类型和关系类型。这是我的一个最小例子kinds: deity: properties: name: string epithet: string realm: string status: [active, fallen, imprisoned, unknown] artifact: properties: name: string material: string power: string relations: wields: type: deity event: properties: title: string date: date? location: string relations: parent_of: from: deity to: deity reborn_from: from: deity to: deity created_in: from: artifact to: event participates_in: from: deity to: event字段命名尽量简短但含义要清晰。我踩过的坑是把所有属性都设成非空录入时压力很大很多早期设定本来就是模糊的。OpenMythos允许字段级别标记为可选用?表示建议对时间、地点这类信息默认可选等确定后再补充。4.3 灌入神话碎片并建立关联在entries/目录下每个文件可以放一个实体或一批相关实体。格式用YAML最舒服kind: deity id: sun-blaze-emperor name: 炽阳神 epithet: 焚天者 realm: 日轮天 status: fallen relations: parent_of: - sky-dispatch-lord participates_in: - event: burning-war roles: [发起者] outcome: 陨落 sources: - 正史·卷三 - 民间传说·九歌残本注意我用了固定的id如sun-blaze-emperor而不是用中文名当主键。这是一个很重要的习惯id一旦定了就不改显示名可以随时改但id是跨文件引用的锚点改id会导致很多关系断裂。4.4 执行校验、时间线推演与导出数据录入后先跑schema检查再跑一致性校验openmythos schema validate openmythos check --level warn如果配置了规则系统会把违规项列出来。接着推演时间线openmythos timeline --entity sun-blaze-emperor openmythos lineage --deity sun-blaze-emperor最后导出设定集openmythos export --format markdown --out dist/compendium.md openmythos export --format web --out dist/site导出为Web形态后整个设定集会变成一个可搜索的站点我经常把这个站发给合作画师和编辑当参考资料比发几十个Word文件好用太多。5. 进阶实践协作维护、API联动和内容管线5.1 多人协作与评审流OpenMythos的数据都是文本格式意味着你可以直接用Git做多人协作。我和搭档的合作方式是每个人在自己分支上改提交后发起评审确认无误后再合并。这样每一次设定变更都有据可查谁在什么时候改了哪个神明的关系一清二楚。这个模式对线上跑团团或项目组也适用。中途加入的新人不需要读十万字设定集直接看图谱和导出站点就能快速上手速度比读文档快得多。5.2 与写作工具联动实时查询设定OpenMythos有HTTP API写作时可以随时查设定。我写稿时会开着一个小面板搜索角色名就能看到它所有的关系、经历和事件时间点不用再开一堆标签页翻设定文档。curl -s -X POST http://localhost:7450/api/graph/query \ -H Content-Type: application/json \ -d { entity_id: sun-blaze-emperor, depth: 2 }返回的JSON里包含该实体两跳之内的所有邻居和关系。这种“写作时零切换成本”的体验是OpenMythos对我生产效率提升最大的点。5.3 把神话图谱变成内容生产管道当设定全部结构化之后它可以成为各种内容生成的底层数据源。比如我写“年度设定集”时直接跑导出命令生成全部文本做视频脚本时按阵营筛选实体生成关系图做角色卡时从图谱里抽取单体数据。这个思路很像数据驱动的文档生成数据维护一份输出多渠道展示。之前手工维护时改一个时间线要改正文、角色卡、年表、百科页四处现在只改一处其他全部自动同步省下的时间至少占我每周工作量的三分之一。6. 实际使用一年后我最想提醒你的五件事6.1 粒度失控比不用工具更可怕刚开始用OpenMythos时我恨不得把每件衣服的颜色、每顿饭的菜谱都录进图谱结果就是录入成本高到离谱更新没几天就坚持不下去。后来我总结出一个及格线能影响到后续情节走向的设定才值得进图谱纯粹的装饰性细节留在文稿里就好。6.2 关系方向的约定比工具更重要前文说过parent_of和child_of的方向问题这里再补一刀不要觉得“反正是双向的随便写都行”。关系少的时候确实无所谓一旦超过三四百条边方向混乱的图会让你每条查询都在填坑。我的习惯是全部从“主动方”指向“被动方”并在schema定义里写明中文注释。6.3 不要试图把所有正文都结构化我见过一些同行试图把小说正文每一段都转成结构化描述结果整个项目变成了巨大的文字狱灵感全被格式磨灭了。正文是正文设定是设定。图谱只维护“可供验证的事实”氛围、情绪、台风描写永远属于散文领地。6.4 每条设定都要能追到来源这个习惯刚开始很烦但帮过我太多次。当读者质疑“这个设定你以前不是这样写吗”的时候我只需在系统里搜一下该实体找到sources列表就能确认是第几卷哪段出现过的。遇到设定需要推翻的场景也能清楚知道影响了多少下游节点。来源字段就是这个系统的存档点。6.5 规则的阈值一开始要宽松规则写得越严录入越慢写得太松又变成装饰品。我的建议是初期只保留两类规则逻辑硬伤类如时间线冲突、祖先环路和致命自洽类如神器不能同时被两个势力独占。风格偏好、审美倾向这类规则不要写进系统那是人做的判断。实际用下来我觉得OpenMythos最珍贵的地方不是某个酷炫功能而是它逼着我用更清醒的方式去定义我的世界。以前我的设定死于文档现在我的设定活在图谱里每次查询都能发现一些以前没注意到的潜在线索。这种“自己构建的世界反过来给你灵感”的体验是结构化世界观管理最令人上瘾的部分。如果你也长期被设定矛盾折磨找时间把最头疼的那个世界观跑进这类工具里先用两周试试不用求全只管理主干和关键人物。过程不轻松但一旦跑顺你回头看那些被推翻的设定文档会感觉自己以前真的是在雷区里光脚走路。