模組看起來完整，直到玩家把核心交給另一個人

主持人準備了一場城市防禦戰。

玩家先進入廢棄礦坑，發現一枚共鳴核心。

主持人預期，玩家角色薇拉會帶走核心，把它交給守軍指揮官塔恩。

幾天後，城市遭到襲擊。

塔恩帶著核心抵達防禦工事，啟動裝置，替玩家爭取進入下一個場景的時間。

地圖準備好了。

敵人準備好了。

塔恩的對話、玩家的獎勵，以及防禦裝置啟動後的演出，也都準備好了。

然後，有人問：

「我們為什麼要交給守軍？研究員米拉不是更了解這東西嗎？」

只換一個收件人，後面的準備就開始出現問題。

塔恩還能帶著核心抵達防禦工事嗎？

米拉會把它交回來嗎？

玩家是否知道交付對象會影響城市防禦？

如果他們根本沒有帶走核心，後面的襲擊又要如何發展？

這就是 TRPG 模組測試值得做的地方。

不是確認玩家能不能按照劇本走完。

而是找出：哪些場景偷偷依賴了一個主持人以為他們一定會做的選擇？

不必測完所有選擇，先找會牽動後文的事情

玩家可以用很多方法進入礦坑。

和守衛談判、翻過圍欄、尋找舊入口，甚至假裝自己是受聘的工人。

這些方法可能帶來不同演出。

但如果它們沒有持續改變後面的條件，主持人未必需要為每一種方法保存完整測試版本。

核心的去向不一樣。

它會影響後面的物品持有、人物行動、獎勵與防禦場景。

所以可以先挑三種重要結果來測試。

測試版本 主持人確認的結果 原定防禦場景需要重新確認什麼
交給守軍 薇拉取得核心，再轉交給塔恩 塔恩是否已抵達防禦工事？裝置啟動是否真的完成？
交給研究員 薇拉取得核心，再轉交給米拉 塔恩沒有核心，原定啟動安排還成立嗎？
不帶走核心 玩家離開，核心仍留在礦坑 是否有人取回？如果沒有，城市如何面對襲擊？

這三種測試，不是三份必須全部寫完的長篇戰役。

它們是主持人挑出的情境，用來檢查同一組後續準備。

關鍵物品換了持有人。

必要人物沒有到場。

角色尚未取得資格。

某個承諾沒有成立。

這些通常比「玩家會不會選擇從東門進城」更值得優先測試。

因為它們會讓後面的事件失去來源，或改變原本可以使用的方法。

測試的價值，不在於涵蓋所有可能。

而在於找到少數真正會讓未來改變形狀的選擇。

在 InkWeave 裡，把一種可能結果實際寫下來

要開始這次測試，不需要先建立整座城市的所有居民。

在 InkWeave 裡，可以先建立薇拉、塔恩、米拉、礦坑、共鳴核心，以及防禦工事所在的地點。

先記錄核心位於礦坑，再試寫玩家的行動。

如果薇拉帶走核心，就確認那次取得。

如果她把核心交給米拉，就確認那次轉交。

如果玩家只看見核心，最後沒有帶走，就不建立取得事件。

這些都是測試情境裡，由主持人選定並確認的結果。

不是 InkWeave 自己扮演玩家，決定他們要相信誰。

寫作時，場景感知與檢閱器可以依游標所在的位置，呈現相關人物、地點與物品的狀態。

薇拉取得核心以後，檢閱器能呈現她當時持有的物品。

轉交給米拉以後，核心的去向也會隨已記錄的事件改變。

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

主持人可以邊寫玩家與米拉的交涉，邊看見這個選擇如何改變世界。

不必每完成一段對話，就另外更新幾份持有人清單。

當角色與物品在正文中靠近，InkWeave 可以呈現相關交互資訊，再讓主持人確認是否發生取得、放置或轉交。

如果玩家只是討論「也許可以交給米拉」，就可以略過事件提示。

