如何在不破坏故事连续性的情况下构建 AI 架空世界设定集
通过为每个已确立的事实赋予稳定的 ID、人类决策负责人、来源和明确的范围,构建 AI 架空世界设定集。追踪它何时成立、在哪里适用,以及哪些角色知晓它。让 AI 提出增补建议并标出潜在冲突;在这些提议成为正史(canon)之前,必须由人工做出明确的编辑决策。本指南面向虚构作品和游戏编剧,旨在帮助他们为下一章、下一幕或下一个任务构建实用的参考依据。其核心任务是创建一份可随时查阅和修改、且不会意外改动故事既定规则的设定集。下方可复用的连续性台账将事实与依赖它们的场景连接起来。
你的 AI 世界观设定集应该包含哪些内容?
从一个能回答起草阶段实际问题的小型参考系统开始。这个角色能在日落前赶到天文台吗?他们知道如何开门了吗?在另一个故事分支中,这个答案会有变化吗?
将设定集划分为六个相互关联的板块:
使用电子表格、互联文档或你能轻松维护的数据库。为实体指定稳定的 ID(如 LOC-01 和 CHAR-02);将显示名称和别名保留在单独的字段中。重命名“玻璃天文台”不应该破坏指向其位置记录的每一处引用。
将叙事摘要视为该台账便于查阅的视图。当摘要与底层记录不一致时,请检查来源并在基于任一版本起草前解决冲突。
谁拥有事实的所有权,是什么让其成为正史?
对于这个工作流程,事实所有权包含两个部分:一条权威记录负责承载该陈述,一个人负责批准变更。独立创作者一人承担这一角色。团队则可将地点决策分配给世界观设计师,将角色披露分配给叙事负责人,并指定一人负责裁决重叠的决策。
在记录所有权的同时记录来源出处(provenance)。W3C 的 PROV 概述(https://www.w3.org/TR/prov-overview/)将出处定义为关于参与产出某物的人员、活动和实体的相关信息。应用于故事设定集时,这意味着保留某项陈述源自何处、如何变更以及由谁批准。此处的台账借鉴了这一原则;它并非正式的 PROV 实现。
为每条记录赋予明确的状态:
导入现有手稿时,让 AI 提取候选事实,并附带精确的场景出处和简短的佐证引文。请亲自核对这些引用。角色说出“天文台总是锁着的”只能证明有人说过这句话;它并不能自动构成一条客观规则。
写下你项目的权威原则。例如:已获采纳的吃书/修正(retcon)决策优于先前的正史词条;已采纳的源场景可确立事实;工作草稿和头脑风暴仍属临时性质。若两个已采纳的场景产生冲突,将该冲突标记为未决,直到你决定修改哪一个。
如何将时间线和地点结合起来追踪?
将故事时间与修订时间分开记录。“桥梁在第 6 天关闭”描述的是一个事件。“作者在修订版 4 中更改了桥梁的关闭日期”描述的是一项编辑决策。将二者混为一谈会导致含糊不清,无法分清究竟是世界本身发生了变化,还是对其描述进行了纠正。
对于每个事件,记录其最早和最晚可能发生的时间、地点、参与者、前置条件和产生的状态。在无需精确时使用区间:“早间送达之后,日落之前”往往比生造一个分钟数更有用。如果你的世界设定使用的是不常见的日或季节,请定义好历法单位。
对于每条路线,记录起点、终点、出行方式、用时或范围,以及可用条件。注明往返旅行是否均可行。地图上可能显示两地距离很近,但按照你已确立的路线,仍需要大绕一圈。
考虑这个明确用于说明的连续性检查:信使于 09:00 离开果园,需要三小时到达天文台,并再花 30 分钟取走一枚透镜。最早到达时间是 12:30。除非有已被采纳的特例适用,否则若某个场景让信使在正午出现在那里,就会与这些前置输入发生冲突。
通过修改某项有依据的输入来化解冲突:出发时间、路线、延误或会面时间。如果旅程耗时两到四小时,到达时间则是一个区间。应保留这种不确定性,而不是直接报告确定性的矛盾。
如何区分世界真相与角色认知?
将角色认知记录与客观事实分开。对于每一次重大披露,记录角色、事实或信念、获取事件、时间以及任何分支条件。区分“知晓”、“怀疑”、“误信”和“尚未得知”。缺少记录只代表该认知未被记录,并不能证明角色不知情。
这在互动式叙事中有直接对应物。Inkle 的官方 ink 教程(https://www.inklestudios.com/ink/web-tutorial/)演示了基于先前访问过的故事小节的条件文本和选项,同时也介绍了自定义变量。这些机制可以代表对信息的接触,尽管创作者仍须判定角色在经历某一场景后是否确实获知了特定事实。
例如,天文台的门在铜盘与标记对齐时打开。这是世界事实。Mira 在演示中学会了这一操作方法,则是另一个独立的事件。另一个读到残缺便条的角色可能仅仅怀疑它是这样运作的。
对于分支游戏,将学习事件关联到相应的路径或状态条件。对角色学会该操作的路线和跳过该操作的路线均进行测试。对于小说,即便章节并非按时间顺序出现,也要检查在故事时间线上,解释和对话发生在学习事件之后。
可复用的连续性台账
将以下字段用作电子表格列或笔记中的可重复记录。每条记录仅保留一项可独立修订的主张。示例纯属虚构,仅用于演示工作流程。
以下是三条互联记录的紧凑视图。完整的台账中每一行都应保留上述证据和所有权字段。
不要让“未决”悄然变成“不行”。问题 Q-003 对替代圆盘方案悬而未决。它既未允许也未禁止。若有场景需要答案,应触发决策申请。
为每个未决问题指定负责人和决策节点:“在起草 S-15 之前解决”。如果答案是刻意对读者保密的,记录作者自己是否已经知晓。作者心中已有的答案与尚未决定的设计选择需要不同的处理方式。
AI 在起草过程中应如何使用设定集?
准备一个场景数据包,其中包含目标场景的时间、地点、视角、分支、相关的正史记录以及未决依赖项。包含关联的前置条件,而不仅仅是与场景具有相同关键字的条目。一个与门有关的场景,可能依赖于早前在另一地点进行的演示。
使用如下可复用的指令提示词:
根据附带的连续性记录及其指定版本,审查所提供的场景。对于每个潜在冲突,引用场景段落并指出相关的记录 ID。将其归类为矛盾、信息缺失或提议的增补。检查时间线、路线旅行、地点准入、角色认知以及分支条件。保留未决问题。单独提出修复建议;不得更改正史或捏造来源引用。说明根据所提供的材料无法完成哪些检查。
对于生成类任务,要求在明确限制下提供替代方案:“在不更改 F-014 且不让 Mira 在 E-008 之前获知该信息的前提下,提出三种拖延 Mira 的方法。”用你自己的语言描述所需的氛围、节奏和场景特征。
分两遍审查输出。首先检查其引用的记录是否支持其结论。然后决定哪些建议对故事有益。只有被采纳的变更才能录入台账。如果缺少必要的来源,应将其找回,或者将该发现保持在未决状态。
如何在不抹去历史的情况下处理吃书/设定追溯(retcon)?
区分普通事件与设定追溯。如果那扇门在第 11 天换了新机关,请添加一个过渡事件和一条有时间限制的新规则。如果你决定它从一开始就使用不同的机关,请修订早前的正史,并检查每个依赖它的场景。
版本历史使先前的状态得以恢复。Git 官方手册对版本控制的介绍(https://git-scm.com/book/en/v2/Getting-Started-About-Version-Control)解释了版本控制如何记录变更、支持比对以及调用以前的版本。Git 只是方案之一;如果其他具备可用历史记录的文档系统更适合你的工作,尽可选用。另外,请单独记录叙事决策变更的原因。
针对每一次提议的设定追溯:
一个可复用的变更日志条目应包含变更 ID、修订日期、决策负责人、原因、旧记录、替换记录、受影响内容以及验证状态。例如:“CH-006 提议要求两个对齐的圆盘;影响 F-014、E-008、K-009 和 S-12;决策待定。”光是批准并不意味着那些受影响的场景已经修改完成。
在采纳一个场景前应该检查什么?
在场景完成创意修订后,通读一遍以检查连续性。核实所需事件是否已经发生,出行与通行条件是否成立,角色是否掌握了他们所使用的信息,以及特定分支的事实是否局限在各自的分支内。检查新细节是已被正史接纳,还是仍明确处于暂定状态。
记录用于该次检查的设定集版本。如果随后的修改触及该场景的某个依赖项,请重新打开该场景进行审查。你可以从一个地点、一个角色以及下一个场景的关键事实开始,每当新的细节对后续发展产生约束时,再逐步扩充台账。
