模组看起来完整，直到玩家把核心交给另一个人

主持人准备了一场城市防御战。

玩家先进入废弃矿坑，发现一枚共鸣核心。

主持人预期，玩家角色薇拉会带走核心，把它交给守军指挥官塔恩。

几天后，城市遭到袭击。

塔恩带着核心抵达防御工事，启动装置，替玩家争取进入下一个场景的时间。

地图准备好了。

敌人准备好了。

塔恩的对话、玩家的奖励，以及防御装置启动后的演出，也都准备好了。

然后，有人问：

「我们为什么要交给守军？研究员米拉不是更了解这东西吗？」

只换一个收件人，后面的准备就开始出现问题。

塔恩还能带着核心抵达防御工事吗？

米拉会把它交回来吗？

玩家是否知道交付对象会影响城市防御？

如果他们根本没有带走核心，后面的袭击又要如何发展？

这就是 TRPG 模组测试值得做的地方。

不是确认玩家能不能按照剧本走完。

而是找出：哪些场景偷偷依赖了一个主持人以为他们一定会做的选择？

不必测完所有选择，先找会牵动后文的事情

玩家可以用很多方法进入矿坑。

和守卫谈判、翻过围栏、寻找旧入口，甚至假装自己是受聘的工人。

这些方法可能带来不同演出。

但如果它们没有持续改变后面的条件，主持人未必需要为每一种方法保存完整测试版本。

核心的去向不一样。

它会影响后面的物品持有、人物行动、奖励与防御场景。

所以可以先挑三种重要结果来测试。

测试版本 主持人确认的结果 原定防御场景需要重新确认什么
交给守军 薇拉取得核心，再转交给塔恩 塔恩是否已抵达防御工事？装置启动是否真的完成？
交给研究员 薇拉取得核心，再转交给米拉 塔恩没有核心，原定启动安排还成立吗？
不带走核心 玩家离开，核心仍留在矿坑 是否有人取回？如果没有，城市如何面对袭击？

这三种测试，不是三份必须全部写完的长篇战役。

它们是主持人挑出的情境，用来检查同一组后续准备。

关键物品换了持有人。

必要人物没有到场。

角色尚未取得资格。

某个承诺没有成立。

这些通常比「玩家会不会选择从东门进城」更值得优先测试。

因为它们会让后面的事件失去来源，或改变原本可以使用的方法。

测试的价值，不在于涵盖所有可能。

而在于找到少数真正会让未来改变形状的选择。

在 InkWeave 里，把一种可能结果实际写下来

要开始这次测试，不需要先建立整座城市的所有居民。

在 InkWeave 里，可以先建立薇拉、塔恩、米拉、矿坑、共鸣核心，以及防御工事所在的地点。

先记录核心位于矿坑，再试写玩家的行动。

如果薇拉带走核心，就确认那次取得。

如果她把核心交给米拉，就确认那次转交。

如果玩家只看见核心，最后没有带走，就不建立取得事件。

这些都是测试情境里，由主持人选定并确认的结果。

不是 InkWeave 自己扮演玩家，决定他们要相信谁。

写作时，场景感知与检阅器可以依游标所在的位置，呈现相关人物、地点与物品的状态。

薇拉取得核心以后，检阅器能呈现她当时持有的物品。

转交给米拉以后，核心的去向也会随已记录的事件改变。

回到转交以前，看到的则是那一刻尚未交出的核心。

主持人可以边写玩家与米拉的交涉，边看见这个选择如何改变世界。

不必每完成一段对话，就另外更新几份持有人清单。

当角色与物品在正文中靠近，InkWeave 可以呈现相关交互资讯，再让主持人确认是否发生取得、放置或转交。

如果玩家只是讨论「也许可以交给米拉」，就可以略过事件提示。

计划不必提前成为事实。

画面把当下的世界带回正文旁边，最后确认仍然留在主持人手上。

再走到原定场景，看看它还能不能照原样发生

现在进入米拉持有核心的测试版本。

主持人继续试写城市遭到袭击。

原稿里，塔恩会拿出核心，把它交给负责操作装置的人。

但这条世界线的前文，已经把核心交给米拉。

塔恩并未取得它。

如果主持人把后面的交付记录成物品事件，因果律引擎就可以验证他是否真的持有核心，指出这次交付缺少来源。

这比单纯在笔记旁写一句「注意核心位置」更具体。

因为问题出现在实际使用核心的地方。

主持人可以回头决定：

让米拉把核心交给塔恩。

让米拉亲自抵达工事。

改用另一种防御方式。

或者接受装置无法启动，让城市进入不同的危机。

这些都是创作上的修正。

因果律引擎不会替主持人偷偷补一枚核心，也不会为了让战斗顺利开始，把持有人改回原稿。

人物位置也值得一起看。

米拉持有核心，不代表她已经来到工事。

塔恩答应启动装置，也不代表启动已经完成。

如果后面的场景需要「防御装置已启动」，主持人可以明确建立这项旗标，在启动结果确认后设定它，再于需要它的地方放下条件检查。

全书验证仪表板可以呈现已建模的问题，让主持人回到相关章节与事件，查看缺少的是哪一项前提。

它不会从「塔恩会处理」这句话，自动推测所有必要步骤都已完成。

测试也能发现：你记录的条件，和真正需要的条件不同

主持人可能建立一个标记：

「玩家已取得核心。」

到了防御场景，只检查这项标记是否成立。

这看起来合理。

但在米拉持有核心的版本里，玩家确实曾经取得它。

标记没有说错。

只是后面的场景真正需要的，可能不是「曾经取得」。

而是核心目前能否被送到工事，以及装置是否已经启动。

一个历史事实，不能代替所有后续条件。

同样地：

