故意把核心设定“打坏”一次：读者发现漏洞前的五遍一致性审计

虚构世界通常不是因为“点子不够”而垮掉，而是因为几个单独看都很棒的点子，放在一起以后不可能同时成立。

解决办法也不是把设定集继续写厚，而是主动做一次一致性审计，让核心设定真正承受“后果测试”。如果一座城市被群山隔绝，贸易就应该有反应；如果魔法便宜，医疗、治安、劳动、战争和身份体系就应该有反应；如果某个宗教机构垄断复活，继承、婚姻和家庭法也必然会有反应。如果一条规则只在剧情记得它的时候才生效，问题不是细节不够，而是因果已经断了。

这套审计适合在大规模写作、游戏制作、授权设定集或团队交接之前使用。它不规定你的世界必须长什么样，而是帮助团队分清正典、证据、推断和原创设定，再检查这些决定能不能同时成立。

第一遍：用一个带“动词”的段落写出核心设定

不要从词典开始。先写一段这个世界会做什么。

薄弱的核心设定常常长这样：

帝国很古老。魔法很稀有。北方很危险。教会很强大。

这些句子有气氛，却很难测试。

更有用的工作版本应该带动作：

帝国对合法施法征税；神殿法庭负责给治疗者发执照；帝国必须维持北方山口畅通，因为三座内陆城市依赖外来盐；公开场合的无证魔法很少，但家庭维修里很常见。

现在问题自然出现了：谁收税？山口封闭会怎样？普通家庭为什么容忍非法维修魔法？治疗执照让谁获利？带动词的核心设定会自动产生后果。

审计问题是：每条核心规则能不能产生至少一个可观察行为、成本、限制或冲突？ 如果不能，它可能只是气氛，不是规则。

第二遍：先画后果链，再决定要不要加更多设定

挑三条“如果世界忽略它，代价最大”的规则。

每条画五个节点：

规则 → 直接行为 → 机构反应 → 二级影响 → 故事压力

例如：

合法传送必须经过持牌传送门
→ 商人把货物集中到传送门城市
→ 检查机构和保税仓库变重要
→ 门附近土地变贵
→ 走私者寻找替代路线，政治派别争论是否新建传送门。

目的不是预测所有后果，而是证明这条规则不会只存在于介绍它的那一段文字里。

如果一种“改变世界的力量”对运输、劳动、法律、军队和普通生活习惯几乎没有影响，那么要么它没有文本宣称得那么重要，要么这个世界还没有真正对它做出反应。

很多创作者此时会不停加解释，但真正需要的可能是改规则。不要为了救一条会自然产生你不想要结果的规则，写三页例外条款。调整核心设定，让它的自然后果本来就能走向你想讲的故事。

第三遍：用矛盾表，不要靠记忆力管理正典

记忆不是可靠的正典数据库。建立一张决策表，每条规则至少记录：

最关键的一列是冲突对象。很多设定工具很擅长存“事实”，却不擅长显式记录“哪里还打架”。真正有价值的审计，恰恰要让这些没解决的摩擦可见。

Zotero 的 collections、tags 和 notes 可以帮助团队把研究资料按项目、主题和状态组织起来；Git 或其他版本控制则可以标记重要发布点和保留历史。具体用什么工具并不重要，重要的是纪律：任何人都应该能回答“这条规则从哪个版本开始成立？还有哪些东西依赖它？”

也不要用一个笼统的 canon 标签代替决策状态。更清楚的状态可以是：idea、working、locked、deprecated、conflict。

第四遍：从四个普通人的视角测试同一套规则

很多世界从王座上看很严密，一走进厨房就坏了。

用四种不掌握系统权力的人，重新看同一套核心设定：

1. 一个孩子；
2. 一个普通劳动者；
3. 一个小店主或手艺人；
4. 一个不喜欢、不能使用或被排除在主流机构之外的人。

如果合法魔法要交高额执照费，穷人家的工具坏了怎么办？如果世界之间可以旅行，会不会产生文件、迷信、保险、检疫、诈骗和跨界家庭分离？如果龙真的会偶尔越过农田，英雄出现之前，农民平时会改什么？

这一步很容易抓到“只有精英有因果”的世界：所有规则只让国王、军队、议会和主角发生反应，普通人好像完全没察觉。

它也能发现规模问题。一条规则在单个戏剧场景里合理，乘以整座城市就可能荒谬。不要只问“这件事能不能发生”，还要问：“如果它发生一千次，会出现什么系统？”

第五遍：用三类边缘案例主动攻击规则

强规则在特殊情况下也应该有可预测表现，而不是作者需要时偷偷关闭。

可以用三类边缘案例。

**边界案例：**规则在哪里停止？例如治疗魔法能闭合伤口，却不能补充失血，那它真正能解决到哪一步？

**对抗案例：**聪明人会怎样钻规则？如果合同由魔法强制执行，能不能操纵定义、管辖、同意或身份？

**碰撞案例：**两条规则同时适用怎么办？如果神殿庇护逃亡者，而帝国法律要求引渡，谁优先？代价是什么？