計畫不必提前成為事實。

畫面把當下的世界帶回正文旁邊，最後確認仍然留在主持人手上。

再走到原定場景，看看它還能不能照原樣發生

現在進入米拉持有核心的測試版本。

主持人繼續試寫城市遭到襲擊。

原稿裡，塔恩會拿出核心，把它交給負責操作裝置的人。

但這條世界線的前文，已經把核心交給米拉。

塔恩並未取得它。

如果主持人把後面的交付記錄成物品事件，因果律引擎就可以驗證他是否真的持有核心，指出這次交付缺少來源。

這比單純在筆記旁寫一句「注意核心位置」更具體。

因為問題出現在實際使用核心的地方。

主持人可以回頭決定：

讓米拉把核心交給塔恩。

讓米拉親自抵達工事。

改用另一種防禦方式。

或者接受裝置無法啟動，讓城市進入不同的危機。

這些都是創作上的修正。

因果律引擎不會替主持人偷偷補一枚核心，也不會為了讓戰鬥順利開始，把持有人改回原稿。

人物位置也值得一起看。

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

塔恩答應啟動裝置，也不代表啟動已經完成。

如果後面的場景需要「防禦裝置已啟動」，主持人可以明確建立這項旗標，在啟動結果確認後設定它，再於需要它的地方放下條件檢查。

全書驗證儀表板可以呈現已建模的問題，讓主持人回到相關章節與事件，查看缺少的是哪一項前提。

它不會從「塔恩會處理」這句話，自動推測所有必要步驟都已完成。

測試也能發現：你記錄的條件，和真正需要的條件不同

主持人可能建立一個標記：

「玩家已取得核心。」

到了防禦場景，只檢查這項標記是否成立。

這看起來合理。

但在米拉持有核心的版本裡，玩家確實曾經取得它。

標記沒有說錯。

只是後面的場景真正需要的，可能不是「曾經取得」。

而是核心目前能否被送到工事，以及装置是否已經啟動。

一個歷史事實，不能代替所有後續條件。

同樣地：

玩家曾經見過塔恩，不代表塔恩已答應支援。

玩家曾經得到邀請，不代表邀請仍然有效。

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

測試不只是找到漏記的事件。

也能讓主持人重新辨認：自己到底想檢查什麼？

如果需要確認物品現在由誰持有，就查看物品流轉與當時的持有狀態。

如果需要確認裝置已啟動，就明確記錄啟動結果。

不必把所有事情都塞進一個叫作「任務完成」的標記。

條件越貼近後文真正需要的事實，驗證結果就越容易理解。

獎勵與角色成長，也不能提前發放

核心的去向還可能影響獎勵。

主持人原本安排，薇拉把核心交給塔恩後，得到加入守軍的機會。

另一個版本裡，她協助米拉完成研究，再接受培訓，取得模組自訂的「符文技師」身分。

這些發展可以很有趣。

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

交付物品，不等於已經加入組織。

得到培訓邀請，不等於培訓已完成。

改變角色身分，也不等於所有屬性已經自動增加。

在 InkWeave 裡，主持人可以分別記錄物品轉交、陣營加入、身分變更與屬性變化。

游標停在培訓以前，檢閱器仍呈現那時的角色身分。

停在已確認的身分變更以後，才呈現新的身分與相應屬性範圍。

如果後續場景需要「研究所培訓已完成」，也應明確建立並記錄這項條件。

這樣，主持人試走後面的劇情時，就能確認角色是否真的走到那一步，而不是因為獎勵早已寫在模組裡，就提前把它當成角色擁有的東西。

InkWeave 不會執行 D&D 的升級規則。

不會判斷兼職資格，也不會替玩家挑選能力。

規則與主持人決定角色如何成長。

因果律引擎忠實呈現已記錄的成長，發生在世界時間裡的哪一刻。

因果驗證能找出什麼，跑團測試還要回答什麼？

