世界观项目很少是因为“大家都不在乎设定”才丢掉正史。更常见的情况是：一次语音会议里做了决定，聊天记录里被概括成另一种说法，一张人物卡又抄了第三种版本，但时间线、术语表、视觉brief和已经发布的正文没有同步。

反直觉的是，解决办法并不一定是“做一本更大的设定圣经”。一个巨型文档同样可能成为变化消失的地方。真正需要的是一套交接系统：用少量明确状态、负责人、审核规则和版本标记，告诉团队一句话究竟是提案、已批准正史、被替代，还是仍有争议。

最小可行版本其实很小：3种正史状态、1句决策句、5行交接包、每周15分钟抽查。这已经足以拦住大多数责任漂移和版本冲突，又不会让创作团队变成文档管理员。

工具不必复杂。Git文档把提交、分支、标签与协作过程记录下来；GitHub则把审阅、请求修改与批准做成清晰状态。创作团队没必要机械复制软件开发流程，但这里有一个值得借用的原则：当“谁提出、谁审、讨论过什么、哪一版被接受、在哪个发布点生效”都可追踪时，改设定的风险会明显下降。

把提案、正式正史和废止正史分开

最重要的规则不是技术规则，而是语义规则。

每一条设定至少应该有三种状态：

提案：有人希望它成为正式设定，但下游暂时不能依赖它。

已批准正史：指定权威已经确认，其他创作可以据此继续。

废止/被替代：它曾经有效，但后来被新决定替换。仍然保留记录，因为旧稿、旧图、对白或合作材料里可能还在使用。

没有这些状态，团队很容易把“写得很肯定”误认成“已经批准”。概念设计师随手写一句“这座城有两个月亮”，画师照着画，几个人都依赖这句话以后，它就因为使用次数多而被反向变成“正史”。

状态必须和事实一起传递。

解释之前先写一句“决定是什么”

长讨论对思考很有帮助，但交接需要一个短决定。

可以固定成：

决定： 当前正史中，[具体事实]；从[剧情/版本节点]起生效；如有旧规则，则替代[旧规则]。

然后再往下写理由、被否决的方案与尚未解决的问题。

这样做解决两件事。第一，别人转述时能直接引用最终决定，而不是误抄讨论中的某个备选。第二，几个月后的审阅者能一眼区分“我们决定了什么”和“当时为什么这样决定”。

如果一句话写不清，通常意味着团队其实还在同时争论多个问题。

按“决策类别”分配权威，不要谁回消息快谁说了算

复杂IP里往往存在多个合理权威。主编剧负责剧情因果，艺术总监负责视觉连续性，游戏设计负责可玩规则，授权负责人可能负责对品牌伙伴能承诺什么。

做一张很小的权责表：

决策类别 主要负责人 必审人 可咨询角色
剧情因果 叙事负责人 连续性编辑 角色编剧
角色视觉身份 艺术总监 叙事负责人 市场/授权
世界规则/能力系统 世界观负责人 叙事+相关玩法负责人 科学/文化顾问
商业使用 授权负责人 法务/品牌权利人 创意负责人
本地化敏感命名 本地化负责人 正史负责人 市场顾问

这张表不是为了制造层级，而是避免批准权自动漂到“在线最快、最先回复”的人手里。

批准改动前，先列依赖清单

设定变化最便宜的时候，是还没有其他资产依赖它的时候。

批准前先问它会影响哪些东西：

  • 已有章节或脚本；
  • 人物传记；
  • 地图与时间线；
  • 概念图或3D资产；
  • 道具说明；
  • 游戏规则；
  • 市场文案；
  • 翻译；
  • 对外合作资料。

角色年龄只改一岁，可能让时间线出错；势力改名，会影响搜索、链接、本地化和授权文案；能力增加一条限制，可能让已经设计好的战斗失去逻辑。

所以审核问题不能只问“新想法是不是更好”，还要问：“现有哪一些承诺会因为这个改动变成错误？”

审阅应该是一段最终会关闭的对话

GitHub的审阅流程会区分普通评论、请求修改和批准。创作团队可以借这个概念，而不需要假装小说就是软件。

审阅者最终最好只做四种动作之一：

  1. 批准；
  2. 批准，但留下明确的非阻塞建议；
  3. 请求一个具体修改；
  4. 说明自己没有权限或上下文不足，不能拍板。

最麻烦的是永远停在“看起来挺有意思”“我再想想”这种状态。它让一个决定在社交层面一直活着，却在执行层面没有结论。

请求修改完成后，应把讨论线程以最终接受的措辞关闭。否则六周后新成员看到旧反对意见，很可能误以为争议仍然存在。

