大綱說角色拿到了鑰匙，正文卻不是這樣

作者在大綱裡安排了一次偷竊。

第六章，莉莎從守衛身上取得檔案庫的鑰匙。

第九章，她用鑰匙進入檔案庫。

第十二章，她把鑰匙交給羅文，讓他能夠執行下一步計畫。

這條事件線很清楚。

作者可以在 Plottr 的時間線與場景卡上安排三個節點，讓鑰匙的取得、使用與轉交沿著章節向前排列。

接著，他把規劃好的內容帶進 Scrivener，開始真正撰寫正文。

但寫到第六章時，故事改變了。

莉莎試圖偷走鑰匙，卻在最後一刻被守衛發現。

作者喜歡這個意外。

他保留失敗，讓莉莎放棄鑰匙，帶著新的懷疑離開現場。

正文因此變得更好。

問題是，大綱裡的第九章仍然寫著她使用鑰匙進入檔案庫。

第十二章也仍然等著她把鑰匙交給羅文。

現在，作者手上有了兩個故事。

一個是原本規劃的故事。

一個是正文真正寫出來的故事。

劇情規劃和正文寫作真正困難的地方，不是它們能不能放在兩個軟體裡。

而是當兩者開始分歧時，哪一個版本有資格決定後面的世界。

Plottr 讓尚未寫出的故事先變得可見

Plottr 最清楚的價值，是讓故事在進入完整正文以前，先成為可以觀看、排列與調整的結構。

創作者可以用時間線整理章節與場景。

用不同情節線區分主線、支線與角色弧線。

透過場景卡安排視角角色、目標、衝突與其他自訂資訊。

也可以篩選角色、地點、標籤與故事屬性，觀察某條劇情在整部作品中的分布。

對系列小說而言，創作者還能從單一本書向上觀看整個系列，確認某段角色發展、世界歷史或長期伏筆橫跨了哪些作品。

這些功能處理的是一個真實而且重要的問題：

在寫出數十萬字以前，作者需要先看見故事可能長成什麼樣子。

一條角色線是否消失太久。

某幾章是否同時塞入太多事件。

一段支線是否離開主線之後再也沒有回來。

高潮以前是否缺少足夠的累積。

Plottr 把這些原本散落在作者腦中的安排，變成可以移動與比較的劇情結構。

但場景卡上的事件仍然是一項規劃。

它可以寫著「莉莎取得鑰匙」。

卻不能保證正文最後真的讓她取得鑰匙。

大綱的工作，是保存作者準備如何寫。

它不是替尚未完成的正文宣布歷史。

Scrivener 讓長篇正文成為可以操作的作品

Scrivener 面對的是另一種複雜度。

長篇小說不是一份從第一行延伸到最後一行的普通文件。

它由章節、場景、研究資料、人物筆記、刪除片段與不同版本共同構成。

Scrivener 的 Binder 讓作者把作品拆成可以重新排列的文件結構。

Corkboard 和 Outliner 能以卡片或列表觀看章節與場景。

編輯器則讓作者組合多份文件，連續閱讀或撰寫較長的內容。

Snapshots 可以保存修改前的版本。

Compile 負責把內部結構重新組合成出版、投稿或其他輸出格式。

所以 Scrivener 並不只是打字介面。

它本身也具有大綱、研究與長篇結構管理能力。

它讓龐大的作品仍然可以被拆開、重組、比較與輸出。

但是，Scrivener 管理的主要對象仍然是文件。

它知道某一個場景位於第九章。

知道一張索引卡上寫著「莉莎進入檔案庫」。

也能保存角色設定與研究資料。

但它不會因為第六章的偷竊失敗，就自行判定第九章已經缺少取得鑰匙的因果來源。

對文件結構而言，兩個場景都存在。

對世界狀態而言，其中一個場景可能已經無法成立。

從 Plottr 匯出到 Scrivener，是交接，不是持續對帳

Plottr 可以把規劃好的章節、場景與大綱匯出，交給 Scrivener 繼續撰寫。

這是一個合理的工作流程。

作者先讓劇情變得可見，再進入適合處理長篇正文的環境。

但匯出完成後，兩份內容不會因此成為同一套持續同步的故事事實。

作者在 Scrivener 裡修改正文，不會自動改寫 Plottr 裡原本的場景卡。

他回到 Plottr 調整劇情，也不會讓已經寫出的正文自然跟著改變。

兩邊可以互相交接資料。

卻仍然會各自繼續發展。

當修改很小，作者通常能靠記憶維持一致。

刪除一個場景，就回到另一邊刪除相應卡片。

改變事件順序，就手動調整大綱。

但有些改動不只影響一張卡片。