物品流轉沒有矛盾，不代表玩家一定喜歡這段冒險。

所有條件都成立，也不代表線索清楚、戰鬥有趣或場景節奏合適。

所以這種測試不能取代實際遊玩。

明確建模後可以驗證的問題 仍需要主持人與實際遊玩判斷的問題
塔恩是否真的持有核心 玩家是否理解核心的用途
防禦裝置所需旗標是否成立 玩家能否找到必要線索
人物當時的位置與行動條件 場景是否拖沓、資訊是否過多
角色何時改變身分與屬性 成長獎勵是否有吸引力
陣營成員與隸屬是否已改變 NPC 的反應是否令人信服
後續事件是否缺少已定義的前提 規則、遭遇與資源配置是否平衡

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

它依照主持人建立的初始狀態、規則與明確事件，沿時間順序推導世界，再驗證後續條件。

在同樣的模型、規則與事件順序下，推導結果保持一致。

這裡的數學保證，針對的是已建立的世界模型。

不是保證模組好玩，也不是保證玩家只會做出測試過的選擇。

如果重要事實從未被建立，因果律引擎也不會自行理解它藏在某段對話中的意義。

它能幫主持人找出模型裡的矛盾與缺少的前提。

真正的跑團測試，則讓主持人看見人坐到桌邊以後，如何理解、選擇與共同創作。

兩者回答不同問題。

也可以互相補充。

保存測試版本，再把發現帶回正式模組

這三種核心去向，可以作為不同的完整測試版本保存。

守軍版本留下核心交給塔恩的歷史。

研究員版本留下核心交給米拉的歷史。

沒有取走的版本，則讓核心繼續留在礦坑，直到主持人另外安排改變。

想在開團前試走幾種重要選擇，又不改壞原本的模組？

請參考What If 劇情分支與多重宇宙故事操作教學，依照教學保存與切換完整版本，再分別試寫各種選擇造成的世界變化。

這是搭配外部版本工具的操作流程，不是 InkWeave 內建的自動玩家模擬或一鍵測試。

保存或切換版本前，必須先完全關閉 InkWeave，再依教學操作，避免自動儲存把內容寫入另一個版本。

外部版本保存流程可以搭配免費版使用；本文提到的場景感知、因果律推導與自動驗證，則屬於 InkWeave Pro 的功能範圍。

每次重新打開版本，因果律引擎依據的是目前這條世界線實際保存的事件，不會同時替所有未開啟的版本進行測試。

測試完成後，也不必把三條路全部寫成正式章節。

可以把發現整理成主持人容易使用的回應原則：

核心交給塔恩時，仍需確認抵達與啟動。

核心交給米拉時，守軍不能直接使用它，需要新的協調或交付。

核心留在礦坑時，可以安排取回，也可以讓城市面對沒有這項防禦的局勢。

模組留下的是承接選擇的方法。

不是要求玩家從三個預寫答案中挑一個。

測試的目的，不是讓每條路都得到相同結果

玩家把核心交給米拉，不一定應該被拉回原本的守軍路線。

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

有些選擇會讓事情更困難。

有些會失去原本的機會。

也有些會讓玩家得到另一種支援，甚至長出主持人原本沒想到的解法。

測試要確認的，不是所有道路最後都能啟動同一座裝置。

而是當裝置無法啟動時，主持人知道為什麼，也知道眼前仍有哪些條件可以繼續使用。

世界可以接受失敗。

可以失去資源。

可以讓原定場景改變形式。

但不能在玩家做出另一個選擇後，仍然沿用一套只有原稿才提供的事實。

在 InkWeave 裡，主持人可以從一個重要選擇開始，邊試寫、邊看見人物與物品的狀態，再用因果驗證確認後文的前提。

不必先完成所有未來。

也不必只靠記憶，想像每種選擇可能牽動什麼。

好的模組測試，不是證明玩家一定會走到你準備的結局。

而是確認他們換一種選擇後，世界仍然接得住。