玩家曾经见过塔恩，不代表塔恩已答应支援。

玩家曾经得到邀请，不代表邀请仍然有效。

玩家取得研究资料，不代表已完成培训。

测试不只是找到漏记的事件。

也能让主持人重新辨认：自己到底想检查什么？

如果需要确认物品现在由谁持有，就查看物品流转与当时的持有状态。

如果需要确认装置已启动，就明确记录启动结果。

不必把所有事情都塞进一个叫作「任务完成」的标记。

条件越贴近后文真正需要的事实，验证结果就越容易理解。

奖励与角色成长，也不能提前发放

核心的去向还可能影响奖励。

主持人原本安排，薇拉把核心交给塔恩后，得到加入守军的机会。

另一个版本里，她协助米拉完成研究，再接受培训，取得模组自订的「符文技师」身分。

这些发展可以很有趣。

但每一件事都需要自己的位置。

交付物品，不等于已经加入组织。

得到培训邀请，不等于培训已完成。

改变角色身分，也不等于所有属性已经自动增加。

在 InkWeave 里，主持人可以分别记录物品转交、阵营加入、身分变更与属性变化。

游标停在培训以前，检阅器仍呈现那时的角色身分。

停在已确认的身分变更以后，才呈现新的身分与相应属性范围。

如果后续场景需要「研究所培训已完成」，也应明确建立并记录这项条件。

这样，主持人试走后面的剧情时，就能确认角色是否真的走到那一步，而不是因为奖励早已写在模组里，就提前把它当成角色拥有的东西。

InkWeave 不会执行 D&D 的升级规则。

不会判断兼职资格，也不会替玩家挑选能力。

规则与主持人决定角色如何成长。

因果律引擎忠实呈现已记录的成长，发生在世界时间里的哪一刻。

因果验证能找出什么，跑团测试还要回答什么？

物品流转没有矛盾，不代表玩家一定喜欢这段冒险。

所有条件都成立，也不代表线索清楚、战斗有趣或场景节奏合适。

所以这种测试不能取代实际游玩。

明确建模后可以验证的问题 仍需要主持人与实际游玩判断的问题
塔恩是否真的持有核心 玩家是否理解核心的用途
防御装置所需旗标是否成立 玩家能否找到必要线索
人物当时的位置与行动条件 场景是否拖沓、资讯是否过多
角色何时改变身分与属性 成长奖励是否有吸引力
阵营成员与隶属是否已改变 NPC 的反应是否令人信服
后续事件是否缺少已定义的前提 规则、遭遇与资源配置是否平衡

InkWeave 使用的是自研的因果律引擎，不是 AI 审计。

它依照主持人建立的初始状态、规则与明确事件，沿时间顺序推导世界，再验证后续条件。

在同样的模型、规则与事件顺序下，推导结果保持一致。

这里的数学保证，针对的是已建立的世界模型。

不是保证模组好玩，也不是保证玩家只会做出测试过的选择。

如果重要事实从未被建立，因果律引擎也不会自行理解它藏在某段对话中的意义。

它能帮主持人找出模型里的矛盾与缺少的前提。

真正的跑团测试，则让主持人看见人坐到桌边以后，如何理解、选择与共同创作。

两者回答不同问题。

也可以互相补充。

保存测试版本，再把发现带回正式模组

这三种核心去向，可以作为不同的完整测试版本保存。

守军版本留下核心交给塔恩的历史。

研究员版本留下核心交给米拉的历史。

没有取走的版本，则让核心继续留在矿坑，直到主持人另外安排改变。

想在开团前试走几种重要选择，又不改坏原本的模组？

请参考What If 剧情分支与多重宇宙故事操作教学，依照教学保存与切换完整版本，再分别试写各种选择造成的世界变化。

这是搭配外部版本工具的操作流程，不是 InkWeave 内建的自动玩家模拟或一键测试。

保存或切换版本前，必须先完全关闭 InkWeave，再依教学操作，避免自动储存把内容写入另一个版本。

外部版本保存流程可以搭配免费版使用；本文提到的场景感知、因果律推导与自动验证，则属于 InkWeave Pro 的功能范围。

每次重新打开版本，因果律引擎依据的是目前这条世界线实际保存的事件，不会同时替所有未开启的版本进行测试。

测试完成后，也不必把三条路全部写成正式章节。

可以把发现整理成主持人容易使用的回应原则：

核心交给塔恩时，仍需确认抵达与启动。

核心交给米拉时，守军不能直接使用它，需要新的协调或交付。

核心留在矿坑时，可以安排取回，也可以让城市面对没有这项防御的局势。

模组留下的是承接选择的方法。

不是要求玩家从三个预写答案中挑一个。

测试的目的，不是让每条路都得到相同结果

玩家把核心交给米拉，不一定应该被拉回原本的守军路线。

没有带走核心，也不一定需要主持人安排另一名 NPC，刚好把它送到工事。

有些选择会让事情更困难。

有些会失去原本的机会。

也有些会让玩家得到另一种支援，甚至长出主持人原本没想到的解法。

测试要确认的，不是所有道路最后都能启动同一座装置。

而是当装置无法启动时，主持人知道为什么，也知道眼前仍有哪些条件可以继续使用。

世界可以接受失败。

可以失去资源。

可以让原定场景改变形式。

但不能在玩家做出另一个选择后，仍然沿用一套只有原稿才提供的事实。

在 InkWeave 里，主持人可以从一个重要选择开始，边试写、边看见人物与物品的状态，再用因果验证确认后文的前提。

不必先完成所有未来。

也不必只靠记忆，想像每种选择可能牵动什么。

好的模组测试，不是证明玩家一定会走到你准备的结局。

而是确认他们换一种选择后，世界仍然接得住。