团队一起做世界观，最反常识的一条规则是：不要追求“所有人都拥有世界观”。 听起来很民主，但如果每个编剧、画师、策划和编辑都能在自己的文件里悄悄改一遍某个势力，最后得到的不是共创，而是几套同时存在的平行正史。

一个势力设定想在多人协作里保持一致，真正需要的硬控制其实只有四个：

  • 一个权威势力简报；
  • 每类决策有明确负责人；
  • 进入正史之前有公开可见的审批状态；
  • 每次改动都留下“改了什么、为什么改”的版本记录。

两个人的小团队，用共享文件夹和一张表也能做到；二十个人的团队可能会用 Git、GitHub、文档系统和正式审批。工具不是核心，真正重要的是交接协议。

先讲硬信息：四种状态、三种角色、两个时间点

在讨论“谁更懂这个角色”以前，先把流程变成能检查的数字。

建议只保留四种内容状态：

  1. Draft / 草稿：可以大胆探索，但其他人不能把它当正史引用。
  2. Review / 审核中：已经提出明确改动，并写出证据与下游影响。
  3. Approved / 已批准：当前版本的正式正史。
  4. Deprecated / 已废止：保留历史记录，但不再代表当前设定。

再明确三个角色：

  • 作者：提出改动的人；
  • 领域负责人：检查势力逻辑、连续性和资料边界；
  • 发布负责人：决定何时把已批准内容变成其他团队应该使用的新基线。

小团队里一个人可以兼两个角色，但“角色”本身仍然应该写出来。

最后设置两个时间点：

  • 审核时钟：正常情况下多久没人回应就需要升级提醒；
  • 发布时钟：已批准的变更什么时候合并成稳定版本统一交接。

这能解决一个特别常见的问题：概念图在用周一的设定，台词写的是周三改版，网站周五又用了另一种理解。

势力简报应该比势力本身小很多

权威简报不是百科全书，而是其他团队必须知道的最小接口。

每个势力或机构，一页里至少保留：

身份。 名称、对外身份、内部真正目的，以及一句“它认为自己在保护什么”。

权力。 谁能做最终决定？领导者如何产生、被替换、被挑战？

资源。 它控制什么：钱、土地、情报、仪式合法性、武力、科技、医疗、交通、教育？

约束。 什么事情它做了就会失去合法性、触发敌对、破坏条约或耗尽稀缺资源？

内部冲突。 哪两个目标不可能同时做到最大？

外部依赖。 哪个阶层、市场、生态或其他机构一断供，它就无法运转？

正史锁定项。 其他团队不能随手改的事实：创始人、辖区、继承规则、禁忌、关键技术、条约、时间轴锚点。

其余内容都可以放到扩展资料里。

这个简报有点像“接口协议”。画师不应该为了确认制服能不能出现某个禁用徽记，先读四十页历史；任务策划也不该去翻半年前的群聊，才能知道谁有权签发逮捕令。

交接最容易失败的原因：只传文件，不传决定

一个合格的交接至少包含三样东西：

  1. 当前文件；
  2. 为什么这样决定；
  3. 还有什么没决定。

比如编剧把某商会从“世袭领导”改成“选举领导”。只把新段落发给美术是不够的。交接还要写清楚为什么改，以及它会影响什么：家族谱系、徽章、选举场景、腐败机制、旧角色背景，甚至所有叫领导者“继承人”的台词。

可以固定用五个字段：

  • 改动：
  • 原因：
  • 影响到的正史：
  • 需要复查的团队/资产：
  • 未解决问题：

这五行的价值，经常比开一小时会更高，因为会议结束会忘，记录不会。

审批应该跟着风险走，而不是跟着职位走

不是每个标点都要世界观总监签字，也不能让最复杂的制度改写由最不熟悉上下文的人直接合并。

可以分三级。

一级：呈现层

错别字、排版、不会改变含义的措辞、图片裁切、导航名称。一个复核者即可。

二级：解释层

服装符号、地方习俗、次要军衔、解释性段落、把原本模糊的点具体化的场景细节。通常由对应领域负责人复核。

三级：正史架构层

领导制度、建国事件、宗教与国家关系、领土、继承、核心技术、势力条约、时间轴锚点。必须明确批准，并检查下游影响。

软件协作里也采用类似的风险门槛。GitHub 的 protected branches 可以要求 pull request 获得指定数量的审批，也可以要求 code owner 批准；CODEOWNERS 能在相关路径发生变化时自动请求对应负责人复核。它们本来是代码工具，但背后的协作原则很适合结构化世界观：先声明谁负责，再让批准过程可见。

当然，不需要为了“像大公司”而强行复制软件流程。两个人写小说，不需要企业级分支保护；但仍然值得区分“错字”“解释”“正史架构”。

不写代码，也能从版本控制里得到巨大好处

世界观协作有一个很现实的问题：画师看到的那版和编辑现在用的这版，到底差了什么？

