企业官网建设流程全解析

先讲个我自己的事故。第三卷细纲写到一半，读者私信来问：“第一卷里那位古神不是已经在大战中陨落了吗，怎么第三卷开头还活着当幕后黑手？你是要写轮回还是吃书？”我翻遍设定集，发现那条“陨落”记录在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最珍贵的地方不是某个酷炫功能，而是它逼着我用更清醒的方式去定义我的世界。以前我的设定死于文档，现在我的设定活在图谱里，每次查询都能发现一些以前没注意到的潜在线索。这种“自己构建的世界反过来给你灵感”的体验，是结构化世界观管理最令人上瘾的部分。

如果你也长期被设定矛盾折磨，找时间把最头疼的那个世界观跑进这类工具里，先用两周试试，不用求全，只管理主干和关键人物。过程不轻松，但一旦跑顺，你回头看那些被推翻的设定文档，会感觉自己以前真的是在雷区里光脚走路。