不需要把所有边缘案例都写死。要区分“故意保留的模糊”与“作者没想过的模糊”。前者可以制造故事压力，后者往往只会制造连续性错误。

审计结果最好写成决策，而不是论文。“庇护最多阻止逮捕三夜；如果申请人欺诈，神殿承担赔偿”就比两页庇护制度历史更好用。

把现实来源、你的解释和原创设定拆开

如果世界观借用了真实历史、宗教、物质文化、法律、医学或技术资料，必须记录“来源到底支持了什么”。

一张研究卡可以固定四栏：

• **来源事实：**资料直接写了或展示了什么；
• **解释：**你认为它为什么重要；
• **原创变形：**为了虚构世界你改了什么；
• **正典规则：**最终真正进入设定的那条规则。

这样可以避免一种常见错误：原创出来的规则后来被团队记成“历史上就是这样”，或者把一件博物馆藏品当成整个文化永久统一的证据。

Zotero 之所以适合做研究层，是因为同一资料可以同时归入不同 collection、打多个 tag、写 note、再搜索，而不会因为被收藏就自动变成正典。真实研究应当始终可追溯，即使最后的虚构改造已经非常大胆。

冻结“一个发布版本”，不要冻结整个世界

一致性审计应该以一个明确发布点结束，例如 Premise v1.0、Series Bible 2026-10。

Git 的 tag 是一个很直观的类比：它用来标记历史上的重要点。团队即使完全不用 Git，也可以采用同样思路——把下游工作正在依赖的那一包设定明确冻结，以后的修改全部走可见变更记录。

每次冻结后修改至少记录：

• 原规则；
• 新规则；
• 修改原因；
• 受影响的角色、地图、场景、商品、文章或游戏文本；
• 谁批准；
• 是否追溯影响旧内容。

这样可以防止“静默正典漂移”：角色卡已经更新，地图、游戏、官网和营销稿却仍在引用旧版本。

30分钟红队会议：让别人故意把设定打坏

进入大规模生产前，找一个不是这套核心设定作者的人来攻击它。

只给对方核心设定段落、规则表和后果链，然后让他问：

• 我能利用什么漏洞？
• 哪种普通人的行为明显不合理？
• 哪两条规则一定会撞上？
• 如果这条规则是真的，经济或文化里应该出现什么？
• 哪条规则总在剧情不方便时突然消失？
• 哪个“事实”没有可追溯来源，也没有明确原创决策？

作者先不要现场为每一条辩护，只负责把问题完整记录下来。防御心不是好的审计工具。

会后把问题分成 fix now、intentional uncertainty、future expansion、not a problem。这个分类本身就是一次很有价值的交付。

当后果变得可预测，核心设定才算真正准备好

一致性审计的目标不是消灭神秘感，而是让团队能够预测既有规则会怎样行动。

当一个没参与最初创作的新作者面对陌生情境时，只要应用同一套规则，就能得到一个与原作者大致一致的答案，而不必私下问“这时候应该怎么写”，核心设定才算真正进入可规模化生产状态。

真正的测试从来不是设定集有多少页，而是它能不能稳定地产生一致的决策。

数字要当“系统依赖”审计，不要只当装饰性细节

数字会偷偷制造承诺。地图比例、旅行时间、军队规模、人口、施法成本、历法长度、寿命、价格，看起来只是单个设定，却会把原本分开设计的区域强行连在一起。

审计时，把所有“会限制另一个决定”的数字单独抓出来，然后逐个问：这个数字会迫使世界发生什么？

如果信使一天能走300公里，交通系统必须有解释；如果首都两百万人，却只有一个山口负责主要粮食输入，仓储和断供风险就会变成非常重要的政治事实；如果一次治疗仪式等于手艺人一个月收入，那么即使魔法“理论上人人可用”，现实可及性也不会平均；如果战争已经持续80年，第80年的士兵、机构、记忆和经济结构就不该像战争刚在去年春天爆发一样。

可以做一张很简单的数字审计表：

目的不是为了“现实主义”而做模拟。奇幻当然可以使用现实中不可能的数字，审计真正问的是：世界剩下的部分有没有相信这个数字。

还要小心“虚假精确”。如果设定写某城人口恰好1,843,217人，它暗示的统计确定性远高于“约180万人”。除非世界内真的存在能产生这种数字的机构和理由，否则过度精确反而会制造新漏洞。

最后，给所有高影响数字写负责人和版本。如果地图比例改了，旅行表必须重查；如果施法成本改了，经济、阶层和剧情限制都可能需要跟着改。数字不是装饰事实，而是依赖关系。

Sources

1. Zotero Documentation — Collections and Tags. https://www.zotero.org/support/collections_and_tags/
2. Zotero Documentation — Notes. https://www.zotero.org/support/notes
3. Git Book — Tagging. https://git-scm.com/book/en/v2/Git-Basics-Tagging.html
4. Zotero Documentation — Searching. https://www.zotero.org/support/searching

延伸阅读

• A Repeatable Core-Premise Workflow
• Core-Premise Tools and Templates
• Advanced Core Premise Without Losing Clarity