给正史里程碑打“发布标签”

Git标签用来标记项目历史中的明确点。创作项目也可以借用类似的发布标记，例如：

  • CANON-2026-10-WEB
  • NOVEL-BOOK03-FINAL
  • GAME-DEMO-V1
  • LICENSING-BIBLE-2026Q4

名字不重要，承诺才重要：标签代表一组明确、已批准的决定。

不同产物更新速度不一样时尤其有用。小说可能已经采用新规则，授权册却仍然对应上一版。此时不要说“用最新文件”，而要告诉接收者“这次必须按哪个正史发布版本”。

不要只靠文件名做版本管理

最终版_v7_真的最终版.docx 不是版本控制。

即便不用Git，也至少应保留：

  • 稳定文档ID；
  • 当前状态；
  • 最近批准日期；
  • 负责人；
  • 变更记录；
  • 被替代版本的链接。

如果团队确实使用Git或其他仓库，则用有意义的提交记录变化，用标签标记正式节点。真正重要的创作习惯是：事实一旦变化，就留下可追踪痕迹。

每次交接压缩成五行

接手的人不应该必须开会才能知道发生了什么。

固定成这五行：

  1. 改了什么： 一句话。
  2. 正史状态： 提案 / 已批准 / 被替代。
  3. 生效版本： 哪个发布或作品开始采用。
  4. 依赖项： 哪些文件或团队必须跟着更新。
  5. 负责人和下一节点： 还有未决问题时，谁负责决定。

证据、截图、参考资料都放在这五行之后。

这个格式故意做得很小。好的交接，是下一位协作者在读完整背景之前就能先做对动作。

例外必须被写成“例外”，不能偷偷改写底层规则

故事当然需要例外。危险的是一次剧情例外悄悄变成第二套规则。

任何例外都记录四个字段：

  • 基础规则；
  • 本次例外；
  • 为什么在这里成立；
  • 未来是否可以重复。

例如：“传送通常必须依赖已配对的门。角色X这一次可以无门跨越，因为神器Y会被永久消耗。该事件不产生可重复的新能力。”

这样写，能防止后续创作者把一次性的戏剧事件当成常驻技能升级。

把“版权/授权来源”与“正史批准”分开

创意上批准使用一个元素，不等于团队拥有对外复制它的权利。

Creative Commons提供多种许可证，条件可能涉及署名、商业使用、衍生改编和相同方式共享。因此“网上找到了”和“可以进入商业IP生产”完全不是同一个检查项。

对于外部图像、文字、地图、字体、音乐或研究素材，至少记录：

  • 来源URL；
  • 作者或机构；
  • 许可/授权状态；
  • 是否要求署名；
  • 是否允许改编和商业使用；
  • 是否仅用于内部参考而不能再分发。

正史审批不能替代权利审批。

每周做一次15分钟交接抽查

随机抽最近五个决定，问：

  • 新成员能不能找到当前批准版本？
  • 负责人是否明确？
  • 有没有发布/版本标记？
  • 被废止的旧说法是否还在关键页面被当成当前版本？
  • 下游团队知道变化了吗？
  • 标成“未解决”的评论真的还没解决吗？

如果五个样本里有两个以上答不上来，问题往往不是“wiki不够大”，而是决定成为权威版本的那条路径坏了。

先修交接路径，不要先扩文档体积。

不要把所有东西都中央化

正史系统应该中央化的是权威和可追踪性，不是每一张草稿。

编剧需要随手稿，画师需要探索板，研究员需要资料笔记，制片需要日程。把这些全部强塞进一个“官方正史文档”，只会让正史层变脏，也会让大家不敢实验。

工作材料保持灵活；只有下游真正需要依赖的决定，才晋升到正史层。

一个轻量结构可以是：

  • /proposals/：正在审的提案；
  • /canon/：当前已批准规则；
  • /deprecated/：旧规则及其替代链接；
  • /releases/：正式快照或manifest；
  • /sources/：权利与研究记录。

文件夹结构不是必须，状态区分才是必须。

分歧最好发生在批准之前，而不是发布之后

健康的正史流程应该让早期分歧很便宜。任何人都可以挑战提案、指出依赖、要求补证据，而不必觉得自己是在“拖项目后腿”。

一旦决定被正式批准并释放，撤回成本就会迅速上升。章节、插画、本地化、代码、商品和合作方资料都可能已经依赖它。

所以流程真正严格的地方，只需要放在提案→已批准这条边界上；其他探索阶段反而应该尽量轻。

最终得到的不是一个不会变化的世界，而是一个能够有意识地变化，又不会让昨天的协作者在不知情的情况下突然变错的世界。

Sources

Related Reading