Git 的分支模型允许不同工作在独立分支上推进，再合并回稳定版本；GitHub 的 pull request 则把修改、讨论和审批放在同一个记录里。团队如果熟悉这些工具，把 Markdown 世界观文件纳入 Git，差异会非常清楚。

目录甚至可以很简单：

/factions/wolf-court.md
/factions/phoenix-command.md
/institutions/arbitration-chamber.md
/timeline/era-07.md
/glossary/terms.md

此时“天狼宫继承规则被改了”会显示成一段可读 diff，而不是突然多出一个 天狼宫_最终版_最终最终_v7_这次真最终.docx。

但 Git 不是必须的。如果团队更适合用带版本历史的文档系统，只要保留同样四件事——唯一权威位置、明确审核人、公开审批状态、可追溯变更——也可以稳定工作。

最差的工具不是“功能少”，而是大家最后懒得用。

大改势力之前，先做依赖地图

势力不会只存在一页设定里。改一个制度，可能同时影响：

  • 角色动机；
  • 军衔与服装；
  • 地图与边界；
  • 法律与惩罚；
  • 经济与贸易；
  • 仪式；
  • 军事体系；
  • UI名称；
  • 收藏卡牌；
  • 游戏任务；
  • 官网文案；
  • 品牌授权资料。

所以三级变更批准前，必须问一句：这个事实还被写进了哪里？

一张很简单的依赖表就够：

正史事实 哪些内容依赖它 负责人 是否复核
凤凰指挥体系向文官议会负责 莱娜人物页、军衔表、城市法律 世界观 必须
天狼宫继承依靠音律试炼 萧凌支线、仪式场景、卡牌文本 故事 必须
裁决庭属于中立空间 地图、外交关系、品牌说明 世界观/品牌 必须

这样，一个看似很小的改动，就不会在十个地方留下互相矛盾的旧版本。

把“真实资料”与“虚构设定”分开存

当一个虚构机构借鉴真实文化、宗教、法律或历史制度时，这一步尤其重要。

建议永远分成两栏：

**资料记录：**真实来源到底说了什么、来自哪里、属于什么历史和社会语境。

**创作转化：**虚构势力具体改了什么、混合了什么、完全发明了什么。

不要因为某个真实少数群体的仪式“看起来神秘”，就直接贴到反派势力上；也不要没做背景调查，就把现实宗教职位改写成“东方神秘官僚”。引用资料时，也不能让读者误以为真实来源在替你的虚构解释背书。

即使是完全原创的势力，这种分栏也有用：后来的协作者一眼能知道，哪些是研究锚点，哪些是刻意创造。

审批会的产出不是“大家都同意”，而是一条变更记录

很多会开完的时候气氛很好，但没有留下稳定结果。

每次正史审核结束，至少要生成：

  • 已批准的版本编号；
  • 本次真正修改的事实；
  • 已拒绝的方案，避免下周又偷偷回来；
  • 需要同步更新的下游资产；
  • 每个跟进事项的负责人和状态；
  • 新版本从哪一天/哪一批开始作为交接基线。

如果没人把这些写下来，那场会的最终产物只是几个人的记忆。

什么时候应该开分支，什么时候分支会制造灾难？

适合单独开工作分支或副本的情况：

  • 两个人正在探索互斥的势力结构；
  • 一次大改还不能打断当前稳定发布版；
  • 游戏改编需要先做实验性变化，再决定是否进入正史。

不适合的是：每个部门长期维护自己的分支，几个月不合并。Git 确实支持长期分支，但创作团队仍然要经常整合；否则最终一次合并，实际上是在谈判“到底哪个宇宙才是真的”。

一句规则：可以大胆分开探索，但要尽早重新汇合。

一份能直接用的协作模板

每个正史改动都记录：

势力 / 机构：
当前正史版本：
拟议改动：
为什么现在要改：
审批等级： 1 / 2 / 3
资料或研究备注：
受影响角色：
受影响地点：
受影响时间轴：
受影响视觉资产：
受影响游戏/产品/网页文案：
审核人：
决定： Draft / Review / Approved / Rejected / Deprecated
生效版本：
开放问题：

它故意很无聊。越无聊的流程工具，越能保护真正需要想象力的部分，不让创作被行政混乱拖死。

真正目标：让不同专业的人都能跑快，但世界仍然只有一个

世界观作者可以继续把势力写深，美术可以把它视觉化，游戏策划可以把它变成机制，授权团队可以向品牌解释这个势力为什么值得合作。

大家不需要同一秒在同一个文件里工作。

但大家必须知道三件事：现在什么是真的、谁有权批准变化、自己上次交接以后又改了什么。

这就是势力与机构协作的核心：一个正史，多个人贡献，所有决定可见。

Sources

  1. GitHub Docs — Requesting a pull request review. https://docs.github.com/en/pull-requests/how-tos/create-pull-requests/requesting-a-pull-request-review
  2. GitHub Docs — About protected branches. https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches
  3. GitHub Docs — About code owners. https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/about-code-owners
  4. Pro Git — Branching Workflows. https://git-scm.com/book/en/v2/Git-Branching-Branching-Workflows

Related Reading