結局很精彩，卻可能缺少抵達它的過去

作者已經想好最後一幕。

王城即將陷落。

凱恩站在城門前，接受黑騎士的身分，決定留下守護這座城市。

這個畫面很有力量。

但故事目前只寫到第十章。

凱恩仍是一名見習騎士。

他還沒有立下契約。

沒有完成試煉。

也沒有經歷那些足以讓他接受新身分的選擇。

作者知道自己想抵達哪裡。

前面的故事卻還沒有走到那裡。

另一個版本也開始浮現。

如果凱恩沒有選擇黑騎士的道路，而是取得符文弓，跟隨另一名導師，最後成為魔法弓箭手呢？

他也許不會留在城門前。

而會帶著同伴穿越森林，替城民找到另一條生路。

兩個結局都值得寫。

問題不是哪個畫面比較漂亮。

而是前面的故事，是否真的給了角色抵達那個畫面的理由。

多重結局最容易缺少的，往往不是最後幾段文字。

是每個結局各自需要的過去。

先替結局留下幾個真正重要的前提

想探索一個結局，不必先把中間二十幾章全部安排完。

可以先問：

這場終局如果要成立，前面有哪些事情不能省略？

對這個故事的作者來說，凱恩接受黑騎士身分，需要取得遺物、立下契約，並完成試煉。

另一條路則需要符文弓、導師訓練與魔法契合。

想探索的結局 作者希望前文完成的事情 結局要承接的角色歷史
凱恩接受黑騎士身分，留下守護王城 取得黑鐵遺物、立下契約、完成黑騎士試煉 他已經選擇承擔這條道路的義務與代價
凱恩成為魔法弓箭手，帶領同伴穿越森林 取得符文弓、完成導師訓練、完成魔法契合 他已經建立另一套能力、合作與行動方式

這些不是 InkWeave 預設的職業規則。

是作者為自己的世界設計的前提。

作者也可以決定，黑騎士不需要遺物，而必須取得某個組織的認可。

魔法弓箭手不需要正式導師，而是在一次冒險中自行完成覺醒。

條件可以改。

重要的是，作者知道哪些事情會讓最後一幕不再只是突然發生。

也不需要把所有情緒都變成條件。

凱恩的遲疑、羞愧、渴望與恐懼，仍然可以自由地留在正文裡。

先挑出少數真正影響終場是否成立的事情，就足以開始。

先寫下第二十七章，不代表前面的故事已經完成

作者目前寫到第十章。

下一個建立的章節，不一定非得是第十一章。

可以先建立第二十七章，留下自己想試寫的終場。

中間尚未完成的章節，之後再插入。

在 InkWeave 裡，作者可以在這個未來位置放下一個條件錨點，聲明：

故事走到這裡時，黑鐵遺物的取得、契約的成立，以及試煉的完成，都必須已經被前文確認。

這個條件錨點叫做 REQ。

名字看起來像技術術語，但用途很直覺。

它是在這個故事位置留下要求：

「這場戲需要哪些事情先成立？」

實際使用時，可以先建立幾個看得懂的故事標記，例如：

「黑鐵遺物已取得」。

「契約已成立」。

「黑騎士試煉已完成」。

在條件視窗裡選出這些標記，指定它們必須成立，再儲存。

不需要寫程式。

也不需要先建立一張涵蓋整部小說的邏輯表。

這個例子只需要三個可以表達「尚未完成／已完成」的標記。

作者現在只寫到第十章，所以第二十七章缺少前提，是正常的。

全知儀表板可以呈現這個未來位置尚未滿足的條件，讓作者知道自己還準備完成哪些事。

這不是因果律引擎在責備作者還沒寫完。

而是作者先替未來留下了一份可檢查的待辦。

一邊寫前文，一邊看見未來還欠什麼

接下來，作者可以在第十章與第二十七章之間插入第十一章。

再繼續寫第十二章，以及後面的冒險。

章節標題裡的數字，不會替故事完成因果。

真正決定哪些事情發生在 REQ 以前的，是專案中正文的排列順序。

作者將取得遺物、立約與試煉的場景放在終場以前，讓它們逐步成為那個結局的來源。

寫作推進到哪裡 黑鐵遺物已取得 契約已成立 試煉已完成 第二十七章仍缺什麼
第十章，凱恩已取得遺物 已完成 尚未完成 尚未完成 契約與試煉
後來寫完立約場景 已完成 已完成 尚未完成 試煉
終場以前完成試煉 已完成 已完成 已完成 這組前提已滿足

作者仍然是在寫場景。

寫凱恩如何發現遺物。

如何面對契約的代價。

如何在試煉中失去某些東西，又決定繼續。

真正發生取得時，可以透過物品操作確認它進入凱恩手中。

要讓 REQ 檢查「取得已經發生」，再於相應位置把那個故事標記設為成立。

物品事件負責保存物品的流轉。

故事標記負責表達作者希望被檢查的前提。

兩者的用途不同，不是因果律引擎讀完場景後自行猜測。

契約與試煉也一樣。

作者確認它们真正完成，再記下相關標記。

不必在每次寫作前重新抄一遍待辦。