莉莎沒有取得鑰匙，會影響檔案庫能否進入、鑰匙能否轉交、羅文後續是否具備行動條件，也可能改變守衛對她的警戒。

作者要更新的不是一條摘要。

而是一整串因果。

這時候，真正需要同步的已經不是 Plottr 與 Scrivener 的文字。

而是故事因為正文改變後，重新形成的世界狀態。

規劃中的結果，不能提前成為世界歷史

大綱可以寫得非常明確。

角色會去哪裡。

取得什麼物品。

遇見什麼人。

知道什麼祕密。

在哪一章背叛某個陣營。

又在什麼時候失去原本擁有的東西。

這些規劃能幫助作者準備後面的劇情。

但只要正文尚未確認，它們就仍然是預定結果。

角色準備前往王城，不代表他已經抵達。

角色打算偷走鑰匙，不代表鑰匙已經換了持有人。

兩個人預定在下一章見面，不代表他們已經建立關係。

一座城市預定在第三幕毀滅，也不代表更早的章節必須把它視為廢墟。

這條界線很重要。

如果大綱可以直接決定世界狀態，作者在正文裡做出的改變就不會真正算數。

正文可能已經讓一個人活下來，大綱卻仍然把他視為死者。

正文可能已經讓物品留在原處，後面的場景卻繼續使用原定持有人。

正文可能讓角色拒絕加入陣營，世界資料卻仍然把他放進組織結構。

大綱保存的是意圖。

世界歷史保存的是已經被作者確認發生的事件。

這兩者可以互相支持。

卻不能被當成同一件事。

一把沒有被取得的鑰匙，會讓後文失去什麼

回到莉莎的故事。

第六章的實際結果，是偷竊失敗。

那麼故事走到那一刻時，世界至少應該承認幾件事。

鑰匙沒有進入莉莎的物品中。

守衛仍然持有鑰匙。

莉莎仍然缺少原本預定的進入方式。

如果作者決定讓失敗提高警戒，檔案庫的進入條件甚至可能比原本更嚴格。

到了第九章，莉莎仍然可以進入檔案庫。

但她需要另一個成立的原因。

她可以從別處取得鑰匙。

說服內部人員協助。

找到另一個入口。

強行破壞門鎖。

或者利用作者在正文中新建立的條件。

作者不必服從原本的大綱。

但世界不能假裝大綱裡的結果仍然存在。

如果第九章直接寫她拿出那把未曾取得的鑰匙，問題就不是場景卡沒有更新。

問題是物品的歸屬史中缺少一筆能夠支持這個行動的事件。

到了第十二章，問題會更加明顯。

一個從未持有鑰匙的人，不能把它轉交給另一個人。

這不是對劇情好壞的評價。

也不是某個系統認為這樣寫「不自然」。

在目前已確認的事件裡，莉莎擁有的鑰匙數量就是零。

後文卻試圖從零交出一。

這是一個可以明確指出來源的因果斷裂。

InkWeave 不把大綱當成歷史，也不讓正文的改動消失

InkWeave 同樣具有正文、章節，以及角色、地點、物品、陣營與故事條件等資料。

它的差別不在於把另一套大綱介面放進編輯器。

而在於這些內容並不是彼此分離的資料頁。

當作者確認角色移動、物品轉手、地點改變、角色死亡、陣營重組或條件成立，這些事件會進入正文時間流。

世界狀態再由實際發生過的事件推導。

因此，大綱裡可以預定莉莎取得鑰匙。

但只要正文沒有建立相應事件，InkWeave 就不會讓鑰匙提前出現在她身上。

如果作者原本建立了取得事件，後來回到第六章把它刪除或改寫，後面的世界狀態也會重新計算。

第九章依賴鑰匙的進入條件可能不再成立。

第十二章的物品轉交也會缺少足夠數量。

作者確認並保存這次改變後，Project Seer 會重新檢查整條因果，將受影響的後續問題依章節整理出來。

作者可以直接回到相關事件，查看是哪一項條件、狀態或數量與目前世界不一致。

InkWeave 不會把正文改回大綱。

也不會替作者偷偷補上一把鑰匙。

它讓正文的改動真正算數，再把因此失去支撐的後文交還給作者處理。

這不是 AI 比較大綱與正文

看到這類功能，很多人第一個直覺會是 AI。

把大綱與正文交給語言模型。

要求模型理解兩邊的內容。

再判斷角色是不是忘了取得鑰匙，或某段劇情是否與原定計畫矛盾。

AI 可以協助閱讀、摘要與提出疑問。

但那是一種語意判斷。

它可能受到上下文範圍、提示方式、措辭與模型差異影響。

它也很難保證同一組故事資料，每次都得到完全相同的結論。

InkWeave 的 Project Seer 不是 AI 審計。

它使用的是 InkWeave 自行研發的確定性因果律引擎。

