世界觀資料完整,不代表故事因果沒有斷裂
搜尋 World Anvil vs Campfire 的小說家,通常已經知道普通筆記不夠用了。
角色開始變多。
地點彼此包含。
歷史跨越不同年代。
家族、文化、宗教、物品、陣營與事件逐漸連在一起。
作者需要的不再只是一個存放靈感的地方。
他需要一套能讓世界被整理、搜尋與重新看見的結構。
World Anvil 和 Campfire 都在處理這個問題。
它們也都不只是單純的世界觀筆記。
World Anvil 可以建立世界百科、角色與地點條目、互動地圖、歷史時間線、家族關係與小說正文,並讓部分世界內容被發布與探索。
Campfire 可以透過角色、地點、物品、文化、關係、時間線、日曆、地圖、故事弧與 Manuscript 等模組,把正文與設定放進同一個創作專案。
如果問題只是「能不能把世界觀整理得更完整」,兩者都有自己的答案。
但世界觀真正困難的地方,往往發生在資料建立完成以後。
角色移動了。
物品轉手了。
地點毀滅了。
陣營失去領袖了。
作者又回到前文,改變了其中一個事件。
這時候,問題不再只是資料放在哪裡。
而是後面的世界是否仍然成立。
世界觀資料完整,不代表故事因果沒有斷裂。
World Anvil 把世界建立成可以探索的知識體系
World Anvil 最鮮明的設計,是把世界視為一套可以不斷擴張的知識體系。
作者可以替國家、城市、人物、種族、組織、歷史事件與其他世界元素建立條目。
不同條目可以彼此連結。
地點能出現在互動地圖上。
事件能被放進歷史時間線。
人物可以進入家族樹與關係結構。
作者也能控制哪些資訊保持私密,哪些內容開放給讀者、玩家或共同創作者。
這使 World Anvil 不只適合整理設定。
它也很適合讓一個世界被閱讀與探索。
讀者可以從一座城市進入統治它的國家。
從一名角色找到他的家族、組織與歷史。
從一場戰爭追溯參與者、地點與造成的影響。
世界不再只是一疊作者自己看得懂的筆記。
它可以逐漸形成一部具有入口、分類與關聯的世界百科。
World Anvil 也提供 Manuscripts,讓小說家可以在同一套世界資料旁邊規劃、撰寫、整理與發布正文。
因此,把 World Anvil 只理解成「做設定集的網站」並不準確。
它同時涵蓋世界建構、小說寫作、協作與展示。
只是它最具有辨識度的能力,仍然是讓世界知識被完整建立、彼此連結,並以可以探索的形式呈現。
Campfire 把世界拆成適合不同內容的創作模組
Campfire 的起點比較接近創作者正在管理的各種材料。
角色需要角色資料。
地點需要地點資料。
物品、文化、宗教、語言、關係、地圖與時間線,也各自需要不同的呈現方式。
所以 Campfire 不要求作者把所有設定都寫成相同形式的百科條目。
它把不同世界元素分進不同模組,再讓創作者按照專案需求選擇、連結與自訂。
角色可以擁有背景、外貌、特徵、數值與圖片。
地點可以包含描述、歷史與自訂面板。
物品可以獨立保存用途、來歷與其他細節。
Relationships 可以整理人物關係與家族結構。
Timeline 與 Calendar 可以呈現事件和自訂曆法。
Maps、Arcs、Systems 與 Research 則分別處理地理、故事弧、組織結構與研究資料。
Campfire 也有 Manuscript 模組。
作者可以拆分章節、撰寫正文、整理索引卡,並在寫作時查看已建立的故事元素。
這種模組化設計的價值,在於作者不必先把自己的世界改寫成一部百科,才能開始整理它。
每一種資料可以使用更接近自身用途的形式存在。
世界仍然是完整的。
但作者操作它時,看見的是角色、地點、物品與事件各自需要的工作空間。
把正文和設定放在一起,只解決了距離
World Anvil 和 Campfire 很容易被簡化成兩種印象。
World Anvil 是世界百科。
Campfire 是角色與設定表。
但這兩個印象都只說對了一部分。
World Anvil 不只提供世界條目。
小說家也能使用 Manuscripts 撰寫正文、安排章節與場景,並在寫作時查看世界資料。
Campfire 也不只提供角色卡。
它有 Manuscript、Timeline、Arcs、Calendar、Research 與其他可以參與完整創作流程的模組。
兩者都在減少正文與設定分散在不同軟體裡的問題。
作者不必在文字處理器裡寫小說,再回到另一套筆記系統尋找世界觀。
這解決了資料距離。
但把正文與設定放進同一個產品,不代表它們已經共享同一條因果。
作者在正文裡寫下一座城市毀滅,不代表所有相關角色、物品、地點與陣營資料會自動知道這件事。
作者修改較早章節,也不代表後面依賴舊版本的事件會主動指出自己已經失去前提。
世界資料可以離正文很近。
卻仍然需要作者親自維持兩者一致。
這就是「可以參考設定」與「世界會承擔正文後果」之間的差別。
一座城市毀滅時,改變的不只是一篇地點資料
假設作者建立了一座名為白港的城市。
世界資料中記錄著它的位置、人口、統治者、港口、商業、信仰、重要建築與歷史。
角色洛恩與莉雅住在城裡。
洛恩同時是白港守衛團的領袖。
一把只能開啟北城門的銅鑰匙在他手上。
另一名角色米拉則停留在城外。
故事走到第十六章。
白港遭到襲擊。
神殿被毀。
洛恩在災難中死亡。
作者確認洛恩身上的銅鑰匙留在廢墟。
莉雅逃往北方。
守衛團因為失去領袖,開始出現權力空缺。
到了第二十二章,米拉回到白港,從廢墟中取得銅鑰匙。
如果只看世界百科,作者可以更新白港的資料。
把地點狀態改成已毀滅。
把洛恩改成死亡。
把銅鑰匙的持有人改成米拉。
把守衛團改成失去領袖。
如果使用模組化世界觀資料,也可以分別更新地點、角色、物品、陣營與時間線。
這些資料都能描述故事最新進度的結果。
但一場城市毀滅不是只改變一篇地點資料。
它同時改變了在場人物、物品位置、角色生死、陣營結構與後續行動條件。
作者需要維護的不是一個答案。
而是一整組共同發生的後果。
真正危險的時刻,是作者回到前文改變過去
幾個月後,作者回頭修改第九章。
他決定讓洛恩提早把銅鑰匙交給米拉。
接著又在第十二章安排洛恩離開白港,前往南方調查另一件事。
這兩個修改本身都很合理。
問題在於,後文仍然保留著舊世界留下的結果。
第十六章的白港毀滅事件,仍把洛恩列為在場人物。
洛恩的死亡處置仍然記錄著銅鑰匙留在廢墟。
第二十二章的米拉,仍然從白港廢墟中再次取得同一把鑰匙。
守衛團的權力空缺,也仍然假設洛恩死於白港。
作者只是改了兩個較早的事件。
後面的城市毀滅、死亡遺物、物品取得與陣營結構卻一起失去了原本答案。
如果作者只更新洛恩的角色頁,其他資料不會因此消失。
如果作者把移動與交易放進時間線,他仍然要自己往後尋找所有受到影響的場景。
如果資料頁保存的是最新結果,作者甚至可能只看見米拉現在持有鑰匙,卻忘了她在故事裡已經取得了兩次。
這才是長篇世界觀最難維護的地方。
不是設定沒有寫。
不是資料找不到。
而是作者改變過去以後,未來仍然安靜地保留著舊世界。
InkWeave 的因果判斷不是 AI 猜測
很多人看到「自動發現故事矛盾」,第一個反應會是:
這是不是把小說交給 AI,請它判斷哪裡不合理?
InkWeave 不是這樣運作。
InkWeave 使用的是自行研發的因果律引擎。
它不需要讓語言模型猜測作者的句子代表什麼,也不會根據文字相似度推測一段劇情是否可能出錯。
作者先建立角色、地點、物品、陣營、屬性與旗標。
當正文中確實發生移動、交易、死亡、地點變化或其他世界事件時,再由作者確認它。
這些已確認事件會成為因果律引擎的輸入。
引擎按照卷冊、章節與事件順序,從故事開頭重播整條時間線。
角色在哪裡。
物品由誰持有。
角色是否仍然活著。
地點是否開放、封鎖、禁入、禁出或毀滅。
陣營目前具有什麼結構。
旗標與前置條件目前是否成立。
這些答案不是由 AI 生成。
它們由事件順序、數量變化、集合差異、狀態轉換與條件比較計算出來。
相同的事件與規則,會得到相同的結果。
如果洛恩已經把唯一的銅鑰匙交給米拉,他後面就沒有第二把可以留在廢墟。
如果洛恩已經離開白港,他就不在原本確認的災難波及名單裡。
如果白港已經毀滅,後面的角色便不能在沒有其他解釋的情況下正常進入。
這不是模型覺得情節可疑。
是事件重播後,後文要求的條件在計算上不成立。
數學保證的不是文學意義,而是已建模的因果
InkWeave 不會宣稱自己理解整部小說的文學意義。
它不知道一場死亡是否感人。
不知道一段背叛是否寫得足夠有力量。
也不知道作者提到白港時,究竟是在描寫現實、回憶、夢境、謊言還是象徵。
這些仍然屬於作者。
因果律引擎保證的是另一件事。
只要作者已經把某項世界變化建立成事件,它的後果就會依照明確規則繼續計算。
角色移動後,位置改變。
物品轉交後,數量與持有人改變。
角色死亡後,後續移動與交易會受到限制。
地點毀滅後,進入條件改變。
旗標被設定、消耗或回收後,依賴它的事件會得到可以驗證的結果。
這種保證具有明確邊界。
InkWeave 無法驗證作者從未建立的事實。
如果作者沒有把某件物品建立成世界實體,因果律引擎就不會憑空理解它的去向。
如果一段關係只存在於隱喻裡,沒有被作者確認成需要追蹤的狀態,系統也不會擅自替作者量化。
但在已建模的事件與規則範圍內,結果不是機率。
不是建議。
也不是某個模型對文章作出的解讀。
它是可以重現、可以檢查,也可以回溯來源的因果審計。
AI 提供的是判斷。
InkWeave 的因果律引擎提供的是證明。
因果律引擎不只重播世界,還會找出未來從哪裡斷裂
當第九章與第十二章被修改,InkWeave 不只更新洛恩與銅鑰匙的最新狀態。
它會重新重播後面的事件。
到了第十六章,因果律引擎會發現白港毀滅時的實際在場人物,已經和作者原本確認的災難波及範圍不同。
洛恩已經離開白港。
原本的受影響人物集合發生了漂移。
同一個死亡事件也可能出現另一項問題。
洛恩在較早章節已經交出銅鑰匙。
因此,故事重播到他的死亡時,實際背包不再包含那把鑰匙。
原本確認的死亡遺物處置,已經和現在的世界狀態不同。
到了第二十二章,米拉又從廢墟取得銅鑰匙。
但她在第九章就已經持有這件唯一物品。
這次取得便不只是資料頁需要更新。
它在目前因果裡已經無法成立。
類似的檢查也會發生在其他世界狀態上。
死亡角色後來仍然移動或交易。
兩名位於不同地點的角色直接轉交物品。
角色試圖進入已經禁入或毀滅的地點。
一件唯一物品同時出現多份。
後續場景要求的旗標、數值或前置條件尚未成立。
被設定的伏筆直到故事結束仍未回收。
陣營領袖離開後產生階層斷裂、孤兒成員或與原本確認結果不同的連鎖影響。
這些不是一般拼字檢查,也不是 AI 對劇情提出的可能建議。
它們都是後文向世界要求某個條件時,因果律引擎發現那個條件並不存在。
Project Seer 把斷裂的因果帶回作者眼前
如果因果錯誤只存在於一份藏得很深的報告裡,作者仍然很難使用它。
InkWeave 的 Project Seer 會把全專案的驗證結果整理成可以處理的寫作資訊。
它會顯示專案整體的因果健康狀態。
列出哪些章節包含錯誤或警告。
區分會阻斷因果的問題,以及需要作者重新確認的後果漂移。
作者可以從 Project Seer 直接進入發生問題的章節與事件錨點。
很多錯誤不只保存「哪裡出錯」。
它們也保存造成目前狀態的來源。
如果角色在死亡後移動,作者可以回到確立死亡的事件。
如果物品交易的雙方不在同一個地點,系統可以追溯兩名角色各自最近一次有效移動的位置。
如果地點狀態阻止角色進出,也可以回到讓地點封鎖、禁入或毀滅的事件。
所以作者面對的不是一句模糊的「這裡可能有劇情漏洞」。
他可以知道:
哪個事件現在無法成立?
它需要的世界條件是什麼?
目前實際狀態又是什麼?
哪一個較早事件造成了這項差異?
這使糾錯不再只是發現結果。
它還保留了因果來源。
即時反應不是邊打字邊猜,而是讓世界在確認後重新結算
InkWeave 的即時性,也和 AI 即時分析文章不同。
它不會在作者每打下一個詞時,擅自猜測故事發生了什麼。
名字靠近名字,只代表這裡可能存在一次世界交互。
角色靠近地點,可能是移動,也可能只是回憶或提到。
角色靠近物品,可能是取得、轉交、放置,也可能什麼都沒有發生。
最後仍然由作者確認。
但當一次世界事件被確認並保存,InkWeave 會重新驗證專案時間線。
角色位置、物品歸屬、生命狀態、地點條件、陣營結構與旗標,都會依照新的事件順序重新計算。
受到影響的後文會在事件錨點與 Project Seer 中浮出來。
與此同時,作者把游標放在不同章節時,Inspector 與 AVG Stage 取得的也不是永遠最新的設定。
它們會依照游標所在的位置,呈現故事走到那一刻的世界切片。
游標停在白港毀滅以前,白港仍然存在。
停在毀滅以後,世界才承認它留下的後果。
因此,InkWeave 同時處理兩個方向。
它向當下回答:
故事走到這裡,世界是什麼狀態?
也向未來追問:
過去改變以後,後面的事件是否仍然成立?
糾錯不是替作者自動修復世界
因果律引擎發現問題,不代表 InkWeave 會擅自修改故事。
洛恩提早離開白港以後,系統不會自行取消他的死亡。
不會自動把銅鑰匙送回他手上。
不會替守衛團選出新的領袖。
也不會為了維持原本劇情,假裝第九章的物品轉交沒有發生。
它只會把失去前提的後果指出來。
作者可以決定洛恩其實又回到了白港。
可以讓他死在南方,並重新安排陣營後果。
可以把廢墟裡的銅鑰匙改成另一件物品。
也可以保留米拉從第九章開始持有鑰匙,重新設計第二十二章的行動。
有些警告也可能只是作者有意接受的新結果。
例如陣營成員離開後,作者可以確認目前重新計算出的連鎖影響。
世界負責證明目前發生了什麼。
作者負責決定故事接下來要承認什麼。
這種分工很重要。
因為創作需要自由。
但自由不是讓前文與後文互相矛盾時,系統替作者假裝沒有看見。
真正的自由,是作者知道自己改變了哪些條件,仍然能選擇如何承擔那些改變。
世界觀工具不只要保存世界,還要知道世界何時斷了
World Anvil 和 Campfire 都能幫助小說家建立比普通文件更有結構的世界。
World Anvil 讓世界知識可以被連結、探索、展示與發布。
Campfire 讓角色、地點、物品、關係、時間線與正文進入各自合適的創作模組。
它們處理的都是真實而且重要的問題。
但一個故事世界不會永遠停在設定完成的那一天。
它會被正文中的事件反覆改變。
作者也會回到過去,重新安排角色、物品、地點與選擇。
這時候,資料是否完整只是一部分。
更深的問題是:
世界能不能依照事件重新計算自己?
後文失去前提時,能不能被立即指出?
作者能不能從錯誤回到造成它的因果來源?
這正是 InkWeave 自行研發因果律引擎所扮演的角色。
它不是把全文交給 AI,再請模型猜測哪裡可能不合理。
它讓作者確認的事件成為可以計算的歷史。
讓角色、地點、物品與陣營在每一個故事位置擁有確定狀態。
也讓過去被修改時,未來無法繼續假裝自己沒有受到影響。
世界百科回答這個世界有什麼。
模組化資料讓作者知道應該到哪裡管理它。
InkWeave 的因果律引擎則繼續追問:
按照這個世界真正發生過的事,後面的故事還成立嗎?
一個世界真正需要的,不只是被完整保存。
它還需要在因果斷裂時,有能力讓作者知道。