條件檢查會依照前文已記錄的變化更新，讓作者看見這個未來位置仍缺哪些前提。

而眼前的冒險，也不需要因此退到設定表後面。

凱恩再次出現在正文裡，場景感知可以呈現他的形象、當時的位置與相關狀態。

查看遺物，檢閱器可以帶回它的持有與流轉資訊。

故事走到不同位置，看到的也會是那個位置上的角色，而不是永遠顯示最後的版本。

需要確認一次取得或移動，就回應引導選項。

只是提到，就略過。

想追溯，再查看歷史。

你可以一邊寫凱恩的冒險，一邊看見它正在替未來補上什麼。

那些資訊留在正文旁邊，不需要把每一句話都變成一次設定工作。

不同世界線，可以各自等待不同的結局

黑騎士結局需要三個前提。

不代表凱恩還必須同時完成魔法弓箭手的全部訓練。

比較兩個結局，不等於要求角色走完兩條道路。

作者如果決定分別續寫，就可以讓不同版本保存各自的未來要求。

黑騎士版本的第二十七章，檢查遺物、契約與試煉。

魔法弓箭手版本的終場，檢查符文弓、導師訓練與魔法契合。

每條世界線依照自己的前文，提供自己的答案。

不能因為作者記得另一個版本已經完成訓練，就把那段歷史借到目前版本裡。

也不能讓一個只在黑騎士版本立下的契約，自動成為另一條路的資格。

想實際保留不同結局，以及通往它們的完整故事版本？

請參考What If 劇情分支與多重宇宙故事操作教學，依照步驟保存與切換各條世界線的專案。

這套版本保存方式需要依照教學中的外部流程操作，不是 InkWeave 內建的一鍵生成結局。操作前，務必先完全關閉 InkWeave。

版本保存流程可以搭配免費版使用；本文介紹的因果律引擎、場景感知、條件驗證與全知儀表板，則屬於 Pro 功能。

保存版本之後，作者仍然決定每條路如何發展。

條件全部成立，也不會自動替凱恩轉職。

作者還需要寫出他接受新身分的場景，並確認那次身分變更。

REQ 負責確認前提。

不負責替作者演出結局，也不會自動完成伏筆的敘事回收。

刪掉一次試煉，結局也應該知道少了什麼

長篇很少完全不回修。

作者可能寫到後來，覺得某次試煉不符合角色的發展。

於是回到前文，連同「黑騎士試煉已完成」的標記一起移除。

第二十七章仍然存在。

但原本支撐它的其中一項前提，已經不在了。

重新驗證後，因果律引擎可以指出：這個未來位置仍然要求試煉完成，目前的事件卻沒有讓那項條件成立。

作者因此有機會在改動之後，看見它影響了哪個終場。

可以補上一場更適合的試煉。

可以調整結局需要的資格。

也可以接受凱恩不再走向黑騎士的未來。

InkWeave 使用的是自己研發的因果律引擎。

它不是 AI 編輯器，也不交由 AI 閱讀前文，猜測角色是否「感覺上已經成長足夠」。

它依照明確的狀態轉換與條件運算，重播已確認的事件，對照 REQ 所要求的前提。

在相同的起點、事件順序與條件下，得到相同的檢查結果。

這份確定性針對作者已建立的世界模型。

試煉写得是否動人，仍然由作者與讀者感受。

試煉是否被明確記錄為完成，則可以被驗證。

同樣地，「曾經取得遺物」和「現在仍持有遺物」也不能混為一談。

凱恩可能早已取得遺物，後來又把它交給別人。

如果終場需要遺物仍在身上，就要依照物品事件查看當時的持有狀態，不能只用一個「已取得」標記代替。

好的條件不是越多越好。

而是名字與要求足夠清楚，能回答作者真正想確認的事情。

結局可以改，條件不是綁住作者的命令

先留下未來要求，不代表作者必須服從最初的安排。

凱恩可能在寫作途中，變成一個不願意立下契約的人。

黑騎士試煉也可能讓作者發現，他真正想寫的不是接受力量，而是拒絕力量。

原本計畫的結局，於是需要改變。

這不是寫作失敗。

作者可以重新安排前提。

可以改寫終場。

也可以保留原來的版本，再讓另一個未來繼續。

條件的作用，不是要求角色無論如何都走向作者最早指定的位置。

而是讓作者在保留某個結局時，知道自己是否已經替它準備好相應的過去。

第二十七章可以先被寫下來。

但凱恩不必提前成為第二十七章的他。

在第十章，場景感知與檢閱器仍然呈現他當時的位置、物品與身分。

他可以繼續猶豫。

可以走錯。

可以失去原本以為不會失去的東西。

作者也可以在這些冒險之間，看見未來仍然等待哪些事情成立。

到了終場，角色接受的身分、得到的資格與作出的決定，就不只是作者突然給他的答案。

它們有前文。

有選擇。

有逐步累積的理由。

多重結局不只是把最後一章寫成幾個版本。

它是讓每一個想保留下來的未來，都有自己的路可以抵達。

先寫下想抵達的未來。

再讓前面的故事，一步步給它成立的理由。