引擎不需要猜測「莉莎似乎有沒有拿到鑰匙」。

作者已經透過明確事件告訴世界：物品是否取得、由誰持有、數量如何變化，以及事件發生在什麼位置。

因果律引擎會依照時間順序重播這些已確認事件，計算角色、地點、物品、陣營與故事條件在每一刻的狀態。

相同的事件、相同的順序與相同的規則，會得到相同的結果。

如果莉莎擁有的鑰匙數量是零，後文就不能從她身上轉出一把鑰匙。

如果地點已經毀滅，後文的普通移動就不能假設它仍能正常進入。

如果某項必要旗標從未成立，依賴它的事件就缺少前提。

這裡所說的數學保證，有清楚的範圍。

InkWeave 能保證的是：在作者明確建立的實體、事件與規則之內，數量、集合、順序、狀態轉換與條件比較會被一致地計算和驗證。

它不會保證作者尚未建模的事實。

也不會假裝理解所有文學意義。

AI 提供的是判斷。

InkWeave 的因果律引擎提供的是可以重播、定位與審計的證明。

不是模型覺得哪裡不對。

而是這件事按照目前世界的歷史，確實無法成立。

修改前文時，後面的世界應該立即重新回答

長篇最危險的修改，通常不是改掉眼前的一句話。

而是改掉一個後文已經使用很多次的條件。

作者可能在完成第二十章後，回到第六章修改莉莎取得鑰匙的方式。

也可能讓原本死亡的角色活下來。

讓一座原本安全的橋提早毀滅。

讓某個人物退出陣營。

或讓一件重要物品改由另一個人保管。

這些修改都可能讓後面許多事件失去原本的支撐。

傳統大綱能提醒作者原本如何安排。

文件版本能保存修改以前寫過什麼。

但作者仍然需要自己尋找所有受到影響的地方。

InkWeave 的因果律引擎會在作者確認並保存世界變化後，重新驗證後續事件。

游標停在某個章節時，AVG Stage 與 Inspector 可以呈現故事走到那一刻的世界切片。

角色在哪裡。

物品由誰持有。

地點處於什麼狀態。

陣營結構是否已經改變。

Project Seer 則從整個專案的角度回答另一個問題：

修改以後，後文還成立嗎？

它不只指出最後出錯的句子。

在能夠追蹤來源的情況下，也會保留造成問題的事件位置，讓作者看見錯誤從哪一次取得、移動、死亡、轉交或狀態改變開始形成。

世界不需要等到作者完成全書，再進行一次模糊的整體檢查。

前文一旦改變，後文就應該重新回答自己是否仍然成立。

劇情規劃和正文寫作不必互相競爭

Plottr、Scrivener 與 InkWeave 處理的，不是同一道問題的三種介面。

Plottr 把尚未完成的劇情變成可以觀看與調整的計畫。

Scrivener 把龐大的正文、章節與研究資料變成可以操作和輸出的作品。

InkWeave 則讓正文中已經確認發生的事件，持續改變角色、物品、地點、陣營與後續條件。

這不是說創作者必須在三者之間挑一個唯一正確的答案。

也不是說規劃、大綱或文件管理不重要。

真正需要分清楚的是它們各自在保存什麼。

大綱保存可能的未來。

正文保存作者最後寫出的故事。

因果律保存這些事件發生以後，世界因此變成了什麼。

InkWeave 也不只是放在 Plottr 與 Scrivener 中間，替兩份文件做同步的附加工具。

它本身承載正文、章節與世界實體。

更重要的是，它讓這些內容共同存在於一條可以重播與驗證的故事時間流裡。

作者不只看見自己打算寫什麼。

也能看見自己真正寫下的改變，已經讓後文失去或得到哪些條件。

可以分開的是工作介面，不能分開的是故事真相

劇情規劃和正文寫作可以分開。

作者可以在一個地方觀看整體結構，在另一個地方專心完成句子。

可以先畫出角色線，再讓正文推翻原本的安排。

也可以在故事找到更好的方向後，回頭修改大綱。

創作本來就不是照表執行。

問題不在於工具是否分開。

而在於規劃與正文分歧後，故事真相是否也跟著分成兩套。

大綱說莉莎取得了鑰匙。

正文說她沒有。

那麼後面的世界就必須從「她沒有鑰匙」繼續。

作者可以替她創造新的方法。

可以改寫後續場景。

也可以回頭讓她真的取得鑰匙。

但不能讓尚未發生的規劃，偷偷替正文補上缺失的歷史。

Plottr 讓作者看見準備中的故事。

Scrivener 讓作者完成實際的作品。

InkWeave 讓作品裡真正發生的改變，持續對後文算數。

可以分開的是工作介面。

不能分開的是故事真相。